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