idnits 2.17.1 draft-ietf-6tisch-architecture-12.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 1935 has weird spacing: '...ssimiti for h...' == Line 1938 has weird spacing: '... Pister for c...' == Line 1941 has weird spacing: '...hardson for h...' == Line 1944 has weird spacing: '... Struik for t...' == Line 1947 has weird spacing: '...ajosana who l...' == (2 more instances...) -- The document date (August 10, 2017) is 2450 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154' is mentioned on line 2346, but not defined == Missing Reference: 'IEEE802154e' is mentioned on line 2352, but not defined == Missing Reference: 'WirelessHART' is mentioned on line 2377, but not defined == Missing Reference: 'PCE' is mentioned on line 2371, but not defined == Missing Reference: 'TEAS' is mentioned on line 2374, but not defined == Missing Reference: 'CCAMP' is mentioned on line 2321, but not defined == Missing Reference: 'ISA100' is mentioned on line 2362, but not defined == Missing Reference: 'HART' is mentioned on line 2330, but not defined == Missing Reference: 'IEC62439' is mentioned on line 2334, but not defined == Missing Reference: 'ACE' is mentioned on line 2317, but not defined == Missing Reference: 'DETNET' is mentioned on line 2324, but not defined == Missing Reference: 'DICE' is mentioned on line 2327, but not defined == Missing Reference: 'IEEE802.1TSNTG' is mentioned on line 2341, but not defined == Unused Reference: 'RFC6655' is defined on line 2293, but no explicit reference was found in the text == Unused Reference: 'RFC6997' is defined on line 2303, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-6lo-backbone-router-04 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-09 == Outdated reference: A later version (-13) exists of draft-ietf-detnet-architecture-03 == Outdated reference: A later version (-23) exists of draft-ietf-6lo-ap-nd-02 == Outdated reference: A later version (-21) exists of draft-ietf-6lo-rfc6775-update-07 == Outdated reference: A later version (-12) exists of draft-ietf-6tisch-6top-protocol-07 == Outdated reference: A later version (-15) exists of draft-ietf-6tisch-minimal-security-03 == Outdated reference: A later version (-45) exists of draft-ietf-anima-bootstrapping-keyinfra-07 == Outdated reference: A later version (-17) exists of draft-ietf-core-comi-01 == Outdated reference: A later version (-20) exists of draft-ietf-detnet-use-cases-12 == Outdated reference: A later version (-14) exists of draft-selander-ace-cose-ecdhe-07 == Outdated reference: A later version (-06) exists of draft-thubert-6lo-bier-dispatch-03 == Outdated reference: A later version (-08) exists of draft-thubert-6lo-forwarding-fragments-07 == Outdated reference: A later version (-03) exists of draft-thubert-bier-replication-elimination-01 -- 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 (~~), 36 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 4 Intended status: Informational August 10, 2017 5 Expires: February 11, 2018 7 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4 8 draft-ietf-6tisch-architecture-12 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 http://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 February 11, 2018. 35 Copyright Notice 37 Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. High Level Architecture . . . . . . . . . . . . . . . . . . . 4 55 3.1. 6TiSCH Stack . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. TSCH: A Deterministic MAC Layer . . . . . . . . . . . . . 6 57 3.3. Scheduling TSCH . . . . . . . . . . . . . . . . . . . . . 7 58 3.4. Routing and Forwarding Over TSCH . . . . . . . . . . . . 9 59 3.5. A Non-Broadcast Multi-Access Radio Mesh Network . . . . . 10 60 3.6. A Multi-Link Subnet Model . . . . . . . . . . . . . . . . 12 61 3.7. Join Process and Registration . . . . . . . . . . . . . . 13 62 3.8. Dependencies on Work In Progress . . . . . . . . . . . . 14 63 4. Architecture Components . . . . . . . . . . . . . . . . . . . 16 64 4.1. 6LoWPAN (and RPL) . . . . . . . . . . . . . . . . . . . . 16 65 4.1.1. RPL Leaf Support in 6LoWPAN ND . . . . . . . . . . . 16 66 4.1.2. RPL Root And 6LBR . . . . . . . . . . . . . . . . . . 17 67 4.2. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . 18 68 4.2.1. 6top . . . . . . . . . . . . . . . . . . . . . . . . 18 69 4.2.2. Scheduling Functions and the 6P protocol . . . . . . 18 70 4.2.3. 6top and RPL Objective Function operations . . . . . 19 71 4.2.4. Network Synchronization . . . . . . . . . . . . . . . 20 72 4.2.5. SlotFrames and Priorities . . . . . . . . . . . . . . 21 73 4.2.6. Distributing the reservation of cells . . . . . . . . 22 74 4.3. Communication Paradigms and Interaction Models . . . . . 24 75 4.4. Schedule Management Mechanisms . . . . . . . . . . . . . 25 76 4.4.1. Static Scheduling . . . . . . . . . . . . . . . . . . 25 77 4.4.2. Neighbor-to-neighbor Scheduling . . . . . . . . . . . 26 78 4.4.3. Remote Monitoring and Schedule Management . . . . . . 26 79 4.4.4. Hop-by-hop Scheduling . . . . . . . . . . . . . . . . 29 80 4.5. On Tracks . . . . . . . . . . . . . . . . . . . . . . . . 29 81 4.5.1. General Behavior of Tracks . . . . . . . . . . . . . 29 82 4.5.2. Serial Track . . . . . . . . . . . . . . . . . . . . 30 83 4.5.3. Complex Track with Replication and Elimination . . . 31 84 4.5.4. DetNet End-to-end Path . . . . . . . . . . . . . . . 31 85 4.5.5. Cell Reuse . . . . . . . . . . . . . . . . . . . . . 32 86 4.6. Forwarding Models . . . . . . . . . . . . . . . . . . . . 33 87 4.6.1. Track Forwarding . . . . . . . . . . . . . . . . . . 33 88 4.6.2. Fragment Forwarding . . . . . . . . . . . . . . . . . 36 89 4.6.3. IPv6 Forwarding . . . . . . . . . . . . . . . . . . . 37 90 4.7. Centralized vs. Distributed Routing . . . . . . . . . . . 38 91 4.7.1. Packet Marking and Handling . . . . . . . . . . . . . 38 92 4.7.2. Replication, Retries and Elimination . . . . . . . . 39 93 4.7.3. Differentiated Services Per-Hop-Behavior . . . . . . 40 94 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 40 96 6.1. Join Process Highlights . . . . . . . . . . . . . . . . . 40 97 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 98 7.1. Contributors . . . . . . . . . . . . . . . . . . . . . . 43 99 7.2. Special Thanks . . . . . . . . . . . . . . . . . . . . . 44 100 7.3. And Do not Forget . . . . . . . . . . . . . . . . . . . . 44 101 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 102 8.1. Normative References . . . . . . . . . . . . . . . . . . 45 103 8.2. Informative References . . . . . . . . . . . . . . . . . 47 104 8.3. Other Informative References . . . . . . . . . . . . . . 51 105 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53 107 1. Introduction 109 Wireless Networks enable a wide variety of devices of any size to get 110 interconnected, often at a very low marginal cost per device, at any 111 distance ranging from Near Field to interplanetary, and in 112 circumstances where wiring may be impractical, for instance on fast- 113 moving or rotating devices. 115 In the other hand, Deterministic Networks enable traffic that is 116 highly sensitive to jitter, quite sensitive to latency, and with a 117 high degree of operational criticality so that loss should be 118 minimized at all times. Applications that need such networks are 119 presented in [I-D.ietf-detnet-use-cases]. They include Professional 120 Media and Operation Technology (OT) Industrial Automation Control 121 Systems (IACS). 123 The Medium access Control (MAC) of IEEE Std 802.15.4 [IEEE802154] has 124 evolved with the IEEE Std 802.15.4e Timeslotted Channel Hopping 125 (TSCH) [RFC7554] mode to provide deterministic properties on wireless 126 networks. TSCH was initially introduced with the IEEE Std 802.15.4e 127 amendment [IEEE802154e] of the IEEE Std 802.15.4 standard and 128 constituted a part of the standard from that day. For all practical 129 purpose, this document is expected to be insensitive to the revisions 130 of the IEEE Std 802.15.4 standard, which is thus referenced undated. 132 Proven Deterministic Networking standards for use in Process Control, 133 including ISA100.11a [ISA100.11a] and WirelessHART [WirelessHART], 134 have demonstrated the capabilities of the IEEE Std 802.15.4 TSCH MAC 135 for high reliability against interference, low-power consumption on 136 well-known flows, and its applicability for Traffic Engineering (TE) 137 from a central controller. 139 In order to enable the convergence of IT and OT in LLN environments, 140 6TiSCH ports the IETF suite of protocol that are defined for such 141 environments over the TSCH MAC. 6TiSCH also provides large scaling 142 capabilities, which, in a number of scenarios, require the addition 143 of a high speed and reliable backbone and the use of IP version 6 144 (IPv6). The 6TiSCH Architecture introduces an IPv6 Multi-Link subnet 145 model that is composed of a federating backbone and a number of IEEE 146 Std 802.15.4 TSCH low-power wireless networks attached and 147 synchronized by Backbone Routers. 149 The architecture defines mechanisms to establish and maintain routing 150 and scheduling in a centralized, distributed, or mixed fashion, for 151 use in multiple OT environments. It is applicable in particular to 152 industrial control systems, building automation that leverage 153 distributed routing to address multipath over a large number of hops, 154 in-vehicle command and control that can be as demanding as industrial 155 applications, commercial automation and asset Tracking with mobile 156 scenarios, home automation and domotics which become more reliable 157 and thus provide a better user experience, and resource management 158 (energy, water, etc.). 160 2. Terminology 162 The draft uses domain-specific terminology defined or referenced in 163 [I-D.ietf-6tisch-terminology], [I-D.ietf-6lo-backbone-router], and 164 [I-D.ietf-roll-rpl-industrial-applicability]. 166 Readers are expected to be familiar with all the terms and concepts 167 that are discussed in "Neighbor Discovery for IP version 6" 168 [RFC4861], "IPv6 over Low-Power Wireless Personal Area Networks 169 (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" 170 [RFC4919], and Neighbor Discovery Optimization for Low-power and 171 Lossy Networks [RFC6775] where the 6LoWPAN Router (6LR) and the 172 6LoWPAN Border Router (6LBR) are introduced. 174 Readers may benefit from reading the "RPL: IPv6 Routing Protocol for 175 Low-Power and Lossy Networks" [RFC6550] specification; "Multi-Link 176 Subnet Issues" [RFC4903]; "Mobility Support in IPv6" [RFC6275]; 177 "Neighbor Discovery Proxies (ND Proxy)" [RFC4389]; "IPv6 Stateless 178 Address Autoconfiguration" [RFC4862]; "FCFS SAVI: First-Come, First- 179 Served Source Address Validation Improvement for Locally Assigned 180 IPv6 Addresses" [RFC6620]; and "Optimistic Duplicate Address 181 Detection" [RFC4429] prior to this specification for a clear 182 understanding of the art in ND-proxying and binding. 184 The draft also conforms to the terms and models described in 185 [RFC3444] and [RFC5889] and uses the vocabulary and the concepts 186 defined in [RFC4291] for the IPv6 Architecture and refers [RFC4080] 187 for reservation signaling and [RFC5191] for authentication. 189 3. High Level Architecture 190 3.1. 6TiSCH Stack 192 The 6TiSCH architecture presents a reference stack that is 193 implemented and interop tested by a conjunction of opensource, IETF 194 and ETSI efforts. One goal is to help other bodies to adopt the 195 stack as a whole, making the effort to move to an IPv6-based IOT 196 stack easier. Now, for a particular, environment, some of the 197 choices that are made in this architecture may not be relevant. For 198 instance, RPL is not required for star topologies and mesh-under 199 Layer-2 routed networks, and the 6LoWPAN compression may not be 200 sufficient for ultra-constrained cases such as some Low Power Wide 201 Area (LPWA) networks. In such cases, it is perfectly doable to adopt 202 a subset of the selection that is presented hereafter and then select 203 alternate components to complete the solution wherever needed. 205 The IETF proposes multiple techniques for implementing functions 206 related to routing, transport or security. In order to control the 207 complexity of the possible deployments and device interactions, and 208 to limit the size of the resulting object code, the architecture 209 limits the possible variations of the stack and recommends a number 210 of base elements for LLN applications. In particular, UDP [RFC0768] 211 [RFC8200] and the Constrained Application Protocol [RFC7252] (CoAP) 212 are used as the transport / binding of choice for applications and 213 management as opposed to TCP and HTTP. 215 The resulting stack is represented below: 217 +-----+-----+ 218 | COMI | 219 +-----+-----+-----+------+-------+-----+ 220 | CoAP/EDHOC/COSE | 6LoWPAN ND | RPL | 221 +-----+-----+-----+------+-------+-----+ 222 | UDP | ICMP | 223 +-----+-----+-----+-----+-------+------+----+ 224 | IPv6 | 225 +-------------------------------------------+ 226 | 6LoWPAN HC / 6LoRH | 227 +-------------------------------------------+ 228 | 6top | 229 +-------------------------------------------+ 230 | IEEE Std 802.15.4 TSCH | 231 +-------------------------------------------+ 233 Figure 1: 6TiSCH Protocol Stack 235 RPL is the routing protocol of choice for LLNs. So far, there was no 236 identified need to define a 6TiSCH specific Objective Function. The 237 Minimal 6TiSCH Configuration [RFC8180] describes the operation of RPL 238 over a static schedule used in a slotted aloha fashion, whereby all 239 active slots may be used for emission or reception of both unicast 240 and multicast frames. 242 The 6LoWPAN Header Compression [RFC6282] is used to compress the IPv6 243 and UDP headers, whereas the 6LoWPAN Routing Header (6LoRH) [RFC8138] 244 is used to compress the RPL artifacts in the IPv6 data packets, 245 including the RPL Packet Information (RPI), the IP-in-IP 246 encapsulation to/from the RPL root, and the Source Route Header (SRH) 247 in non-storing mode. 249 6TiSCH has adopted the general direction of CoAP Management Interface 250 (COMI) [I-D.ietf-core-comi] for the management of devices. This is 251 leveraged for instance for the implementation of the generic data 252 model for the 6top sublayer management interface 253 [I-D.ietf-6tisch-6top-interface]. The proposed implementation is 254 based on CoAP and CBOR, and specified in 6TiSCH Resource Management 255 and Interaction using CoAP [I-D.ietf-6tisch-coap]. 257 The Datagram Transport Layer Security (DTLS) [RFC6347] sitting either 258 under CoAP or over CoAP so as to traverse proxies, as well as 259 Ephemeral Diffie-Hellman Over COSE (EDHOC) 260 [I-D.selander-ace-cose-ecdhe], are examples of protocol that could be 261 used to protect CoAP datagrams, but the exact stack is not determined 262 at the time of this writing. 264 An overview of the the join process can be found in Section 3.7; the 265 security aspects of the join process are further detailed in 266 Section 6. 268 The 6TiSCH Operation sublayer (6top) [I-D.wang-6tisch-6top-sublayer] 269 is a sublayer of a Logical Link Control (LLC) that provides the 270 abstraction of an IP link over a TSCH MAC and schedules packets over 271 TSCH cells,as further discussed in the next sections. 273 3.2. TSCH: A Deterministic MAC Layer 275 Though at a different time scale (several orders of magnitude), both 276 IEEE Std 802.1TSN and IEEE Std 802.15.4TSCH standards provide 277 Deterministic capabilities to the point that a packet that pertains 278 to a certain flow may traverse a network from node to node following 279 a very precise schedule, as a train that enters and then leaves 280 intermediate stations at precise times along its path. With TSCH, 281 time is formatted into timeslots, and individual communication cells 282 are allocated to unicast or broadcast communication at the MAC level. 283 The time-slotted operation reduces collisions, saves energy, and 284 enables to more closely engineer the network for deterministic 285 properties. The channel hopping aspect is a simple and efficient 286 technique to combat multipath fading and external interference (for 287 example by Wi-Fi emitters). 289 6TiSCH builds on the IEEE Std 802.15.4TSCH MAC and inherits its 290 advanced capabilities to enable them in multiple environments where 291 they can be leveraged to improve automated operations. The 6TiSCH 292 Architecture also inherits the capability to perform a centralized 293 route computation to achieve deterministic properties, though it 294 relies on the IETF DetNet Architecture 295 [I-D.ietf-detnet-architecture], and IETF components such as the Path 296 Computation Element (PCE) [PCE], for the protocol aspects. 298 On top of this inheritance, 6TiSCH adds capabilities for distributed 299 routing and scheduling operations based on the RPL routing protocol 300 and capabilities to negotiate schedule adjustments between peers. 301 These distributed routing and scheduling operations simplify the 302 deployment of TSCH networks and enable wireless solutions in a larger 303 variety of use cases from operational technology in general. 304 Examples of such use-cases in industrial environments include plant 305 setup and decommissioning, as well as monitoring of lots of lesser 306 importance measurements such as corrosion and events. RPL also 307 enables mobile use cases such as mobile workers and cranes, as 308 presented in [I-D.ietf-roll-rpl-industrial-applicability]. 310 3.3. Scheduling TSCH 312 A scheduling operation attributes cells in a Time-Division- 313 Multiplexing (TDM) / Frequency-Division Multiplexing (FDM) matrix 314 called the Channel distribution/usage (CDU) to either individual 315 transmissions or as multi-access shared resources (see the 6TiSCH 316 Terminology [I-D.ietf-6tisch-terminology] for more on these terms). 317 Scheduling effectively enables multiple communications at a same time 318 in a same interference domain using different channels; but a node 319 equipped with a single radio can only transmit or receive on one 320 channel at any given point of time. 322 From the standpoint of a 6TiSCH node (at the MAC layer), its schedule 323 is the collection of the times at which it must wake up for 324 transmission, and the channels to which it should either send or 325 listen at those times. The schedule is expressed as one or more 326 slotframes that repeat over and over. Slotframes may collide and 327 require a device to wake at a same time, in which case a priority 328 indicates which slotframe is actually activated. 330 The 6top sublayer hides the complexity of the schedule to the upper 331 layers. The Link that IP may utilize between the 6TiSCH node and a 332 peer may in fact be composed of a pair of cell bundles, one to 333 receive and one to transmit. Some of the cells may be shared, in 334 which case the 6top sublayer must perform some arbitration. 336 The 6TiSCH architecture identifies four ways a schedule can be 337 managed and CDU cells can be allocated: Static Scheduling, Neighbor- 338 to-Neighbor Scheduling, Remote Monitoring and Schedule Management, 339 and Hop-by-hop Scheduling. 341 Static Scheduling: This refers to the minimal 6TiSCH operation 342 whereby a static schedule is configured for the whole network for 343 use in a slotted-aloha fashion. The static schedule is 344 distributed through the native methods in the TSCH MAC layer. 345 This operation leverages RPL to maintain a loopless graph for 346 routing and time distribution. It is specified in the Minimal 347 6TiSCH Configuration [RFC8180] specification. and does not 348 preclude other scheduling operations to co-exist on a same 6TiSCH 349 network. 351 Neighbor-to-Neighbor Scheduling: This refers to the dynamic 352 adaptation of the bandwidth of the Links that are used for IPv6 353 traffic between adjacent routers. Scheduling Functions such as 354 SF0 [I-D.ietf-6tisch-6top-sf0] influence the operation of the 6top 355 sublayer [I-D.wang-6tisch-6top-sublayer] to add and remove cells 356 in peers schedule, using the 6top protocol 357 [I-D.ietf-6tisch-6top-protocol] for the negotiation on the MAC 358 resources. 360 Remote Monitoring and Schedule Management: This refers to the 361 central computation of a schedule and the capability to forward a 362 frame based on the cell of arrival. In that case, the related 363 portion of the device schedule as well as other device resources 364 are managed by an abstract Network Management Entity (NME), which 365 may cooperate with the PCE in order to minimize the interaction 366 with and the load on the constrained device. This model is the 367 TSCH adaption of the DetNet Architecture 368 [I-D.ietf-detnet-architecture], and it enables Traffic Engineering 369 with deterministic properties. 371 Hop-by-hop Scheduling: This refers to the possibility to reserves 372 cells along a path for a particular flow using a distributed 373 mechanism. 375 It is not expected that all use cases will require all those 376 mechanisms. Static Scheduling with minimal configuration one is the 377 only one that is expected in all implementations, since it provides a 378 simple and solid basis for convergecast routing and time 379 distribution. 381 A deeper dive in those mechanisms can be found in Section 4.4. 383 3.4. Routing and Forwarding Over TSCH 385 6TiSCH leverages the RPL routing protocol for interoperable 386 distributed routing operations. RPL is applicable to Static 387 Scheduling and Neighbor-to-Neighbor Scheduling. The architecture 388 also supports a centralized routing model for Remote Monitoring and 389 Schedule Management. It is expected that a routing protocol that is 390 more optimized for point-to-point routing than RPL, such as the 391 Reactive Discovery of Point-to-Point Routes in Low-Power and Lossy 392 Networks [RFC6997](P2P RPL), or the Ad Hoc On-demand Distance Vector 393 Routing (AODV) [I-D.ietf-manet-aodvv2] will be selected for Hop-by- 394 hop Scheduling. 396 The 6TiSCH architecture supports three different forwarding models, 397 the classical IPv6 Forwarding, where the node selects a feasible 398 successor at Layer-3 on a per packet basis and based on its routing 399 table, G-MPLS Track Forwarding, which switches a frame received at a 400 particular Timeslot into another Timeslot at Layer-2, and 6LoWPAN 401 Fragment Forwarding, which allows to forward individual 6loWPAN 402 fragments along the route set by the first fragment. 404 IPv6 Forwarding: This is the classical IP forwarding model, with a 405 Routing Information Based (RIB) that is installed by the RPL 406 routing protocol and used to select a feasible successor per 407 packet. The packet is placed on an outgoing Link, that the 6top 408 layer maps into a (Layer-3) bundle of cells, and scheduled for 409 transmission based on QoS parameters. On top of RPL, this model 410 also applies to any routing protocol which may be operated in the 411 6TiSCH network, and corresponds to all the distributed scheduling 412 models, Static, Neighbor-to-Neighbor and Hop-by-Hop Scheduling. 414 G-MPLS Track Forwarding: This model corresponds to the Remote 415 Monitoring and Schedule Management. In this model, A central 416 controller (hosting a PCE) computes and installs the schedules in 417 the devices per flow. The incoming (Layer-2) bundle of cells from 418 the previous node along the path determines the outgoing (Layer-2) 419 bundle towards the next hop for that flow as determined by the 420 PCE. The programmed sequence for bundles is called a Track and 421 can assume shapes that are more complex than a simple direct 422 sequence of nodes. 424 6LoWPAN Fragment Forwarding: This is an hybrid model that derives 425 from IPv6 forwarding for the case where packets must be fragmented 426 at the 6LoWPAN sublayer. The first fragment is forwarded like any 427 IPv6 packet and leaves a state in the intermediate hops to enable 428 forwarding of the next fragments that do not have a IP header 429 without the need to recompose the packet at every hop. 431 This can be broadly summarized in the following table: 433 +---------------------+------------+-----------------------------------+ 434 | Forwarding Model | Routing | Scheduling | 435 +=====================+============+===================================+ 436 |G-MPLS Track Fwrding | PCE |Remote Monitoring and Schedule Mgt | 437 +---------------------+------------+-----------------------------------+ 438 | | | Static (Minimal Configuration) | 439 + classical IPv6 + RPL +-----------------------------------+ 440 | / | | Neighbor-to-Neighbor (SF0) | 441 + 6LoWPAN Fragment F. +------------+-----------------------------------+ 442 | |Reactive P2P| Hop-by-Hop (TBD) | 443 +---------------------+------------+-----------------------------------+ 445 Figure 2: Routing, Forwarding and Scheduling 447 3.5. A Non-Broadcast Multi-Access Radio Mesh Network 449 A 6TiSCH network is an IPv6 [RFC8200] subnet which, in its basic 450 configuration, is a single Low Power Lossy Network (LLN) operating 451 over a synchronized TSCH-based mesh. 453 Inside a 6TiSCH LLN, nodes rely on 6LoWPAN Header Compression 454 (6LoWPAN HC) [RFC6282] to encode IPv6 packets. From the perspective 455 of the network layer, a single LLN interface (typically an IEEE Std 456 802.15.4-compliant radio) may be seen as a collection of Links with 457 different capabilities for unicast or multicast services. 459 6TiSCH nodes are not necessarily reachable from one another at 460 Layer-2 and an LLN may span over multiple links. This effectively 461 forms an homogeneous non-broadcast multi-access (NBMA) subnet, which 462 is beyond the scope of existing IPv6 ND methods. Extensions to IPv6 463 ND have to be introduced. 465 Within that subnet, neighbor devices are discovered with 6LoWPAN 466 Neighbor Discovery [RFC6775] (6LoWPAN ND), whereas RPL [RFC6550] 467 enables routing in the so called Route Over fashion, either in 468 storing (stateful) or non-storing (stateless, with routing headers) 469 mode. 471 ---+-------- ............ ------------ 472 | External Network | 473 | +-----+ 474 +-----+ | NME | 475 | | LLN Border | | 476 | | router +-----+ 477 +-----+ 478 o o o 479 o o o o o 480 o o 6LoWPAN + RPL o o 481 o o o o 482 o o 484 Figure 3: Basic Configuration of a 6TiSCH Network 486 6TiSCH nodes join the mesh by attaching to nodes that are already 487 members of the mesh. Some nodes act as routers for 6LoWPAN ND and 488 RPL operations, as detailed in Section 4.1. Security aspects of the 489 join process by which a device obtains access to the network are 490 discussed in Section 6. 492 With TSCH, devices are time-synchronized at the MAC level. The use 493 of a particular RPL Instance for time synchronization is discussed in 494 Section 4.2.4. With this mechanism, the time synchronization starts 495 at the RPL root and follows the RPL DODAGs with no timing loop. 497 RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) 498 within Instances of the protocol, each Instance being associated with 499 an Objective Function (OF) to form a routing topology. A particular 500 6TiSCH node, the LLN Border Router (LBR), acts as RPL root, 6LoWPAN 501 HC terminator, and Border Router for the LLN to the outside. The LBR 502 is usually powered. More on RPL Instances can be found in section 503 3.1 of RPL [RFC6550], in particular "3.1.2. RPL Identifiers" and 504 "3.1.3. Instances, DODAGs, and DODAG Versions". RPL adds artifacts 505 in the data packets that are compressed with a 6LoWPAN addition 6LoRH 506 [RFC8138]. 508 Additional routing and scheduling protocols may be deployed to 509 establish on-demand Peer-to-Peer routes with particular 510 characteristics inside the 6TiSCH network. This may be achieved in a 511 centralized fashion by a PCE [PCE] that programs both the routes and 512 the schedules inside the 6TiSCH nodes, or by in a distributed fashion 513 using a reactive routing protocol and a Hop-by-Hop scheduling 514 protocol. 516 A Backbone Router may be connected to the node that acts as RPL root 517 and / or 6LoWPAN 6LBR and provides connectivity to the larger campus 518 / factory plant network over a high speed backbone or a back-haul 519 link. A Backbone Router may perform proxy IPv6 Neighbor Discovery 520 (ND) [RFC4861] operations over the backbone on behalf of the 6TiSCH 521 nodes so they can share a same IPv6 subnet and appear to be connected 522 to the same backbone as classical devices. A Backbone Router may 523 alternatively redistribute the registration in a routing protocol 524 such as OSPF [RFC5340] or BGP [RFC2545], or inject them in a mobility 525 protocol such as MIPv6 [RFC6275], NEMO [RFC3963], or LISP [RFC6830]. 527 This architecture expects that a 6LoWPAN node can connect as a leaf 528 to a RPL network, where the leaf support is the minimal functionality 529 to connect as a host to a RPL network without the need to participate 530 to the full routing protocol. The architecture also expects that a 531 6LoWPAN node that is not aware at all of the RPL protocol may also 532 connect as a host but the specifications for this to happen are not 533 available at the time of this writing. 535 3.6. A Multi-Link Subnet Model 537 An extended configuration of the subnet comprises multiple LLNs. The 538 LLNs are interconnected and synchronized over a backbone, that can be 539 wired or wireless. The backbone can be a classical IPv6 network, 540 with Neighbor Discovery operating as defined in [RFC4861] and 541 [RFC4862]. This architecture requires work to standardize the the 542 registration of 6LoWPAN nodes to the Backbone Routers. 544 In the extended configuration, a Backbone Router (6BBR) operates as 545 described in [I-D.ietf-6lo-backbone-router]. The 6BBR performs ND 546 proxy operations between the registered devices and the classical ND 547 devices that are located over the backbone. 6TiSCH 6BBRs synchronize 548 with one another over the backbone, so as to ensure that the multiple 549 LLNs that form the IPv6 subnet stay tightly synchronized. 551 ---+-------- ............ ------------ 552 | External Network | 553 | +-----+ 554 | +-----+ | NME | 555 +-----+ | +-----+ | | 556 | | Router | | PCE | +-----+ 557 | | +--| | 558 +-----+ +-----+ 559 | | 560 | Subnet Backbone | 561 +--------------------+------------------+ 562 | | | 563 +-----+ +-----+ +-----+ 564 | | Backbone | | Backbone | | Backbone 565 o | | router | | router | | router 566 +-----+ +-----+ +-----+ 567 o o o o o 568 o o o o o o o o o o o 569 o o o LLN o o o o 570 o o o o o o o o o o o o 572 Figure 4: Extended Configuration of a 6TiSCH Network 574 As detailed in Section 4.1 the 6LoWPAN ND 6LBR and the root of the 575 RPL network need to be collocated and share information about the 576 devices that is learned through either protocol but not both. The 577 combined RPL root and 6LBR may be collocated with the 6BBR, or 578 directly attached to the 6BBR. In the latter case, it leverages the 579 extended registration process defined in 580 [I-D.ietf-6lo-backbone-router] to proxy the 6LoWPAN ND registration 581 to the 6BBR on behalf of the LLN nodes, so that the 6BBR may in turn 582 perform proxy classical ND operations over the backbone. 584 If the Backbone is Deterministic (such as defined by the Time 585 Sensitive Networking WG at IEEE), then the Backbone Router ensures 586 that the end-to-end deterministic behavior is maintained between the 587 LLN and the backbone. The DetNet Architecture 588 [I-D.ietf-detnet-architecture] studies Layer-3 aspects of 589 Deterministic Networks, and covers networks that span multiple 590 Layer-2 domains. 592 3.7. Join Process and Registration 594 As detailed in Section 4.1 the combined 6LoWPAN ND 6LBR and root of 595 the RPL network learn information such as the device Unique ID (from 596 6LoWPAN ND) and the updated Sequence Number (from RPL), and perform 597 6LoWPAN ND proxy registration to the 6BBR of behalf of the LLN nodes. 598 Figure 5 illustrates the periodic signaling that starts at the leaf 599 node with 6LoWPAN ND, is then carried over RPL to the RPL root, and 600 then to the 6BBR. Efficient ND being an adaptation of 6LoWPAN ND, it 601 makes sense to keep those two homogeneous in the way they use the 602 source and the target addresses in the Neighbor Solicitation (NS) 603 messages for registration, as well as in the options that they use 604 for that process. 606 6LoWPAN Node 6LR 6LBR 6BBR 607 (RPL leaf) (router) (root) 608 | | | | 609 | 6LoWPAN ND |6LoWPAN ND+RPL | Efficient ND | IPv6 ND 610 | LLN link |Route-Over mesh| IPv6 link | Backbone 611 | | | | 612 | NS(ARO) | | | 613 |-------------->| | | 614 | 6LoWPAN ND | DAR (then DAO)| | 615 | |-------------->| | 616 | | | NS(ARO) | 617 | | |-------------->| 618 | | | | DAD 619 | | | |------> 620 | | | | 621 | | | NA(ARO) | 622 | | |<--------------| 623 | | DAC | | 624 | |<--------------| | 625 | NA(ARO) | | | 626 |<--------------| | | 628 Figure 5: (Re-)Registration Flow over Multi-Link Subnet 630 As the network builds up, a node should start as a leaf to join the 631 RPL network, and may later turn into both a RPL-capable router and a 632 6LR, so as to accept leaf nodes to recursively join the network. 634 3.8. Dependencies on Work In Progress 636 In order to control the complexity and the size of the 6TiSCH work, 637 the architecture and the associated IETF work are staged and the WG 638 is expected to recharter multiple times. This document is 639 incremented as the work progresses following the evolution of the WG 640 charter and the availability of dependent work. The intent is to 641 publish when the WG concludes. 643 At the time of this writing: 645 o The architecture of the operation of RPL over a dynamic schedule 646 is being studied at 6TISCH as the second iteration of the charter. 648 o The need of a reactive routing protocol to establish on-demand 649 constraint-optimized routes and a reservation protocol to 650 establish Layer-3 Tracks is being discussed at 6TiSCH but not 651 chartered for. 653 o The components and protocols that are required to implement this 654 stage of architecture are being standardized at the IETF. An 655 Update to 6LoWPAN ND [I-D.ietf-6lo-rfc6775-update] covers the 656 evolution of 6LoWPAN Neighbor Discovery that is needed to 657 implement the Backbone Router [I-D.ietf-6lo-backbone-router]. In 658 addition the protection of registered addresses against 659 impersonation and take over can be guaranteed by Address Protected 660 Neighbor Discovery for Low-power and Lossy Networks 661 [I-D.ietf-6lo-ap-nd]. 663 o The work on centralized Track computation is deferred to a 664 subsequent iteration of the 6TiSCH charter. The idea at the time 665 of this writing is that 6TiSCH will apply the concepts of 666 Deterministic Networking on a Layer-3 network. The 6TiSCH 667 Architecture should thus inherit from the DetNet 668 [I-D.ietf-detnet-architecture] architecture and thus depends on 669 it. The Path Computation Element (PCE) should be a core component 670 of that architecture. Around the PCE, a protocol such as an 671 extension to a TEAS [TEAS] protocol will be required to expose the 672 6TiSCH node capabilities and the network peers to the PCE, and a 673 protocol such as a lightweight PCEP or an adaptation of CCAMP 674 [CCAMP] G-MPLS formats and procedures will be used to publish the 675 Tracks, as computed by the PCE, to the 6TiSCH nodes. 677 o BIER-TE-based OAM, Replication and Elimination 678 [I-D.thubert-bier-replication-elimination] leverages Bit Index 679 Explicit Replication - Traffic Engineering to control in the data 680 plane the DetNet Replication and Elimination activities, and to 681 provide traceability on links where replication and loss happen, 682 in a manner that is abstract to the forwarding information, 683 whereas a 6loRH for BitStrings [I-D.thubert-6lo-bier-dispatch] 684 proposes a 6LoWPAN compression for the BIER Bitstring based on 685 6LoWPAN Routing Header [RFC8138]. 687 o The security model and in particular the join process depends on 688 the ANIMA Bootstrapping Remote Secure Key Infrastructures (BRSKI) 689 [I-D.ietf-anima-bootstrapping-keyinfra] in order to enable zero- 690 touch security provisionning; for highly constrained nodes, a 691 minimal model based on pre-shared keys (PSK) is also available. 693 o The current charter positions 6TiSCH on IEEE Std 802.15.4 only. 694 Though most of the design should be portable on other link types, 695 6TiSCH has a strong dependency on IEEE Std 802.15.4 and its 696 evolution. At the time of this writing, a revision of the IEEE 697 Std 802.15.4 standard is expected early 2016. That revision 698 should integrate TSCH as well as other amendments and fixes into 699 the main specification. The impact on this Architecture should be 700 minimal to non-existent, but deeper work such as 6top and security 701 may be impacted. A 6TiSCH Interest Group was formed at IEEE to 702 maintain the synchronization and help foster work at the IEEE 703 should 6TiSCH demand it. 705 o Work is being proposed at IEEE (802.15.12 PAR) for an LLC that 706 would logically include the 6top sublayer. The interaction with 707 the 6top sublayer and the Scheduling Functions described in this 708 document are yet to be defined. 710 o ISA100 [ISA100] Common Network Management (CNM) is another 711 external work of interest for 6TiSCH. The group, referred to as 712 ISA100.20, defines a Common Network Management framework that 713 should enable the management of resources that are controlled by 714 heterogeneous protocols such as ISA100.11a [ISA100.11a], 715 WirelessHART [WirelessHART], and 6TiSCH. Interestingly, the 716 establishment of 6TiSCH Deterministic paths, called Tracks, are 717 also in scope, and ISA100.20 is working on requirements for 718 DetNet. 720 4. Architecture Components 722 4.1. 6LoWPAN (and RPL) 724 4.1.1. RPL Leaf Support in 6LoWPAN ND 726 RPL needs a set of information in order to advertise a leaf node 727 through a DAO message and establish reachability. 729 At the bare minimum the leaf device must provide a sequence number 730 that matches the RPL specification in section 7. Section 5.3 of 731 [I-D.ietf-6lo-backbone-router], on the Extended Address Registration 732 Option (EARO), already incorporates that addition with a new field in 733 the option called the Transaction ID. 735 If for some reason the node is aware of RPL topologies, then 736 providing the RPL InstanceID for the instances to which the node 737 wishes to participate would be a welcome addition. In the absence of 738 such information, the RPL router must infer the proper instanceID 739 from external rules and policies. 741 On the backbone, the InstanceID is expected to be mapped onto a an 742 overlay that matches the instanceID, for instance a VLANID. 744 This architecture leverages [I-D.ietf-6lo-backbone-router] that 745 extends 6LoWPAN ND [RFC6775] to carry the counter as an abstract 746 Transaction ID (TID). 748 4.1.2. RPL Root And 6LBR 750 6LoWPAN ND is unclear on how the 6LBR is discovered, and how the 751 liveliness of the 6LBR is asserted over time. On the other hand, the 752 discovery and liveliness of the RPL root are obtained through the RPL 753 protocol. This architecture suggests to collocate these functions by 754 default, in which case the discovery of the 6LBR is automatic for RPL 755 leaves. 757 When 6LoWPAN ND is coupled with RPL, the 6LBR and RPL root 758 functionalities are co-located in order that the address of the 6LBR 759 be indicated by RPL DIO messages and to associate the unique ID from 760 the DAR/DAC exchange with the state that is maintained by RPL. The 761 DAR/DAC exchange becomes a preamble to the DAO messages that are used 762 from then on to reconfirm the registration, thus eliminating a 763 duplication of functionality between DAO and DAR messages. 765 Even though the root of the RPL network is integrated with the 6LBR, 766 it is logically separated from the Backbone Router (6BBR) that is 767 used to connect the 6TiSCH LLN to the backbone. This way, the root 768 has all information from 6LoWPAN ND and RPL about the LLN devices 769 attached to it. 771 This architecture also expects that the root of the RPL network 772 (proxy-)registers the 6TiSCH nodes on their behalf to the 6BBR, for 773 whatever operation the 6BBR performs on the backbone, such as ND 774 proxy, or redistribution in a routing protocol. This relies on an 775 extension of the 6LoWPAN ND registration described in 776 [I-D.ietf-6lo-backbone-router]. 778 This model supports the movement of a 6TiSCH device across the Multi- 779 Link Subnet, and allows the proxy registration of 6TiSCH nodes deep 780 into the 6TiSCH LLN by the 6LBR / RPL root. This requires an 781 alteration from [RFC6775] whereby the Target Address of the NS 782 message is registered as opposed to the Source, which, in the case of 783 a proxy registration, is that of the 6LBR / RPL root itself. 785 4.2. TSCH and 6top 787 4.2.1. 6top 789 6top is a logical link control sitting between the IP layer and the 790 TSCH MAC layer, which provides the link abstraction that is required 791 for IP operations. The 6top operations are specified in 792 [I-D.ietf-6tisch-6top-protocol]. In particular, 6top provides a 793 management interface that enables an external management entity to 794 schedule cells and slotFrames, and allows the addition of 795 complementary functionality, for instance to support a dynamic 796 schedule management based on observed resource usage as discussed in 797 Section 4.4.2. 799 The 6top data model and management interfaces are further discussed 800 in Section 4.4.3. 802 4.2.1.1. Hard Cells 804 The architecture defines "soft" cells and "hard" cells. "Hard" cells 805 are owned and managed by an separate scheduling entity (e.g. a PCE) 806 that specifies the slotOffset/channelOffset of the cells to be 807 added/moved/deleted, in which case 6top can only act as instructed, 808 and may not move hard cells in the TSCH schedule on its own. 810 4.2.1.2. Soft Cells 812 6top contains a monitoring process which monitors the performance of 813 cells, and can move a cell in the TSCH schedule when it performs 814 poorly. This is only applicable to cells which are marked as "soft". 815 To reserve a soft cell, the higher layer does not indicate the exact 816 slotOffset/channelOffset of the cell to add, but rather the resulting 817 bandwidth and QoS requirements. When the monitoring process triggers 818 a cell reallocation, the two neighbor devices communicating over this 819 cell negotiate its new position in the TSCH schedule. 821 4.2.2. Scheduling Functions and the 6P protocol 823 In the case of soft cells, the cell management entity that controls 824 the dynamic attribution of cells to adapt to the dynamics of variable 825 rate flows is called a Scheduling Function (SF). There may be 826 multiple SFs with more or less aggressive reaction to the dynamics of 827 the network. The 6TiSCH 6top Scheduling Function Zero (SF0) 828 [I-D.ietf-6tisch-6top-sf0] provides a simple scheduling function that 829 can be used by default by devices that support dynamic scheduling of 830 soft cells. 832 The SF may be seen as divided between an upper bandwidth adaptation 833 logic that is not aware of the particular technology that is used to 834 obtain and release bandwidth, and an underlying service that maps 835 those needs in the actual technology, which means mapping the 836 bandwidth onto cells in the case of TSCH. 838 +------------------------+ +------------------------+ 839 | Scheduling Function | | Scheduling Function | 840 | Bandwidth adaptation | | Bandwidth adaptation | 841 +------------------------+ +------------------------+ 842 | Scheduling Function | | Scheduling Function | 843 | TSCH mapping to cells | | TSCH mapping to cells | 844 +------------------------+ +------------------------+ 845 | 6top cells negotiation | <- 6P -> | 6top cells negotiation | 846 +------------------------+ +------------------------+ 847 Device A Device B 849 Figure 6: SF/6P stack in 6top 851 The SF relies on 6top services that implement the 6top Protocol (6P) 852 [I-D.ietf-6tisch-6top-protocol] to negotiate the precise cells that 853 will be allocated or freed based on the schedule of the peer. It may 854 be for instance that a peer wants to use a particular time slot that 855 is free in its schedule, but that timeslot is already in use by the 856 other peer for a communication with a third party on a different 857 cell. The 6P protocol enables the peers to find an agreement in a 858 transactional manner that ensures the final consistency of the nodes 859 state. 861 4.2.3. 6top and RPL Objective Function operations 863 An implementation of a RPL [RFC6550] Objective Function (OF), such as 864 the RPL Objective Function Zero (OF0) [RFC6552] that is used in the 865 Minimal 6TiSCH Configuration [RFC8180] to support RPL over a static 866 schedule, may leverage, for its internal computation, the information 867 maintained by 6top. 869 Most OFs require metrics about reachability, such as the ETX. 6top 870 creates and maintains an abstract neighbor table, and this state may 871 be leveraged to feed an OF and/or store OF information as well. In 872 particular, 6top creates and maintains an abstract neighbor table. A 873 neighbor table entry contains a set of statistics with respect to 874 that specific neighbor including the time when the last packet has 875 been received from that neighbor, a set of cell quality metrics (e.g. 876 RSSI or LQI), the number of packets sent to the neighbor or the 877 number of packets received from it. This information can be obtained 878 through 6top management APIs as detailed in the 6top sublayer 879 specification [I-D.wang-6tisch-6top-sublayer] and used for instance 880 to compute a Rank Increment that will determine the selection of the 881 preferred parent. 883 6top provides statistics about the underlying layer so the OF can be 884 tuned to the nature of the TSCH MAC layer. 6top also enables the RPL 885 OF to influence the MAC behaviour, for instance by configuring the 886 periodicity of IEEE Std 802.15.4 Extended Beacons (EB's). By 887 augmenting the EB periodicity, it is possible to change the network 888 dynamics so as to improve the support of devices that may change 889 their point of attachment in the 6TiSCH network. 891 Some RPL control messages, such as the DODAG Information Object (DIO) 892 are ICMPv6 messages that are broadcast to all neighbor nodes. With 893 6TiSCH, the broadcast channel requirement is addressed by 6top by 894 configuring TSCH to provide a broadcast channel, as opposed to, for 895 instance, piggybacking the DIO messages in Enhance Beacons. 896 Consideration was given towards finding a way to embed the Route 897 Advertisements and the RPL DIO messages (both of which are multicast) 898 into the IEEE Std 802.15.4 Enhanced Beacons. It was determined that 899 this produced undue timer coupling among layers, that the resulting 900 packet size was potentially too large, and required it is not yet 901 clear that there is any need for Enhanced Beacons in a production 902 network. 904 4.2.4. Network Synchronization 906 Nodes in a TSCH network must be time synchronized. A node keeps 907 synchronized to its time source neighbor through a combination of 908 frame-based and acknowledgment-based synchronization. In order to 909 maximize battery life and network throughput, it is advisable that 910 RPL ICMP discovery and maintenance traffic (governed by the trickle 911 timer) be somehow coordinated with the transmission of time 912 synchronization packets (especially with enhanced beacons). This 913 could be achieved through an interaction of the 6top sublayer and the 914 RPL objective Function, or could be controlled by a management 915 entity. 917 Time distribution requires a loop-less structure. Nodes taken in a 918 synchronization loop will rapidly desynchronize from the network and 919 become isolated. It is expected that a RPL DAG with a dedicated 920 global Instance is deployed for the purpose of time synchronization. 921 That Instance is referred to as the Time Synchronization Global 922 Instance (TSGI). The TSGI can be operated in either of the 3 modes 923 that are detailed in section 3.1.3 of RPL [RFC6550], "Instances, 924 DODAGs, and DODAG Versions". Multiple uncoordinated DODAGs with 925 independent roots may be used if all the roots share a common time 926 source such as the Global Positioning System (GPS). In the absence 927 of a common time source, the TSGI should form a single DODAG with a 928 virtual root. A backbone network is then used to synchronize and 929 coordinate RPL operations between the backbone routers that act as 930 sinks for the LLN. Optionally, RPL's periodic operations may be used 931 to transport the network synchronization. This may mean that 6top 932 would need to trigger (override) the trickle timer if no other 933 traffic has occurred for such a time that nodes may get out of 934 synchronization. 936 A node that has not joined the TSGI advertises a MAC level Join 937 Priority of 0xFF to notify its neighbors that is not capable of 938 serving as time parent. A node that has joined the TSGI advertises a 939 MAC level Join Priority set to its DAGRank() in that Instance, where 940 DAGRank() is the operation specified in section 3.5.1 of [RFC6550], 941 "Rank Comparison". 943 A root is configured or obtains by some external means the knowledge 944 of the RPLInstanceID for the TSGI. The root advertises its DagRank 945 in the TSGI, that must be less than 0xFF, as its Join Priority (JP) 946 in its IEEE Std 802.15.4 Extended Beacons (EB). We'll note that the 947 JP is now specified between 0 and 0x3F leaving 2 bits in the octet 948 unused in the IEEE Std 802.15.4e specification. After consultation 949 with IEEE authors, it was asserted that 6TiSCH can make a full use of 950 the octet to carry an integer value up to 0xFF. 952 A node that reads a Join Priority of less than 0xFF should join the 953 neighbor with the lesser Join Priority and use it as time parent. If 954 the node is configured to serve as time parent, then the node should 955 join the TSGI, obtain a Rank in that Instance and start advertising 956 its own DagRank in the TSGI as its Join Priority in its EBs. 958 4.2.5. SlotFrames and Priorities 960 6TiSCH enables in essence the capability to use IPv6 over a MAC layer 961 that enables to schedule some of the transmissions. In order to 962 ensure that the medium is free of contending packets when time 963 arrives for a scheduled transmission, a window of time is defined 964 around the scheduled transmission time where the medium must be free 965 of contending energy. 967 One simple way to obtain such a window is to format time and 968 frequencies in cells of transmission of equal duration. This is the 969 method that is adopted in IEEE Std 802.15.4 TSCH as well as the Long 970 Term Evolution (LTE) of cellular networks. 972 In order to describe that formatting of time and frequencies, the 973 6TiSCH architecture defines a global concept that is called a Channel 974 Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of 975 cells with an height equal to the number of available channels 976 (indexed by ChannelOffsets) and a width (in timeslots) that is the 977 period of the network scheduling operation (indexed by slotOffsets) 978 for that CDU matrix. The size of a cell is a timeslot duration, and 979 values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to 980 accommodate for the transmission of a frame and an ack, including the 981 security validation on the receive side which may take up to a few 982 milliseconds on some device architecture. 984 A CDU matrix iterates over and over with a pseudo-random rotation 985 from an epoch time. In a given network, there might be multiple CDU 986 matrices that operate with different width, so they have different 987 durations and represent different periodic operations. It is 988 recommended that all CDU matrices in a 6TiSCH domain operate with the 989 same cell duration and are aligned, so as to reduce the chances of 990 interferences from slotted-aloha operations. The knowledge of the 991 CDU matrices is shared between all the nodes and used in particular 992 to define slotFrames. 994 A slotFrame is a MAC-level abstraction that is common to all nodes 995 and contains a series of timeslots of equal length and precedence. 996 It is characterized by a slotFrame_ID, and a slotFrame_size. A 997 slotFrame aligns to a CDU matrix for its parameters, such as number 998 and duration of timeslots. 1000 Multiple slotFrames can coexist in a node schedule, i.e., a node can 1001 have multiple activities scheduled in different slotFrames, based on 1002 the precedence of the 6TiSCH topologies. The slotFrames may be 1003 aligned to different CDU matrices and thus have different width. 1004 There is typically one slotFrame for scheduled traffic that has the 1005 highest precedence and one or more slotFrame(s) for RPL traffic. The 1006 timeslots in the slotFrame are indexed by the SlotOffset; the first 1007 cell is at SlotOffset 0. 1009 When a packet is received from a higher layer for transmission, 6top 1010 inserts that packet in the outgoing queue which matches the packet 1011 best (Differentiated Services [RFC2474] can therefore be used). At 1012 each scheduled transmit slot, 6top looks for the frame in all the 1013 outgoing queues that best matches the cells. If a frame is found, it 1014 is given to the TSCH MAC for transmission. 1016 4.2.6. Distributing the reservation of cells 1018 6TiSCH expects a high degree of scalability together with a 1019 distributed routing functionality based on RPL. To achieve this 1020 goal, the spectrum must be allocated in a way that allows for spatial 1021 reuse between zones that will not interfere with one another. In a 1022 large and spatially distributed network, a 6TiSCH node is often in a 1023 good position to determine usage of spectrum in its vicinity. 1025 Use cases for distributed routing are often associated with a 1026 statistical distribution of best-effort traffic with variable needs 1027 for bandwidth on each individual link. With 6TiSCH, the abstraction 1028 of an IPv6 link is implemented as a pair of bundles of cells, one in 1029 each direction; the size of a bundle is optimal when both the energy 1030 wasted idle listening and the packet drops due to congestion loss are 1031 minimized. This can be maintained if the number of cells in a bundle 1032 is adapted dynamically, and with enough reactivity, to match the 1033 variations of best-effort traffic. In turn, the agility to fulfill 1034 the needs for additional cells improves when the number of 1035 interactions with other devices and the protocol latencies are 1036 minimized. 1038 6TiSCH limits that interaction to RPL parents that will only 1039 negotiate with other RPL parents, and performs that negotiation by 1040 groups of cells as opposed to individual cells. The 6TiSCH 1041 architecture allows RPL parents to adjust dynamically, and 1042 independently from the PCE, the amount of bandwidth that is used to 1043 communicate between themselves and their children, in both 1044 directions; to that effect, an allocation mechanism enables a RPL 1045 parent to obtain the exclusive use of a portion of a CDU matrix 1046 within its interference domain. Note that a PCE is expected to have 1047 precedence in the allocation, so that a RPL parent would only be able 1048 to obtain portions that are not in-use by the PCE. 1050 The 6TiSCH architecture introduces the concept of chunks 1051 [I-D.ietf-6tisch-terminology]) to operate such spectrum distribution 1052 for a whole group of cells at a time. The CDU matrix is formatted 1053 into a set of chunks, each of them identified uniquely by a chunk-ID. 1054 The knowledge of this formatting is shared between all the nodes in a 1055 6TiSCH network. 6TiSCH also defines the process of chunk ownership 1056 appropriation whereby a RPL parent discovers a chunk that is not used 1057 in its interference domain (e.g lack of energy detected in reference 1058 cells in that chunk); then claims the chunk, and then defends it in 1059 case another RPL parent would attempt to appropriate it while it is 1060 in use. The chunk is the basic unit of ownership that is used in 1061 that process. 1063 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1064 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| 1065 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1066 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| 1067 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1068 ... 1069 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1070 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| 1071 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 1072 0 1 2 3 4 5 6 M 1074 Figure 7: CDU matrix Partitioning in Chunks 1076 As a result of the process of chunk ownership appropriation, the RPL 1077 parent has exclusive authority to decide which cell in the 1078 appropriated chunk can be used by which node in its interference 1079 domain. In other words, it is implicitly delegated the right to 1080 manage the portion of the CDU matrix that is represented by the 1081 chunk. The RPL parent may thus orchestrate which transmissions occur 1082 in any of the cells in the chunk, by allocating cells from the chunk 1083 to any form of communication (unicast, multicast) in any direction 1084 between itself and its children. Initially, those cells are added to 1085 the heap of free cells, then dynamically placed into existing 1086 bundles, in new bundles, or allocated opportunistically for one 1087 transmission. 1089 The appropriation of a chunk can also be requested explicitly by the 1090 PCE to any node. In that case, the node still may need to perform 1091 the appropriation process to validate that no other node has claimed 1092 that chunk already. After a successful appropriation, the PCE owns 1093 the cells in that chunk, and may use them as hard cells to set up 1094 Tracks. 1096 4.3. Communication Paradigms and Interaction Models 1098 [I-D.ietf-6tisch-terminology] defines the terms of Communication 1099 Paradigms and Interaction Models, which can be placed in parallel to 1100 the Information Models and Data Models that are defined in [RFC3444]. 1102 A Communication Paradigms would be an abstract view of a protocol 1103 exchange, and would come with an Information Model for the 1104 information that is being exchanged. In contrast, an Interaction 1105 Models would be more refined and could point on standard operation 1106 such as a Representational state transfer (REST) "GET" operation and 1107 would match a Data Model for the data that is provided over the 1108 protocol exchange. 1110 section 2.1.3 of [I-D.ietf-roll-rpl-industrial-applicability] and 1111 next sections discuss application-layer paradigms, such as Source- 1112 sink (SS) that is a Multipeer to Multipeer (MP2MP) model primarily 1113 used for alarms and alerts, Publish-subscribe (PS, or pub/sub) that 1114 is typically used for sensor data, as well as Peer-to-peer (P2P) and 1115 Peer-to-multipeer (P2MP) communications. Additional considerations 1116 on Duocast and its N-cast generalization are also provided. Those 1117 paradigms are frequently used in industrial automation, which is a 1118 major use case for IEEE Std 802.15.4 TSCH wireless networks with 1119 [ISA100.11a] and [WirelessHART], that provides a wireless access to 1120 [HART] applications and devices. 1122 This specification focuses on Communication Paradigms and Interaction 1123 Models for packet forwarding and TSCH resources (cells) management. 1124 Management mechanisms for the TSCH schedule at Link-layer (one-hop), 1125 Network-layer (multithop along a Track), and Application-layer 1126 (remote control) are discussed in Section 4.4. Link-layer frame 1127 forwarding interactions are discussed in Section 4.6, and Network- 1128 layer Packet routing is addressed in Section 4.7. 1130 4.4. Schedule Management Mechanisms 1132 6TiSCH uses 4 paradigms to manage the TSCH schedule of the LLN nodes: 1133 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring 1134 and scheduling management, and Hop-by-hop scheduling. Multiple 1135 mechanisms are defined that implement the associated Interaction 1136 Models, and can be combined and used in the same LLN. Which 1137 mechanism(s) to use depends on application requirements. 1139 4.4.1. Static Scheduling 1141 In the simplest instantiation of a 6TiSCH network, a common fixed 1142 schedule may be shared by all nodes in the network. Cells are 1143 shared, and nodes contend for slot access in a slotted aloha manner. 1145 A static TSCH schedule can be used to bootstrap a network, as an 1146 initial phase during implementation, or as a fall-back mechanism in 1147 case of network malfunction. This schedule is pre-established, for 1148 instance decided by a network administrator based on operational 1149 needs. It can be pre-configured into the nodes, or, more commonly, 1150 learned by a node when joining the network using standard IEEE Std 1151 802.15.4 Information Elements (IE). Regardless, the schedule remains 1152 unchanged after the node has joined a network. RPL is used on the 1153 resulting network. This "minimal" scheduling mechanism that 1154 implements this paradigm is detailed in [RFC8180]. 1156 4.4.2. Neighbor-to-neighbor Scheduling 1158 In the simplest instantiation of a 6TiSCH network described in 1159 Section 4.4.1, nodes may expect a packet at any cell in the schedule 1160 and will waste energy idle listening. In a more complex 1161 instantiation of a 6TiSCH network, a matching portion of the schedule 1162 is established between peers to reflect the observed amount of 1163 transmissions between those nodes. The aggregation of the cells 1164 between a node and a peer forms a bundle that the 6top layer uses to 1165 implement the abstraction of a link for IP. The bandwidth on that 1166 link is proportional to the number of cells in the bundle. 1168 If the size of a bundle is configured to fit an average amount of 1169 bandwidth, peak traffic is dropped. If the size is configured to 1170 allow for peak emissions, energy is be wasted idle listening. 1172 The 6top sublayer [I-D.wang-6tisch-6top-sublayer] defines a protocol 1173 for neighbor nodes to reserve soft cells to transmit to one another. 1174 Because this reservation is done without global knowledge of the 1175 schedule of nodes in the LLN, scheduling collisions are possible. 1176 6top defines a monitoring process which continuously Tracks the 1177 packet delivery ratio of soft cells. It uses these statistics to 1178 trigger the reallocation of a soft cell in the schedule, using a 1179 negotiation protocol between the neighbors nodes communicating over 1180 that cell. 1182 In the most efficient instantiations of a 6TiSCH network, the size of 1183 the bundles that implement the links may be changed dynamically in 1184 order to adapt to the need of end-to-end flows routed by RPL. An 1185 optional Scheduling Function (SF) such as SF0 1186 [I-D.ietf-6tisch-6top-sf0] is used to monitor bandwidth usage and 1187 perform requests for dynamic allocation by the 6top sublayer. The SF 1188 component is not part of the 6top sublayer. It may be collocated on 1189 the same device or may be partially or fully offloaded to an external 1190 system. 1192 Monitoring and relocation is done in the 6top layer. For the upper 1193 layer, the connection between two neighbor nodes appears as an number 1194 of cells. Depending on traffic requirements, the upper layer can 1195 request 6top to add or delete a number of cells scheduled to a 1196 particular neighbor, without being responsible for choosing the exact 1197 slotOffset/channelOffset of those cells. 1199 4.4.3. Remote Monitoring and Schedule Management 1201 The 6top interface document [I-D.ietf-6tisch-6top-interface] 1202 specifies the generic data model that can be used to monitor and 1203 manage resources of the 6top sublayer. Abstract methods are 1204 suggested for use by a management entity in the device. The data 1205 model also enables remote control operations on the 6top sublayer. 1207 The capability to interact with the node 6top sublayer from multiple 1208 hops away can be leveraged for monitoring, scheduling, or a 1209 combination of thereof. The architecture supports variations on the 1210 deployment model, and focuses on the flows rather than whether there 1211 is a proxy or a translation operation en-route. 1213 [I-D.ietf-6tisch-coap] defines an mapping of the 6top set of 1214 commands, which is described in [I-D.ietf-6tisch-6top-interface], to 1215 CoAP resources. This allows an entity to interact with the 6top 1216 layer of a node that is multiple hops away in a RESTful fashion. 1218 The entity issuing the CoAP requests can be a central scheduling 1219 entity (e.g. a PCE), a node multiple hops away with the authority to 1220 modify the TSCH schedule (e.g. the head of a local cluster), or a 1221 external device monitoring the overall state of the network (e.g. 1222 NME). It is also possible that a mapping entity on the backbone 1223 transforms a non-CoAP protocol such as PCEP into the RESTful 1224 interfaces that the 6TiSCH devices support. 1226 With respect to Centralized routing and scheduling, the 6TiSCH 1227 Architecture is (expected to be) be an extension of the detnet work 1228 Deterministic Networking Architecture [I-D.ietf-detnet-architecture], 1229 which studies Layer-3 aspects of Deterministic Networks, and covers 1230 networks that span multiple Layer-2 domains. The DetNet architecture 1231 is a form of SDN Architecture and is composed of three planes, a 1232 (User) Application Plane, a Controller Plane (where the PCE 1233 operates), and a Network Plane which in our case is the 6TiSCH LLN. 1234 The generic SDN architecture is discussed in Software-Defined 1235 Networking (SDN): Layers and Architecture Terminology [RFC7426] and 1236 is represented below: 1238 SDN Layers and Architecture Terminology per RFC 7426 1240 o--------------------------------o 1241 | | 1242 | +-------------+ +----------+ | 1243 | | Application | | Service | | 1244 | +-------------+ +----------+ | 1245 | Application Plane | 1246 o---------------Y----------------o 1247 | 1248 *-----------------------------Y---------------------------------* 1249 | Network Services Abstraction Layer (NSAL) | 1250 *------Y------------------------------------------------Y-------* 1251 | | 1252 | Service Interface | 1253 | | 1254 o------Y------------------o o---------------------Y------o 1255 | | Control Plane | | Management Plane | | 1256 | +----Y----+ +-----+ | | +-----+ +----Y----+ | 1257 | | Service | | App | | | | App | | Service | | 1258 | +----Y----+ +--Y--+ | | +--Y--+ +----Y----+ | 1259 | | | | | | | | 1260 | *----Y-----------Y----* | | *---Y---------------Y----* | 1261 | | Control Abstraction | | | | Management Abstraction | | 1262 | | Layer (CAL) | | | | Layer (MAL) | | 1263 | *----------Y----------* | | *----------Y-------------* | 1264 | | | | | | 1265 o------------|------------o o------------|---------------o 1266 | | 1267 | CP | MP 1268 | Southbound | Southbound 1269 | Interface | Interface 1270 | | 1271 *------------Y---------------------------------Y----------------* 1272 | Device and resource Abstraction Layer (DAL) | 1273 *------------Y---------------------------------Y----------------* 1274 | | | | 1275 | o-------Y----------o +-----+ o--------Y----------o | 1276 | | Forwarding Plane | | App | | Operational Plane | | 1277 | o------------------o +-----+ o-------------------o | 1278 | Network Device | 1279 +---------------------------------------------------------------+ 1281 Figure 8 1283 The PCE establishes end-to-end Tracks of hard cells, which are 1284 described in more details in Section 4.6.1. The DetNet work is 1285 expected to enable end to end Deterministic Path across heterogeneous 1286 network (e.g. a 6TiSCH LLN and an Ethernet Backbone). This model 1287 fits the 6TiSCH extended configuration, whereby a 6BBR federates 1288 multiple 6TiSCH LLN in a single subnet over a backbone that can be, 1289 for instance, Ethernet or Wi-Fi. In that model, 6TiSCH 6BBRs 1290 synchronize with one another over the backbone, so as to ensure that 1291 the multiple LLNs that form the IPv6 subnet stay tightly 1292 synchronized. 1294 If the Backbone is Deterministic, then the Backbone Router ensures 1295 that the end-to-end deterministic behavior is maintained between the 1296 LLN and the backbone. It is the responsibility of the PCE to compute 1297 a deterministic path and to end across the TSCH network and an IEEE 1298 Std 802.1 TSN Ethernet backbone, and that of DetNet to enable end-to- 1299 end deterministic forwarding. 1301 4.4.4. Hop-by-hop Scheduling 1303 A node can reserve a Track (Section 4.5) to a destination node 1304 multiple hops away by installing soft cells at each intermediate 1305 node. This forms a Track of soft cells. It is the responsibility of 1306 the 6top sublayer of each node on the Track to monitor these soft 1307 cells and trigger relocation when needed. 1309 This hop-by-hop reservation mechanism is expected to be similar in 1310 essence to [RFC3209] and/or [RFC4080]/[RFC5974]. The protocol for a 1311 node to trigger hop-by-hop scheduling is not yet defined. 1313 4.5. On Tracks 1315 4.5.1. General Behavior of Tracks 1317 The architecture introduces the concept of a Track, which is a 1318 directed path from a source 6TiSCH node to a destination 6TiSCH node 1319 across a 6TiSCH LLN. A Track is the 6TiSCH instantiation of the 1320 concept of a Deterministic Path as described in 1321 [I-D.ietf-detnet-architecture]. Constrained resources such as memory 1322 buffers are reserved for that Track in intermediate 6TiSCH nodes to 1323 avoid loss related to limited capacity. A 6TiSCH node along a Track 1324 not only knows which bundles of cells it should use to receive 1325 packets from a previous hop, but also knows which bundle(s) it should 1326 use to send packets to its next hop along the Track. 1328 A Track is composed of bundles of cells with related schedules and 1329 logical relationships and that ensure that a packet that is injected 1330 in a Track will progress in due time all the way to destination. 1331 Multiple cells may be scheduled in a Track for the transmission of a 1332 single packet, in which case the normal operation of IEEE Std 1333 802.15.4 Automatic Repeat-reQuest (ARQ) can take place; the 1334 acknowledgment may be omitted in some cases, for instance if there is 1335 no scheduled cell for a possible retry. 1337 There are several benefits for using a Track to forward a packet from 1338 a source node to the destination node. 1340 1. Track forwarding, as further described in Section 4.6.1, is a 1341 Layer-2 forwarding scheme, which introduces less process delay 1342 and overhead than Layer-3 forwarding scheme. Therefore, LLN 1343 Devices can save more energy and resource, which is critical for 1344 resource constrained devices. 1346 2. Since channel resources, i.e. bundles of cells, have been 1347 reserved for communications between 6TiSCH nodes of each hop on 1348 the Track, the throughput and the maximum latency of the traffic 1349 along a Track are guaranteed and the jitter is maintained small. 1351 3. By knowing the scheduled time slots of incoming bundle(s) and 1352 outgoing bundle(s), 6TiSCH nodes on a Track could save more 1353 energy by staying in sleep state during in-active slots. 1355 4. Tracks are protected from interfering with one another if a cell 1356 belongs to at most one Track, and congestion loss is avoided if 1357 at most one packet can be presented to the MAC to use that cell. 1358 Tracks enhance the reliability of transmissions and thus further 1359 improve the energy consumption in LLN Devices by reducing the 1360 chances of retransmission. 1362 4.5.2. Serial Track 1364 A Serial (or simple) Track is the 6TiSCH version of a circuit; a 1365 bundle of cells that are programmed to receive (RX-cells) is uniquely 1366 paired to a bundle of cells that are set to transmit (TX-cells), 1367 representing a Layer-2 forwarding state which can be used regardless 1368 of the network layer protocol. 1370 A Serial Track is thus formed end-to-end as a succession of paired 1371 bundles, a receive bundle from the previous hop and a transmit bundle 1372 to the next hop along the Track. For a given iteration of the device 1373 schedule, the effective channel of the cell is obtained by adding a 1374 pseudo-random number to the channelOffset of the cell, which results 1375 in a rotation of the frequency that used for transmission. 1377 The bundles may be computed so as to accommodate both variable rates 1378 and retransmissions, so they might not be fully used at a given 1379 iteration of the schedule. 1381 4.5.3. Complex Track with Replication and Elimination 1383 As opposed to a Serial Track that is a sequence of nodes and links, a 1384 Complex Track is shaped as a directed acyclic graph towards a 1385 destination to support multi-path forwarding and route around 1386 failures. 1388 A Complex Track may also branch off and rejoin, for the purpose of 1389 the DetNet Packet Replication and Elimination (PRE), over non 1390 congruent branches. PRE may be used to complement Layer-2 ARQ to 1391 meet industrial expectations in Packet Delivery Ratio (PDR), in 1392 particular when the Track extends beyond the 6TiSCH network in a 1393 larger DetNet network. 1395 The art of Deterministic Networks already include PRE techniques. 1396 Example standards include the Parallel Redundancy Protocol (PRP) and 1397 the High-availability Seamless Redundancy (HSR) [IEC62439]. 1399 At each 6TiSCH hop along the Track, the PCE may schedule more than 1400 one timeslot for a packet, so as to support Layer-2 retries (ARQ). 1401 It is also possible that the field device only uses the second branch 1402 if sending over the first branch fails. 1404 In the art of TSCH, a path does not necessarily support PRE but it is 1405 almost systematically multi-path. This means that a Track is 1406 scheduled so as to ensure that each hop has at least two forwarding 1407 solutions, and the forwarding decision is to try the preferred one 1408 and use the other in case of Layer-2 transmission failure as detected 1409 by ARQ. 1411 4.5.4. DetNet End-to-end Path 1413 Ultimately, DetNet should enable to extend a Track beyond the 6TiSCH 1414 LLN. Figure 9 illustrates a Track that is laid out from a field 1415 device in a 6TiSCH network to an IoT gateway that is located on an 1416 802.1 Time-Sensitive Networking (TSN) backbone. 1418 +-=-=-+ 1419 | IoT | 1420 | G/W | 1421 +-=-=-+ 1422 ^ <=== Elimination 1423 | | 1424 Track branch | | 1425 +-=-=-=-+ +-=-=-=-=+ Subnet Backbone 1426 | | 1427 +-=|-=+ +-=|-=+ 1428 | | | Backbone | | | Backbone 1429 o | | | router | | | router 1430 +-=/-=+ +-=|-=+ 1431 o / o o-=-o-=-=/ o 1432 o o-=-o-=/ o o o o o 1433 o \ / o o LLN o 1434 o v <=== Replication 1435 o 1437 Figure 9: End-to-End deterministic Track 1439 The Replication function in the 6TiSCH Node sends a copy of each 1440 packet over two different branches, and the PCE schedules each hop of 1441 both branches so that the two copies arrive in due time at the 1442 gateway. In case of a loss on one branch, hopefully the other copy 1443 of the packet still makes it in due time. If two copies make it to 1444 the IoT gateway, the Elimination function in the gateway ignores the 1445 extra packet and presents only one copy to upper layers. 1447 4.5.5. Cell Reuse 1449 The 6TiSCH architecture provides means to avoid waste of cells as 1450 well as overflows in the transmit bundle pof a Track, as follows: 1452 In one hand, a TX-cell that is not needed for the current 1453 iteration may be reused opportunistically on a per-hop basis for 1454 routed packets. When all of the frame that were received for a 1455 given Track are effectively transmitted, any available TX-cell for 1456 that Track can be reused for upper layer traffic for which the 1457 next-hop router matches the next hop along the Track. In that 1458 case, the cell that is being used is effectively a TX-cell from 1459 the Track, but the short address for the destination is that of 1460 the next-hop router. It results that a frame that is received in 1461 a RX-cell of a Track with a destination MAC address set to this 1462 node as opposed to broadcast must be extracted from the Track and 1463 delivered to the upper layer (a frame with an unrecognized 1464 destination MAC address is dropped at the lower MAC layer and thus 1465 is not received at the 6top sublayer). 1467 On the other hand, it might happen that there are not enough TX- 1468 cells in the transmit bundle to accommodate the Track traffic, for 1469 instance if more retransmissions are needed than provisioned. In 1470 that case, the frame can be placed for transmission in the bundle 1471 that is used for Layer-3 traffic towards the next hop along the 1472 Track as long as it can be routed by the upper layer, that is, 1473 typically, if the frame transports an IPv6 packet. The MAC 1474 address should be set to the next-hop MAC address to avoid 1475 confusion. It results that a frame that is received over a 1476 Layer-3 bundle may be in fact associated to a Track. In a 1477 classical IP link such as an Ethernet, off-Track traffic is 1478 typically in excess over reservation to be routed along the non- 1479 reserved path based on its QoS setting. But with 6TiSCH, since 1480 the use of the Layer-3 bundle may be due to transmission failures, 1481 it makes sense for the receiver to recognize a frame that should 1482 be re-Tracked, and to place it back on the appropriate bundle if 1483 possible. A frame should be re-Tracked if the Per-Hop-Behavior 1484 group indicated in the Differentiated Services Field of the IPv6 1485 header is set to Deterministic Forwarding, as discussed in 1486 Section 4.7.1. A frame is re-Tracked by scheduling it for 1487 transmission over the transmit bundle associated to the Track, 1488 with the destination MAC address set to broadcast. 1490 4.6. Forwarding Models 1492 By forwarding, this specification means the per-packet operation that 1493 allows to deliver a packet to a next hop or an upper layer in this 1494 node. Forwarding is based on pre-existing state that was installed 1495 as a result of a routing computation Section 4.7. 6TiSCH supports 1496 three different forwarding model, G-MPLS Track Forwarding (TF), 1497 6LoWPAN Fragment Forwarding (FF) and IPv6 Forwarding (6F). 1499 4.6.1. Track Forwarding 1501 Forwarding along a Track can be seen as a Generalized Multi-protocol 1502 Label Switching (G-MPLS) operation in that the information used to 1503 switch a frame is not an explicit label, but rather related to other 1504 properties of the way the packet was received, a particular cell in 1505 the case of 6TiSCH. As a result, as long as the TSCH MAC (and 1506 Layer-2 security) accepts a frame, that frame can be switched 1507 regardless of the protocol, whether this is an IPv6 packet, a 6LoWPAN 1508 fragment, or a frame from an alternate protocol such as WirelessHART 1509 or ISA100.11a. 1511 A data frame that is forwarded along a Track normally has a 1512 destination MAC address that is set to broadcast - or a multicast 1513 address depending on MAC support. This way, the MAC layer in the 1514 intermediate nodes accepts the incoming frame and 6top switches it 1515 without incurring a change in the MAC header. In the case of IEEE 1516 Std 802.15.4, this means effectively broadcast, so that along the 1517 Track the short address for the destination of the frame is set to 1518 0xFFFF. 1520 There are 2 modes for a Track, transport mode and tunnel mode. 1522 4.6.1.1. Transport Mode 1524 In transport mode, the Protocol Data Unit (PDU) is associated with 1525 flow-dependant meta-data that refers uniquely to the Track, so the 1526 6top sublayer can place the frame in the appropriate cell without 1527 ambiguity. In the case of IPv6 traffic, this flow identification is 1528 transported in the Flow Label of the IPv6 header. Associated with 1529 the source IPv6 address, the Flow Label forms a globally unique 1530 identifier for that particular Track that is validated at egress 1531 before restoring the destination MAC address (DMAC) and punting to 1532 the upper layer. 1534 | ^ 1535 +--------------+ | | 1536 | IPv6 | | | 1537 +--------------+ | | 1538 | 6LoWPAN HC | | | 1539 +--------------+ ingress egress 1540 | 6top | sets +----+ +----+ restores 1541 +--------------+ dmac to | | | | dmac to 1542 | TSCH MAC | brdcst | | | | self 1543 +--------------+ | | | | | | 1544 | LLN PHY | +-------+ +--...-----+ +-------+ 1545 +--------------+ 1547 Track Forwarding, Transport Mode 1549 4.6.1.2. Tunnel Mode 1551 In tunnel mode, the frames originate from an arbitrary protocol over 1552 a compatible MAC that may or may not be synchronized with the 6TiSCH 1553 network. An example of this would be a router with a dual radio that 1554 is capable of receiving and sending WirelessHART or ISA100.11a frames 1555 with the second radio, by presenting itself as an access Point or a 1556 Backbone Router, respectively. 1558 In that mode, some entity (e.g. PCE) can coordinate with a 1559 WirelessHART Network Manager or an ISA100.11a System Manager to 1560 specify the flows that are to be transported transparently over the 1561 Track. 1563 +--------------+ 1564 | IPv6 | 1565 +--------------+ 1566 | 6LoWPAN HC | 1567 +--------------+ set restore 1568 | 6top | +dmac+ +dmac+ 1569 +--------------+ to|brdcst to|nexthop 1570 | TSCH MAC | | | | | 1571 +--------------+ | | | | 1572 | LLN PHY | +-------+ +--...-----+ +-------+ 1573 +--------------+ | ingress egress | 1574 | | 1575 +--------------+ | | 1576 | LLN PHY | | | 1577 +--------------+ | | 1578 | TSCH MAC | | | 1579 +--------------+ | dmac = | dmac = 1580 |ISA100/WiHART | | nexthop v nexthop 1581 +--------------+ 1583 Figure 10: Track Forwarding, Tunnel Mode 1585 In that case, the flow information that identifies the Track at the 1586 ingress 6TiSCH router is derived from the RX-cell. The dmac is set 1587 to this node but the flow information indicates that the frame must 1588 be tunneled over a particular Track so the frame is not passed to the 1589 upper layer. Instead, the dmac is forced to broadcast and the frame 1590 is passed to the 6top sublayer for switching. 1592 At the egress 6TiSCH router, the reverse operation occurs. Based on 1593 metadata associated to the Track, the frame is passed to the 1594 appropriate link layer with the destination MAC restored. 1596 4.6.1.3. Tunnel Metadata 1598 Metadata coming with the Track configuration is expected to provide 1599 the destination MAC address of the egress endpoint as well as the 1600 tunnel mode and specific data depending on the mode, for instance a 1601 service access point for frame delivery at egress. If the tunnel 1602 egress point does not have a MAC address that matches the 1603 configuration, the Track installation fails. 1605 In transport mode, if the final Layer-3 destination is the tunnel 1606 termination, then it is possible that the IPv6 address of the 1607 destination is compressed at the 6LoWPAN sublayer based on the MAC 1608 address. It is thus mandatory at the ingress point to validate that 1609 the MAC address that was used at the 6LoWPAN sublayer for compression 1610 matches that of the tunnel egress point. For that reason, the node 1611 that injects a packet on a Track checks that the destination is 1612 effectively that of the tunnel egress point before it overwrites it 1613 to broadcast. The 6top sublayer at the tunnel egress point reverts 1614 that operation to the MAC address obtained from the tunnel metadata. 1616 4.6.2. Fragment Forwarding 1618 Considering that 6LoWPAN packets can be as large as 1280 bytes (the 1619 IPv6 MTU), and that the non-storing mode of RPL implies Source 1620 Routing that requires space for routing headers, and that a IEEE Std 1621 802.15.4 frame with security may carry in the order of 80 bytes of 1622 effective payload, an IPv6 packet might be fragmented into more than 1623 16 fragments at the 6LoWPAN sublayer. 1625 This level of fragmentation is much higher than that traditionally 1626 experienced over the Internet with IPv4 fragments, where 1627 fragmentation is already known as harmful. 1629 In the case to a multihop route within a 6TiSCH network, Hop-by-Hop 1630 recomposition occurs at each hop in order to reform the packet and 1631 route it. This creates additional latency and forces intermediate 1632 nodes to store a portion of a packet for an undetermined time, thus 1633 impacting critical resources such as memory and battery. 1635 [I-D.thubert-6lo-forwarding-fragments] describes a mechanism whereby 1636 the datagram tag in the 6LoWPAN Fragment is used as a label for 1637 switching at the 6LoWPAN sublayer. The draft allows for a degree of 1638 flow control based on an Explicit Congestion Notification, as well as 1639 end-to-end individual fragment recovery. 1641 | ^ 1642 +--------------+ | | 1643 | IPv6 | | +----+ +----+ | 1644 +--------------+ | | | | | | 1645 | 6LoWPAN HC | | learn learn | 1646 +--------------+ | | | | | | 1647 | 6top | | | | | | | 1648 +--------------+ | | | | | | 1649 | TSCH MAC | | | | | | | 1650 +--------------+ | | | | | | 1651 | LLN PHY | +-------+ +--...-----+ +-------+ 1652 +--------------+ 1654 Figure 11: Forwarding First Fragment 1656 In that model, the first fragment is routed based on the IPv6 header 1657 that is present in that fragment. The 6LoWPAN sublayer learns the 1658 next hop selection, generates a new datagram tag for transmission to 1659 the next hop, and stores that information indexed by the incoming MAC 1660 address and datagram tag. The next fragments are then switched based 1661 on that stored state. 1663 | ^ 1664 +--------------+ | | 1665 | IPv6 | | | 1666 +--------------+ | | 1667 | 6LoWPAN HC | | replay replay | 1668 +--------------+ | | | | | | 1669 | 6top | | | | | | | 1670 +--------------+ | | | | | | 1671 | TSCH MAC | | | | | | | 1672 +--------------+ | | | | | | 1673 | LLN PHY | +-------+ +--...-----+ +-------+ 1674 +--------------+ 1676 Figure 12: Forwarding Next Fragment 1678 A bitmap and an ECN echo in the end-to-end acknowledgment enable the 1679 source to resend the missing fragments selectively. The first 1680 fragment may be resent to carve a new path in case of a path failure. 1681 The ECN echo set indicates that the number of outstanding fragments 1682 should be reduced. 1684 4.6.3. IPv6 Forwarding 1686 As the packets are routed at Layer-3, traditional QoS and Active 1687 Queue Management (AQM) operations are expected to prioritize flows; 1688 the application of Differentiated Services is further discussed in 1689 [I-D.svshah-tsvwg-lln-diffserv-recommendations]. 1691 | ^ 1692 +--------------+ | | 1693 | IPv6 | | +-QoS+ +-QoS+ | 1694 +--------------+ | | | | | | 1695 | 6LoWPAN HC | | | | | | | 1696 +--------------+ | | | | | | 1697 | 6top | | | | | | | 1698 +--------------+ | | | | | | 1699 | TSCH MAC | | | | | | | 1700 +--------------+ | | | | | | 1701 | LLN PHY | +-------+ +--...-----+ +-------+ 1702 +--------------+ 1704 Figure 13: IP Forwarding 1706 4.7. Centralized vs. Distributed Routing 1708 6TiSCH supports a mixed model of centralized routes and distributed 1709 routes. Centralized routes can for example be computed by a entity 1710 such as a PCE. Distributed routes are computed by RPL. 1712 Both methods may inject routes in the Routing Tables of the 6TiSCH 1713 routers. In either case, each route is associated with a 6TiSCH 1714 topology that can be a RPL Instance topology or a Track. The 6TiSCH 1715 topology is indexed by a Instance ID, in a format that reuses the 1716 RPLInstanceID as defined in RPL [RFC6550]. 1718 Both RPL and PCE rely on shared sources such as policies to define 1719 Global and Local RPLInstanceIDs that can be used by either method. 1720 It is possible for centralized and distributed routing to share a 1721 same topology. Generally they will operate in different slotFrames, 1722 and centralized routes will be used for scheduled traffic and will 1723 have precedence over distributed routes in case of conflict between 1724 the slotFrames. 1726 4.7.1. Packet Marking and Handling 1728 All packets inside a 6TiSCH domain must carry the Instance ID that 1729 identifies the 6TiSCH topology that is to be used for routing and 1730 forwarding that packet. The location of that information must be the 1731 same for all packets forwarded inside the domain. 1733 For packets that are routed by a PCE along a Track, the tuple formed 1734 by the IPv6 source address and a local RPLInstanceID in the packet 1735 identify uniquely the Track and associated transmit bundle. 1737 For packets that are routed by RPL, that information is the 1738 RPLInstanceID which is carried in the RPL Packet Information, as 1739 discussed in section 11.2 of [RFC6550], "Loop Avoidance and 1740 Detection". 1742 The RPL Packet Information (RPI) is carried in IPv6 packets as a RPL 1743 option in the IPv6 Hop-By-Hop Header [RFC6553]. 1745 A compression mechanism for the RPL packet artifacts that integrates 1746 the compression of IP-in-IP encapsulation and the Routing Header type 1747 3 [RFC6554] with that of the RPI in a 6LoWPAN dispatch/header type is 1748 specified in [RFC8025] and [RFC8138]. 1750 Either way, the method and format used for encoding the RPLInstanceID 1751 is generalized to all 6TiSCH topological Instances, which include 1752 both RPL Instances and Tracks. 1754 4.7.2. Replication, Retries and Elimination 1756 6TiSCH expects elimination and replication of packets along a complex 1757 Track, but has no position about how the sequence numbers would be 1758 tagged in the packet. 1760 As it goes, 6TiSCH expects that timeSlots corresponding to copies of 1761 a same packet along a Track are correlated by configuration, and does 1762 not need to process the sequence numbers. 1764 The semantics of the configuration will enable correlated timeSlots 1765 to be grouped for transmit (and respectively receive) with a 'OR' 1766 relations, and then a 'AND' relation would be configurable between 1767 groups. The semantics is that if the transmit (and respectively 1768 receive) operation succeeded in one timeSlot in a 'OR' group, then 1769 all the other timeSLots in the group are ignored. Now, if there are 1770 at least two groups, the 'AND' relation between the groups indicates 1771 that one operation must succeed in each of the groups. 1773 On the transmit side, timeSlots provisioned for retries along a same 1774 branch of a Track are placed a same 'OR' group. The 'OR' relation 1775 indicates that if a transmission is acknowledged, then further 1776 transmissions should not be attempted for timeSlots in that group. 1777 There are as many 'OR' groups as there are branches of the Track 1778 departing from this node. Different 'OR' groups are programmed for 1779 the purpose of replication, each group corresponding to one branch of 1780 the Track. The 'AND' relation between the groups indicates that 1781 transmission over any of branches must be attempted regardless of 1782 whether a transmission succeeded in another branch. It is also 1783 possible to place cells to different next-hop routers in a same 'OR' 1784 group. This allows to route along multi-path tracks, trying one 1785 next-hop and then another only if sending to the first fails. 1787 On the receive side, all timeSlots are programmed in a same 'OR' 1788 group. Retries of a same copy as well as converging branches for 1789 elimination are converged, meaning that the first successful 1790 reception is enough and that all the other timeSlots can be ignored. 1792 4.7.3. Differentiated Services Per-Hop-Behavior 1794 Additionally, an IP packet that is sent along a Track uses the 1795 Differentiated Services Per-Hop-Behavior Group called Deterministic 1796 Forwarding, as described in 1797 [I-D.svshah-tsvwg-deterministic-forwarding]. 1799 5. IANA Considerations 1801 This specification does not require IANA action. 1803 6. Security Considerations 1805 This architecture operates on IEEE Std 802.15.4 and expects link- 1806 layer security to be enabled at all times between connected devices, 1807 except for the very first step of the device join process, where a 1808 joining device may need some initial, unsecured exchanges so as to 1809 obtain its initial key material. 1811 The Minimal Security Framework for 6TiSCH 1812 [I-D.ietf-6tisch-minimal-security] describes the minimal mechanisms 1813 required to support secure enrollment of a pledge to a 6TiSCH network 1814 based on PSK. The specification enables to establish of link-layer 1815 keys, typically used in combination with a variation of Counter with 1816 CBC-MAC (CCM) [RFC3610], and set up a secure end-to-end session 1817 between the pledge and the join registrar via a Join Proxy. It can 1818 also be used to obtain a link layer short address. The 6TiSCH Secure 1819 Join protocol [I-D.ietf-6tisch-dtsecurity-secure-join] wraps the 1820 minimal security draft with a flow inspired from ANIMA BRSKI 1821 [I-D.ietf-anima-bootstrapping-keyinfra]. 1823 6.1. Join Process Highlights 1825 The BRSKI architecture specifies three logical elements to describe 1826 the join process: 1828 Pledge: Node that wishes to become part of the network; 1829 Join Registrar/Coordinator (JRC) : An entity that arbitrates network 1830 access and hands out network parameters (such as keying 1831 material); 1833 Join Proxy (JP), a one-hop (radio) neighbor of the joining node that 1834 acts as proxy network node and may provide connectivity with 1835 the JRC. 1837 The join protocol consists of three major activities: 1839 Device Authentication: The Pledge and the JP mutually authenticate 1840 each other and establish a shared key, so as to ensure on-going 1841 authenticated communications. This may involve a server as a 1842 third party. 1844 Authorization: The JP decides on whether/how to authorize a Pledge 1845 (if denied, this may result in loss of bandwidth). Conversely, 1846 the Pledge decides on whether/how to authorize the network (if 1847 denied, it will not join the network). Authorization decisions 1848 may involve other nodes in the network. 1850 Configuration/Parameterization: The JP distributes configuration 1851 information to the Pledge, such as scheduling information, IP 1852 address assignment information, and network policies. This may 1853 originate from other network devices, for which the JP may act 1854 as proxy. This step may also include distribution of 1855 information from the Pledge to the JP and other nodes in the 1856 network and, more generally, synchronization of information 1857 between these entities. 1859 The device joining process is depicted in Figure 14, where it is 1860 assumed that devices have access to certificates and where entities 1861 have access to the root CA keys of their communicating parties 1862 (initial set-up requirement). Under these assumptions, the 1863 authentication step of the device joining process does not require 1864 online involvement of a third party. Mutual authentication is 1865 performed between the Pledge and the JP using their certificates, 1866 which also results in a shared key between these two entities. 1868 The JP assists the Pledge in mutual authentication with a remote 1869 server node (primarily via provision of a communication path with the 1870 server), which also results in a shared (end-to-end) key between 1871 those two entities. The server node may be a JRC that arbitrages the 1872 network authorization of the Pledge (where the JP will deny bandwidth 1873 if authorization is not successful); it may distribute network- 1874 specific configuration parameters (including network-wide keys) to 1875 the Pledge. In its turn, the Pledge may distribute and synchronize 1876 information (including, e.g., network statistics) to the server node 1877 and, if so desired, also to the JP. The actual decision of the 1878 Pledge to become part of the network may depend on authorization of 1879 the network itself. 1881 The server functionality is a role which may be implemented with one 1882 (centralized) or multiple devices (distributed). In either case, 1883 mutual authentication is established with each physical server entity 1884 with which a role is implemented. 1886 Note that in the above description, the JP does not solely act as a 1887 relay node, thereby allowing it to first filter traffic to be relayed 1888 based on cryptographic authentication criteria - this provides first- 1889 level access control and mitigates certain types of denial-of-service 1890 attacks on the network at large. 1892 Depending on more detailed insight in cost/benefit trade-offs, this 1893 process might be complemented by a more "relaxed" mechanism, where 1894 the JP acts as a relay node only. The final architecture will 1895 provide mechanisms to also cover cases where the initial set-up 1896 requirements are not met or where some other out-of-sync behavior 1897 occurs; it will also suggest some optimizations in case JRC-related 1898 information is already available with the JP (via caching of 1899 information). 1901 When a device rejoins the network in the same authorization domain, 1902 the authorization step could be omitted if the server distributes the 1903 authorization state for the device to the JP when the device 1904 initially joined the network. However, this generally still requires 1905 the exchange of updated configuration information, e.g., related to 1906 time schedules and bandwidth allocation. 1908 {joining node} {neighbor} {server, etc.} Example: 1909 +---------+ +---------+ +---------+ 1910 | Joining | | Join | +--| CA |certificate 1911 | Node | |Assistant| | +---------+ issuance 1912 +---------+ +---------+ | +---------+ 1913 | | +--|Authoriz.| membership 1914 |<----Beaconing------| | +---------+ test (JRC) 1915 | | | +---------+ 1916 |<--Authentication-->| +--| Routing | IP address 1917 | |<--Authorization-->| +--------- assignment 1918 |<-------------------| | +---------+ 1919 | | +--| Gateway | backbone, 1920 |------------------->| | +---------+ cloud 1921 | |<--Configuration-->| +---------+ 1922 |<-------------------| +--|Bandwidth| PCE 1923 +---------+ schedule 1924 . . . 1925 . . . 1927 Figure 14: Network joining, with only authorization by third party 1929 7. Acknowledgments 1931 7.1. Contributors 1933 The co-authors of this document are listed below: 1935 Robert Assimiti for his breakthrough work on RPL over TSCH and 1936 initial text and guidance. 1938 Kris Pister for creating it all and his continuing guidance through 1939 the elaboration of this design. 1941 Michael Richardson for his leadership role in the Security Design 1942 Team and his contribution throughout this document. 1944 Rene Struik for the security section and his contribution to the 1945 Security Design Team. 1947 Xavier Vilajosana who lead the design of the minimal support with 1948 RPL and contributed deeply to the 6top design and the G-MPLS 1949 operation of Track switching. 1951 Qin Wang who lead the design of the 6top sublayer and contributed 1952 related text that was moved and/or adapted in this document. 1954 Thomas Watteyne for his contribution to the whole design, in 1955 particular on TSCH and security. 1957 7.2. Special Thanks 1959 Special thanks to Tero Kivinen, Jonathan Simon, Giuseppe Piro, Subir 1960 Das and Yoshihiro Ohba for their deep contribution to the initial 1961 security work, and to Diego Dujovne for starting and leading the SF0 1962 effort. 1964 Special thanks also to Pat Kinney for his support in maintaining the 1965 connection active and the design in line with work happening at IEEE 1966 Std 802.15.4. 1968 Special thanks to Ted Lemon who was the INT Area A-D while this 1969 specification was developed for his great support and help 1970 throughout. 1972 Also special thanks to Ralph Droms who performed the first INT Area 1973 Directorate review, that was very deep and through and radically 1974 changed the orientations of this document. 1976 7.3. And Do not Forget 1978 This specification is the result of multiple interactions, in 1979 particular during the 6TiSCH (bi)Weekly Interim call, relayed through 1980 the 6TiSCH mailing list at the IETF. 1982 The authors wish to thank: Alaeddine Weslati, Chonggang Wang, 1983 Georgios Exarchakos, Zhuo Chen, Alfredo Grieco, Bert Greevenbosch, 1984 Cedric Adjih, Deji Chen, Martin Turon, Dominique Barthel, Elvis 1985 Vogli, Geraldine Texier, Malisa Vucinic, Guillaume Gaillard, Herman 1986 Storey, Kazushi Muraoka, Ken Bannister, Kuor Hsin Chang, Laurent 1987 Toutain, Maik Seewald, Maria Rita Palattella, Michael Behringer, 1988 Nancy Cam Winget, Nicola Accettura, Nicolas Montavont, Oleg Hahm, 1989 Patrick Wetterwald, Paul Duffy, Peter van der Stock, Rahul Sen, 1990 Pieter de Mil, Pouria Zand, Rouhollah Nabati, Rafa Marin-Lopez, 1991 Raghuram Sudhaakar, Sedat Gormus, Shitanshu Shah, Steve Simlo, 1992 Tengfei Chang, Tina Tsou, Tom Phinney, Xavier Lagrange, Ines Robles 1993 and Samita Chakrabarti for their participation and various 1994 contributions. 1996 8. References 1997 8.1. Normative References 1999 [I-D.ietf-6lo-backbone-router] 2000 Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- 2001 backbone-router-04 (work in progress), July 2017. 2003 [I-D.ietf-6tisch-terminology] 2004 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 2005 "Terminology in IPv6 over the TSCH mode of IEEE 2006 802.15.4e", draft-ietf-6tisch-terminology-09 (work in 2007 progress), June 2017. 2009 [I-D.ietf-detnet-architecture] 2010 Finn, N., Thubert, P., Varga, B., and J. Farkas, 2011 "Deterministic Networking Architecture", draft-ietf- 2012 detnet-architecture-03 (work in progress), August 2017. 2014 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 2015 DOI 10.17487/RFC0768, August 1980, 2016 . 2018 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 2019 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 2020 DOI 10.17487/RFC4861, September 2007, 2021 . 2023 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 2024 Address Autoconfiguration", RFC 4862, 2025 DOI 10.17487/RFC4862, September 2007, 2026 . 2028 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 2029 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 2030 DOI 10.17487/RFC6282, September 2011, 2031 . 2033 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 2034 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 2035 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 2036 Low-Power and Lossy Networks", RFC 6550, 2037 DOI 10.17487/RFC6550, March 2012, 2038 . 2040 [RFC6552] Thubert, P., Ed., "Objective Function Zero for the Routing 2041 Protocol for Low-Power and Lossy Networks (RPL)", 2042 RFC 6552, DOI 10.17487/RFC6552, March 2012, 2043 . 2045 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 2046 Power and Lossy Networks (RPL) Option for Carrying RPL 2047 Information in Data-Plane Datagrams", RFC 6553, 2048 DOI 10.17487/RFC6553, March 2012, 2049 . 2051 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 2052 Routing Header for Source Routes with the Routing Protocol 2053 for Low-Power and Lossy Networks (RPL)", RFC 6554, 2054 DOI 10.17487/RFC6554, March 2012, 2055 . 2057 [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. 2058 Bormann, "Neighbor Discovery Optimization for IPv6 over 2059 Low-Power Wireless Personal Area Networks (6LoWPANs)", 2060 RFC 6775, DOI 10.17487/RFC6775, November 2012, 2061 . 2063 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 2064 Application Protocol (CoAP)", RFC 7252, 2065 DOI 10.17487/RFC7252, June 2014, 2066 . 2068 [RFC7554] Watteyne, T., Ed., Palattella, M., and L. Grieco, "Using 2069 IEEE 802.15.4e Time-Slotted Channel Hopping (TSCH) in the 2070 Internet of Things (IoT): Problem Statement", RFC 7554, 2071 DOI 10.17487/RFC7554, May 2015, 2072 . 2074 [RFC8025] Thubert, P., Ed. and R. Cragie, "IPv6 over Low-Power 2075 Wireless Personal Area Network (6LoWPAN) Paging Dispatch", 2076 RFC 8025, DOI 10.17487/RFC8025, November 2016, 2077 . 2079 [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, 2080 "IPv6 over Low-Power Wireless Personal Area Network 2081 (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, 2082 April 2017, . 2084 [RFC8180] Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal 2085 IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH) 2086 Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180, 2087 May 2017, . 2089 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 2090 (IPv6) Specification", STD 86, RFC 8200, 2091 DOI 10.17487/RFC8200, July 2017, 2092 . 2094 8.2. Informative References 2096 [I-D.ietf-6lo-ap-nd] 2097 Sarikaya, B., Thubert, P., and M. Sethi, "Address 2098 Protected Neighbor Discovery for Low-power and Lossy 2099 Networks", draft-ietf-6lo-ap-nd-02 (work in progress), May 2100 2017. 2102 [I-D.ietf-6lo-rfc6775-update] 2103 Thubert, P., Nordmark, E., and S. Chakrabarti, "An Update 2104 to 6LoWPAN ND", draft-ietf-6lo-rfc6775-update-07 (work in 2105 progress), July 2017. 2107 [I-D.ietf-6tisch-6top-interface] 2108 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 2109 (6top) Interface", draft-ietf-6tisch-6top-interface-04 2110 (work in progress), July 2015. 2112 [I-D.ietf-6tisch-6top-protocol] 2113 Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol 2114 (6P)", draft-ietf-6tisch-6top-protocol-07 (work in 2115 progress), June 2017. 2117 [I-D.ietf-6tisch-6top-sf0] 2118 Dujovne, D., Grieco, L., Palattella, M., and N. Accettura, 2119 "6TiSCH 6top Scheduling Function Zero (SF0)", draft-ietf- 2120 6tisch-6top-sf0-05 (work in progress), July 2017. 2122 [I-D.ietf-6tisch-coap] 2123 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 2124 Interaction using CoAP", draft-ietf-6tisch-coap-03 (work 2125 in progress), March 2015. 2127 [I-D.ietf-6tisch-dtsecurity-secure-join] 2128 Richardson, M., "6tisch Secure Join protocol", draft-ietf- 2129 6tisch-dtsecurity-secure-join-01 (work in progress), 2130 February 2017. 2132 [I-D.ietf-6tisch-minimal-security] 2133 Vucinic, M., Simon, J., Pister, K., and M. Richardson, 2134 "Minimal Security Framework for 6TiSCH", draft-ietf- 2135 6tisch-minimal-security-03 (work in progress), June 2017. 2137 [I-D.ietf-anima-bootstrapping-keyinfra] 2138 Pritikin, M., Richardson, M., Behringer, M., Bjarnason, 2139 S., and K. Watsen, "Bootstrapping Remote Secure Key 2140 Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- 2141 keyinfra-07 (work in progress), July 2017. 2143 [I-D.ietf-core-comi] 2144 Veillette, M., Stok, P., Pelov, A., and A. Bierman, "CoAP 2145 Management Interface", draft-ietf-core-comi-01 (work in 2146 progress), July 2017. 2148 [I-D.ietf-detnet-use-cases] 2149 Grossman, E., Gunther, C., Thubert, P., Wetterwald, P., 2150 Raymond, J., Korhonen, J., Kaneko, Y., Das, S., Zha, Y., 2151 Varga, B., Farkas, J., Goetz, F., Schmitt, J., Vilajosana, 2152 X., Mahmoodi, T., Spirou, S., and P. Vizarreta, 2153 "Deterministic Networking Use Cases", draft-ietf-detnet- 2154 use-cases-12 (work in progress), April 2017. 2156 [I-D.ietf-manet-aodvv2] 2157 Perkins, C., Ratliff, S., Dowdell, J., Steenbrink, L., and 2158 V. Mercieca, "Ad Hoc On-demand Distance Vector Version 2 2159 (AODVv2) Routing", draft-ietf-manet-aodvv2-16 (work in 2160 progress), May 2016. 2162 [I-D.ietf-roll-rpl-industrial-applicability] 2163 Phinney, T., Thubert, P., and R. Assimiti, "RPL 2164 applicability in industrial networks", draft-ietf-roll- 2165 rpl-industrial-applicability-02 (work in progress), 2166 October 2013. 2168 [I-D.selander-ace-cose-ecdhe] 2169 Selander, G., Mattsson, J., and F. Palombini, "Ephemeral 2170 Diffie-Hellman Over COSE (EDHOC)", draft-selander-ace- 2171 cose-ecdhe-07 (work in progress), July 2017. 2173 [I-D.svshah-tsvwg-deterministic-forwarding] 2174 Shah, S. and P. Thubert, "Deterministic Forwarding PHB", 2175 draft-svshah-tsvwg-deterministic-forwarding-04 (work in 2176 progress), August 2015. 2178 [I-D.svshah-tsvwg-lln-diffserv-recommendations] 2179 Shah, S. and P. Thubert, "Differentiated Service Class 2180 Recommendations for LLN Traffic", draft-svshah-tsvwg-lln- 2181 diffserv-recommendations-04 (work in progress), February 2182 2015. 2184 [I-D.thubert-6lo-bier-dispatch] 2185 Thubert, P., Brodard, Z., Jiang, H., and G. Texier, "A 2186 6loRH for BitStrings", draft-thubert-6lo-bier-dispatch-03 2187 (work in progress), July 2017. 2189 [I-D.thubert-6lo-forwarding-fragments] 2190 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 2191 Recovery", draft-thubert-6lo-forwarding-fragments-07 (work 2192 in progress), July 2017. 2194 [I-D.thubert-bier-replication-elimination] 2195 Thubert, P., Brodard, Z., and H. Jiang, "BIER-TE-based 2196 OAM, Replication and Elimination", draft-thubert-bier- 2197 replication-elimination-01 (work in progress), July 2017. 2199 [I-D.wang-6tisch-6top-sublayer] 2200 Wang, Q. and X. Vilajosana, "6TiSCH Operation Sublayer 2201 (6top)", draft-wang-6tisch-6top-sublayer-04 (work in 2202 progress), November 2015. 2204 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 2205 "Definition of the Differentiated Services Field (DS 2206 Field) in the IPv4 and IPv6 Headers", RFC 2474, 2207 DOI 10.17487/RFC2474, December 1998, 2208 . 2210 [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol 2211 Extensions for IPv6 Inter-Domain Routing", RFC 2545, 2212 DOI 10.17487/RFC2545, March 1999, 2213 . 2215 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 2216 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 2217 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 2218 . 2220 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 2221 Information Models and Data Models", RFC 3444, 2222 DOI 10.17487/RFC3444, January 2003, 2223 . 2225 [RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with 2226 CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2227 2003, . 2229 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 2230 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 2231 RFC 3963, DOI 10.17487/RFC3963, January 2005, 2232 . 2234 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 2235 Bosch, "Next Steps in Signaling (NSIS): Framework", 2236 RFC 4080, DOI 10.17487/RFC4080, June 2005, 2237 . 2239 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2240 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2241 2006, . 2243 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 2244 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 2245 2006, . 2247 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 2248 for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, 2249 . 2251 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 2252 DOI 10.17487/RFC4903, June 2007, 2253 . 2255 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 2256 over Low-Power Wireless Personal Area Networks (6LoWPANs): 2257 Overview, Assumptions, Problem Statement, and Goals", 2258 RFC 4919, DOI 10.17487/RFC4919, August 2007, 2259 . 2261 [RFC5191] Forsberg, D., Ohba, Y., Ed., Patil, B., Tschofenig, H., 2262 and A. Yegin, "Protocol for Carrying Authentication for 2263 Network Access (PANA)", RFC 5191, DOI 10.17487/RFC5191, 2264 May 2008, . 2266 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 2267 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 2268 . 2270 [RFC5889] Baccelli, E., Ed. and M. Townsley, Ed., "IP Addressing 2271 Model in Ad Hoc Networks", RFC 5889, DOI 10.17487/RFC5889, 2272 September 2010, . 2274 [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS 2275 Signaling Layer Protocol (NSLP) for Quality-of-Service 2276 Signaling", RFC 5974, DOI 10.17487/RFC5974, October 2010, 2277 . 2279 [RFC6275] Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility 2280 Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July 2281 2011, . 2283 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2284 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 2285 January 2012, . 2287 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 2288 SAVI: First-Come, First-Served Source Address Validation 2289 Improvement for Locally Assigned IPv6 Addresses", 2290 RFC 6620, DOI 10.17487/RFC6620, May 2012, 2291 . 2293 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 2294 Transport Layer Security (TLS)", RFC 6655, 2295 DOI 10.17487/RFC6655, July 2012, 2296 . 2298 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 2299 Locator/ID Separation Protocol (LISP)", RFC 6830, 2300 DOI 10.17487/RFC6830, January 2013, 2301 . 2303 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 2304 J. Martocci, "Reactive Discovery of Point-to-Point Routes 2305 in Low-Power and Lossy Networks", RFC 6997, 2306 DOI 10.17487/RFC6997, August 2013, 2307 . 2309 [RFC7426] Haleplidis, E., Ed., Pentikousis, K., Ed., Denazis, S., 2310 Hadi Salim, J., Meyer, D., and O. Koufopavlou, "Software- 2311 Defined Networking (SDN): Layers and Architecture 2312 Terminology", RFC 7426, DOI 10.17487/RFC7426, January 2313 2015, . 2315 8.3. Other Informative References 2317 [ACE] IETF, "Authentication and Authorization for Constrained 2318 Environments", . 2321 [CCAMP] IETF, "Common Control and Measurement Plane", 2322 . 2324 [DETNET] IETF, "Deterministic Networking", 2325 . 2327 [DICE] IETF, "DTLS In Constrained Environments", 2328 . 2330 [HART] www.hartcomm.org, "Highway Addressable remote Transducer, 2331 a group of specifications for industrial process and 2332 control devices administered by the HART Foundation". 2334 [IEC62439] 2335 IEC, "Industrial communication networks - High 2336 availability automation networks - Part 3: Parallel 2337 Redundancy Protocol (PRP) and High-availability Seamless 2338 Redundancy (HSR) - IEC62439-3", 2012, 2339 . 2341 [IEEE802.1TSNTG] 2342 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 2343 Networks Task Group", March 2013, 2344 . 2346 [IEEE802154] 2347 IEEE standard for Information Technology, "IEEE Std. 2348 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 2349 and Physical Layer (PHY) Specifications for Low-Rate 2350 Wireless Personal Area Networks". 2352 [IEEE802154e] 2353 IEEE standard for Information Technology, "IEEE standard 2354 for Information Technology, IEEE Std. 802.15.4, Part. 2355 15.4: Wireless Medium Access Control (MAC) and Physical 2356 Layer (PHY) Specifications for Low-Rate Wireless Personal 2357 Area Networks, June 2011 as amended by IEEE Std. 2358 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 2359 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 2360 2012. 2362 [ISA100] ISA/ANSI, "ISA100, Wireless Systems for Automation", 2363 . 2365 [ISA100.11a] 2366 ISA/ANSI, "Wireless Systems for Industrial Automation: 2367 Process Control and Related Applications - ISA100.11a-2011 2368 - IEC 62734", 2011, . 2371 [PCE] IETF, "Path Computation Element", 2372 . 2374 [TEAS] IETF, "Traffic Engineering Architecture and Signaling", 2375 . 2377 [WirelessHART] 2378 www.hartcomm.org, "Industrial Communication Networks - 2379 Wireless Communication Network and Communication Profiles 2380 - WirelessHART - IEC 62591", 2010. 2382 Author's Address 2384 Pascal Thubert (editor) 2385 Cisco Systems, Inc 2386 Building D 2387 45 Allee des Ormes - BP1200 2388 MOUGINS - Sophia Antipolis 06254 2389 FRANCE 2391 Phone: +33 497 23 26 34 2392 Email: pthubert@cisco.com