idnits 2.17.1 draft-ietf-6tisch-architecture-27.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 2584 has weird spacing: '...atteyne for h...' == Line 2588 has weird spacing: '...ajosana who l...' == Line 2592 has weird spacing: '... Pister for c...' == Line 2595 has weird spacing: '...Vucinic for t...' == Line 2598 has weird spacing: '...hardson for h...' == (6 more instances...) -- The document date (October 18, 2019) is 1652 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-13 == Outdated reference: A later version (-21) exists of draft-ietf-6lo-fragment-recovery-05 == Outdated reference: A later version (-15) exists of draft-ietf-6lo-minimal-fragment-04 == Outdated reference: A later version (-14) exists of draft-ietf-6tisch-enrollment-enhanced-beacon-05 == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-12 == Outdated reference: A later version (-18) exists of draft-ietf-6tisch-msf-06 == Outdated reference: A later version (-30) exists of draft-ietf-roll-unaware-leaves-04 == Outdated reference: A later version (-44) exists of draft-ietf-roll-useofrplinfo-31 == Outdated reference: A later version (-18) exists of draft-ietf-ace-coap-est-15 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-28 == Outdated reference: A later version (-24) exists of draft-ietf-anima-constrained-voucher-05 == Outdated reference: A later version (-07) exists of draft-ietf-detnet-ip-01 == 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 (-04) exists of draft-pthubert-raw-problem-statement-03 == Outdated reference: A later version (-05) exists of draft-thubert-raw-technologies-03 -- 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 (~~), 25 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 October 18, 2019 5 Expires: April 20, 2020 7 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4 8 draft-ietf-6tisch-architecture-27 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 April 20, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 2.1. New Terms . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . 16 61 3.4. Scheduling TSCH . . . . . . . . . . . . . . . . . . . . . 17 62 3.5. Distributed vs. Centralized Routing . . . . . . . . . . . 18 63 3.6. Forwarding Over TSCH . . . . . . . . . . . . . . . . . . 19 64 3.7. 6TiSCH Stack . . . . . . . . . . . . . . . . . . . . . . 20 65 3.8. Communication Paradigms and Interaction Models . . . . . 22 66 4. Architecture Components . . . . . . . . . . . . . . . . . . . 23 67 4.1. 6LoWPAN (and RPL) . . . . . . . . . . . . . . . . . . . . 23 68 4.1.1. RPL-Unaware Leaves and 6LoWPAN ND . . . . . . . . . . 23 69 4.1.2. 6LBR and RPL Root . . . . . . . . . . . . . . . . . . 23 70 4.2. Network Access and Addressing . . . . . . . . . . . . . . 24 71 4.2.1. Join Process . . . . . . . . . . . . . . . . . . . . 24 72 4.2.2. Registration . . . . . . . . . . . . . . . . . . . . 26 73 4.3. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . 28 74 4.3.1. 6top . . . . . . . . . . . . . . . . . . . . . . . . 28 75 4.3.2. Scheduling Functions and the 6top protocol . . . . . 29 76 4.3.3. 6top and RPL Objective Function operations . . . . . 31 77 4.3.4. Network Synchronization . . . . . . . . . . . . . . . 31 78 4.3.5. Slotframes and CDU matrix . . . . . . . . . . . . . . 33 79 4.3.6. Distributing the reservation of cells . . . . . . . . 34 80 4.4. Schedule Management Mechanisms . . . . . . . . . . . . . 35 81 4.4.1. Static Scheduling . . . . . . . . . . . . . . . . . . 35 82 4.4.2. Neighbor-to-neighbor Scheduling . . . . . . . . . . . 36 83 4.4.3. Remote Monitoring and Schedule Management . . . . . . 36 84 4.4.4. Hop-by-hop Scheduling . . . . . . . . . . . . . . . . 39 85 4.5. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 39 86 4.5.1. General Behavior of Tracks . . . . . . . . . . . . . 40 87 4.5.2. Serial Track . . . . . . . . . . . . . . . . . . . . 40 88 4.5.3. Complex Track with Replication and Elimination . . . 41 89 4.5.4. DetNet End-to-end Path . . . . . . . . . . . . . . . 41 90 4.5.5. Cell Reuse . . . . . . . . . . . . . . . . . . . . . 42 91 4.6. Forwarding Models . . . . . . . . . . . . . . . . . . . . 43 92 4.6.1. Track Forwarding . . . . . . . . . . . . . . . . . . 43 93 4.6.2. IPv6 Forwarding . . . . . . . . . . . . . . . . . . . 46 94 4.6.3. Fragment Forwarding . . . . . . . . . . . . . . . . . 46 95 4.7. Advanced 6TiSCH Routing . . . . . . . . . . . . . . . . . 48 96 4.7.1. Packet Marking and Handling . . . . . . . . . . . . . 48 97 4.7.2. Replication, Retries and Elimination . . . . . . . . 49 99 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 51 101 6.1. Availability of Remote Services . . . . . . . . . . . . . 51 102 6.2. Selective Jamming . . . . . . . . . . . . . . . . . . . . 52 103 6.3. MAC-Layer Security . . . . . . . . . . . . . . . . . . . 52 104 6.4. Time Synchronization . . . . . . . . . . . . . . . . . . 53 105 6.5. Validating ASN . . . . . . . . . . . . . . . . . . . . . 54 106 6.6. Network Keying and Rekeying . . . . . . . . . . . . . . . 54 107 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 108 7.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 56 109 7.2. Special Thanks . . . . . . . . . . . . . . . . . . . . . 57 110 7.3. And Do not Forget . . . . . . . . . . . . . . . . . . . . 58 111 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 112 8.1. Normative References . . . . . . . . . . . . . . . . . . 58 113 8.2. Informative References . . . . . . . . . . . . . . . . . 62 114 Appendix A. Related Work In Progress . . . . . . . . . . . . . . 68 115 A.1. Unchartered IETF work items . . . . . . . . . . . . . . . 68 116 A.1.1. 6TiSCH Zerotouch security . . . . . . . . . . . . . . 68 117 A.1.2. 6TiSCH Track Setup . . . . . . . . . . . . . . . . . 68 118 A.1.3. Using BIER in a 6TiSCH Network . . . . . . . . . . . 69 119 A.2. External (non-IETF) work items . . . . . . . . . . . . . 69 120 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 70 122 1. Introduction 124 Wireless Networks enable a wide variety of devices of any size to get 125 interconnected, often at a very low marginal cost per device, at any 126 range, and in circumstances where wiring may be impractical, for 127 instance on fast-moving or rotating devices. 129 On the other hand, Deterministic Networking maximizes the packet 130 delivery ratio within a bounded latency so as to enable mission- 131 critical machine-to-machine (M2M) operations. Applications that need 132 such networks are presented in [RFC8578]. The considered 133 applications include Professional Media, Industrial Automation 134 Control Systems (IACS), building automation, in-vehicle command and 135 control, commercial automation and asset tracking with mobile 136 scenarios, as well as gaming, drones and edge robotic control, and 137 home automation applications. 139 The Timeslotted Channel Hopping (TSCH) [RFC7554] mode of the IEEE 140 Std. 802.15.4 [IEEE802154] Medium Access Control (MAC) was introduced 141 with the IEEE Std. 802.15.4e [IEEE802154e] amendment and is now 142 retrofitted in the main standard. For all practical purposes, this 143 document is expected to be insensitive to the revisions of that 144 standard, which is thus referenced without a date. TSCH is both a 145 Time-Division Multiplexing and a Frequency-Division Multiplexing 146 technique whereby a different channel can be used for each 147 transmission, and that allows to schedule transmissions for 148 deterministic operations, and applies to the slower and most energy 149 constrained wireless use cases. 151 The scheduled operation provides for a more reliable experience which 152 can be used to monitor and manage resources, e.g., energy and water, 153 in a more efficient fashion. 155 Proven Deterministic Networking standards for use in Process Control, 156 including ISA100.11a [ISA100.11a] and WirelessHART [WirelessHART], 157 have demonstrated the capabilities of the IEEE Std. 802.15.4 TSCH MAC 158 for high reliability against interference, low-power consumption on 159 well-known flows, and its applicability for Traffic Engineering (TE) 160 from a central controller. 162 To enable the convergence of Information Technology (IT) and 163 Operational Technology (OT) in Low-Power Lossy Networks (LLNs), the 164 6TiSCH Architecture supports an IETF suite of protocols over the IEEE 165 Std. 802.15.4 TSCH MAC to provide IP connectivity for energy and 166 otherwise constrained wireless devices. 168 The 6TiSCH Architecture relies on IPv6 [RFC8200] and the use of 169 routing to provide large scaling capabilities. The addition of a 170 high-speed federating backbone adds yet another degree of scalability 171 to the design. The backbone is typically a Layer-2 transit Link such 172 as an Ethernet bridged network, but it can also be a more complex 173 routed structure. 175 The 6TiSCH Architecture introduces an IPv6 Multi-Link subnet model 176 that is composed of a federating backbone and a number of IEEE Std. 177 802.15.4 TSCH low-power wireless networks federated and synchronized 178 by Backbone Routers. If the backbone is a Layer-2 transit Link then 179 the Backbone Routers can operate as an IPv6 Neighbor Discovery (IPv6 180 ND) [RFC4861] proxy. 182 The 6TiSCH Architecture leverages 6LoWPAN [RFC4944] to adapt IPv6 to 183 the constrained media and RPL [RFC6550] for the distributed routing 184 operations. 186 Centralized routing refers to a model where routes are computed and 187 resources are allocated from a central controller. This is 188 particularly helpful to schedule deterministic multihop 189 transmissions. In contrast, Distributed Routing refers to a model 190 that relies on concurrent peer to peer protocol exchanges for TSCH 191 resource allocation and routing operations. 193 The architecture defines mechanisms to establish and maintain routing 194 and scheduling in a centralized, distributed, or mixed fashion, for 195 use in multiple OT environments. It is applicable in particular to 196 highly scalable solutions such as used in Advanced Metering 197 Infrastructure [AMI] solutions that leverage distributed routing to 198 enable multipath forwarding over large LLN meshes. 200 2. Terminology 202 2.1. New Terms 204 The draft does not reuse terms from the IEEE Std. 802.15.4 205 [IEEE802154] standard such as "path" or "link" which bear a meaning 206 that is quite different from classical IETF parlance. 208 This document adds the following terms: 210 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4): 6TiSCH defines an 211 adaptation sublayer for IPv6 over TSCH called 6top, a set 212 of protocols for setting up a TSCH schedule in 213 distributed approach, and a security solution. 6TiSCH may 214 be extended in the future for other MAC/PHY pairs 215 providing a service similar to TSCH. 217 6top (6TiSCH Operation Sublayer): The next higher layer of the IEEE 218 Std. 802.15.4 TSCH MAC layer. 6top provides the 219 abstraction of an IP link over a TSCH MAC, schedules 220 packets over TSCH cells, and exposes a management 221 interface to schedule TSCH cells. 223 6P (6top Protocol): The protocol defined in [RFC8480]. 6P enables 224 Layer-2 peers to allocate, move or deallocate cells in 225 their respective schedules to communicate. 6P operates 226 at the 6top layer. 228 6P Transaction: A 2-way or 3-way sequence of 6P messages used by 229 Layer-2 peers to modify their communication schedule. 231 ASN (Absolute Slot Number): Defined in [IEEE802154], the ASN is the 232 total number of timeslots that have elapsed since the 233 Epoch Time when the TSCH network started. Incremented by 234 one at each timeslot. It is wide enough to not roll over 235 in practice. 237 bundle: A group of equivalent scheduled cells, i.e., cells 238 identified by different [slotOffset, channelOffset], 239 which are scheduled for a same purpose, with the same 240 neighbor, with the same flags, and the same slotframe. 241 The size of the bundle refers to the number of cells it 242 contains. For a given slotframe length, the size of the 243 bundle translates directly into bandwidth. A bundle is a 244 local abstraction that represents a half-duplex link for 245 either sending or receiving, with bandwidth that amounts 246 to the sum of the cells in the bundle. 248 Layer-2 vs. Layer-3 bundle: Bundles are associated for either 249 Layer-2 (switching) or Layer-3 (routing) forwarding 250 operations. A pair of Layer-3 bundles (one for each 251 direction) maps to an IP Link with a neighbor, whereas a 252 set of Layer-2 bundles (of an "arbitrary" cardinality and 253 direction) corresponds to the relation of one or more 254 incoming bundle(s) from the previous-hop neighbor(s) with 255 one or more outgoing bundle(s) to the next-hop 256 neighbor(s) along a Track as part of the switching role, 257 which may include replication and elimination. 259 CCA (Clear Channel Assessment): A mechanism defined in [IEEE802154] 260 whereby nodes listen to the channel before sending to 261 detect ongoing transmissions from other parties. Because 262 the network is synchronized, CCA cannot be used to detect 263 colliding transmissions within the same network, but it 264 can be used to detect other radio networks in vicinity. 266 cell: A unit of transmission resource in the CDU matrix, a cell 267 is identified by a slotOffset and a channelOffset. A 268 cell can be scheduled or unscheduled. 270 Channel Distribution/Usage (CDU) matrix: : A matrix of cells (i,j) 271 representing the spectrum (channel) distribution among 272 the different nodes in the 6TiSCH network. The CDU 273 matrix has width in timeslots, equal to the period of the 274 network scheduling operation, and height equal to the 275 number of available channels. Every cell (i,j) in the 276 CDU, identified by (slotOffset, channelOffset), belongs 277 to a specific chunk. 279 channelOffset: Identifies a row in the TSCH schedule. The number of 280 channelOffset values is bounded by the number of 281 available frequencies. The channelOffset translates into 282 a frequency with a function that depends on the absolute 283 time when the communication takes place, resulting in a 284 channel hopping operation. 286 chunk: A well-known list of cells, distributed in time and 287 frequency, within a CDU matrix. A chunk represents a 288 portion of a CDU matrix. The partition of the CDU matrix 289 in chunks is globally known by all the nodes in the 290 network to support the appropriation process, which is a 291 negotiation between nodes within an interference domain. 292 A node that manages to appropriate a chunk gets to decide 293 which transmissions will occur over the cells in the 294 chunk within its interference domain, i.e., a parent node 295 will decide when the cells within the appropriated chunk 296 are used and by which node, among its children. 298 CoJP (Constrained Join Protocol): The Constrained Join Protocol 299 (CoJP) enables a pledge to securely join a 6TiSCH network 300 and obtain network parameters over a secure channel. 301 Minimal Security Framework for 6TiSCH 302 [I-D.ietf-6tisch-minimal-security] defines the minimal 303 CoJP setup with pre-shared keys defined. In that mode, 304 CoJP can operate with a single round trip exchange. 306 dedicated cell: A cell that is reserved for a given node to transmit 307 to a specific neighbor. 309 deterministic network: The generic concept of deterministic network 310 is defined in [I-D.ietf-detnet-architecture]. When 311 applied to 6TiSCH, it refers to the reservation of Tracks 312 which guarantees an end-to-end latency and optimizes the 313 Packet Delivery Ratio (PDR) for well-characterized flows. 315 distributed cell reservation: A reservation of a cell done by one or 316 more in-network entities. 318 distributed Track reservation: A reservation of a Track done by one 319 or more in-network entities. 321 EB (Enhanced Beacon): A special frame defined in [IEEE802154] used 322 by a node, including the JP, to announce the presence of 323 the network. It contains enough information for a pledge 324 to synchronize to the network. 326 hard cell: A scheduled cell which the 6top sublayer may not 327 relocate. 329 hopping sequence: Ordered sequence of frequencies, identified by a 330 Hopping_Sequence_ID, used for channel hopping when 331 translating the channelOffset value into a frequency. 333 IE (Information Element): Type-Length-Value containers placed at the 334 end of the MAC header, used to pass data between layers 335 or devices. Some IE identifiers are managed by the IEEE 336 [IEEE802154]. Some IE identifiers are managed by the 337 IETF [RFC8137], and 339 [I-D.ietf-6tisch-enrollment-enhanced-beacon] uses one 340 subtype to support the selection of the Join Proxy. 342 join process: The overall process that includes the discovery of the 343 network by pledge(s) and the execution of the join 344 protocol. 346 join protocol: The protocol that allows the pledge to join the 347 network. The join protocol encompasses authentication, 348 authorization and parameter distribution. The join 349 protocol is executed between the pledge and the JRC. 351 joined node: The new device, after having completed the join 352 process, often just called a node. 354 JP (Join Proxy): Node already part of the 6TiSCH network that serves 355 as a relay to provide connectivity between the pledge and 356 the JRC. The JP announces the presence of the network by 357 regularly sending EB frames. 359 JRC (Join Registrar/Coordinator): Central entity responsible for the 360 authentication, authorization and configuration of the 361 pledge. 363 link: A communication facility or medium over which nodes can 364 communicate at the Link-Layer, the layer immediately 365 below IP. In 6TiSCH, the concept is implemented as a 366 collection of Layer-3 bundles. Note: the IETF parlance 367 for the term "Link" is adopted, as opposed to the IEEE 368 Std. 802.15.4 terminology. 370 Operational Technology: OT refers to technology used in automation, 371 for instance in industrial control networks. The 372 convergence of IT and OT is the main object of the 373 Industrial Internet of Things (IIOT). 375 pledge: A new device that attempts to join a 6TiSCH network. 377 (to) relocate a cell: The action operated by the 6top sublayer of 378 changing the slotOffset and/or channelOffset of a soft 379 cell. 381 (to) schedule a cell: The action of turning an unscheduled cell into 382 a scheduled cell. 384 scheduled cell: A cell which is assigned a neighbor MAC address 385 (broadcast address is also possible), and one or more of 386 the following flags: TX, RX, Shared and Timekeeping. A 387 scheduled cell can be used by the IEEE Std. 802.15.4 TSCH 388 implementation to communicate. A scheduled cell can 389 either be a hard or a soft cell. 391 SF (6top Scheduling Function): The cell management entity that adds 392 or deletes cells dynamically based on application 393 networking requirements. The cell negotiation with a 394 neighbor is done using 6P. 396 SFID (6top Scheduling Function Identifier): A 4-bit field 397 identifying an SF. 399 shared cell: A cell marked with both the "TX" and "shared" flags. 400 This cell can be used by more than one transmitter node. 401 A back-off algorithm is used to resolve contention. 403 slotframe: A collection of timeslots repeating in time, analogous to 404 a superframe in that it defines periods of communication 405 opportunities. It is characterized by a slotframe_ID, 406 and a slotframe_size. Multiple slotframes can coexist in 407 a node's schedule, i.e., a node can have multiple 408 activities scheduled in different slotframes, based on 409 the priority of its packets/traffic flows. The timeslots 410 in the Slotframe are indexed by the SlotOffset; the first 411 timeslot is at SlotOffset 0. 413 slotOffset: A column in the TSCH schedule, i.e., the number of 414 timeslots since the beginning of the current iteration of 415 the slotframe. 417 soft cell: A scheduled cell which the 6top sublayer can relocate. 419 time source neighbor: A neighbor that a node uses as its time 420 reference, and to which it needs to keep its clock 421 synchronized. 423 timeslot: A basic communication unit in TSCH which allows a 424 transmitter node to send a frame to a receiver neighbor, 425 and that receiver neighbor to optionally send back an 426 acknowledgment. 428 Track: A Track is a Directed Acyclic Graph (DAG) that is used as 429 a complex multi-hop path to the destination(s) of the 430 path. In the case of unicast traffic, the Track is a 431 Destination Oriented DAG (DODAG) where the Root of the 432 DODAG is the destination of the unicast traffic. A Track 433 enables replication, elimination and reordering functions 434 on the way (more on those functions in the Deterministic 435 Networking Architecture [I-D.ietf-detnet-architecture]). 436 A Track reservation locks physical resources such as 437 cells and buffers in every node along the DODAG. A Track 438 is associated with a owner that can be for instance the 439 destination of the Track. 441 TrackID: A TrackID is either globally unique, or locally unique to 442 the Track owner, in which case the identification of the 443 owner must be provided together with the TrackID to 444 provide a full reference to the Track. If the Track 445 owner is the destination of the Track then the 446 destination IP address of packets along the Track can be 447 used as identification of the owner and a local 448 InstanceID [RFC6550] can be used as TrackID. In that 449 case, a RPL Packet Information [RFC6550] in an IPv6 450 packet can unambiguously identify the Track and can be 451 expressed in a compressed form using [RFC8138]. 453 TSCH: A medium access mode of the IEEE Std. 802.15.4 454 [IEEE802154] standard which uses time synchronization to 455 achieve ultra-low-power operation, and channel hopping to 456 enable high reliability. 458 TSCH Schedule: A matrix of cells, each cell indexed by a slotOffset 459 and a channelOffset. The TSCH schedule contains all the 460 scheduled cells from all slotframes and is sufficient to 461 qualify the communication in the TSCH network. The 462 number of channelOffset values (the "height" of the 463 matrix) is equal to the number of available frequencies. 465 Unscheduled Cell: A cell which is not used by the IEEE Std. 802.15.4 466 TSCH implementation. 468 2.2. Abbreviations 470 This document uses the following abbreviations: 472 6BBR: 6LoWPAN Backbone Router (router with a proxy ND function) 474 6LBR: 6LoWPAN Border Router (authoritative on DAD) 476 6LN: 6LoWPAN Node 478 6LR: 6LoWPAN Router (relay to the registration process) 480 6CIO: Capability Indication Option 482 (E)ARO: (Extended) Address Registration Option 483 (E)DAR: (Extended) Duplicate Address Request 485 (E)DAC: (Extended) Duplicate Address Confirmation 487 DAD: Duplicate Address Detection 489 DODAG: Destination-Oriented Directed Acyclic Graph 491 LLN: Low-Power and Lossy Network (a typical IoT network) 493 NA: Neighbor Advertisement 495 NCE: Neighbor Cache Entry 497 ND: Neighbor Discovery 499 NDP: Neighbor Discovery Protocol 501 PCE: Path Computation Element 503 NME: Network Management Entity 505 ROVR: Registration Ownership Verifier (pronounced rover) 507 RPL: IPv6 Routing Protocol for LLNs (pronounced ripple) 509 RA: Router Advertisement 511 RS: Router Solicitation 513 TSCH: timeslotted Channel Hopping 515 TID: Transaction ID (a sequence counter in the EARO) 517 2.3. Related Documents 519 The draft also conforms to the terms and models described in 520 [RFC3444] and [RFC5889] and uses the vocabulary and the concepts 521 defined in [RFC4291] for the IPv6 Architecture and refers [RFC4080] 522 for reservation 524 The draft uses domain-specific terminology defined or referenced in: 526 6LoWPAN ND "Neighbor Discovery Optimization for Low-power and 527 Lossy Networks" [RFC6775] and "Registration Extensions for 6LoWPAN 528 Neighbor Discovery" [RFC8505], 529 "Terms Used in Routing for Low-Power and Lossy Networks (LLNs)" 530 [RFC7102], 532 and RPL "Objective Function Zero for the Routing Protocol for Low- 533 Power and Lossy Networks (RPL)" [RFC6552], and "RPL: IPv6 Routing 534 Protocol for Low-Power and Lossy Networks" [RFC6550]. 536 Other terms in use in LLNs are found in "Terminology for Constrained- 537 Node Networks" [RFC7228]. 539 Readers are expected to be familiar with all the terms and concepts 540 that are discussed in 542 o "Neighbor Discovery for IP version 6" [RFC4861], and "IPv6 543 Stateless Address Autoconfiguration" [RFC4862]. 545 In addition, readers would benefit from reading: 547 o "Problem Statement and Requirements for IPv6 over Low-Power 548 Wireless Personal Area Network (6LoWPAN) Routing" [RFC6606], 550 o "Multi-Link Subnet Issues" [RFC4903], and 552 o "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 553 Overview, Assumptions, Problem Statement, and Goals" [RFC4919] 555 prior to this specification for a clear understanding of the art in 556 ND-proxying and binding. 558 3. High Level Architecture 560 3.1. A Non-Broadcast Multi-Access Radio Mesh Network 562 A 6TiSCH network is an IPv6 [RFC8200] subnet which, in its basic 563 configuration illustrated in Figure 1, is a single Low-Power Lossy 564 Network (LLN) operating over a synchronized TSCH-based mesh. 566 ---+-------- ............ ------------ 567 | External Network | 568 | +-----+ 569 +-----+ | NME | 570 | | LLN Border | PCE | 571 | | router (6LBR) +-----+ 572 +-----+ 573 o o o 574 o o o o o 575 o o 6LoWPAN + RPL o o 576 o o o o 578 Figure 1: Basic Configuration of a 6TiSCH Network 580 Inside a 6TiSCH LLN, nodes rely on 6LoWPAN Header Compression 581 (6LoWPAN HC) [RFC6282] to encode IPv6 packets. From the perspective 582 of the network layer, a single LLN interface (typically an IEEE Std. 583 802.15.4-compliant radio) may be seen as a collection of Links with 584 different capabilities for unicast or multicast services. 586 6TiSCH nodes join a mesh network by attaching to nodes that are 587 already members of the mesh (see Section 4.2.1). The security 588 aspects of the join process are further detailed in Section 6. In a 589 mesh network, 6TiSCH nodes are not necessarily reachable from one 590 another at Layer-2 and an LLN may span over multiple links. 592 This forms a homogeneous non-broadcast multi-access (NBMA) subnet, 593 which is beyond the scope of IPv6 Neighbor Discovery (IPv6 ND) 594 [RFC4861][RFC4862]. 6LoWPAN Neighbor Discovery (6LoWPAN ND) 595 [RFC6775][RFC8505] specifies extensions to IPv6 ND that enable ND 596 operations in this type of subnet that can be protected against 597 address theft and impersonation with [I-D.ietf-6lo-ap-nd]. 599 Once it has joined the 6TiSCH network, a node acquires IPv6 Addresses 600 and register them using 6LoWPAN ND. This guarantees that the 601 addresses are unique and protects the address ownership over the 602 subnet, more in Section 4.2.2. 604 Within the NBMA subnet, RPL [RFC6550] enables routing in the so- 605 called Route Over fashion, either in storing (stateful) or non- 606 storing (stateless, with routing headers) mode. From there, some 607 nodes can act as routers for 6LoWPAN ND and RPL operations, as 608 detailed in Section 4.1. 610 With TSCH, devices are time-synchronized at the MAC level. The use 611 of a particular RPL Instance for time synchronization is discussed in 612 Section 4.3.4. With this mechanism, the time synchronization starts 613 at the RPL Root and follows the RPL loopless routing topology. 615 RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) 616 within Instances of the protocol, each Instance being associated with 617 an Objective Function (OF) to form a routing topology. A particular 618 6TiSCH node, the LLN Border Router (6LBR), acts as RPL Root, 6LoWPAN 619 HC terminator, and Border Router for the LLN to the outside. The 620 6LBR is usually powered. More on RPL Instances can be found in 621 section 3.1 of RPL [RFC6550], in particular "3.1.2. RPL Identifiers" 622 and "3.1.3. Instances, DODAGs, and DODAG Versions". RPL adds 623 artifacts in the data packets that are compressed with a 6LoWPAN 624 addition 6LoRH [RFC8138]. 626 Additional routing and scheduling protocols may be deployed to 627 establish on-demand Peer-to-Peer routes with particular 628 characteristics inside the 6TiSCH network. This may be achieved in a 629 centralized fashion by a Path Computation Element (PCE) [PCE] that 630 programs both the routes and the schedules inside the 6TiSCH nodes, 631 or by in a distributed fashion using a reactive routing protocol and 632 a Hop-by-Hop scheduling protocol. 634 This architecture expects that a 6LoWPAN node can connect as a leaf 635 to a RPL network, where the leaf support is the minimal functionality 636 to connect as a host to a RPL network without the need to participate 637 to the full routing protocol. The architecture also expects that a 638 6LoWPAN node that is not aware at all of the RPL protocol may also 639 connect as described in [I-D.ietf-roll-unaware-leaves]. 641 3.2. A Multi-Link Subnet Model 643 An extended configuration of the subnet comprises multiple LLNs as 644 illustrated in Figure 2. In the extended configuration, a Routing 645 Registrar [RFC8505] may be connected to the node that acts as RPL 646 Root and / or 6LoWPAN 6LBR and provides connectivity to the larger 647 campus / factory plant network over a high-speed backbone or a back- 648 haul link. The Routing registrar may perform IPv6 ND proxy 649 operations, or redistribute the registration in a routing protocol 650 such as OSPF [RFC5340] or BGP [RFC2545], or inject a route in a 651 mobility protocol such as MIPv6 [RFC6275], NEMO [RFC3963], or LISP 652 [RFC6830]. 654 Multiple LLNs can be interconnected and possibly synchronized over a 655 backbone, which can be wired or wireless. The backbone can operate 656 with IPv6 ND [RFC4861][RFC4862] procedures or an hybrid of IPv6 ND 657 and 6LoWPAN ND [RFC6775][RFC8505][I-D.ietf-6lo-ap-nd]. 659 | 660 +-----+ +-----+ +-----+ 661 (default) | | (Optional) | | | | IPv6 662 Router | | 6LBR | | | | Node 663 +-----+ +-----+ +-----+ 664 | Backbone side | | 665 --------+---+--------------------+-+---------------+------+--- 666 | | | 667 +-----------+ +-----------+ +-----------+ 668 | Routing | | Routing | | Routing | 669 | Registrar | | Registrar | | Registrar | 670 +-----------+ +-----------+ +-----------+ 671 o Wireless side o o o o 672 o o o o o o o o o o o o o o 673 o 6TiSCH o 6TiSCH o o o o 6TiSCH o 674 o o LLN o o o o LLN o o LLN o 675 o o o o o o o o o o o o o o 677 Figure 2: Extended Configuration of a 6TiSCH Network 679 A Routing Registrar that performs proxy IPv6 ND operations over the 680 backbone on behalf of the 6TiSCH nodes is called a Backbone Router 681 (6BBR) [I-D.ietf-6lo-backbone-router]. The 6BBRs are placed along 682 the wireless edge of a Backbone, and federate multiple wireless links 683 to form a single MultiLink Subnet. The 6BBRs synchronize with one 684 another over the backbone, so as to ensure that the multiple LLNs 685 that form the IPv6 subnet stay tightly synchronized. 687 The use of multicast can also be reduced on the backbone with a 688 registrar that would contribute to Duplicate Address Detection as 689 well as Address Lookup using only unicast request/response exchanges. 690 [I-D.thubert-6man-unicast-lookup] is a proposed method that presents 691 an example of how to this could be achieved with an extension of 692 [RFC8505], using an optional 6LBR as a SubNet-level registrar, as 693 illustrated in Figure 2. 695 As detailed in Section 4.1 the 6LBR that serves the LLN and the Root 696 of the RPL network need to share information about the devices that 697 are learned through either 6LoWPAN ND or RPL but not both. The 698 preferred way of achieving this is to collocate/combine them. The 699 combined RPL Root and 6LBR may be collocated with the 6BBR, or 700 directly attached to the 6BBR. In the latter case, it leverages the 701 extended registration process defined in [RFC8505] to proxy the 702 6LoWPAN ND registration to the 6BBR on behalf of the LLN nodes, so 703 that the 6BBR may in turn perform proxy classical ND operations over 704 the backbone. 706 The DetNet Architecture [I-D.ietf-detnet-architecture] studies 707 Layer-3 aspects of Deterministic Networks, and covers networks that 708 span multiple Layer-2 domains. If the Backbone is Deterministic 709 (such as defined by the Time Sensitive Networking WG at IEEE), then 710 the Backbone Router ensures that the end-to-end deterministic 711 behavior is maintained between the LLN and the backbone. 713 3.3. TSCH: A Deterministic MAC Layer 715 Though at a different time scale (several orders of magnitude), both 716 IEEE Std. 802.1TSN and IEEE Std. 802.15.4 TSCH standards provide 717 Deterministic capabilities to the point that a packet that pertains 718 to a certain flow may traverse a network from node to node following 719 a precise schedule, as a train that enters and then leaves 720 intermediate stations at precise times along its path. 722 With TSCH, time is formatted into timeslots, and individual 723 communication cells are allocated to unicast or broadcast 724 communication at the MAC level. The time-slotted operation reduces 725 collisions, saves energy, and enables to more closely engineer the 726 network for deterministic properties. The channel hopping aspect is 727 a simple and efficient technique to combat multipath fading and co- 728 channel interference. 730 6TiSCH builds on the IEEE Std. 802.15.4 TSCH MAC and inherits its 731 advanced capabilities to enable them in multiple environments where 732 they can be leveraged to improve automated operations. The 6TiSCH 733 Architecture also inherits the capability to perform a centralized 734 route computation to achieve deterministic properties, though it 735 relies on the IETF DetNet Architecture 736 [I-D.ietf-detnet-architecture], and IETF components such as the PCE 737 [PCE], for the protocol aspects. 739 On top of this inheritance, 6TiSCH adds capabilities for distributed 740 routing and scheduling operations based on the RPL routing protocol 741 and capabilities to negotiate schedule adjustments between peers. 742 These distributed routing and scheduling operations simplify the 743 deployment of TSCH networks and enable wireless solutions in a larger 744 variety of use cases from operational technology in general. 745 Examples of such use-cases in industrial environments include plant 746 setup and decommissioning, as well as monitoring of lots of lesser 747 importance measurements such as corrosion and events and mobile 748 workers accessing local devices. 750 3.4. Scheduling TSCH 752 A scheduling operation attributes cells in a Time-Division- 753 Multiplexing (TDM) / Frequency-Division Multiplexing (FDM) matrix 754 called the Channel distribution/usage (CDU) to either individual 755 transmissions or as multi-access shared resources. The CDU matrix 756 can be formatted in chunks that can be allocated exclusively to 757 particular nodes to enable distributed scheduling without collision. 758 More in Section 4.3.5. 760 From the standpoint of a 6TiSCH node (at the MAC layer), its schedule 761 is the collection of the timeslots at which it must wake up for 762 transmission, and the channels to which it should either send or 763 listen at those times. The schedule is expressed as one or more 764 slotframes that repeat over and over. Slotframes may collide and 765 require a device to wake up at a same time, in which case the 766 slotframe with the highest priority is actionable. 768 The 6top sublayer (see Section 4.3 for more) hides the complexity of 769 the schedule from the upper layers. The Link abstraction that IP 770 traffic utilizes is composed of a pair of Layer-3 cell bundles, one 771 to receive and one to transmit. Some of the cells may be shared, in 772 which case the 6top sublayer must perform some arbitration. 774 Scheduling enables multiple communications at a same time in a same 775 interference domain using different channels; but a node equipped 776 with a single radio can only either transmit or receive on one 777 channel at any point of time. Scheduled cells that fulfil the same 778 role, e.g., receive IP packets from a peer, are grouped in bundles. 780 The 6TiSCH architecture identifies four ways a schedule can be 781 managed and CDU cells can be allocated: Static Scheduling, Neighbor- 782 to-Neighbor Scheduling, Centralized (or Remote) Monitoring and 783 Schedule Management, and Hop-by-hop Scheduling. 785 Static Scheduling: This refers to the minimal 6TiSCH operation 786 whereby a static schedule is configured for the whole network for 787 use in a Slotted ALOHA [S-ALOHA] fashion. The static schedule is 788 distributed through the native methods in the TSCH MAC layer and 789 does not preclude other scheduling operations to co-exist on a 790 same 6TiSCH network. A static schedule is necessary for basic 791 operations such as the join process and for interoperability 792 during the network formation, which is specified as part of the 793 Minimal 6TiSCH Configuration [RFC8180]. 795 Neighbor-to-Neighbor Scheduling: This refers to the dynamic 796 adaptation of the bandwidth of the Links that are used for IPv6 797 traffic between adjacent peers. Scheduling Functions such as the 798 "6TiSCH Minimal Scheduling Function (MSF)" [I-D.ietf-6tisch-msf] 799 influence the operation of the MAC layer to add, update and remove 800 cells in its own, and its peer's schedules using 6P [RFC8480], for 801 the negotiation of the MAC resources. 803 Centralized (or Remote) Monitoring and Schedule Management: This 804 refers to the central computation of a schedule and the capability 805 to forward a frame based on the cell of arrival. In that case, 806 the related portion of the device schedule as well as other device 807 resources are managed by an abstract Network Management Entity 808 (NME), which may cooperate with the PCE to minimize the 809 interaction with and the load on the constrained device. This 810 model is the TSCH adaption of the "DetNet Architecture" 811 [I-D.ietf-detnet-architecture], and it enables Traffic Engineering 812 with deterministic properties. 814 Hop-by-hop Scheduling: This refers to the possibility to reserves 815 cells along a path for a particular flow using a distributed 816 mechanism. 818 It is not expected that all use cases will require all those 819 mechanisms. Static Scheduling with minimal configuration one is the 820 only one that is expected in all implementations, since it provides a 821 simple and solid basis for convergecast routing and time 822 distribution. 824 A deeper dive in those mechanisms can be found in Section 4.4. 826 3.5. Distributed vs. Centralized Routing 828 6TiSCH enables a mixed model of centralized routes and distributed 829 routes. Centralized routes can for example be computed by an entity 830 such as a PCE. 6TiSCH leverages the RPL [RFC6550] routing protocol 831 for interoperable distributed routing operations. 833 Both methods may inject routes in the Routing Tables of the 6TiSCH 834 routers. In either case, each route is associated with a 6TiSCH 835 topology that can be a RPL Instance topology or a Track. The 6TiSCH 836 topology is indexed by a RPLInstanceID, in a format that reuses the 837 RPLInstanceID as defined in RPL. 839 RPL [RFC6550] is applicable to Static Scheduling and Neighbor-to- 840 Neighbor Scheduling. The architecture also supports a centralized 841 routing model for Remote Monitoring and Schedule Management. It is 842 expected that a routing protocol that is more optimized for point-to- 843 point routing than RPL [RFC6550], such as the Asymmetric AODV-P2P-RPL 844 in Low-Power and Lossy Networks" [I-D.ietf-roll-aodv-rpl] AODV-RPL), 845 which derives from the Ad Hoc On-demand Distance Vector Routing 846 (AODV) [I-D.ietf-manet-aodvv2] will be selected for Hop-by-hop 847 Scheduling. 849 Both RPL and PCE rely on shared sources such as policies to define 850 Global and Local RPLInstanceIDs that can be used by either method. 851 It is possible for centralized and distributed routing to share a 852 same topology. Generally they will operate in different slotframes, 853 and centralized routes will be used for scheduled traffic and will 854 have precedence over distributed routes in case of conflict between 855 the slotframes. 857 3.6. Forwarding Over TSCH 859 The 6TiSCH architecture supports three different forwarding models. 860 One is the classical IPv6 Forwarding, where the node selects a 861 feasible successor at Layer-3 on a per packet basis and based on its 862 routing table. The second derives from Generic MPLS (G-MPLS) for so- 863 called Track Forwarding, whereby a frame received at a particular 864 timeslot can be switched into another timeslot at Layer-2 without 865 regard to the upper layer protocol. The third model is the 6LoWPAN 866 Fragment Forwarding, which allows to forward individual 6loWPAN 867 fragments along a route that is setup by the first fragment. 869 In more details: 871 IPv6 Forwarding: This is the classical IP forwarding model, with a 872 Routing Information Based (RIB) that is installed by the RPL 873 routing protocol and used to select a feasible successor per 874 packet. The packet is placed on an outgoing Link, that the 6top 875 layer maps into a (Layer-3) bundle of cells, and scheduled for 876 transmission based on QoS parameters. Besides RPL, this model 877 also applies to any routing protocol which may be operated in the 878 6TiSCH network, and corresponds to all the distributed scheduling 879 models, Static, Neighbor-to-Neighbor and Hop-by-Hop Scheduling. 881 G-MPLS Track Forwarding: This model corresponds to the Remote 882 Monitoring and Schedule Management. In this model, a central 883 controller (hosting a PCE) computes and installs the schedules in 884 the devices per flow. The incoming (Layer-2) bundle of cells from 885 the previous node along the path determines the outgoing (Layer-2) 886 bundle towards the next hop for that flow as determined by the 887 PCE. The programmed sequence for bundles is called a Track and 888 can assume DAG shapes that are more complex than a simple direct 889 sequence of nodes. 891 6LoWPAN Fragment Forwarding: This is a hybrid model that derives 892 from IPv6 forwarding for the case where packets must be fragmented 893 at the 6LoWPAN sublayer. The first fragment is forwarded like any 894 IPv6 packet and leaves a state in the intermediate hops to enable 895 forwarding of the next fragments that do not have a IP header 896 without the need to recompose the packet at every hop. 898 A deeper dive on these operations can be found in Section 4.6. 900 The following table summarizes how the forwarding models apply to the 901 various routing and scheduling possibilities: 903 +-------------------+------------+----------------------------------+ 904 | Forwarding Model | Routing | Scheduling | 905 +===================+============+==================================+ 906 | | | Static (Minimal Configuration) | 907 + classical IPv6 + RPL +----------------------------------+ 908 | / | | Neighbor-to-Neighbor (SF+6P) | 909 + 6LoWPAN Fragment +------------+----------------------------------+ 910 | | Reactive | Hop-by-Hop (AODV-RPL) | 911 +-------------------+------------+----------------------------------+ 912 |G-MPLS Track Fwding| PCE |Remote Monitoring and Schedule Mgt| 913 +-------------------+------------+----------------------------------+ 915 3.7. 6TiSCH Stack 917 The IETF proposes multiple techniques for implementing functions 918 related to routing, transport or security. 920 The 6TiSCH architecture limits the possible variations of the stack 921 and recommends a number of base elements for LLN applications to 922 control the complexity of possible deployments and device 923 interactions, and to limit the size of the resulting object code. In 924 particular, UDP [RFC0768], IPv6 [RFC8200] and the Constrained 925 Application Protocol [RFC7252] (CoAP) are used as the transport / 926 binding of choice for applications and management as opposed to TCP 927 and HTTP. 929 The resulting protocol stack is represented in Figure 4: 931 +--------+--------+ 932 | Applis | CoJP | 933 +--------+--------+--------------+-----+ 934 | CoAP / OSCORE | 6LoWPAN ND | RPL | 935 +-----------------+--------------+-----+ 936 | UDP | ICMPv6 | 937 +-----------------+--------------------+ 938 | IPv6 | 939 +--------------------------------------+----------------------+ 940 | 6LoWPAN HC / 6LoRH HC | Scheduling Functions | 941 +--------------------------------------+----------------------+ 942 | 6top inc. 6top protocol | 943 +-------------------------------------------------------------+ 944 | IEEE Std. 802.15.4 TSCH | 945 +-------------------------------------------------------------+ 947 Figure 4: 6TiSCH Protocol Stack 949 RPL is the routing protocol of choice for LLNs. So far, there was no 950 identified need to define a 6TiSCH specific Objective Function. The 951 Minimal 6TiSCH Configuration [RFC8180] describes the operation of RPL 952 over a static schedule used in a Slotted ALOHA fashion [S-ALOHA], 953 whereby all active slots may be used for emission or reception of 954 both unicast and multicast frames. 956 The 6LoWPAN Header Compression [RFC6282] is used to compress the IPv6 957 and UDP headers, whereas the 6LoWPAN Routing Header (6LoRH) [RFC8138] 958 is used to compress the RPL artifacts in the IPv6 data packets, 959 including the RPL Packet Information (RPI), the IP-in-IP 960 encapsulation to/from the RPL Root, and the Source Route Header (SRH) 961 in non-storing mode. "When to use RFC 6553, 6554 and IPv6-in-IPv6" 962 [I-D.ietf-roll-useofrplinfo] provides the details on when headers or 963 encapsulation are needed. 965 The Object Security for Constrained RESTful Environments (OSCORE) 966 [I-D.ietf-core-object-security], is leveraged by the Constrained Join 967 Protocol (CoJP) and is expected to be the primary protocol for the 968 protection of the application payload as well. The application 969 payload may also be protected by the Datagram Transport Layer 970 Security (DTLS) [RFC6347] sitting either under CoAP or over CoAP so 971 it can traverse proxies. 973 The 6TiSCH Operation sublayer (6top) is a sublayer of a Logical Link 974 Control (LLC) that provides the abstraction of an IP link over a TSCH 975 MAC and schedules packets over TSCH cells, as further discussed in 976 the next sections, providing in particular dynamic cell allocation 977 with the 6top Protocol (6P) [RFC8480]. 979 The reference stack presented in this document was implemented and 980 interop-tested by a conjunction of opensource, IETF and ETSI efforts. 981 One goal is to help other bodies to adopt the stack as a whole, 982 making the effort to move to an IPv6-based IoT stack easier. 984 For a particular environment, some of the choices that are made in 985 this architecture may not be relevant. For instance, RPL is not 986 required for star topologies and mesh-under Layer-2 routed networks, 987 and the 6LoWPAN compression may not be sufficient for ultra- 988 constrained cases such as some Low-Power Wide Area (LPWA) networks. 989 In such cases, it is perfectly doable to adopt a subset of the 990 selection that is presented hereafter and then select alternate 991 components to complete the solution wherever needed. 993 3.8. Communication Paradigms and Interaction Models 995 Section 2.1 provides the terms of Communication Paradigms and 996 Interaction Models, in relation with "On the Difference between 997 Information Models and Data Models" [RFC3444]. A Communication 998 Paradigm would be an abstract view of a protocol exchange, and would 999 come with an Information Model for the information that is being 1000 exchanged. In contrast, an Interaction Model would be more refined 1001 and could point to standard operation such as a Representational 1002 state transfer (REST) "GET" operation and would match a Data Model 1003 for the data that is provided over the protocol exchange. 1005 Section 2.1.3 of [I-D.ietf-roll-rpl-industrial-applicability] and 1006 next sections discuss application-layer paradigms, such as Source- 1007 sink (SS) that is a Multipeer to Multipeer (MP2MP) model primarily 1008 used for alarms and alerts, Publish-subscribe (PS, or pub/sub) that 1009 is typically used for sensor data, as well as Peer-to-peer (P2P) and 1010 Peer-to-multipeer (P2MP) communications. 1012 Additional considerations on Duocast - one sender, two receivers for 1013 redundancy - and its N-cast generalization are also provided. Those 1014 paradigms are frequently used in industrial automation, which is a 1015 major use case for IEEE Std. 802.15.4 TSCH wireless networks with 1016 [ISA100.11a] and [WirelessHART], that provides a wireless access to 1017 [HART] applications and devices. 1019 This document focuses on Communication Paradigms and Interaction 1020 Models for packet forwarding and TSCH resources (cells) management. 1021 Management mechanisms for the TSCH schedule at Link-Layer (one-hop), 1022 Network-layer (multihop along a Track), and Application-layer (remote 1023 control) are discussed in Section 4.4. Link-Layer frame forwarding 1024 interactions are discussed in Section 4.6, and Network-layer Packet 1025 routing is addressed in Section 4.7. 1027 4. Architecture Components 1029 4.1. 6LoWPAN (and RPL) 1031 A RPL DODAG is formed of a Root, a collection of routers, and leaves 1032 that are hosts. Hosts are nodes which do not forward packets that 1033 they did not generate. RPL-aware leaves will participate to RPL to 1034 advertise their own addresses, whereas RPL-unaware leaves depend on a 1035 connected RPL router to do so. RPL interacts with 6LoWPAN ND at 1036 multiple levels, in particular at the Root and in the RPL-unaware 1037 leaves. 1039 4.1.1. RPL-Unaware Leaves and 6LoWPAN ND 1041 RPL needs a set of information to advertise a leaf node through a 1042 Destination Advertisement Object (DAO) message and establish 1043 reachability. 1045 "Routing for RPL Leaves" [I-D.ietf-roll-unaware-leaves] details the 1046 basic interaction of 6LoWPAN ND and RPL and enables a plain 6LN that 1047 supports [RFC8505] to obtain return connectivity via the RPL network 1048 as an RPL-unaware leaf. The leaf indicates that it requires 1049 reachability services for the Registered Address from a Routing 1050 Registrar by setting a 'R' flag in the Extended Address Registration 1051 Option [RFC8505], and it provides a TID that maps to a sequence 1052 number in section 7 of RPL [RFC6550]. 1054 [I-D.ietf-roll-unaware-leaves] also enables the leaf to signal the 1055 RPL InstanceID that it wants to participate to using the Opaque field 1056 of the EARO. On the backbone, the InstanceID is expected to be 1057 mapped to an overlay that matches the RPL Instance, e.g., a Virtual 1058 LAN (VLAN) or a virtual routing and forwarding (VRF) instance. 1060 Though at the time of this writing the above specification enables a 1061 model where the separation is possible, this architecture recommends 1062 to collocate the functions of 6LBR and RPL Root. 1064 4.1.2. 6LBR and RPL Root 1066 With the 6LowPAN ND [RFC6775], information on the 6LBR is 1067 disseminated via an Authoritative Border Router Option (ABRO) in RA 1068 messages. [RFC8505] extends [RFC6775] to enable a registration for 1069 routing and proxy ND. The capability to support [RFC8505] is 1070 indicated in the 6LoWPAN Capability Indication Option (6CIO). The 1071 discovery and liveliness of the RPL Root are obtained through RPL 1072 [RFC6550] itself. 1074 When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL Root 1075 functionalities are co-located in order that the address of the 6LBR 1076 be indicated by RPL DIO messages and to associate the unique ID from 1077 the EDAR/EDAC [RFC8505] exchange with the state that is maintained by 1078 RPL. 1080 Section 7 of [I-D.ietf-roll-unaware-leaves] specifies how the DAO 1081 messages are used to reconfirm the registration, thus eliminating a 1082 duplication of functionality between DAO and EDAR/EDAC messages, as 1083 illustrated in Figure 7. [I-D.ietf-roll-unaware-leaves] also 1084 provides the protocol elements that are needed when the 6LBR and RPL 1085 Root functionalities are not co-located. 1087 Even though the Root of the RPL network is integrated with the 6LBR, 1088 it is logically separated from the Backbone Router (6BBR) that is 1089 used to connect the 6TiSCH LLN to the backbone. This way, the Root 1090 has all information from 6LoWPAN ND and RPL about the LLN devices 1091 attached to it. 1093 This architecture also expects that the Root of the RPL network 1094 (proxy-)registers the 6TiSCH nodes on their behalf to the 6BBR, for 1095 whatever operation the 6BBR performs on the backbone, such as ND 1096 proxy, or redistribution in a routing protocol. This relies on an 1097 extension of the 6LoWPAN ND registration described in 1098 [I-D.ietf-6lo-backbone-router]. 1100 This model supports the movement of a 6TiSCH device across the Multi- 1101 Link Subnet, and allows the proxy registration of 6TiSCH nodes deep 1102 into the 6TiSCH LLN by the 6LBR / RPL Root. This is why in [RFC8505] 1103 the Registered Address is signaled in the Target Address field of the 1104 NS message as opposed to the IPv6 Source Address, which, in the case 1105 of a proxy registration, is that of the 6LBR / RPL Root itself. 1107 4.2. Network Access and Addressing 1109 4.2.1. Join Process 1111 A new device, called the pledge, undergoes the join protocol to 1112 become a node in a 6TiSCH network. This usually occurs only once 1113 when the device is first powered on. The pledge communicates with 1114 the Join Registrar/Coordinator (JRC) of the network through a Join 1115 Proxy (JP), a radio neighbor of the pledge. 1117 The JP is discovered though MAC layer beacons. When multiple JPs 1118 from possibly multiple networks are visible, trial and error till an 1119 acceptable position in the right network is obtained becomes 1120 ineffficient. [I-D.ietf-6tisch-enrollment-enhanced-beacon] adds a 1121 new subtype in the Information Element that was delegated to the IETF 1123 [RFC8137] and provides visibility on the network that can be joined 1124 and the willingness by the JP and the Root to be used by the pledge. 1126 The join protocol provides the following functionality: 1128 o Mutual authentication 1130 o Authorization 1132 o Parameter distribution to the pledge over a secure channel 1134 Minimal Security Framework for 6TiSCH 1135 [I-D.ietf-6tisch-minimal-security] defines the minimal mechanisms 1136 required for this join process to occur in a secure manner. The 1137 specification defines the Constrained Join Protocol (CoJP) that is 1138 used to distribute the parameters to the pledge over a secure session 1139 established through OSCORE [I-D.ietf-core-object-security], and a 1140 secure configuration of the network stack. In the minimal setting 1141 with pre-shared keys (PSKs), CoJP allows the pledge to join after a 1142 single round-trip exchange with the JRC. The provisioning of the PSK 1143 to the pledge and the JRC needs to be done out of band, through a 1144 'one-touch' bootstrapping process, which effectively enrolls the 1145 pledge into the domain managed by the JRC. 1147 In certain use cases, the 'one touch' bootstrapping is not feasible 1148 due to the operational constraints and the enrollment of the pledge 1149 into the domain needs to occur in-band. This is handled through a 1150 'zero-touch' extension of the Minimal Security Framework for 6TiSCH. 1151 Zero touch [I-D.ietf-6tisch-dtsecurity-zerotouch-join] extension 1152 leverages the 'Bootstrapping Remote Secure Key Infrastructures 1153 (BRSKI)' [[I-D.ietf-anima-bootstrapping-keyinfra] work to establish a 1154 shared secret between a pledge and the JRC without necessarily having 1155 them belong to a common (security) domain at join time. This happens 1156 through inter-domain communication occurring between the JRC of the 1157 network and the domain of the pledge, represented by a fourth entity, 1158 Manufacturer Authorized Signing Authority (MASA). Once the zero- 1159 touch exchange completes, the CoJP exchange defined in 1160 [I-D.ietf-6tisch-minimal-security] is carried over the secure session 1161 established between the pledge and the JRC. 1163 Figure 5 depicts the join process and where a Link-Local Address 1164 (LLA) is used, versus a Global Unicast Address (GUA). 1166 6LoWPAN Node 6LR 6LBR Join Registrar MASA 1167 (pledge) (Join Proxy) (Root) /Coordinator (JRC) 1168 | | | | | 1169 | 6LoWPAN ND |6LoWPAN ND+RPL | IPv6 network |IPv6 network | 1170 | LLN link |Route-Over mesh|(the Internet)|(the Internet)| 1171 | | | | | 1172 | Layer-2 | | | | 1173 |enhanced beacon| | | | 1174 |<--------------| | | | 1175 | | | | | 1176 | NS (EARO) | | | | 1177 | (for the LLA) | | | | 1178 |-------------->| | | | 1179 | NA (EARO) | | | | 1180 |<--------------| | | | 1181 | | | | | 1182 | (Zero-touch | | | | 1183 | handshake) | (Zero-touch handshake) | (Zero-touch | 1184 | using LLA | using GUA | handshake) | 1185 |<------------->|<---------------------------->|<------------>| 1186 | | | | | 1187 | CoJP Join Req | | | | \ 1188 | using LLA | | | | | 1189 |-------------->| | | | | 1190 | | CoJP Join Request | | | 1191 | | using GUA | | | 1192 | |----------------------------->| | | C 1193 | | | | | | o 1194 | | CoJP Join Response | | | J 1195 | | using GUA | | | P 1196 | |<-----------------------------| | | 1197 |CoJP Join Resp | | | | | 1198 | using LLA | | | | | 1199 |<--------------| | | | / 1200 | | | | | 1202 Figure 5: Join process in a Multi-Link Subnet. Parentheses () denote 1203 optional exchanges. 1205 4.2.2. Registration 1207 Once the pledge successfully completes the CoJP protocol and becomes 1208 a network node, it obtains the network prefix from neighboring 1209 routers and registers its IPv6 addresses. As detailed in 1210 Section 4.1, the combined 6LoWPAN ND 6LBR and Root of the RPL network 1211 learn information such as the device Unique ID (from 6LoWPAN ND) and 1212 the updated Sequence Number (from RPL), and perform 6LoWPAN ND proxy 1213 registration to the 6BBR of behalf of the LLN nodes. 1215 Figure 6 illustrates the initial IPv6 signaling that enables a 6LN to 1216 form a global address and register it to a 6LBR using 6LoWPAN ND 1217 [RFC8505], is then carried over RPL to the RPL Root, and then to the 1218 6BBR. This flow happens just once when the address is created and 1219 first registered. 1221 6LoWPAN Node 6LR 6LBR 6BBR 1222 (RPL leaf) (router) (Root) 1223 | | | | 1224 | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND 1225 | LLN link |Route-Over mesh|Ethernet/serial| Backbone 1226 | | | | 1227 | RS (mcast) | | | 1228 |-------------->| | | 1229 |-----------> | | | 1230 |------------------> | | 1231 | RA (unicast) | | | 1232 |<--------------| | | 1233 | | | | 1234 | NS(EARO) | | | 1235 |-------------->| | | 1236 | 6LoWPAN ND | Extended DAR | | 1237 | |-------------->| | 1238 | | | NS(EARO) | 1239 | | |-------------->| 1240 | | | | NS-DAD 1241 | | | |------> 1242 | | | | (EARO) 1243 | | | | 1244 | | | NA(EARO) | 1245 | | |<--------------| 1246 | | Extended DAC | | 1247 | |<--------------| | 1248 | NA(EARO) | | | 1249 |<--------------| | | 1250 | | | | 1252 Figure 6: Initial Registration Flow over Multi-Link Subnet 1254 Figure 7 illustrates the repeating IPv6 signaling that enables a 6LN 1255 to keep a global address alive and registered to its 6LBR using 1256 6LoWPAN ND to the 6LR, RPL to the RPL Root, and then 6LoWPAN ND again 1257 to the 6BBR, which avoids repeating the Extended DAR/DAC flow across 1258 the network when RPL can suffice as a keep-alive mechanism. 1260 6LoWPAN Node 6LR 6LBR 6BBR 1261 (RPL leaf) (router) (Root) 1262 | | | | 1263 | 6LoWPAN ND |6LoWPAN ND+RPL | 6LoWPAN ND | IPv6 ND 1264 | LLN link |Route-Over mesh| ant IPv6 link | Backbone 1265 | | | 1266 | | | | 1267 | NS(EARO) | | | 1268 |-------------->| | | 1269 | NA(EARO) | | | 1270 |<--------------| | | 1271 | | DAO | | 1272 | |-------------->| | 1273 | | DAO-ACK | | 1274 | |<--------------| | 1275 | | | NS(EARO) | 1276 | | |-------------->| 1277 | | | NA(EARO) | 1278 | | |<--------------| 1279 | | | | 1280 | | | | 1282 Figure 7: Next Registration Flow over Multi-Link Subnet 1284 As the network builds up, a node should start as a leaf to join the 1285 RPL network, and may later turn into both a RPL-capable router and a 1286 6LR, so as to accept leaf nodes to recursively join the network. 1288 4.3. TSCH and 6top 1290 4.3.1. 6top 1292 6TiSCH expects a high degree of scalability together with a 1293 distributed routing functionality based on RPL. To achieve this 1294 goal, the spectrum must be allocated in a way that allows for spatial 1295 reuse between zones that will not interfere with one another. In a 1296 large and spatially distributed network, a 6TiSCH node is often in a 1297 good position to determine usage of the spectrum in its vicinity. 1299 With 6TiSCH, the abstraction of an IPv6 link is implemented as a pair 1300 of bundles of cells, one in each direction. IP Links are only 1301 enabled between RPL parents and children. The 6TiSCH operation is 1302 optimal when the size of a bundle is such that both the energy wasted 1303 in idle listening and the packet drops due to congestion loss are 1304 minimized, while packets are forwarded within an acceptable latency. 1306 Use cases for distributed routing are often associated with a 1307 statistical distribution of best-effort traffic with variable needs 1308 for bandwidth on each individual link. The 6TiSCH operation can 1309 remain optimal if RPL parents can adjust dynamically, and with enough 1310 reactivity to match the variations of best-effort traffic, the amount 1311 of bandwidth that is used to communicate between themselves and their 1312 children, in both directions. In turn, the agility to fulfill the 1313 needs for additional cells improves when the number of interactions 1314 with other devices and the protocol latencies are minimized. 1316 6top is a logical link control sitting between the IP layer and the 1317 TSCH MAC layer, which provides the link abstraction that is required 1318 for IP operations. The 6top protocol, 6P, which is specified in 1319 [RFC8480], is one of the services provided by 6top. In particular, 1320 the 6top services are available over a management API that enables an 1321 external management entity to schedule cells and slotframes, and 1322 allows the addition of complementary functionality, for instance a 1323 Scheduling Function that manages a dynamic schedule management based 1324 on observed resource usage as discussed in Section 4.4.2. For this 1325 purpose, the 6TiSCH architecture differentiates "soft" cells and 1326 "hard" cells. 1328 4.3.1.1. Hard Cells 1330 "Hard" cells are cells that are owned and managed by a separate 1331 scheduling entity (e.g., a PCE) that specifies the slotOffset/ 1332 channelOffset of the cells to be added/moved/deleted, in which case 1333 6top can only act as instructed, and may not move hard cells in the 1334 TSCH schedule on its own. 1336 4.3.1.2. Soft Cells 1338 In contrast, "soft" cells are cells that 6top can manage locally. 1339 6top contains a monitoring process which monitors the performance of 1340 cells, and can add, remove soft cells in the TSCH schedule to adapt 1341 to the traffic needs, or move one when it performs poorly. To 1342 reserve a soft cell, the higher layer does not indicate the exact 1343 slotOffset/channelOffset of the cell to add, but rather the resulting 1344 bandwidth and QoS requirements. When the monitoring process triggers 1345 a cell reallocation, the two neighbor devices communicating over this 1346 cell negotiate its new position in the TSCH schedule. 1348 4.3.2. Scheduling Functions and the 6top protocol 1350 In the case of soft cells, the cell management entity that controls 1351 the dynamic attribution of cells to adapt to the dynamics of variable 1352 rate flows is called a Scheduling Function (SF). 1354 There may be multiple SFs with more or less aggressive reaction to 1355 the dynamics of the network. 1357 An SF may be seen as divided between an upper bandwidth adaptation 1358 logic that is not aware of the particular technology that is used to 1359 obtain and release bandwidth, and an underlying service that maps 1360 those needs in the actual technology, which means mapping the 1361 bandwidth onto cells in the case of TSCH using the 6top protocol as 1362 illustrated in Figure 8. 1364 +------------------------+ +------------------------+ 1365 | Scheduling Function | | Scheduling Function | 1366 | Bandwidth adaptation | | Bandwidth adaptation | 1367 +------------------------+ +------------------------+ 1368 | Scheduling Function | | Scheduling Function | 1369 | TSCH mapping to cells | | TSCH mapping to cells | 1370 +------------------------+ +------------------------+ 1371 | 6top cells negotiation | <- 6P -> | 6top cells negotiation | 1372 +------------------------+ +------------------------+ 1373 Device A Device B 1375 Figure 8: SF/6P stack in 6top 1377 The SF relies on 6top services that implement the 6top Protocol (6P) 1378 [RFC8480] to negotiate the precise cells that will be allocated or 1379 freed based on the schedule of the peer. It may be for instance that 1380 a peer wants to use a particular time slot that is free in its 1381 schedule, but that timeslot is already in use by the other peer for a 1382 communication with a third party on a different cell. 6P enables the 1383 peers to find an agreement in a transactional manner that ensures the 1384 final consistency of the nodes state. 1386 MSF [I-D.ietf-6tisch-msf] is one of the possible scheduling 1387 functions. MSF uses the rendez-vous slot from [RFC8180] for network 1388 discovery, neighbor discovery, and any other broadcast. 1390 For basic unicast communication with any neighbor, each node uses a 1391 receive cell at a well-known slotOffset/channelOffset, derived from a 1392 hash of their own MAC address. Nodes can reach any neighbor by 1393 installing a transmit (shared) cell with slotOffset/channelOffset 1394 derived from the neighbor's MAC address. 1396 For child-parent links, MSF continuously monitors the load to/from 1397 parents and children. It then uses 6P to install/remove unicast 1398 cells whenever the current schedule appears to be under-/over- 1399 provisioned. 1401 4.3.3. 6top and RPL Objective Function operations 1403 An implementation of a RPL [RFC6550] Objective Function (OF), such as 1404 the RPL Objective Function Zero (OF0) [RFC6552] that is used in the 1405 Minimal 6TiSCH Configuration [RFC8180] to support RPL over a static 1406 schedule, may leverage, for its internal computation, the information 1407 maintained by 6top. 1409 An OF may require metrics about reachability, such as the Expected 1410 Transmission Count (ETX) metric [RFC6551]. 6top creates and 1411 maintains an abstract neighbor table, and this state may be leveraged 1412 to feed an OF and/or store OF information as well. A neighbor table 1413 entry may contain a set of statistics with respect to that specific 1414 neighbor. 1416 The neighbor information may include the time when the last packet 1417 has been received from that neighbor, a set of cell quality metrics, 1418 e.g., received signal strength indication (RSSI) or link quality 1419 indicator (LQI), the number of packets sent to the neighbor or the 1420 number of packets received from it. This information can be made 1421 available through 6top management APIs and used for instance to 1422 compute a Rank Increment that will determine the selection of the 1423 preferred parent. 1425 6top provides statistics about the underlying layer so the OF can be 1426 tuned to the nature of the TSCH MAC layer. 6top also enables the RPL 1427 OF to influence the MAC behavior, for instance by configuring the 1428 periodicity of IEEE Std. 802.15.4 Extended Beacons (EBs). By 1429 augmenting the EB periodicity, it is possible to change the network 1430 dynamics so as to improve the support of devices that may change 1431 their point of attachment in the 6TiSCH network. 1433 Some RPL control messages, such as the DODAG Information Object (DIO) 1434 are ICMPv6 messages that are broadcast to all neighbor nodes. With 1435 6TiSCH, the broadcast channel requirement is addressed by 6top by 1436 configuring TSCH to provide a broadcast channel, as opposed to, for 1437 instance, piggybacking the DIO messages in Layer-2 Enhanced Beacons 1438 (EBs), which would produce undue timer coupling among layers, packet 1439 size issues and could conflict with the policy of production networks 1440 where EBs are mostly eliminated to conserve energy. 1442 4.3.4. Network Synchronization 1444 Nodes in a TSCH network must be time synchronized. A node keeps 1445 synchronized to its time source neighbor through a combination of 1446 frame-based and acknowledgment-based synchronization. To maximize 1447 battery life and network throughput, it is advisable that RPL ICMP 1448 discovery and maintenance traffic (governed by the trickle timer) be 1449 somehow coordinated with the transmission of time synchronization 1450 packets (especially with enhanced beacons). 1452 This could be achieved through an interaction of the 6top sublayer 1453 and the RPL objective Function, or could be controlled by a 1454 management entity. 1456 Time distribution requires a loop-free structure. Nodes taken in a 1457 synchronization loop will rapidly desynchronize from the network and 1458 become isolated. 6TiSCH uses a RPL DAG with a dedicated global 1459 Instance for the purpose of time synchronization. That Instance is 1460 referred to as the Time Synchronization Global Instance (TSGI). The 1461 TSGI can be operated in either of the 3 modes that are detailed in 1462 section 3.1.3 of RPL [RFC6550], "Instances, DODAGs, and DODAG 1463 Versions". Multiple uncoordinated DODAGs with independent Roots may 1464 be used if all the Roots share a common time source such as the 1465 Global Positioning System (GPS). 1467 In the absence of a common time source, the TSGI should form a single 1468 DODAG with a virtual Root. A backbone network is then used to 1469 synchronize and coordinate RPL operations between the backbone 1470 routers that act as sinks for the LLN. Optionally, RPL's periodic 1471 operations may be used to transport the network synchronization. 1472 This may mean that 6top would need to trigger (override) the trickle 1473 timer if no other traffic has occurred for such a time that nodes may 1474 get out of synchronization. 1476 A node that has not joined the TSGI advertises a MAC level Join 1477 Priority of 0xFF to notify its neighbors that is not capable of 1478 serving as time parent. A node that has joined the TSGI advertises a 1479 MAC level Join Priority set to its DAGRank() in that Instance, where 1480 DAGRank() is the operation specified in section 3.5.1 of [RFC6550], 1481 "Rank Comparison". 1483 The provisioning of a RPL Root is out of scope for both RPL and this 1484 Architecture, whereas RPL enables to propagate configuration 1485 information down the DODAG. This applies to the TSGI as well; a Root 1486 is configured or obtains by unspecified means the knowledge of the 1487 RPLInstanceID for the TSGI. The Root advertises its DagRank in the 1488 TSGI, that must be less than 0xFF, as its Join Priority in its IEEE 1489 Std. 802.15.4 Extended Beacons (EB). 1491 A node that reads a Join Priority of less than 0xFF should join the 1492 neighbor with the lesser Join Priority and use it as time parent. If 1493 the node is configured to serve as time parent, then the node should 1494 join the TSGI, obtain a Rank in that Instance and start advertising 1495 its own DagRank in the TSGI as its Join Priority in its EBs. 1497 4.3.5. Slotframes and CDU matrix 1499 6TiSCH enables IPv6 best effort (stochastic) transmissions over a MAC 1500 layer that is also capable of scheduled (deterministic) 1501 transmissions. A window of time is defined around the scheduled 1502 transmission where the medium must, as much as practically feasible, 1503 be free of contending energy to ensure that the medium is free of 1504 contending packets when time comes for a scheduled transmission. One 1505 simple way to obtain such a window is to format time and frequencies 1506 in cells of transmission of equal duration. This is the method that 1507 is adopted in IEEE Std. 802.15.4 TSCH as well as the Long Term 1508 Evolution (LTE) of cellular networks. 1510 The 6TiSCH architecture defines a global concept that is called a 1511 Channel Distribution and Usage (CDU) matrix to describe that 1512 formatting of time and frequencies, 1514 A CDU matrix is defined centrally as part of the network definition. 1515 It is a matrix of cells with a height equal to the number of 1516 available channels (indexed by ChannelOffsets) and a width (in 1517 timeslots) that is the period of the network scheduling operation 1518 (indexed by slotOffsets) for that CDU matrix. There are different 1519 models for scheduling the usage of the cells, which place the 1520 responsibility of avoiding collisions either on a central controller 1521 or on the devices themselves, at an extra cost in terms of energy to 1522 scan for free cells (more in Section 4.4). 1524 The size of a cell is a timeslot duration, and values of 10 to 15 1525 milliseconds are typical in 802.15.4 TSCH to accommodate for the 1526 transmission of a frame and an ack, including the security validation 1527 on the receive side which may take up to a few milliseconds on some 1528 device architecture. 1530 A CDU matrix iterates over and over with a well-known channel 1531 rotation called the hopping sequence. In a given network, there 1532 might be multiple CDU matrices that operate with different width, so 1533 they have different durations and represent different periodic 1534 operations. It is recommended that all CDU matrices in a 6TiSCH 1535 domain operate with the same cell duration and are aligned, so as to 1536 reduce the chances of interferences from the Slotted ALOHA 1537 operations. The knowledge of the CDU matrices is shared between all 1538 the nodes and used in particular to define slotframes. 1540 A slotframe is a MAC-level abstraction that is common to all nodes 1541 and contains a series of timeslots of equal length and precedence. 1542 It is characterized by a slotframe_ID, and a slotframe_size. A 1543 slotframe aligns to a CDU matrix for its parameters, such as number 1544 and duration of timeslots. 1546 Multiple slotframes can coexist in a node schedule, i.e., a node can 1547 have multiple activities scheduled in different slotframes. A 1548 slotframe is associated with a priority that may be related to the 1549 precedence of different 6TiSCH topologies. The slotframes may be 1550 aligned to different CDU matrices and thus have different width. 1551 There is typically one slotframe for scheduled traffic that has the 1552 highest precedence and one or more slotframe(s) for RPL traffic. The 1553 timeslots in the slotframe are indexed by the SlotOffset; the first 1554 cell is at SlotOffset 0. 1556 When a packet is received from a higher layer for transmission, 6top 1557 inserts that packet in the outgoing queue which matches the packet 1558 best (Differentiated Services [RFC2474] can therefore be used). At 1559 each scheduled transmit slot, 6top looks for the frame in all the 1560 outgoing queues that best matches the cells. If a frame is found, it 1561 is given to the TSCH MAC for transmission. 1563 4.3.6. Distributing the reservation of cells 1565 The 6TiSCH architecture introduces the concept of chunks 1566 (Section 2.1) to distribute the allocation of the spectrum for a 1567 whole group of cells at a time. The CDU matrix is formatted into a 1568 set of chunks, possibly as illustrated in Figure 9, each of the 1569 chunks identified uniquely by a chunk-ID. The knowledge of this 1570 formatting is shared between all the nodes in a 6TiSCH network. It 1571 could be conveyed during the join process, or codified into a profile 1572 document, or obtained using some other mechanism. This is as opposed 1573 to static scheduling that refers to the pre-programmed mechanism that 1574 is specified in [RFC8180] and pre-exists to the distribution of the 1575 chunk formatting. 1577 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1578 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| 1579 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1580 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| 1581 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1582 ... 1583 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1584 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| 1585 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1586 0 1 2 3 4 5 6 M 1588 Figure 9: CDU matrix Partitioning in Chunks 1590 The 6TiSCH Architecture envisions a protocol that enables chunk 1591 ownership appropriation whereby a RPL parent discovers a chunk that 1592 is not used in its interference domain, claims the chunk, and then 1593 defends it in case another RPL parent would attempt to appropriate it 1594 while it is in use. The chunk is the basic unit of ownership that is 1595 used in that process. 1597 As a result of the process of chunk ownership appropriation, the RPL 1598 parent has exclusive authority to decide which cell in the 1599 appropriated chunk can be used by which node in its interference 1600 domain. In other words, it is implicitly delegated the right to 1601 manage the portion of the CDU matrix that is represented by the 1602 chunk. 1604 Initially, those cells are added to the heap of free cells, then 1605 dynamically placed into existing bundles, in new bundles, or 1606 allocated opportunistically for one transmission. 1608 Note that a PCE is expected to have precedence in the allocation, so 1609 that a RPL parent would only be able to obtain portions that are not 1610 in-use by the PCE. 1612 4.4. Schedule Management Mechanisms 1614 6TiSCH uses 4 paradigms to manage the TSCH schedule of the LLN nodes: 1615 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring 1616 and scheduling management, and Hop-by-hop scheduling. Multiple 1617 mechanisms are defined that implement the associated Interaction 1618 Models, and can be combined and used in the same LLN. Which 1619 mechanism(s) to use depends on application requirements. 1621 4.4.1. Static Scheduling 1623 In the simplest instantiation of a 6TiSCH network, a common fixed 1624 schedule may be shared by all nodes in the network. Cells are 1625 shared, and nodes contend for slot access in a slotted ALOHA manner. 1627 A static TSCH schedule can be used to bootstrap a network, as an 1628 initial phase during implementation, or as a fall-back mechanism in 1629 case of network malfunction. This schedule is pre-established, for 1630 instance decided by a network administrator based on operational 1631 needs. It can be pre-configured into the nodes, or, more commonly, 1632 learned by a node when joining the network using standard IEEE Std. 1633 802.15.4 Information Elements (IE). Regardless, the schedule remains 1634 unchanged after the node has joined a network. RPL is used on the 1635 resulting network. This "minimal" scheduling mechanism that 1636 implements this paradigm is detailed in [RFC8180]. 1638 4.4.2. Neighbor-to-neighbor Scheduling 1640 In the simplest instantiation of a 6TiSCH network described in 1641 Section 4.4.1, nodes may expect a packet at any cell in the schedule 1642 and will waste energy idle listening. In a more complex 1643 instantiation of a 6TiSCH network, a matching portion of the schedule 1644 is established between peers to reflect the observed amount of 1645 transmissions between those nodes. The aggregation of the cells 1646 between a node and a peer forms a bundle that the 6top layer uses to 1647 implement the abstraction of a link for IP. The bandwidth on that 1648 link is proportional to the number of cells in the bundle. 1650 If the size of a bundle is configured to fit an average amount of 1651 bandwidth, peak traffic is dropped. If the size is configured to 1652 allow for peak emissions, energy is be wasted idle listening. 1654 As discussed in more details in Section 4.3, the 6top Protocol 1655 [RFC8480] specifies the exchanges between neighbor nodes to reserve 1656 soft cells to transmit to one another, possibly under the control of 1657 a Scheduling Function (SF). Because this reservation is done without 1658 global knowledge of the schedule of other nodes in the LLN, 1659 scheduling collisions are possible. 1661 And as discussed in Section 4.3.2, an optional Scheduling Function 1662 (SF) is used to monitor bandwidth usage and perform requests for 1663 dynamic allocation by the 6top sublayer. The SF component is not 1664 part of the 6top sublayer. It may be collocated on the same device 1665 or may be partially or fully offloaded to an external system. The 1666 "6TiSCH Minimal Scheduling Function (MSF)" [I-D.ietf-6tisch-msf] 1667 provides a simple scheduling function that can be used by default by 1668 devices that support dynamic scheduling of soft cells. 1670 Monitoring and relocation is done in the 6top layer. For the upper 1671 layer, the connection between two neighbor nodes appears as a number 1672 of cells. Depending on traffic requirements, the upper layer can 1673 request 6top to add or delete a number of cells scheduled to a 1674 particular neighbor, without being responsible for choosing the exact 1675 slotOffset/channelOffset of those cells. 1677 4.4.3. Remote Monitoring and Schedule Management 1679 Remote monitoring and Schedule Management refers to a DetNet/SDN 1680 model whereby an NME and a scheduling entity, associated with a PCE, 1681 reside in a central controller and interact with the 6top layer to 1682 control IPv6 Links and Tracks (Section 4.5) in a 6TiSCH network. The 1683 composite centralized controller can assign physical resources (e.g., 1684 buffers and hard cells) to a particular Track to optimize the 1685 reliability within a bounded latency for a well-specified flow. 1687 The work at the 6TiSCH WG focused on non-deterministic traffic and 1688 did not provide the generic data model that is necessary for the 1689 controller to monitor and manage resources of the 6top sublayer. 1690 This is deferred to future work, see Appendix A.1.2. 1692 With respect to Centralized routing and scheduling, it is envisioned 1693 that the related component of the 6TiSCH Architecture would be an 1694 extension of the Deterministic Networking Architecture 1695 [I-D.ietf-detnet-architecture], which studies Layer-3 aspects of 1696 Deterministic Networks, and covers networks that span multiple 1697 Layer-2 domains. 1699 The DetNet architecture is a form of Software Defined Networking 1700 (SDN) Architecture and is composed of three planes, a (User) 1701 Application Plane, a Controller Plane (where the PCE operates), and a 1702 Network Plane which can represent a 6TiSCH LLN. 1704 Software-Defined Networking (SDN): Layers and Architecture 1705 Terminology [RFC7426] proposes a generic representation of the SDN 1706 architecture that is reproduced in Figure 10. 1708 o--------------------------------o 1709 | | 1710 | +-------------+ +----------+ | 1711 | | Application | | Service | | 1712 | +-------------+ +----------+ | 1713 | Application Plane | 1714 o---------------Y----------------o 1715 | 1716 *-----------------------------Y---------------------------------* 1717 | Network Services Abstraction Layer (NSAL) | 1718 *------Y------------------------------------------------Y-------* 1719 | | 1720 | Service Interface | 1721 | | 1722 o------Y------------------o o---------------------Y------o 1723 | | Control Plane | | Management Plane | | 1724 | +----Y----+ +-----+ | | +-----+ +----Y----+ | 1725 | | Service | | App | | | | App | | Service | | 1726 | +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ | 1727 | | | | | | | | 1728 | *----Y-----------Y----* | | *---Y---------------Y----* | 1729 | | Control Abstraction | | | | Management Abstraction | | 1730 | | Layer (CAL) | | | | Layer (MAL) | | 1731 | *----------Y----------* | | *----------Y-------------* | 1732 | | | | | | 1733 o------------|------------o o------------|---------------o 1734 | | 1735 | CP | MP 1736 | Southbound | Southbound 1737 | Interface | Interface 1738 | | 1739 *------------Y---------------------------------Y----------------* 1740 | Device and resource Abstraction Layer (DAL) | 1741 *------------Y---------------------------------Y----------------* 1742 | | | | 1743 | o-------Y----------o +-----+ o--------Y----------o | 1744 | | Forwarding Plane | | App | | Operational Plane | | 1745 | o------------------o +-----+ o-------------------o | 1746 | Network Device | 1747 +---------------------------------------------------------------+ 1749 Figure 10: SDN Layers and Architecture Terminology per RFC 7426 1751 The PCE establishes end-to-end Tracks of hard cells, which are 1752 described in more details in Section 4.6.1. 1754 The DetNet work is expected to enable end to end Deterministic Path 1755 across heterogeneous network. This can be for instance a 6TiSCH LLN 1756 and an Ethernet Backbone. 1758 This model fits the 6TiSCH extended configuration, whereby a 6BBR 1759 federates multiple 6TiSCH LLN in a single subnet over a backbone that 1760 can be, for instance, Ethernet or Wi-Fi. In that model, 6TiSCH 6BBRs 1761 synchronize with one another over the backbone, so as to ensure that 1762 the multiple LLNs that form the IPv6 subnet stay tightly 1763 synchronized. 1765 If the Backbone is Deterministic, then the Backbone Router ensures 1766 that the end-to-end deterministic behavior is maintained between the 1767 LLN and the backbone. It is the responsibility of the PCE to compute 1768 a deterministic path and to end across the TSCH network and an IEEE 1769 Std. 802.1 TSN Ethernet backbone, and that of DetNet to enable end- 1770 to-end deterministic forwarding. 1772 4.4.4. Hop-by-hop Scheduling 1774 A node can reserve a Track (Section 4.5) to one or more 1775 destination(s) that are multiple hops away by installing soft cells 1776 at each intermediate node. This forms a Track of soft cells. A 1777 Track Scheduling Function above the 6top sublayer of each node on the 1778 Track is needed to monitor these soft cells and trigger relocation 1779 when needed. 1781 This hop-by-hop reservation mechanism is expected to be similar in 1782 essence to [RFC3209] and/or [RFC4080]/[RFC5974]. The protocol for a 1783 node to trigger hop-by-hop scheduling is not yet defined. 1785 4.5. On Tracks 1787 The architecture introduces the concept of a Track, which is a 1788 directed path from a source 6TiSCH node to one or more destination 1789 6TiSCH node(s) across a 6TiSCH LLN. 1791 A Track is the 6TiSCH instantiation of the concept of a Deterministic 1792 Path as described in [I-D.ietf-detnet-architecture]. Constrained 1793 resources such as memory buffers are reserved for that Track in 1794 intermediate 6TiSCH nodes to avoid loss related to limited capacity. 1795 A 6TiSCH node along a Track not only knows which bundles of cells it 1796 should use to receive packets from a previous hop, but also knows 1797 which bundle(s) it should use to send packets to its next hop along 1798 the Track. 1800 4.5.1. General Behavior of Tracks 1802 A Track is associated with Layer-2 bundles of cells with related 1803 schedules and logical relationships and that ensure that a packet 1804 that is injected in a Track will progress in due time all the way to 1805 destination. 1807 Multiple cells may be scheduled in a Track for the transmission of a 1808 single packet, in which case the normal operation of IEEE Std. 1809 802.15.4 Automatic Repeat-reQuest (ARQ) can take place; the 1810 acknowledgment may be omitted in some cases, for instance if there is 1811 no scheduled cell for a possible retry. 1813 There are several benefits for using a Track to forward a packet from 1814 a source node to the destination node. 1816 1. Track forwarding, as further described in Section 4.6.1, is a 1817 Layer-2 forwarding scheme, which introduces less process delay 1818 and overhead than Layer-3 forwarding scheme. Therefore, LLN 1819 Devices can save more energy and resource, which is critical for 1820 resource constrained devices. 1822 2. Since channel resources, i.e., bundles of cells, have been 1823 reserved for communications between 6TiSCH nodes of each hop on 1824 the Track, the throughput and the maximum latency of the traffic 1825 along a Track are guaranteed and the jitter is maintained small. 1827 3. By knowing the scheduled time slots of incoming bundle(s) and 1828 outgoing bundle(s), 6TiSCH nodes on a Track could save more 1829 energy by staying in sleep state during in-active slots. 1831 4. Tracks are protected from interfering with one another if a cell 1832 is scheduled to belong to at most one Track, and congestion loss 1833 is avoided if at most one packet can be presented to the MAC to 1834 use that cell. Tracks enhance the reliability of transmissions 1835 and thus further improve the energy consumption in LLN Devices by 1836 reducing the chances of retransmission. 1838 4.5.2. Serial Track 1840 A Serial (or simple) Track is the 6TiSCH version of a circuit; a 1841 bundle of cells that are programmed to receive (RX-cells) is uniquely 1842 paired to a bundle of cells that are set to transmit (TX-cells), 1843 representing a Layer-2 forwarding state which can be used regardless 1844 of the network layer protocol. A Serial Track is thus formed end-to- 1845 end as a succession of paired bundles, a receive bundle from the 1846 previous hop and a transmit bundle to the next hop along the Track. 1848 For a given iteration of the device schedule, the effective channel 1849 of the cell is obtained by following in a loop a well-known hopping 1850 sequence that started at Epoch time at the channelOffset of the cell, 1851 which results in a rotation of the frequency that used for 1852 transmission. The bundles may be computed so as to accommodate both 1853 variable rates and retransmissions, so they might not be fully used 1854 in the iteration of the schedule. 1856 4.5.3. Complex Track with Replication and Elimination 1858 The art of Deterministic Networks already include Packet Replication 1859 and Elimination techniques. Example standards include the Parallel 1860 Redundancy Protocol (PRP) and the High-availability Seamless 1861 Redundancy (HSR) [IEC62439]. Similarly, and as opposed to a Serial 1862 Track that is a sequence of nodes and links, a Complex Track is 1863 shaped as a directed acyclic graph towards one or more destination(s) 1864 to support multi-path forwarding and route around failures. 1866 A Complex Track may branch off over non congruent branches for the 1867 purpose of multicasting, and/or redundancy, in which case it 1868 reconverges later down the path. This enables the Packet 1869 Replication, Elimination and Ordering Functions (PREOF) defined by 1870 Detnet. Packet ARQ, Replication, Elimination and Overhearing (PAREO) 1871 adds radio-specific capabilities of Layer-2 ARQ and promiscuous 1872 listening to redundant transmissions to compensate for the lossiness 1873 of the medium and meet industrial expectations of a Reliable and 1874 Available Wireless network. Combining PAREO and PREOF, a Track may 1875 extend beyond the 6TiSCH network in a larger DetNet network. 1877 In the art of TSCH, a path does not necessarily support PRE but it is 1878 almost systematically multi-path. This means that a Track is 1879 scheduled so as to ensure that each hop has at least two forwarding 1880 solutions, and the forwarding decision is to try the preferred one 1881 and use the other in case of Layer-2 transmission failure as detected 1882 by ARQ. Similarly, at each 6TiSCH hop along the Track, the PCE may 1883 schedule more than one timeslot for a packet, so as to support 1884 Layer-2 retries (ARQ). It is also possible that the field device 1885 only uses the second branch if sending over the first branch fails. 1887 4.5.4. DetNet End-to-end Path 1889 Ultimately, DetNet [I-D.ietf-detnet-architecture] should enable to 1890 extend a Track beyond the 6TiSCH LLN as illustrated in Figure 11. In 1891 that example, a Track that is laid out from a field device in a 1892 6TiSCH network to an IoT gateway that is located on an 802.1 Time- 1893 Sensitive Networking (TSN) backbone. A 6TiSCH-Aware DetNet Service 1894 Layer handles the Packet Replication, Elimination, and Ordering 1895 Functions over the DODAG that forms a Track. 1897 The Replication function in the 6TiSCH Node sends a copy of each 1898 packet over two different branches, and the PCE schedules each hop of 1899 both branches so that the two copies arrive in due time at the 1900 gateway. In case of a loss on one branch, hopefully the other copy 1901 of the packet still makes it in due time. If two copies make it to 1902 the IoT gateway, the Elimination function in the gateway ignores the 1903 extra packet and presents only one copy to upper layers. 1905 +-=-=-+ 1906 | IoT | 1907 | G/W | 1908 +-=-=-+ 1909 ^ <=== Elimination 1910 Track branch | | 1911 +-=-=-=-+ +-=-=-=-=+ Subnet Backbone 1912 | | 1913 +-=|-=+ +-=|-=+ 1914 | | | Backbone | | | Backbone 1915 o | | | router | | | router 1916 +-=/-=+ +-=|-=+ 1917 o / o o-=-o-=-=/ o 1918 o o-=-o-=/ o o o o o 1919 o \ / o o LLN o 1920 o v <=== Replication 1921 o 1923 Figure 11: Example End-to-End DetNet Track 1925 4.5.5. Cell Reuse 1927 The 6TiSCH architecture provides means to avoid waste of cells as 1928 well as overflows in the transmit bundle of a Track, as follows: 1930 A TX-cell that is not needed for the current iteration may be reused 1931 opportunistically on a per-hop basis for routed packets. When all of 1932 the frame that were received for a given Track are effectively 1933 transmitted, any available TX-cell for that Track can be reused for 1934 upper layer traffic for which the next-hop router matches the next 1935 hop along the Track. In that case, the cell that is being used is 1936 effectively a TX-cell from the Track, but the short address for the 1937 destination is that of the next-hop router. 1939 It results in a frame that is received in a RX-cell of a Track with a 1940 destination MAC address set to this node as opposed to the broadcast 1941 MAC address must be extracted from the Track and delivered to the 1942 upper layer. Note that a frame with an unrecognized destination MAC 1943 address is dropped at the lower MAC layer and thus is not received at 1944 the 6top sublayer. 1946 On the other hand, it might happen that there are not enough TX-cells 1947 in the transmit bundle to accommodate the Track traffic, for instance 1948 if more retransmissions are needed than provisioned. In that case, 1949 and if the frame transports an IPv6 packet, then it can be placed for 1950 transmission in the bundle that is used for Layer-3 traffic towards 1951 the next hop along the Track. The MAC address should be set to the 1952 next-hop MAC address to avoid confusion. 1954 It results in a frame that is received over a Layer-3 bundle may be 1955 in fact associated to a Track. In a classical IP link such as an 1956 Ethernet, off-Track traffic is typically in excess over reservation 1957 to be routed along the non-reserved path based on its QoS setting. 1958 But with 6TiSCH, since the use of the Layer-3 bundle may be due to 1959 transmission failures, it makes sense for the receiver to recognize a 1960 frame that should be re-Tracked, and to place it back on the 1961 appropriate bundle if possible. . A frame is re-Tracked by 1962 scheduling it for transmission over the transmit bundle associated to 1963 the Track, with the destination MAC address set to broadcast. 1965 4.6. Forwarding Models 1967 By forwarding, this document means the per-packet operation that 1968 allows to deliver a packet to a next hop or an upper layer in this 1969 node. Forwarding is based on pre-existing state that was installed 1970 as a result of a routing computation Section 4.7. 6TiSCH supports 1971 three different forwarding model:(G-MPLS) Track Forwarding, 1972 (classical) IPv6 Forwarding and (6LoWPAN) Fragment Forwarding. 1974 4.6.1. Track Forwarding 1976 Forwarding along a Track can be seen as a Generalized Multi-protocol 1977 Label Switching (G-MPLS) operation in that the information used to 1978 switch a frame is not an explicit label, but rather related to other 1979 properties of the way the packet was received, a particular cell in 1980 the case of 6TiSCH. As a result, as long as the TSCH MAC (and 1981 Layer-2 security) accepts a frame, that frame can be switched 1982 regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN 1983 fragment, or a frame from an alternate protocol such as WirelessHART 1984 or ISA100.11a. 1986 A data frame that is forwarded along a Track normally has a 1987 destination MAC address that is set to broadcast - or a multicast 1988 address depending on MAC support. This way, the MAC layer in the 1989 intermediate nodes accepts the incoming frame and 6top switches it 1990 without incurring a change in the MAC header. In the case of IEEE 1991 Std. 802.15.4, this means effectively broadcast, so that along the 1992 Track the short address for the destination of the frame is set to 1993 0xFFFF. 1995 There are 2 modes for a Track, native mode and tunnel mode. 1997 4.6.1.1. Native Mode 1999 In native mode, the Protocol Data Unit (PDU) is associated with flow- 2000 dependent meta-data that refers uniquely to the Track, so the 6top 2001 sublayer can place the frame in the appropriate cell without 2002 ambiguity. In the case of IPv6 traffic, this flow identification may 2003 be done using a 6-tuple as discussed in [I-D.ietf-detnet-ip]. In 2004 particular, implementations of this document should support 2005 identification of DetNet flows based on the IPv6 Flow Label field. 2006 The flow identification may also be done using a dedicated RPL 2007 Instance (see section 3.1.3 of [RFC6550]), signaled in a RPL Packet 2008 Information (more in section 11.2.2.1 of [RFC6550]). The flow 2009 identification is validated at egress before restoring the 2010 destination MAC address (DMAC) and punting to the upper layer. 2012 Figure 12 illustrates the Track Forwarding operation which happens at 2013 the 6top sublayer, below IP. 2015 | Packet flowing across the network ^ 2016 +--------------+ | | 2017 | IPv6 | | | 2018 +--------------+ | | 2019 | 6LoWPAN HC | | | 2020 +--------------+ ingress egress 2021 | 6top | sets +----+ +----+ restores 2022 +--------------+ DMAC to | | | | DMAC to 2023 | TSCH MAC | brdcst | | | | dest 2024 +--------------+ | | | | | | 2025 | LLN PHY | +-------+ +--...-----+ +-------+ 2026 +--------------+ 2027 Ingress Relay Relay Egress 2028 Stack Layer Node Node Node Node 2030 Figure 12: Track Forwarding, Native Mode 2032 4.6.1.2. Tunnel Mode 2034 In tunnel mode, the frames originate from an arbitrary protocol over 2035 a compatible MAC that may or may not be synchronized with the 6TiSCH 2036 network. An example of this would be a router with a dual radio that 2037 is capable of receiving and sending WirelessHART or ISA100.11a frames 2038 with the second radio, by presenting itself as an access Point or a 2039 Backbone Router, respectively. In that mode, some entity (e.g., PCE) 2040 can coordinate with a WirelessHART Network Manager or an ISA100.11a 2041 System Manager to specify the flows that are transported. 2043 +--------------+ 2044 | IPv6 | 2045 +--------------+ 2046 | 6LoWPAN HC | 2047 +--------------+ set restore 2048 | 6top | +DMAC+ +DMAC+ 2049 +--------------+ to|brdcst to|nexthop 2050 | TSCH MAC | | | | | 2051 +--------------+ | | | | 2052 | LLN PHY | +-------+ +--...-----+ +-------+ 2053 +--------------+ | ingress egress | 2054 | | 2055 +--------------+ | | 2056 | LLN PHY | | | 2057 +--------------+ | Packet flowing across the network | 2058 | TSCH MAC | | | 2059 +--------------+ | DMAC = | DMAC = 2060 |ISA100/WiHART | | nexthop v nexthop 2061 +--------------+ 2062 Source Ingress Egress Destination 2063 Stack Layer Node Node Node Node 2065 Figure 13: Track Forwarding, Tunnel Mode 2067 In that case, the flow information that identifies the Track at the 2068 ingress 6TiSCH router is derived from the RX-cell. The DMAC is set 2069 to this node but the flow information indicates that the frame must 2070 be tunneled over a particular Track so the frame is not passed to the 2071 upper layer. Instead, the DMAC is forced to broadcast and the frame 2072 is passed to the 6top sublayer for switching. 2074 At the egress 6TiSCH router, the reverse operation occurs. Based on 2075 tunneling information of the Track, which may for instance indicate 2076 that the tunneled datagram is an IP packet, the datagram is passed to 2077 the appropriate Link-Layer with the destination MAC restored. 2079 4.6.1.3. Tunneling Information 2081 Tunneling information coming with the Track configuration provides 2082 the destination MAC address of the egress endpoint as well as the 2083 tunnel mode and specific data depending on the mode, for instance a 2084 service access point for frame delivery at egress. 2086 If the tunnel egress point does not have a MAC address that matches 2087 the configuration, the Track installation fails. 2089 If the Layer-3 destination address belongs to the tunnel termination, 2090 then it is possible that the IPv6 address of the destination is 2091 compressed at the 6LoWPAN sublayer based on the MAC address. 2092 Restoring the wrong MAC address at the egress would then also result 2093 in the wrong IP address in the packet after decompression. For that 2094 reason, a packet can be injected in a Track only if the destination 2095 MAC address is effectively that of the tunnel egress point. It is 2096 thus mandatory for the ingress router to validate that the MAC 2097 address that was used at the 6LoWPAN sublayer for compression matches 2098 that of the tunnel egress point before it overwrites it to broadcast. 2099 The 6top sublayer at the tunnel egress point reverts that operation 2100 to the MAC address obtained from the tunnel information. 2102 4.6.2. IPv6 Forwarding 2104 As the packets are routed at Layer-3, traditional QoS and Active 2105 Queue Management (AQM) operations are expected to prioritize flows. 2107 | Packet flowing across the network ^ 2108 +--------------+ | | 2109 | IPv6 | | +-QoS+ +-QoS+ | 2110 +--------------+ | | | | | | 2111 | 6LoWPAN HC | | | | | | | 2112 +--------------+ | | | | | | 2113 | 6top | | | | | | | 2114 +--------------+ | | | | | | 2115 | TSCH MAC | | | | | | | 2116 +--------------+ | | | | | | 2117 | LLN PHY | +-------+ +--...-----+ +-------+ 2118 +--------------+ 2119 Source Ingress Egress Destination 2120 Stack Layer Node Router Router Node 2122 Figure 14: IP Forwarding 2124 4.6.3. Fragment Forwarding 2126 Considering that per section 4 of [RFC4944] 6LoWPAN packets can be as 2127 large as 1280 bytes (the IPv6 minimum MTU), and that the non-storing 2128 mode of RPL implies Source Routing that requires space for routing 2129 headers, and that a IEEE Std. 802.15.4 frame with security may carry 2130 in the order of 80 bytes of effective payload, an IPv6 packet might 2131 be fragmented into more than 16 fragments at the 6LoWPAN sublayer. 2133 This level of fragmentation is much higher than that traditionally 2134 experienced over the Internet with IPv4 fragments, where 2135 fragmentation is already known as harmful. 2137 In the case to a multihop route within a 6TiSCH network, Hop-by-Hop 2138 recomposition occurs at each hop to reform the packet and route it. 2139 This creates additional latency and forces intermediate nodes to 2140 store a portion of a packet for an undetermined time, thus impacting 2141 critical resources such as memory and battery. 2143 [I-D.ietf-6lo-minimal-fragment] describes a framework for forwarding 2144 fragments end-to-end across a 6TiSCH route-over mesh. Within that 2145 framework, [I-D.ietf-lwig-6lowpan-virtual-reassembly] details a 2146 virtual reassembly buffer mechanism whereby the datagram tag in the 2147 6LoWPAN Fragment is used as a label for switching at the 6LoWPAN 2148 sublayer. 2150 Building on this technique, [I-D.ietf-6lo-fragment-recovery] 2151 introduces a new format for 6LoWPAN fragments that enables the 2152 selective recovery of individual fragments, and allows for a degree 2153 of flow control based on an Explicit Congestion Notification. 2155 | Packet flowing across the network ^ 2156 +--------------+ | | 2157 | IPv6 | | +----+ +----+ | 2158 +--------------+ | | | | | | 2159 | 6LoWPAN HC | | learn learn | 2160 +--------------+ | | | | | | 2161 | 6top | | | | | | | 2162 +--------------+ | | | | | | 2163 | TSCH MAC | | | | | | | 2164 +--------------+ | | | | | | 2165 | LLN PHY | +-------+ +--...-----+ +-------+ 2166 +--------------+ 2167 Source Ingress Egress Destination 2168 Stack Layer Node Router Router Node 2170 Figure 15: Forwarding First Fragment 2172 In that model, the first fragment is routed based on the IPv6 header 2173 that is present in that fragment. The 6LoWPAN sublayer learns the 2174 next hop selection, generates a new datagram tag for transmission to 2175 the next hop, and stores that information indexed by the incoming MAC 2176 address and datagram tag. The next fragments are then switched based 2177 on that stored state. 2179 | Packet flowing across the network ^ 2180 +--------------+ | | 2181 | IPv6 | | | 2182 +--------------+ | | 2183 | 6LoWPAN HC | | replay replay | 2184 +--------------+ | | | | | | 2185 | 6top | | | | | | | 2186 +--------------+ | | | | | | 2187 | TSCH MAC | | | | | | | 2188 +--------------+ | | | | | | 2189 | LLN PHY | +-------+ +--...-----+ +-------+ 2190 +--------------+ 2191 Source Ingress Egress Destination 2192 Stack Layer Node Router Router Node 2194 Figure 16: Forwarding Next Fragment 2196 A bitmap and an ECN echo in the end-to-end acknowledgment enable the 2197 source to resend the missing fragments selectively. The first 2198 fragment may be resent to carve a new path in case of a path failure. 2199 The ECN echo set indicates that the number of outstanding fragments 2200 should be reduced. 2202 4.7. Advanced 6TiSCH Routing 2204 4.7.1. Packet Marking and Handling 2206 All packets inside a 6TiSCH domain must carry the RPLInstanceID that 2207 identifies the 6TiSCH topology that is to be used for routing and 2208 forwarding that packet. The location of that information must be the 2209 same for all packets forwarded inside the domain. 2211 For packets that are routed by a PCE along a Track, the tuple formed 2212 by the IPv6 source address and a local RPLInstanceID in the packet 2213 identify uniquely the Track and associated transmit bundle. 2215 For packets that are routed by RPL, that information is the 2216 RPLInstanceID which is carried in the RPL Packet Information (RPI), 2217 as discussed in section 11.2 of [RFC6550], "Loop Avoidance and 2218 Detection". The RPI is transported by a RPL option in the IPv6 Hop- 2219 By-Hop Header [RFC6553]. 2221 A compression mechanism for the RPL packet artifacts that integrates 2222 the compression of IP-in-IP encapsulation and the Routing Header type 2223 3 [RFC6554] with that of the RPI in a 6LoWPAN dispatch/header type is 2224 specified in [RFC8025] and [RFC8138]. 2226 Either way, the method and format used for encoding the RPLInstanceID 2227 is generalized to all 6TiSCH topological Instances, which include 2228 both RPL Instances and Tracks. 2230 4.7.2. Replication, Retries and Elimination 2232 6TiSCH supports the PREOF operations of elimination and reordering of 2233 packets along a complex Track, but has no requirement about whether a 2234 sequence number is tagged in the packet for that purpose. With 2235 6TiSCH, the schedule can tell when multiple receive timeslots 2236 correspond to copies of a same packet, in which case the receiver may 2237 avoid listening to the extra copies once it had received one instance 2238 of the packet. 2240 The semantics of the configuration will enable correlated timeslots 2241 to be grouped for transmit (and respectively receive) with a 'OR' 2242 relations, and then a 'AND' relation would be configurable between 2243 groups. The semantics is that if the transmit (and respectively 2244 receive) operation succeeded in one timeslot in a 'OR' group, then 2245 all the other timeslots in the group are ignored. Now, if there are 2246 at least two groups, the 'AND' relation between the groups indicates 2247 that one operation must succeed in each of the groups. 2249 On the transmit side, timeslots provisioned for retries along a same 2250 branch of a Track are placed a same 'OR' group. The 'OR' relation 2251 indicates that if a transmission is acknowledged, then 2252 retransmissions of that packet should not be attempted for remaining 2253 timeslots in that group. There are as many 'OR' groups as there are 2254 branches of the Track departing from this node. Different 'OR' 2255 groups are programmed for the purpose of replication, each group 2256 corresponding to one branch of the Track. The 'AND' relation between 2257 the groups indicates that transmission over any of branches must be 2258 attempted regardless of whether a transmission succeeded in another 2259 branch. It is also possible to place cells to different next-hop 2260 routers in a same 'OR' group. This allows to route along multi-path 2261 Tracks, trying one next-hop and then another only if sending to the 2262 first fails. 2264 On the receive side, all timeslots are programmed in a same 'OR' 2265 group. Retries of a same copy as well as converging branches for 2266 elimination are converged, meaning that the first successful 2267 reception is enough and that all the other timeslots can be ignored. 2268 A 'AND' group denotes different packets that must all be received and 2269 transmitted over the associated transmit groups within their 2270 respected 'AND' or 'OR' rules. 2272 As an example say that we have a simple network as represented in 2273 Figure 17, and we want to enable PREOF between an ingress node I and 2274 an egress node E. 2276 +-+ +-+ 2277 -- |A| ------ |C| -- 2278 / +-+ +-+ \ 2279 / \ 2280 +-+ +-+ 2281 |I| |E| 2282 +-+ +-+ 2283 \ / 2284 \ +-+ +-+ / 2285 -- |B| ------- |D| -- 2286 +-+ +-+ 2288 Figure 17: Scheduling PREOF on a Simple Network 2290 The assumption for this particular problem is that a 6TiSCH node has 2291 a single radio, so it cannot perform 2 receive and/or transmit 2292 operations at the same time, even on 2 different channels. 2294 Say we have 6 possible channels, and at least 10 timeslots per 2295 slotframe. Figure 18 shows a possible schedule whereby each 2296 transmission is retried 2 or 3 times, and redundant copies are 2297 forwarded in parallel via A and C on the one hand, and B and D on the 2298 other, providing time diversity, spatial diversity though different 2299 physical paths, and frequency diversity. 2301 slotOffset 0 1 2 3 4 5 6 7 9 2302 +----+----+----+----+----+----+----+----+----+ 2303 channelOffset 0 | | | | | | |B->D| | | ... 2304 +----+----+----+----+----+----+----+----+----+ 2305 channelOffset 1 | |I->A| |A->C|B->D| | | | | ... 2306 +----+----+----+----+----+----+----+----+----+ 2307 channelOffset 2 |I->A| | |I->B| |C->E| |D->E| | ... 2308 +----+----+----+----+----+----+----+----+----+ 2309 channelOffset 3 | | | | |A->C| | | | | ... 2310 +----+----+----+----+----+----+----+----+----+ 2311 channelOffset 4 | | |I->B| | |B->D| | |D->E| ... 2312 +----+----+----+----+----+----+----+----+----+ 2313 channelOffset 5 | | |A->C| | | |C->E| | | ... 2314 +----+----+----+----+----+----+----+----+----+ 2316 Figure 18: Example Global Schedule 2318 This translates in a different slotframe for every node that provides 2319 the waking and sleeping times, and the channelOffset to be used when 2320 awake. Figure 19 shows the corresponding slotframe for node A. 2322 slotOffset 0 1 2 3 4 5 6 7 9 2323 +----+----+----+----+----+----+----+----+----+ 2324 operation |rcv |rcv |xmit|xmit|xmit|none|none|none|none| ... 2325 +----+----+----+----+----+----+----+----+----+ 2326 channelOffset | 2 | 1 | 5 | 1 | 3 |N/A |N/A |N/A |N/A | ... 2327 +----+----+----+----+----+----+----+----+----+ 2329 Figure 19: Example Slotframe for Node A 2331 The logical relationship between the timeslots is given by the 2332 following table: 2334 +------+---------------------+------------------------+ 2335 | Node | rcv slotOffset | xmit slotOffset | 2336 +------+---------------------+------------------------+ 2337 | I | N/A | (0 OR 1) AND (2 OR 3) | 2338 | A | (0 OR 1) | (2 OR 3 OR 4) | 2339 | B | (2 OR 3) | (4 OR 5 OR 6) | 2340 | C | (2 OR 3 OR 4) | (5 OR 6) | 2341 | D | (4 OR 5 OR 6) | (7 OR 8) | 2342 | E | (5 OR 6 OR 7 OR 8) | N/A | 2343 +------+---------------------+------------------------+ 2345 5. IANA Considerations 2347 This document does not require IANA action. 2349 6. Security Considerations 2351 The "Minimal Security Framework for 6TiSCH" 2352 [I-D.ietf-6tisch-minimal-security] was optimized for Low-Power and 2353 TSCH operations. The reader is encouraged to review the Security 2354 Considerations section of that document, which discusses 6TiSCH 2355 security issues in more details. 2357 6.1. Availability of Remote Services 2359 The operation of 6TiSCH Tracks inherits its high level operation from 2360 DetNet and is subject to the observations in section 5 of 2361 [I-D.ietf-detnet-architecture]. The installation and the maintenance 2362 of the 6TiSCH Tracks depends on the availability of a controller with 2363 a PCE to compute and push them in the network. When that 2364 connectivity is lost, existing Tracks may continue to operate until 2365 the end of their lifetime, but cannot be removed or updated, and new 2366 Tracks cannot be installed. 2368 In a LLN, the communication with a remote PCE may be slow and 2369 unreactive to rapid changes in the condition of the wireless 2370 communication. An attacker may introduce extra delay by selectively 2371 jamming some packets or some flows. The expectation is that the 2372 6TiSCH Tracks enable enough redundancy to maintain the critical 2373 traffic in operation while new routes are calculated and programmed 2374 into the network. 2376 As with DetNet in general, the communication with the PCE must be 2377 secured and should be protected against DoS attacks, including delay 2378 injection and blackholing attacks, and secured as discussed in the 2379 security considerations defined for Abstraction and Control of 2380 Traffic Engineered Networks (ACTN) in Section 9 of [RFC8453], which 2381 applies equally to DetNet and 6TiSCH. In a similar manner, the 2382 communication with the JRC must be secured and should be protected 2383 against DoS attacks when possible. 2385 6.2. Selective Jamming 2387 The Hopping Sequence of a TSCH network is well-known, meaning that if 2388 a rogue manages to identify a cell of a particular flow, then it may 2389 to selectively jam that cell, without impacting any other traffic. 2390 This attack can be performed at the PHY layer without any knowledge 2391 of the Layer-2 keys, and is very hard to detect and diagnose because 2392 only one flow is impacted. 2394 [I-D.tiloca-6tisch-robust-scheduling] proposes a method to obfuscate 2395 the hopping sequence and make it harder to perpetrate that particular 2396 attack. 2398 6.3. MAC-Layer Security 2400 This architecture operates on IEEE Std. 802.15.4 and expects the 2401 Link-Layer security to be enabled at all times between connected 2402 devices, except for the very first step of the device join process, 2403 where a joining device may need some initial, unsecured exchanges so 2404 as to obtain its initial key material. In a typical deployment, all 2405 joined nodes use the same keys and rekeying needs to be global. 2407 The 6TISCH Architecture relies on the join process to deny 2408 authorization of invalid nodes and preserve the integrity of the 2409 network keys. A rogue that managed to access the network can perform 2410 a large variety of attacks from DoS to injecting forged packets and 2411 routing information. "Zero-trust" properties would be highly 2412 desirable but are mostly not available at the time of this writing. 2413 [I-D.ietf-6lo-ap-nd] is a notable exception that protects the 2414 ownership of IPv6 addresses and prevents a rogue node with L2 access 2415 from stealing and injecting traffic on behalf of a legitimate node. 2417 6.4. Time Synchronization 2419 Time Synchronization in TSCH induces another event horizon whereby a 2420 node will only communicate with another node if they are synchronized 2421 within a guard time. The pledge discovers the synchronization of the 2422 network based on the time of reception of the beacon. If an attacker 2423 synchronizes a pledge outside of the guard time of the legitimate 2424 nodes then the pledge will never see a legitimate beacon and may not 2425 discover the attack. 2427 As discussed in [I-D.ietf-detnet-architecture], measures must be 2428 taken to protect the time synchronization, and for 6TiSCH this 2429 includes ensuring that the Absolute Slot Number (ASN), which is the 2430 node's sense of time, is not compromised. Once installed and as long 2431 as the node is synchronized to the network, ASN is implicit in the 2432 transmissions. 2434 IEEE Std. 802.15.4 [IEEE802154] specifies that in a TSCH network, the 2435 nonce that is used for the computation of the Message Integrity Code 2436 (MIC) to secure Link-Layer frames is composed of the address of the 2437 source of the frame and of the ASN. The standard assumes that the 2438 ASN is distributed securely by other means. The ASN is not passed 2439 explicitly in the data frames and does not constitute a complete 2440 anti-replay protection. It results that upper layer protocols must 2441 provide a way to detect duplicates and cope with them. 2443 If the receiver and the sender have a different sense of ASN, the MIC 2444 will not validate and the frame will be dropped. In that sense, TSCH 2445 induces an event horizon whereby only nodes that have a common sense 2446 of ASN can talk to one another in an authenticated manner. With 2447 6TiSCH, the pledge discovers a tentative ASN in beacons from nodes 2448 that have already joined the network. But even if the beacon can be 2449 authenticated, the ASN cannot be trusted as it could be a replay by 2450 an attacker and thus could announce an ASN that represents a time in 2451 the past. If the pledge uses an ASN that is learned from a replayed 2452 beacon for an encrypted transmission, a nonce-reuse attack becomes 2453 possible and the network keys may be compromised. 2455 6.5. Validating ASN 2457 After obtaining the tentative ASN, a pledge that wishes to join the 2458 6TiSCH network must use a join protocol to obtain its security keys. 2459 The join protocol used in 6TiSCH is the Constrained Join Protocol 2460 (CoJP). In the minimal setting defined in 2461 [I-D.ietf-6tisch-minimal-security], the authentication requires a 2462 pre-shared key, based on which a secure session is derived. The CoJP 2463 exchange may also be preceded with a zero-touch handshake 2464 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] in order to enable pledge 2465 joining based on certificates and/or inter-domain communication. 2467 As detailed in Section 4.2.1, a Join Proxy (JP) helps the pledge for 2468 the join procedure by relaying the link-scope Join Request over the 2469 IP network to a Join Registrar/Coordinator (JRC) that can 2470 authenticate the pledge and validate that it is attached to the 2471 appropriate network. As a result of the CoJP exchange, the pledge is 2472 in possession of a Link-Layer material including keys and a short 2473 address, and if the ASN is known to be correct, all traffic can now 2474 be secured using CCM* [CCMstar] at the Link-Layer. 2476 The authentication steps must be such that they cannot be replayed by 2477 an attacker, and they must not depend on the tentative ASN being 2478 valid. During the authentication, the keying material that the 2479 pledge obtains from the JRC does not provide protection against 2480 spoofed ASN. Once the pledge has obtained the keys to use in the 2481 network, it may still need to verify the ASN. If the nonce used in 2482 the Layer-2 security derives from the extended (MAC-64) address, then 2483 replaying the ASN alone cannot enable a nonce-reuse attack unless the 2484 same node is lost its state with a previous ASN. But if the nonce 2485 derives from the short address (e.g., assigned by the JRC) then the 2486 JRC must ensure that it never assigns short addresses that were 2487 already given to this or other nodes with the same keys. In other 2488 words, the network must be rekeyed before the JRC runs out of short 2489 addresses. 2491 6.6. Network Keying and Rekeying 2493 Section 4.2.1 provides an overview of the CoJP process described in 2494 [I-D.ietf-6tisch-minimal-security] by which an LLN can be assembled 2495 in the field, having been provisioned in a lab. 2496 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] is future work that 2497 preceeds and then leverages the CoJP protocol using the 2498 [I-D.ietf-anima-constrained-voucher] constrained profile of 2499 [I-D.ietf-anima-bootstrapping-keyinfra] (BRSKI). This later work 2500 requires a yet-to-be standardized Lighweight Authenticated Key 2501 Exchange protocol. 2503 The CoJP protocol results in distribution of a network-wide key that 2504 is to be used with [IEEE802154] security. The details of use are 2505 described in [I-D.ietf-6tisch-minimal-security] sections 9.2 and 2506 9.3.2. 2508 The BRSKI mechanism may lead to the use of the CoJP protocol, in 2509 which case it also results in distribution of a network-wide key. 2510 Alternatively the BRSKI mechanism may be followed by use of 2511 [I-D.ietf-ace-coap-est] to enroll certificates for each device. In 2512 that case, the certificates may be used with an [IEEE802154] key 2513 agreement protocol. The description of this mechanism, while 2514 conceptually straight forward still has significant standardization 2515 hurdles to pass. 2517 [I-D.ietf-6tisch-minimal-security] section 9.2 describes a mechanism 2518 to change (rekey) the network. There are a number of reasons to 2519 initiate a network rekey: to remove unwanted (corrupt/malicious) 2520 nodes, to recover unused 2-byte short addresses, or due to limits in 2521 encryption algorithms. For all of the mechanisms that distribute a 2522 network-wide key, rekeying is also needed on a periodic basis. In 2523 more details: 2525 o The mechanism described in [I-D.ietf-6tisch-minimal-security] 2526 section 9.2 requires advance communication between the JRC and 2527 every one of the nodes before the key change. Given that many 2528 nodes may be sleepy, this operation may take a significant amount 2529 of time, and may consume a significant portion of the available 2530 bandwidth. As such, network-wide rekeys in order to exclude nodes 2531 that have become malicious will not be particularly quick. If a 2532 rekey is already in progress, but the unwanted node has not yet 2533 been updated, then it is possible to to just continue the 2534 operation. If the unwanted node has already received the update, 2535 then the rekey operation will need to be restarted. 2537 o The cryptographic mechanisms used by IEEE Std. 802.15.4 include 2538 the 2-byte short address in the calculation of the context. A 2539 nonce-reuse attack may become feasible if a short address is 2540 reassigned to another node while the same network-wide keys are in 2541 operation. A network that gains and loses nodes on a regular 2542 basis is likely to reach the 65536 limit of the 2-byte (16-bit) 2543 short addresses, even if the network has only a few thousand 2544 nodes. Network planners should consider the need to rekey the 2545 network on a periodic basis in order to recover 2-byte addresses. 2546 The rekey can update the short addresses for active nodes if 2547 desired, but there is actually no need to do this as long as the 2548 key has been changed. 2550 o With TSCH as it stands at the time of this writing, the ASN will 2551 wrap after 2^40 timeslot durations, which means with the default 2552 values around 350 years. Wrapping ASN is not expected to happen 2553 within the lifetime of most LLNs. Yet, should the ASN wrap, the 2554 network must be rekeyed to avoid a nonce-reuse attack. 2556 o Many cipher algorithms have some suggested limits on how many 2557 bytes should be encrypted with that algorithm before a new key is 2558 used. These numbers are typically in the many to hundreds of 2559 gigabytes of data. On very fast backbone networks this becomes an 2560 important concern. On LLNs with typical data rates in the 2561 kilobits/second, this concern is significantly less. With IEEE 2562 Std. 802.15.4 as it stands at the time of this writing, the ASN 2563 will wrap before the limits of the current L2 crypto (AES-CCM-128) 2564 are reached, so the problem should never occur. 2566 o In any fashion, if the LLN is expected to operate continuously for 2567 decades then the operators are advised to plan for the need to 2568 rekey. 2570 Except for urgent rekeys caused by malicious nodes, the rekey 2571 operation described in [I-D.ietf-6tisch-minimal-security] can be done 2572 as a background task and can be done incrementally. It is a make- 2573 before-break mechanism. The switch over to the new key is not 2574 signaled by time, but rather by observation that the new key is in 2575 use. As such, the update can take as long as needed, or occur in as 2576 short a time as practical. 2578 7. Acknowledgments 2580 7.1. Contributors 2582 The co-authors of this document are listed below: 2584 Thomas Watteyne for his contribution to the whole design, in 2585 particular on TSCH and security, and to the open source 2586 community with openWSN that he created. 2588 Xavier Vilajosana who lead the design of the minimal support with 2589 RPL and contributed deeply to the 6top design and the G-MPLS 2590 operation of Track switching; 2592 Kris Pister for creating TSCH and his continuing guidance through 2593 the elaboration of this design; 2595 Malisa Vucinic for the work on the one-touch join process and his 2596 contribution to the Security Design Team; 2598 Michael Richardson for his leadership role in the Security Design 2599 Team and his contribution throughout this document; 2601 Tero Kivinen for his contribution to the security work in general 2602 and the security section in particular. 2604 Maria Rita Palattella for managing the Terminology document merged 2605 into this through the work of 6TiSCH; 2607 Simon Duquennoy for his contribution to the open source community 2608 with the 6TiSCH implementaton of contiki, and for his 2609 contribution to MSF and autonomous unicast cells. 2611 Qin Wang who lead the design of the 6top sublayer and contributed 2612 related text that was moved and/or adapted in this document; 2614 Rene Struik for the security section and his contribution to the 2615 Security Design Team; 2617 Robert Assimiti for his breakthrough work on RPL over TSCH and 2618 initial text and guidance; 2620 7.2. Special Thanks 2622 Special thanks to Jonathan Simon, Giuseppe Piro, Subir Das and 2623 Yoshihiro Ohba for their deep contribution to the initial security 2624 work, to Yasuyuki Tanaka for his work on implementation and 2625 simulation that tremendously helped build a robust system, to Diego 2626 Dujovne for starting and leading the SF0 effort and to Tengfei Chang 2627 for evolving it in the MSF. 2629 Special thanks also to Pat Kinney, Charlie Perkins and Bob Heile for 2630 their support in maintaining the connection active and the design in 2631 line with work happening at IEEE 802.15. 2633 Special thanks to Ted Lemon who was the INT Area A-D while this 2634 document was initiated for his great support and help throughout, and 2635 to Suresh Krishnan who took over with that kind efficiency of his 2636 till publication. 2638 Also special thanks to Ralph Droms who performed the first INT Area 2639 Directorate review, that was very deep and thorough and radically 2640 changed the orientations of this document, and then to Eliot Lear and 2641 Carlos Pignataro who help finalize this document in preparation to 2642 the IESG reviews, and to Gorry Fairhurst, David Mandelberg, Qin Wu, 2643 Francis Dupont, Eric Vyncke, Mirja Kuhlewind, Roman Danyliw, Benjamin 2644 Kaduk and Andrew Malis, who contributed to the final shaping of this 2645 document through the IESG review procedure. 2647 7.3. And Do not Forget 2649 This document is the result of multiple interactions, in particular 2650 during the 6TiSCH (bi)Weekly Interim call, relayed through the 6TiSCH 2651 mailing list at the IETF, over the course of more than 5 years. 2653 The authors wish to thank in arbitrary order: Alaeddine Weslati, 2654 Chonggang Wang, Georgios Exarchakos, Zhuo Chen, Georgios 2655 Papadopoulos, Eric Levy-Abegnoli, Alfredo Grieco, Bert Greevenbosch, 2656 Cedric Adjih, Deji Chen, Martin Turon, Dominique Barthel, Elvis 2657 Vogli, Geraldine Texier, Guillaume Gaillard, Herman Storey, Kazushi 2658 Muraoka, Ken Bannister, Kuor Hsin Chang, Laurent Toutain, Maik 2659 Seewald, Michael Behringer, Nancy Cam Winget, Nicola Accettura, 2660 Nicolas Montavont, Oleg Hahm, Patrick Wetterwald, Paul Duffy, Peter 2661 van der Stock, Rahul Sen, Pieter de Mil, Pouria Zand, Rouhollah 2662 Nabati, Rafa Marin-Lopez, Raghuram Sudhaakar, Sedat Gormus, Shitanshu 2663 Shah, Steve Simlo, Tina Tsou, Tom Phinney, Xavier Lagrange, Ines 2664 Robles and Samita Chakrabarti for their participation and various 2665 contributions. 2667 8. References 2669 8.1. Normative References 2671 [I-D.ietf-6lo-ap-nd] 2672 Thubert, P., Sarikaya, B., Sethi, M., and R. Struik, 2673 "Address Protected Neighbor Discovery for Low-power and 2674 Lossy Networks", draft-ietf-6lo-ap-nd-12 (work in 2675 progress), April 2019. 2677 [I-D.ietf-6lo-backbone-router] 2678 Thubert, P., Perkins, C., and E. Levy-Abegnoli, "IPv6 2679 Backbone Router", draft-ietf-6lo-backbone-router-13 (work 2680 in progress), September 2019. 2682 [I-D.ietf-6lo-fragment-recovery] 2683 Thubert, P., "6LoWPAN Selective Fragment Recovery", draft- 2684 ietf-6lo-fragment-recovery-05 (work in progress), July 2685 2019. 2687 [I-D.ietf-6lo-minimal-fragment] 2688 Watteyne, T., Bormann, C., and P. Thubert, "6LoWPAN 2689 Fragment Forwarding", draft-ietf-6lo-minimal-fragment-04 2690 (work in progress), September 2019. 2692 [I-D.ietf-6tisch-enrollment-enhanced-beacon] 2693 Dujovne, D. and M. Richardson, "IEEE802.15.4 Informational 2694 Element encapsulation of 6tisch Join and Enrollment 2695 Information", draft-ietf-6tisch-enrollment-enhanced- 2696 beacon-05 (work in progress), September 2019. 2698 [I-D.ietf-6tisch-minimal-security] 2699 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 2700 "Minimal Security Framework for 6TiSCH", draft-ietf- 2701 6tisch-minimal-security-12 (work in progress), July 2019. 2703 [I-D.ietf-6tisch-msf] 2704 Chang, T., Vucinic, M., Vilajosana, X., Duquennoy, S., and 2705 D. Dujovne, "6TiSCH Minimal Scheduling Function (MSF)", 2706 draft-ietf-6tisch-msf-06 (work in progress), August 2019. 2708 [I-D.ietf-detnet-architecture] 2709 Finn, N., Thubert, P., Varga, B., and J. Farkas, 2710 "Deterministic Networking Architecture", draft-ietf- 2711 detnet-architecture-13 (work in progress), May 2019. 2713 [I-D.ietf-roll-unaware-leaves] 2714 Thubert, P. and M. Richardson, "Routing for RPL Leaves", 2715 draft-ietf-roll-unaware-leaves-04 (work in progress), 2716 September 2019. 2718 [I-D.ietf-roll-useofrplinfo] 2719 Robles, I., Richardson, M., and P. Thubert, "Using RPL 2720 Option Type, Routing Header for Source Routes and IPv6-in- 2721 IPv6 encapsulation in the RPL Data Plane", draft-ietf- 2722 roll-useofrplinfo-31 (work in progress), August 2019. 2724 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2725 DOI 10.17487/RFC0768, August 1980, 2726 . 2728 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2729 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2730 DOI 10.17487/RFC4861, September 2007, 2731 . 2733 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2734 Address Autoconfiguration", RFC 4862, 2735 DOI 10.17487/RFC4862, September 2007, 2736 . 2738 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 2739 "Transmission of IPv6 Packets over IEEE 802.15.4 2740 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 2741 . 2743 [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing 2744 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 2745 September 2010, . 2747 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2748 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2749 DOI 10.17487/RFC6282, September 2011, 2750 . 2752 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2753 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2754 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2755 Low-Power and Lossy Networks", RFC 6550, 2756 DOI 10.17487/RFC6550, March 2012, 2757 . 2759 [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., 2760 and D. Barthel, "Routing Metrics Used for Path Calculation 2761 in Low-Power and Lossy Networks", RFC 6551, 2762 DOI 10.17487/RFC6551, March 2012, 2763 . 2765 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 2766 Protocol for Low-Power and Lossy Networks (RPL)", 2767 RFC 6552, DOI 10.17487/RFC6552, March 2012, 2768 . 2770 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2771 Power and Lossy Networks (RPL) Option for Carrying RPL 2772 Information in Data-Plane Datagrams", RFC 6553, 2773 DOI 10.17487/RFC6553, March 2012, 2774 . 2776 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2777 Routing Header for Source Routes with the Routing Protocol 2778 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2779 DOI 10.17487/RFC6554, March 2012, 2780 . 2782 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2783 Bormann, "Neighbor Discovery Optimization for IPv6 over 2784 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2785 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2786 . 2788 [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and 2789 Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2790 2014, . 2792 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 2793 Constrained-Node Networks", RFC 7228, 2794 DOI 10.17487/RFC7228, May 2014, 2795 . 2797 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2798 Application Protocol (CoAP)", RFC 7252, 2799 DOI 10.17487/RFC7252, June 2014, 2800 . 2802 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 2803 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 2804 Internet of Things (IoT): Problem Statement", RFC 7554, 2805 DOI 10.17487/RFC7554, May 2015, 2806 . 2808 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 2809 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 2810 RFC 8025, DOI 10.17487/RFC8025, November 2016, 2811 . 2813 [RFC8137] Kivinen, T. and P. Kinney, "IEEE 802.15.4 Information 2814 Element for the IETF", RFC 8137, DOI 10.17487/RFC8137, May 2815 2017, . 2817 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2818 "IPv6 over Low-Power Wireless Personal Area Network 2819 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2820 April 2017, . 2822 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2823 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2824 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2825 May 2017, . 2827 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2828 (IPv6) Specification", STD 86, RFC 8200, 2829 DOI 10.17487/RFC8200, July 2017, 2830 . 2832 [RFC8453] Ceccarelli, D., Ed. and Y. Lee, Ed., "Framework for 2833 Abstraction and Control of TE Networks (ACTN)", RFC 8453, 2834 DOI 10.17487/RFC8453, August 2018, 2835 . 2837 [RFC8480] Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6TiSCH 2838 Operation Sublayer (6top) Protocol (6P)", RFC 8480, 2839 DOI 10.17487/RFC8480, November 2018, 2840 . 2842 [RFC8505] Thubert, P., Ed., Nordmark, E., Chakrabarti, S., and C. 2843 Perkins, "Registration Extensions for IPv6 over Low-Power 2844 Wireless Personal Area Network (6LoWPAN) Neighbor 2845 Discovery", RFC 8505, DOI 10.17487/RFC8505, November 2018, 2846 . 2848 8.2. Informative References 2850 [AMI] US Department of Energy, "Advanced Metering Infrastructure 2851 and Customer Systems", 2006, 2852 . 2855 [ANIMA] IETF, "Autonomic Networking Integrated Model and 2856 Approach", 2857 . 2859 [CCAMP] IETF, "Common Control and Measurement Plane", 2860 . 2862 [CCMstar] Struik, R., "Formal Specification of the CCM* Mode of 2863 Operation", September 2004, . 2867 [HART] www.hartcomm.org, "Highway Addressable remote Transducer, 2868 a group of specifications for industrial process and 2869 control devices administered by the HART Foundation". 2871 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] 2872 Richardson, M., "6tisch Zero-Touch Secure Join protocol", 2873 draft-ietf-6tisch-dtsecurity-zerotouch-join-04 (work in 2874 progress), July 2019. 2876 [I-D.ietf-ace-coap-est] 2877 Stok, P., Kampanakis, P., Richardson, M., and S. Raza, 2878 "EST over secure CoAP (EST-coaps)", draft-ietf-ace-coap- 2879 est-15 (work in progress), October 2019. 2881 [I-D.ietf-anima-bootstrapping-keyinfra] 2882 Pritikin, M., Richardson, M., Eckert, T., Behringer, M., 2883 and K. Watsen, "Bootstrapping Remote Secure Key 2884 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2885 keyinfra-28 (work in progress), September 2019. 2887 [I-D.ietf-anima-constrained-voucher] 2888 Richardson, M., Stok, P., and P. Kampanakis, "Constrained 2889 Voucher Artifacts for Bootstrapping Protocols", draft- 2890 ietf-anima-constrained-voucher-05 (work in progress), July 2891 2019. 2893 [I-D.ietf-core-object-security] 2894 Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 2895 "Object Security for Constrained RESTful Environments 2896 (OSCORE)", draft-ietf-core-object-security-16 (work in 2897 progress), March 2019. 2899 [I-D.ietf-detnet-ip] 2900 Varga, B., Farkas, J., Berger, L., Fedyk, D., Malis, A., 2901 Bryant, S., and J. Korhonen, "DetNet Data Plane: IP", 2902 draft-ietf-detnet-ip-01 (work in progress), July 2019. 2904 [I-D.ietf-lwig-6lowpan-virtual-reassembly] 2905 Bormann, C. and T. Watteyne, "Virtual reassembly buffers 2906 in 6LoWPAN", draft-ietf-lwig-6lowpan-virtual-reassembly-01 2907 (work in progress), March 2019. 2909 [I-D.ietf-manet-aodvv2] 2910 Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and 2911 V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 2912 (AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in 2913 progress), May 2016. 2915 [I-D.ietf-roll-aodv-rpl] 2916 Anamalamudi, S., Zhang, M., Perkins, C., Anand, S., and B. 2917 Liu, "Asymmetric AODV-P2P-RPL in Low-Power and Lossy 2918 Networks (LLNs)", draft-ietf-roll-aodv-rpl-07 (work in 2919 progress), April 2019. 2921 [I-D.ietf-roll-dao-projection] 2922 Thubert, P., Jadhav, R., Gillmore, M., and J. Pylakutty, 2923 "Root initiated routing state in RPL", draft-ietf-roll- 2924 dao-projection-06 (work in progress), May 2019. 2926 [I-D.ietf-roll-rpl-industrial-applicability] 2927 Phinney, T., Thubert, P., and R. Assimiti, "RPL 2928 applicability in industrial networks", draft-ietf-roll- 2929 rpl-industrial-applicability-02 (work in progress), 2930 October 2013. 2932 [I-D.pthubert-raw-problem-statement] 2933 Thubert, P. and G. Papadopoulos, "Reliable and Available 2934 Wireless Problem Statement", draft-pthubert-raw-problem- 2935 statement-03 (work in progress), October 2019. 2937 [I-D.rahul-roll-mop-ext] 2938 Jadhav, R. and P. Thubert, "RPL Mode of Operation 2939 extension", draft-rahul-roll-mop-ext-01 (work in 2940 progress), June 2019. 2942 [I-D.selander-ace-cose-ecdhe] 2943 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 2944 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 2945 cose-ecdhe-14 (work in progress), September 2019. 2947 [I-D.thubert-6lo-bier-dispatch] 2948 Thubert, P., Brodard, Z., Jiang, H., and G. Texier, "A 2949 6loRH for BitStrings", draft-thubert-6lo-bier-dispatch-06 2950 (work in progress), January 2019. 2952 [I-D.thubert-6man-unicast-lookup] 2953 Thubert, P. and E. Levy-Abegnoli, "IPv6 Neighbor Discovery 2954 Unicast Lookup", draft-thubert-6man-unicast-lookup-00 2955 (work in progress), July 2019. 2957 [I-D.thubert-bier-replication-elimination] 2958 Thubert, P., Eckert, T., Brodard, Z., and H. Jiang, "BIER- 2959 TE extensions for Packet Replication and Elimination 2960 Function (PREF) and OAM", draft-thubert-bier-replication- 2961 elimination-03 (work in progress), March 2018. 2963 [I-D.thubert-raw-technologies] 2964 Thubert, P., Cavalcanti, D., Vilajosana, X., and C. 2965 Schmitt, "Reliable and Available Wireless Technologies", 2966 draft-thubert-raw-technologies-03 (work in progress), July 2967 2019. 2969 [I-D.thubert-roll-bier] 2970 Thubert, P., "RPL-BIER", draft-thubert-roll-bier-02 (work 2971 in progress), July 2018. 2973 [I-D.tiloca-6tisch-robust-scheduling] 2974 Tiloca, M., Duquennoy, S., and G. Dini, "Robust Scheduling 2975 against Selective Jamming in 6TiSCH Networks", draft- 2976 tiloca-6tisch-robust-scheduling-02 (work in progress), 2977 June 2019. 2979 [IEC62439] 2980 IEC, "Industrial communication networks - High 2981 availability automation networks - Part 3: Parallel 2982 Redundancy Protocol (PRP) and High-availability Seamless 2983 Redundancy (HSR) - IEC62439-3", 2012, 2984 . 2986 [IEEE802154] 2987 IEEE standard for Information Technology, "IEEE Std. 2988 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 2989 and Physical Layer (PHY) Specifications for Low-Rate 2990 Wireless Personal Area Networks". 2992 [IEEE802154e] 2993 IEEE standard for Information Technology, "IEEE standard 2994 for Information Technology, IEEE Std. 802.15.4, Part. 2995 15.4: Wireless Medium Access Control (MAC) and Physical 2996 Layer (PHY) Specifications for Low-Rate Wireless Personal 2997 Area Networks, June 2011 as amended by IEEE Std. 2998 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 2999 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 3000 2012. 3002 [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", 3003 . 3005 [ISA100.11a] 3006 ISA/ANSI, "Wireless Systems for Industrial Automation: 3007 Process Control and Related Applications - ISA100.11a-2011 3008 - IEC 62734", 2011, . 3011 [PCE] IETF, "Path Computation Element", 3012 . 3014 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 3015 "Definition of the Differentiated Services Field (DS 3016 Field) in the IPv4 and IPv6 Headers", RFC 2474, 3017 DOI 10.17487/RFC2474, December 1998, 3018 . 3020 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 3021 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 3022 DOI 10.17487/RFC2545, March 1999, 3023 . 3025 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 3026 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 3027 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 3028 . 3030 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 3031 Information Models and Data Models", RFC 3444, 3032 DOI 10.17487/RFC3444, January 2003, 3033 . 3035 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 3036 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 3037 RFC 3963, DOI 10.17487/RFC3963, January 2005, 3038 . 3040 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 3041 Bosch, "Next Steps in Signaling (NSIS): Framework", 3042 RFC 4080, DOI 10.17487/RFC4080, June 2005, 3043 . 3045 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3046 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 3047 2006, . 3049 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 3050 DOI 10.17487/RFC4903, June 2007, 3051 . 3053 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 3054 over Low-Power Wireless Personal Area Networks (6LoWPANs): 3055 Overview, Assumptions, Problem Statement, and Goals", 3056 RFC 4919, DOI 10.17487/RFC4919, August 2007, 3057 . 3059 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 3060 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 3061 . 3063 [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS 3064 Signaling Layer Protocol (NSLP) for Quality-of-Service 3065 Signaling", RFC 5974, DOI 10.17487/RFC5974, October 2010, 3066 . 3068 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 3069 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 3070 2011, . 3072 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 3073 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 3074 January 2012, . 3076 [RFC6606] Kim, E., Kaspar, D., Gomez, C., and C. Bormann, "Problem 3077 Statement and Requirements for IPv6 over Low-Power 3078 Wireless Personal Area Network (6LoWPAN) Routing", 3079 RFC 6606, DOI 10.17487/RFC6606, May 2012, 3080 . 3082 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 3083 Locator/ID Separation Protocol (LISP)", RFC 6830, 3084 DOI 10.17487/RFC6830, January 2013, 3085 . 3087 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 3088 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 3089 Defined Networking (SDN): Layers and Architecture 3090 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 3091 2015, . 3093 [RFC8578] Grossman, E., Ed., "Deterministic Networking Use Cases", 3094 RFC 8578, DOI 10.17487/RFC8578, May 2019, 3095 . 3097 [S-ALOHA] Roberts, L. G., "ALOHA Packet System With and Without 3098 Slots and Capture", doi 10.1145/1024916.1024920, April 3099 1975, . 3101 [TEAS] IETF, "Traffic Engineering Architecture and Signaling", 3102 . 3104 [WirelessHART] 3105 www.hartcomm.org, "Industrial Communication Networks - 3106 Wireless Communication Network and Communication Profiles 3107 - WirelessHART - IEC 62591", 2010. 3109 Appendix A. Related Work In Progress 3111 This document has been incremented as the work progressed following 3112 the evolution of the WG charter and the availability of dependent 3113 work. The intent was to publish when the WG concludes on the covered 3114 items. At the time of publishing the following specification are 3115 still in progress and may affect the evolution of the stack in a 3116 6TiSCH-aware node. 3118 A.1. Unchartered IETF work items 3120 A.1.1. 6TiSCH Zerotouch security 3122 The security model and in particular the zerotouch join process 3123 [I-D.ietf-6tisch-dtsecurity-zerotouch-join] depends on the ANIMA 3124 [ANIMA] Bootstrapping Remote Secure Key Infrastructures (BRSKI) 3125 [I-D.ietf-anima-bootstrapping-keyinfra] to enable zero-touch security 3126 provisionning; for highly constrained nodes, a minimal model based on 3127 pre-shared keys (PSK) is also available. As written to this day, it 3128 also depends on a number of documents in progress as CORE, and on 3129 "Ephemeral Diffie-Hellman Over COSE (EDHOC)" 3130 [I-D.selander-ace-cose-ecdhe], which is being considered for adoption 3131 at the LAKE WG. 3133 A.1.2. 6TiSCH Track Setup 3135 ROLL is now standardizing a reactive routing protocol based on RPL 3136 [I-D.ietf-roll-aodv-rpl] The need of a reactive routing protocol to 3137 establish on-demand constraint-optimized routes and a reservation 3138 protocol to establish Layer-3 Tracks is being discussed at 6TiSCH but 3139 not chartered for. 3141 At the time of this writing, the formation of a new working group 3142 called RAW for Reliable and Available Wireless networking is being 3143 considered. The work on centralized Track computation is deferred to 3144 a subsequent work, not necessarily at 6TiSCH. A Predictable and 3145 Available Wireless (PAW) bar-BoF took place. RAW may form as a WG 3146 and develop a generic specification for Track operations that would 3147 cover 6TiSCH requirements as expressed in this architecture, more in 3148 [I-D.thubert-raw-technologies] and 3149 [I-D.pthubert-raw-problem-statement]. In a large LLN, it is not 3150 feasible to update the routes from a central controller that resides 3151 far over the constrained network at the speed at which the quality of 3152 the wireless links varies. RAW would focus on forwarding behaviors 3153 to react quickly and locally to the changes in the wireless links. 3155 ROLL is also standardizing an extension to RPL to setup centrally- 3156 computed routes [I-D.ietf-roll-dao-projection] 3157 The 6TiSCH Architecture should thus inherit from the DetNet 3158 [I-D.ietf-detnet-architecture] architecture and thus depends on it. 3159 The Path Computation Element (PCE) should be a core component of that 3160 architecture. An extension to RPL or to TEAS [TEAS] will be required 3161 to expose the 6TiSCH node capabilities and the network peers to the 3162 PCE, possibly in combination with [I-D.rahul-roll-mop-ext]. A 3163 protocol such as a lightweight PCEP or an adaptation of CCAMP [CCAMP] 3164 G-MPLS formats and procedures could be used in combination to 3165 [I-D.ietf-roll-dao-projection] to install the Tracks, as computed by 3166 the PCE, to the 6TiSCH nodes. 3168 A.1.3. Using BIER in a 6TiSCH Network 3170 ROLL is actively working on Bit Index Explicit Replication (BIER) as 3171 a method to compress both the dataplane packets and the routing 3172 tables in storing mode [I-D.thubert-roll-bier]. 3174 BIER could also be used in the context of the DetNet service layer. 3175 BIER-TE-based OAM, Replication and Elimination 3176 [I-D.thubert-bier-replication-elimination] leverages BIER Traffic 3177 Engineering (TE) to control in the data plane the DetNet Replication 3178 and Elimination activities, and to provide traceability on links 3179 where replication and loss happen, in a manner that is abstract to 3180 the forwarding information. 3182 a 6loRH for BitStrings [I-D.thubert-6lo-bier-dispatch] proposes a 3183 6LoWPAN compression for the BIER Bitstring based on 6LoWPAN Routing 3184 Header [RFC8138]. 3186 A.2. External (non-IETF) work items 3188 The current charter positions 6TiSCH on IEEE Std. 802.15.4 only. 3189 Though most of the design should be portable on other link types, 3190 6TiSCH has a strong dependency on IEEE Std. 802.15.4 and its 3191 evolution. The impact of changes to TSCH on this Architecture should 3192 be minimal to non-existent, but deeper work such as 6top and security 3193 may be impacted. A 6TiSCH Interest Group at the IEEE maintains the 3194 synchronization and helps foster work at the IEEE should 6TiSCH 3195 demand it. 3197 Work is being proposed at IEEE (802.15.12 PAR) for an LLC that would 3198 logically include the 6top sublayer. The interaction with the 6top 3199 sublayer and the Scheduling Functions described in this document are 3200 yet to be defined. 3202 ISA100 [ISA100] Common Network Management (CNM) is another external 3203 work of interest for 6TiSCH. The group, referred to as ISA100.20, 3204 defines a Common Network Management framework that should enable the 3205 management of resources that are controlled by heterogeneous 3206 protocols such as ISA100.11a [ISA100.11a], WirelessHART 3207 [WirelessHART], and 6TiSCH. Interestingly, the establishment of 3208 6TiSCH Deterministic paths, called Tracks, are also in scope, and 3209 ISA100.20 is working on requirements for DetNet. 3211 Author's Address 3213 Pascal Thubert (editor) 3214 Cisco Systems, Inc 3215 Building D 3216 45 Allee des Ormes - BP1200 3217 MOUGINS - Sophia Antipolis 06254 3218 FRANCE 3220 Phone: +33 497 23 26 34 3221 Email: pthubert@cisco.com