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