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