idnits 2.17.1 draft-ietf-6tisch-architecture-02.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 1070 has weird spacing: '...ajosana who l...' == Line 1073 has weird spacing: '...in Wang who l...' -- The document date (June 16, 2014) is 3599 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'IEEE802154e' is mentioned on line 1259, but not defined == Missing Reference: 'WirelessHART' is mentioned on line 1271, but not defined == Missing Reference: 'HART' is mentioned on line 1250, but not defined == Missing Reference: 'IEEE802.1TSNTG' is mentioned on line 1254, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Downref: Normative reference to an Informational RFC: RFC 3444 ** Downref: Normative reference to an Informational RFC: RFC 4080 ** Downref: Normative reference to an Experimental RFC: RFC 4389 ** Downref: Normative reference to an Informational RFC: RFC 4903 ** Downref: Normative reference to an Informational RFC: RFC 4919 ** Downref: Normative reference to an Informational RFC: RFC 5889 ** Downref: Normative reference to an Experimental RFC: RFC 5974 == Outdated reference: A later version (-07) exists of draft-chakrabarti-nordmark-6man-efficient-nd-05 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-6top-interface-00 == Outdated reference: A later version (-03) exists of draft-ietf-6tisch-coap-00 == Outdated reference: A later version (-21) exists of draft-ietf-6tisch-minimal-00 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-01 == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-00 == Outdated reference: A later version (-04) exists of draft-svshah-tsvwg-lln-diffserv-recommendations-02 == Outdated reference: A later version (-05) exists of draft-thubert-6man-flow-label-for-rpl-03 == Outdated reference: A later version (-04) exists of draft-wang-6tisch-6top-sublayer-00 Summary: 8 errors (**), 0 flaws (~~), 16 warnings (==), 1 comment (--). 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: Standards Track T. Watteyne 5 Expires: December 18, 2014 Linear Technology 6 RA. Assimiti 7 Centero 8 June 16, 2014 10 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e 11 draft-ietf-6tisch-architecture-02 13 Abstract 15 This document presents an architecture for an IPv6 Multi-Link subnet 16 that is composed of a high speed powered backbone and a number of 17 IEEE802.15.4e TSCH wireless networks attached and synchronized by 18 Backbone Routers. The TSCH schedule can be static or dynamic. 19 6TiSCH defines mechanisms to establish and maintain the routing and 20 scheduling operations in a centralized, distributed, or mixed 21 fashion. Backbone Routers perform proxy Neighbor Discovery 22 operations over the backbone on behalf of the wireless devices, so 23 they can share a same subnet and appear to be connected to the same 24 backbone as classical devices 26 Requirements Language 28 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 29 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 30 "OPTIONAL" in this document are to be interpreted as described in RFC 31 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on December 18, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Applications and Goals . . . . . . . . . . . . . . . . . . . 4 70 4. Overview and Scope . . . . . . . . . . . . . . . . . . . . . 5 71 5. Communication Paradigms and Interaction Models . . . . . . . 8 72 6. Forwarding Models . . . . . . . . . . . . . . . . . . . . . . 9 73 6.1. Track Forwarding . . . . . . . . . . . . . . . . . . . . 9 74 6.1.1. Transport Mode . . . . . . . . . . . . . . . . . . . 10 75 6.1.2. Tunnel Mode . . . . . . . . . . . . . . . . . . . . . 10 76 6.1.3. Tunnel Metadata . . . . . . . . . . . . . . . . . . . 11 77 6.2. Fragment Forwarding . . . . . . . . . . . . . . . . . . . 12 78 6.3. IPv6 Forwarding . . . . . . . . . . . . . . . . . . . . . 13 79 7. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . . . 14 80 7.1. 6top . . . . . . . . . . . . . . . . . . . . . . . . . . 14 81 7.2. 6top and RPL Objective Function operations . . . . . . . 15 82 7.3. Network Synchronization . . . . . . . . . . . . . . . . . 16 83 7.4. SlotFrames and Priorities . . . . . . . . . . . . . . . . 17 84 7.5. Distributing the reservation of cells . . . . . . . . . . 18 85 8. Schedule Management Mechanisms . . . . . . . . . . . . . . . 20 86 8.1. Minimal Static Scheduling . . . . . . . . . . . . . . . . 20 87 8.2. Neighbor-to-neighbor Scheduling . . . . . . . . . . . . . 20 88 8.3. Remote Monitoring and Schedule Management . . . . . . . . 21 89 8.4. Hop-by-hop Scheduling . . . . . . . . . . . . . . . . . . 22 90 9. Centralized vs. Distributed Routing . . . . . . . . . . . . . 22 91 9.1. Packet Marking and Handling . . . . . . . . . . . . . . . 23 92 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 93 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 94 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 95 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 96 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 98 14.2. Informative References . . . . . . . . . . . . . . . . . 26 99 14.3. External Informative References . . . . . . . . . . . . 27 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 102 1. Introduction 104 The emergence of radio technology enabled a large variety of new 105 types of devices to be interconnected, at a very low marginal cost 106 compared to wire, at any range from Near Field to interplanetary 107 distances, and in circumstances where wiring would be less than 108 practical, for instance rotating devices. 110 At the same time, a new breed of Time Sensitive Networks is being 111 developed to enable traffic that is highly sensitive to jitter and 112 quite sensitive to latency. Such traffic is not limited to voice and 113 video, but also includes command and control operations such as found 114 in industrial automation or in-vehicle sensors and actuators. 116 At IEEE802.1, the "Audio/Video Task Group", was renamed TSN for Time 117 Sensitive Networking to address Deterministic Ethernet. The 118 IEEE802.15.4 Medium access Control (MAC) has evolved with 119 IEEE802.15.4e that provides in particular the timeSlotted Channel 120 Hopping (TSCH) mode for industrial-type applications. 122 Though at a different time scale, both standards provide 123 Deterministic capabilities to the point that a packet that pertains 124 to a certain flow crosses the network from node to node following a 125 very precise schedule, as a train that leaves intermediate stations 126 at precise times along its path. With TSCH, time is formatted into 127 timeSlots, and an individual cell is allocated to unicast or 128 broadcast communication at the MAC level. The time slotted operation 129 reduces collisions, saves energy, and enables to more closely 130 engineer the network for deterministic properties. The channel 131 hopping aspect is a simple and efficient technique to combat 132 multipath fading and external interference (for example by WiFi 133 emitters). 135 This document presents an architecture for an IPv6 Multi-Link subnet 136 that is composed of a high speed powered backbone and a number of 137 IEEE802.15.4e TSCH wireless networks attached and synchronized by 138 backbone routers. Route Computation may be achieved in a centralized 139 fashion by a Path Computation Element (PCE), in a distributed fashion 140 using the Routing Protocol for Low Power and Lossy Networks (RPL), or 141 in a mixed mode. The Backbone Routers perform proxy IPv6 neighbor 142 Discovery (ND) operations over the backbone on behalf of the wireless 143 devices, so they can share a same IPv6 subnet and appear to be 144 connected to the same backbone as classical devices. timeSlots and 145 other device resources are managed by an abstract Network Management 146 Entity (NME) that may cooperate with the PCE in order to minimize the 147 interaction with and the load on the constrained device. 149 2. Terminology 151 Readers are expected to be familiar with all the terms and concepts 152 that are discussed in "neighbor Discovery for IP version 6" 153 [RFC4861], "IPv6 over Low-Power Wireless Personal Area Networks 154 (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" 155 [RFC4919], neighbor Discovery Optimization for Low-power and Lossy 156 Networks [RFC6775] and "Multi-link Subnet Support in IPv6" 157 [I-D.ietf-ipv6-multilink-subnets]. 159 Readers may benefit from reading the "RPL: IPv6 Routing Protocol for 160 Low-Power and Lossy Networks" [RFC6550] specification; "Multi-Link 161 Subnet Issues" [RFC4903]; "Mobility Support in IPv6" [RFC6275]; 162 "neighbor Discovery Proxies (ND Proxy)" [RFC4389]; "IPv6 Stateless 163 Address Autoconfiguration" [RFC4862]; "FCFS SAVI: First-Come, First- 164 Served Source Address Validation Improvement for Locally Assigned 165 IPv6 Addresses" [RFC6620]; and "Optimistic Duplicate Address 166 Detection" [RFC4429] prior to this specification for a clear 167 understanding of the art in ND-proxying and binding. 169 The draft uses terminology defined or referenced in 170 [I-D.ietf-6tisch-terminology], 171 [I-D.chakrabarti-nordmark-6man-efficient-nd], 172 [I-D.ietf-roll-rpl-industrial-applicability], [RFC5191] and 173 [RFC4080]. 175 The draft also conforms to the terms and models described in 176 [RFC3444] and [RFC5889] and uses the vocabulary and the concepts 177 defined in [RFC4291] for the IPv6 Architecture. 179 3. Applications and Goals 181 The architecture derives from existing industrial standards for 182 Process Control by its focus on Deterministic Networking, in 183 particular with the use of the IEEE802.15.4e TSCH MAC [IEEE802154e] 184 and the centralized PCE. This approach leverages the TSCH MAC 185 benefits for high reliability against interference, low-power 186 consumption on deterministic traffic, and its Traffic Engineering 187 capabilities. Deterministic Networking applies in particular to open 188 and closed control loops, as well as supervisory control flows and 189 management. 191 An incremental set of industrial requirements are addressed with the 192 addition of an autonomic and distributed routing operation based on 193 RPL. These use cases include plant setup and decommissioning, as 194 well as monitoring of lots of lesser importance measurements such as 195 corrosion and events. RPL also enables mobile use cases such as 196 mobile workers and cranes. 198 A Backbone Router is included in order to scale the factory plant 199 subnet to address large deployments, with proxy ND and time 200 synchronization over a high speed backbone. 202 The architecture also applies to building automation that leverage 203 RPL's storing mode to address multipath over a large number of hops, 204 in-vehicle command and control that can be as demanding as industrial 205 applications, commercial automation and asset Tracking with mobile 206 scenarios, home automation and domotics which become more reliable 207 and thus provide a better user experience, and resource management 208 (energy, water, etc.). 210 4. Overview and Scope 212 The scope of the present work is a subnet that, in its basic 213 configuration, is made of a IEEE802.15.4e timeSlotted Channel Hopping 214 (TSCH) [I-D.ietf-6tisch-tsch] MAC Low Power Lossy Network (LLN). 216 ---+-------- ............ ------------ 217 | External Network | 218 | +-----+ 219 +-----+ | NME | 220 | | LLN Border | | 221 | | router +-----+ 222 +-----+ 223 o o o 224 o o o o 225 o o LLN o o o 226 o o o o 227 o 229 Figure 1: Basic Configuration 231 The LLN devices communicate over IPv6 [RFC2460] using the 6LoWPAN 232 Header Compression (6LoWPAN HC) [RFC6282]. From the perspective of 233 Layer 3, a single LLN interface (typically an IEEE802.15.4-compliant 234 radio) may be seen as a collection of Links with different 235 capabilities for unicast or multicast services. An IPv6 subnet spans 236 over multiple links, effectively forming a Multi-Link subnet. Within 237 that subnet, neighbor Devices are discovered with 6LoWPAN neighbor 238 Discovery (6LoWPAN ND) [RFC6775]. RPL [RFC6550] enables routing 239 within the LLN, typically within the Multi-Link subnet in the so 240 called Route Over fashion. 242 RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) 243 within Instances of the protocol, each Instance being associated with 244 an Objective Function (OF) to form a routing topology. A particular 245 LLN device, the LLN Border Router (LBR), acts as RPL root, 6LoWPAN HC 246 terminator, and LLN Border Router (LBR) to the outside. The LBR is 247 usually powered. More on RPL Instances can be found in RPL 248 [RFC6550], sections "3.1.2. RPL Identifiers" and "3.1.3. Instances, 249 DODAGs, and DODAG Versions". 251 An extended configuration of the subnet comprises multiple LLNs. The 252 LLNs are interconnected and synchronized over a backbone, that can be 253 wired or wireless. The backbone can be a classical IPv6 network, 254 with neighbor Discovery operating as defined in [RFC4861] and 255 [RFC4862]. The backbone can also support Efficiency-aware IPv6 256 neighbor Discovery Optimizations 257 [I-D.chakrabarti-nordmark-6man-efficient-nd] in mixed mode as 258 described in [I-D.thubert-6lowpan-backbone-router]. 260 Security is often handled at layer 2 and Layer 4. Authentication 261 during the join process can be handled by the Protocol for Carrying 262 Authentication for Network access (PANA) [RFC5191]. 264 The LLN devices are time-synchronized at the MAC level. The LBR that 265 serves as time source is a RPL parent in a particular RPL Instance 266 that serves for time synchronization; this way, the time 267 synchronization starts at the RPL root and follows the RPL DODAGs 268 with no timing loop. 270 In the extended configuration, the functionality of the LBR is 271 enhanced to that of Backbone Router (BBR). A BBR is an LBR, but also 272 an Energy Aware Default Router (NEAR) as defined in 273 [I-D.chakrabarti-nordmark-6man-efficient-nd]. The BBR performs ND 274 proxy operations between the registered devices and the classical ND 275 devices that are located over the backbone. 6TiSCH BBRs synchronize 276 with one another over the backbone, so as to ensure that the multiple 277 LLNs that form the IPv6 subnet stay tightly synchronized. If the 278 Backbone is Deterministic (such as defined by the Time Sensitive 279 Networking WG at IEEE), then the Backbone Router ensures that the 280 end-to-end deterministic behavior is maintained between the LLN and 281 the backbone. 283 ---+-------- ............ ------------ 284 | External Network | 285 | +-----+ 286 | +-----+ | NME | 287 +-----+ | +-----+ | | 288 | | Router | | PCE | +-----+ 289 | | +--| | 290 +-----+ +-----+ 291 | | 292 | Subnet Backbone | 293 +--------------------+------------------+ 294 | | | 295 +-----+ +-----+ +-----+ 296 | | Backbone | | Backbone | | Backbone 297 o | | router | | router | | router 298 +-----+ +-----+ +-----+ 299 o o o o o 300 o o o o o o o o o o o 301 o o o LLN o o o o 302 o o o o o o o o o o o o 304 Figure 2: Extended Configuration 306 The main architectural blocks are arranged as follows: 308 +-----+-----+-----+-----+-------+-----+ 309 |PCEP | CoAP |PANA |6LoWPAN| RPL | 310 | PCE |DTLS | | | ND | | 311 +-----+-----+-----+-----+-------+-----+-----+ 312 | TCP | UDP | ICMP |RSVP | 313 +-----+-----+-----+-----+-------+-----+-----+ 314 | IPv6 | 315 +-------------------------------------------+ 316 | 6LoWPAN HC | 317 +-------------------------------------------+ 318 | 6top | 319 +-------------------------------------------+ 320 | IEEE802.15.4e TSCH | 321 +-------------------------------------------+ 323 Figure 3: 6TiSCH stack 325 RPL is the routing protocol of choice for LLNs. (TBD RPL) whether 326 there is a need to define a 6TiSCH OF. 328 (tbd NME) COMAN is working on network Management for LLN. They are 329 considering the Open Mobile Alliance (OMA) Lightweight M2M (LWM2M) 330 Object system. This standard includes DTLS, CoAP (core plus Block 331 and Observe patterns), SenML and CoAP Resource Directory. 333 (tbd PCE) need to work with PCE WG to define flows to PCE, and define 334 how to accommodate PCE routes and reservation. Will probably look a 335 lot like GMPLS. 337 (tbd PANA) There is a debate whether PANA (layer 3) or IEEE802.1x 338 (layer 2) should be used in the join process. There is also a debate 339 whether the node should be able to send any unprotected packet on the 340 medium. Regardless, the security model must ensure that, prior to a 341 join process, packets from a untrusted device must be controlled in 342 volume and in reachability. 344 (tbd Backbone Router) need to work with 6MAN to define ND proxy. 345 Also need BBR sync sync between deterministic Ethernet and 6TiSCH 346 LLNs. 348 IEEE802.1TSN: external, maintain consistency. See also AVnu. 350 IEEE802.15.4: external, (tbd need updates?). 352 ISA100.20 Common Network Management: external, maintain consistency. 354 The 6TiSCH Operation sublayer (6top) [I-D.wang-6tisch-6top-sublayer] 355 is an Logical Link Control (LLC) or a portion thereof that provides 356 the abstraction of an IP link over a TSCH MAC. 358 5. Communication Paradigms and Interaction Models 360 [I-D.ietf-6tisch-terminology] defines the terms of Communication 361 Paradigms and Interaction Models, which can be placed in parallel to 362 the Information Models and Data Models that are defined in [RFC3444]. 364 A Communication Paradigms would be an abstract view of a protocol 365 exchange, and would come with an Information Model for the 366 information that is being exchanged. In contrast, an Interaction 367 Models would be more refined and could point on standard operation 368 such as a Representational state transfer (REST) "GET" operation and 369 would match a Data Model for the data that is provided over the 370 protocol exchange. 372 [I-D.ietf-roll-rpl-industrial-applicability] section 2.1.3. and next 373 discusses appplication-layer paradigms, such as Source-sink (SS) that 374 is a Multipeer to Multipeer (MP2MP) model that is primarily used for 375 alarms and alerts, Publish-subscribe (PS, or pub/sub) that is 376 typically used for sensor data, as well as Peer-to-peer (P2P) and 377 Peer-to-multipeer (P2MP) communications. Additional considerations 378 on Duocast and its N-cast generalization are also provided. Those 379 paradigms are frequently used in industrial automation, which is a 380 major use case for IEEE802.15.4e TSCH wireless networks with 381 [ISA100.11a] and [WirelessHART], that provides a wireless access to 382 [HART] applications and devices. 384 This specification focuses on Communication Paradigms and Interaction 385 Models for packet forwarding and TSCH resources (cells) management. 386 L ink-layer and Network-layer Packet forwarding interactions are 387 discussed in Section 6, whereas Link-layer (one-hop), Network-layer 388 (multithop along a track), and Application-layer (remote control) 389 management mechanisms for the TSCH schedule are discussed in 390 Section 8. 392 6. Forwarding Models 394 6TiSCH supports three different forwarding model, G-MPLS Track 395 Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 Forwarding 396 (6F). 398 6.1. Track Forwarding 400 Track Forwarding is the simplest and fastest. A bundle of cells set 401 to receive (RX-cells) is uniquely paired to a bundle of cells that 402 are set to transmit (TX-cells), representing a layer-2 forwarding 403 state that can be used regardless of the network layer protocol. 404 This model can effectively be seen as a Generalized Multi-protocol 405 Label Switching (G-MPLS) operation in that the information used to 406 switch a frame is not an explicit label, but rather related to other 407 properties of the way the packet was received, a particular cell in 408 the case of 6TiSCH. As a result, as long as the TSCH MAC (and Layer 409 2 security) accepts a frame, that frame can be switched regardless of 410 the protocol, whether this is an IPv6 packet, a 6LoWPAN fragment, or 411 a frame from an alternate protocol such as WirelessHART or 412 ISA100.11a. 414 A Track is defined end-to-end as a succession of paired bundles. A 415 cell in such a bundle belongs to at most one Track but it may be 416 reused opportunistically on a per-hop basis for routed packets. For 417 a given iteration of the device schedule, the effective channel of 418 the cell is obtained by adding a pseudo-random number to the 419 channelOffset of the cell, which results in a rotation of the 420 frequency that used for transmission. 422 A data frame that is forwarded along a Track has a destination MAC 423 address set to broadcast or a multicast address depending on MAC 424 support. This way, the MAC layer in the intermediate nodes accepts 425 the incoming frame and 6top switches it without incurring a change in 426 the MAC header. In the case of IEEE802.15.4e, this means effectively 427 broadcast, so that along the Track the short address for the 428 destination is set to 0xFFFF. 430 Conversely, a frame that is received along a Track with a destination 431 MAC address set to this node is extracted from the Track stream and 432 delivered to the upper layer. A frame with an unrecognized MAC 433 address is dropped at the MAC layer and thus is not received at the 434 6top sublayer. 436 There are 2 modes for a Track, transport mode and tunnel mode. 438 6.1.1. Transport Mode 440 In transport mode, the Protocol Data Unit (PDU) is associated with 441 flow-dependant meta-data that refers uniquely to the Track, so the 442 6top sublayer can place the frame in the appropriate cell without 443 ambiguity. In the case of IPv6 traffic, this flow identification is 444 transported in the Flow Label of the IPv6 header. Associated with 445 the source IPv6 address, the Flow Label forms a globally unique 446 identifier for that particular Track that is validated at egress 447 before restoring the destination MAC address (DMAC) and punting to 448 the upper layer. 450 | ^ 451 +--------------+ | | 452 | IPv6 | | | 453 +--------------+ | | 454 | 6LoWPAN HC | | | 455 +--------------+ ingress egress 456 | 6top | sets +----+ +----+ restores 457 +--------------+ dmac to | | | | dmac to 458 | TSCH MAC | brdcst | | | | self 459 +--------------+ | | | | | | 460 | LLN PHY | +-------+ +--...-----+ +-------+ 461 +--------------+ 463 Track Forwarding, Transport Mode 465 6.1.2. Tunnel Mode 467 In tunnel mode, the frames originate from an arbitrary protocol over 468 a compatible MAC that may or may not be synchronized with the 6TiSCH 469 network. An example of this would be a router with a dual radio that 470 is capable of receiving and sending WirelessHART or ISA100.11a frames 471 with the second radio, by presenting itself as an access Point or a 472 Backbone Router, respectively. 474 In that mode, some entity (e.g. PCE) can coordinate with a 475 WirelessHART Network Manager or an ISA100.11a System Manager to 476 specify the flows that are to be transported transparently over the 477 Track. 479 +--------------+ 480 | IPv6 | 481 +--------------+ 482 | 6LoWPAN HC | 483 +--------------+ set restore 484 | 6top | +dmac+ +dmac+ 485 +--------------+ | | | | 486 | TSCH MAC | | | | | 487 +--------------+ | | | | 488 | LLN PHY | +-------+ +--...-----+ +-------+ 489 +--------------+ | ingress egress | 490 | | 491 +--------------+ | | 492 | LLN PHY | | | 493 +--------------+ | | 494 | TSCH MAC | | | 495 +--------------+ | | 496 |ISA100/WiHART | | v 497 +--------------+ 499 Figure 4: Track Forwarding, Tunnel Mode 501 In that case, the flow information that identifies the Track at the 502 ingress 6TiSCH router is derived from the RX-cell. The dmac is set 503 to this node but the flow information indicates that the frame must 504 be tunnelled over a particular Track so the frame is not passed to 505 the upper layer. Instead, the dmac is forced to broadcast and the 506 frame is passed to the 6top sublayer for switching. 508 At the egress 6TiSCH router, the reverse operation occurs. Based on 509 metadata associated to the Track, the frame is passed to the 510 appropriate link layer with the destination MAC restored. 512 6.1.3. Tunnel Metadata 514 Metadata coming with the Track configuration is expected to provide 515 the destination MAC address of the egress endpoint as well as the 516 tunnel mode and specific data depending on the mode, for instance a 517 service access point for frame delivery at egress. If the tunnel 518 egress point does not have a MAC address that matches the 519 configuration, the Track installation fails. 521 In transport mode, if the final layer-3 destination is the tunnel 522 termination, then it is possible that the IPv6 address of the 523 destination is compressed at the 6LoWPAN sublayer based on the MAC 524 address. It is thus mandatory at the ingress point to validate that 525 the MAC address that was used at the 6LoWPAN sublayer for compression 526 matches that of the tunnel egress point. For that reason, the node 527 that injects a packet on a Track checks that the destination is 528 effectively that of the tunnel egress point before it overwrites it 529 to broadcast. The 6top sublayer at the tunnel egress point reverts 530 that operation to the MAC address obtained from the tunnel metadata. 532 6.2. Fragment Forwarding 534 Considering that 6LoWPAN packets can be as large as 1280 bytes (the 535 IPv6 MTU), and that the non-storing mode of RPL implies Source 536 Routing that requires space for routing headers, and that a 537 IEEE802.15.4 frame with security may carry in the order of 80 bytes 538 of effective payload, an IPv6 packet might be fragmented into more 539 than 16 fragments at the 6LoWPAN sublayer. 541 This level of fragmentation is much higher than that traditionally 542 experienced over the Internet with IPv4 fragments, where 543 fragmentation is already known as harmful. 545 In the case to a multihop route within a 6TiSCH network, Hop-by-Hop 546 recomposition occurs at each hop in order to reform the packet and 547 route it. This creates additional latency and forces intermediate 548 nodes to store a portion of a packet for an undetermined time, thus 549 impacting critical resources such as memory and battery. 551 [I-D.thubert-roll-forwarding-frags] describes a mechanism whereby the 552 datagram tag in the 6LoWPAN Fragment is used as a label for switching 553 at the 6LoWPAN sublayer. The draft allows for a degree of flow 554 control base on an Explicit Congestion Notification, as well as end- 555 to-end individual fragment recovery. 557 | ^ 558 +--------------+ | | 559 | IPv6 | | +----+ +----+ | 560 +--------------+ | | | | | | 561 | 6LoWPAN HC | | learn learn | 562 +--------------+ | | | | | | 563 | 6top | | | | | | | 564 +--------------+ | | | | | | 565 | TSCH MAC | | | | | | | 566 +--------------+ | | | | | | 567 | LLN PHY | +-------+ +--...-----+ +-------+ 568 +--------------+ 570 Figure 5: Forwarding First Fragment 572 In that model, the first fragment is routed based on the IPv6 header 573 that is present in that fragment. The 6LoWPAN sublayer learns the 574 next hop selection, generates a new datagram tag for transmission to 575 the next hop, and stores that information indexed by the incoming MAC 576 address and datagram tag. The next fragments are then switched based 577 on that stored state. 579 | ^ 580 +--------------+ | | 581 | IPv6 | | | 582 +--------------+ | | 583 | 6LoWPAN HC | | replay replay | 584 +--------------+ | | | | | | 585 | 6top | | | | | | | 586 +--------------+ | | | | | | 587 | TSCH MAC | | | | | | | 588 +--------------+ | | | | | | 589 | LLN PHY | +-------+ +--...-----+ +-------+ 590 +--------------+ 592 Figure 6: Forwarding Next Fragment 594 A bitmap and an ECN echo in the end-to-end acknowledgement enable the 595 source to resend the missing fragments selectively. The first 596 fragment may be resent to carve a new path in case of a path failure. 597 The ECN echo set indicates that the number of outstanding fragments 598 should be reduced. 600 6.3. IPv6 Forwarding 602 As the packets are routed at layer 3, traditional QoS and RED 603 operations are expected to prioritize flows with differentiated 604 services. A new class of service for Deterministic Forwarding is 605 being defined to that effect in 606 [I-D.svshah-tsvwg-lln-diffserv-recommendations]. 608 | ^ 609 +--------------+ | | 610 | IPv6 | | +-QoS+ +-QoS+ | 611 +--------------+ | | | | | | 612 | 6LoWPAN HC | | | | | | | 613 +--------------+ | | | | | | 614 | 6top | | | | | | | 615 +--------------+ | | | | | | 616 | TSCH MAC | | | | | | | 617 +--------------+ | | | | | | 618 | LLN PHY | +-------+ +--...-----+ +-------+ 619 +--------------+ 621 Figure 7: IP Forwarding 623 7. TSCH and 6top 625 7.1. 6top 627 6top is a logical link control sitting between the IP layer and the 628 TSCH MAC layer, which provides the link abstraction that is required 629 for IP operations. The 6top operations are specified in 630 [I-D.wang-6tisch-6top-sublayer]. In particular, 6top provides a 631 management interface that enables an external management entity to 632 schedule cells and slotFrames, and allows the addition of 633 complementary functionality, for instance to support a dynamic 634 schedule management based on observed resource usage as discussed in 635 section Section 8.2. The 6top data model and management interfaces 636 are further discussed in Section 8.3. 638 If the scheduling entity explicitly specifies the slotOffset/ 639 channelOffset of the cells to be added/deleted, those cells are 640 marked as "hard". 6top cannot move hard cells in the TSCH schedule. 641 Hard cells are for example used by a central PCE. 643 6top contains a monitoring process which monitors the performance of 644 cells, and can move a cell in the TSCH schedule when it performs bad. 645 This is only applicable to cells which are marked as "soft". To 646 reserve a soft cell, the higher layer does not indicate the exact 647 slotOffset/channelOffset of the cell to add, but rather the resulting 648 bandwidth and QoS requirements. When the monitoring process triggers 649 a cell reallocation, the two neighbor motes communicating over this 650 cell negotiate its new position in the TSCH schedule. 652 7.2. 6top and RPL Objective Function operations 654 An implementation of a RPL [RFC6550] Objective Function (OF), such as 655 the RPL Objective Function Zero (OF0) [RFC6552] that is used in the 656 Minimal 6TiSCH Configuration [I-D.ietf-6tisch-minimal] to support RPL 657 over a static schedule, may leverage, for its internal computation, 658 the information maintained by 6top. 660 In particular, 6top creates and maintains an abstract neighbor table. 661 A neighbor table entry contains a set of statistics with respect to 662 that specific neighbor including the time when the last packet has 663 been received from that neighbor, a set of cell quality metrics 664 (RSSI, LQI), the number of packets sent to the neighbor or the number 665 of packets received from it. This information can be obtained 666 through 6top management APIs as detailed in the 6top sublayer 667 specification [I-D.wang-6tisch-6top-sublayer] and used to compute a 668 Rank Increment that will determine the selection of the preferred 669 parent. 671 6top provides statistics about the underlying layer so the OF can be 672 tuned to the nature of the TSCH MAC layer. 6top also enables the RPL 673 OF to influence the MAC behaviour, for instance by configuring the 674 periodicity of IEEE802.15.4e Extended Beacons (EB's). By augmenting 675 the EB periodicity, it is possible to change the network dynamics so 676 as to improve the support of devices that may change their point of 677 attachment in the 6TiSCH network. 679 Some RPL control messages, such as the DODAG Information Object (DIO) 680 are ICMPv6 messages that are broadcast to all neighbor nodes. With 681 6TiSCH, the broadcast channel requirement is addressed by 6top by 682 configuring TSCH to provide a broadcast channel, as opposed to, for 683 instance, piggybacking the DIO messages in Enhance Beacons. 685 In the TSCH schedule, each cell has the IEEE802.15.4e LinkType 686 attribute. Setting the LinkType to ADVERTISING indicates that the 687 cell MAY be used to send an Enhanced Beacon. When a node forms its 688 Enhanced Beacon, the cell, with LinkType=ADVERTISING, SHOULD be 689 included in the FrameAndLinkIE, and its LinkOption field SHOULD be 690 set to the combination of "Receive" and "Timekeeping". The receiver 691 of the Enhanced Beacon MAY be listening at the cell to get the 692 Enhanced Beacon ([IEEE802154e]). 6top takes this way to establish 693 broadcast channel, which not only allows TSCH to broadcast Enhanced 694 Beacons, but also allows an upper layer like RPL. 696 To broadcast ICMPv6 control messages used by RPL such as DIO or DAO, 697 6top uses the payload of a Data frames. The message is inserted into 698 the queue associated with the cells which LinkType is set to 699 ADVERTISING. Then, taking advantage of the broadcast cell feature 700 established with FrameAndLinkIE (as described above), the RPL control 701 message can be received by neighbors, which enables the maintenance 702 of RPL DODAGs. 704 A LinkOption combining "Receive" and "Timekeeping" bits indicates to 705 the receivers of the Enhanced Beacon that the cell MUST be used as a 706 broadcast cell. The frequency of sending Enhanced Beacons or other 707 broadcast messages by the upper layer is determined by the timers 708 associated with the messages. For example, the transmission of 709 Enhance Beacons is triggered by a timer in 6top; transmission of a 710 DIO message is triggered by the trickle timer of RPL. 712 7.3. Network Synchronization 714 Nodes in a TSCH network must be time synchronized. A node keeps 715 synchronized to its time source neighbor through a combination of 716 frame-based and acknowledgement-based synchronization. In order to 717 maximize battery life and network throughput, it is advisable that 718 RPL ICMP discovery and maintenance traffic (governed by the trickle 719 timer) be somehow coordinated with the transmission of time 720 synchronization packets (especially with enhanced beacons). This 721 could be achieved through an interaction of the 6top sublayer and the 722 RPL objective Function, or could be controlled by a management 723 entity. 725 Time distribution requires a loop-less structure. Nodes taken in a 726 synchronization loop will rapidly desynchronize from the network and 727 become isolated. It is expected that a RPL DAG with a dedicated 728 global Instance is deployed for the purpose of time synchronization. 729 That Instance is referred to as the Time Synchronization Global 730 Instance (TSGI). The TSGI can be operated in either of the 3 modes 731 that are detailed in RPL [RFC6550] section "3.1.3. Instances, 732 DODAGs, and DODAG Versions". Multiple uncoordinated DODAGs with 733 independent roots may be used if all the roots share a common time 734 source such as the Global Positioning System (GPS). In the absence 735 of a common time source, the TSGI should form a single DODAG with a 736 virtual root. A backbone network is then used to synchronize and 737 coordinate RPL operations between the backbone routers that act as 738 sinks for the LLN. 740 A node that has not joined the TSGI advertises a MAC level Join 741 Priority of 0xFF to notify its neighbors that is is not capable of 742 serving as time parent. A node that has joined the TSGI advertises a 743 MAC level Join Priority set to its DAGRank() in that Instance, where 744 DAGRank() is the operation specified in [RFC6550], section "3.5.1. 745 Rank Comparison". 747 A root is configured or obtains by some external means the knowledge 748 of the RPLInstanceID for the TSGI. The root advertises its DagRank 749 in the TSGI, that MUST be less than 0xFF, as its Join Priority (JP) 750 in its IEEE802.15.4e Extended Beacons (EB). We'll note that the JP 751 is now specified between 0 and 0x3F leaving 2 bits in the octet 752 unused in the IEEE802.15.4e specification. After consultation with 753 IEEE authors, it was asserted that 6TiSCH can make a full use of the 754 octet to carry an integer value up to 0xFF. 756 A node that reads a Join Priority of less than 0xFF should join the 757 neighbor with the lesser Join Priority and use it as time parent. If 758 the node is configured to serve as time parent, then the node should 759 join the TSGI, obtain a Rank in that Instance and start advertising 760 its own DagRank in the TSGI as its Join Priority in its EBs. 762 7.4. SlotFrames and Priorities 764 6TiSCH enables in essence the capability to use IPv6 over a MAC layer 765 that enables to schedule some of the transmissions. In order to 766 ensure that the medium if free of contending packets when time 767 arrives for a scheduled transmission, a window of time is defined 768 around the scheduled transmission time where the medium must be free 769 of contending energy. 771 One simple way to obtain such a window is to format time and 772 frequencies in cells of transmission of equal duration. This is the 773 method that is adopted in IEEE802.15.4e TSCH as well as the Long Term 774 Evolution (LTE) of cellular networks. 776 In order to describe that formatting of time and frequencies, the 777 6TiSCH architecture defines a global concept that is called a Channel 778 Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of 779 cells with an height equal to the number of available channels 780 (indexed by ChannelOffsets), a timeSlot duration (10-15 milliseconds 781 are typical in 802.15.4e TSCH) and a width (in timeSlots) that is the 782 period of the network scheduling operation (indexed by slotOffsets) 783 for that CDU matrix. 785 A CDU matrix iterates over and over with a pseudo-random rotation 786 from an epoch time. In a given network, there might be multiple CDU 787 matrices that operate with different width, so they have different 788 durations and represent different periodic operations. It is 789 RECOMMENDED that all CDU matrices in a 6TiSCH domain operate with the 790 same cell duration and are aligned, so as to optimize the chances of 791 interferences from slotted-aloha operations. The knowledge of the 792 CDU matrices is shared between all the nodes and used in particular 793 to define slotFrames. 795 A slotFrame is a MAC-level abstraction that is common to all nodes 796 and contains a series of timeSlots of equal length and precedence. 797 It is characterized by a slotFrame_ID, and a slotFrame_size. A 798 slotFrame aligns to a CDU matrix for its parameters, such as number 799 and duration of timeSlots. 801 Multiple slotFrames can coexist in a node schedule, i.e., a node can 802 have multiple activities scheduled in different slotFrames, based on 803 the precedence of the 6TiSCH topologies. The slotFrames may be 804 aligned to different CDU matrices and thus have different width. 805 There is typically one slotFrame for scheduled traffic that has the 806 highest precedence and one or more slotFrame(s) for RPL traffic. The 807 timeSlots in the slotFrame are indexed by the SlotOffset; the first 808 cell is at SlotOffset 0. 810 A 6TISCH Instance is associated to one slotFrame. A slotFrame may be 811 shared by multiple Instances of equal relative precedence. Within an 812 Instance, 6top uses priority queues to manage concurrent data flows 813 of different priorities within an Instance and between Instances of a 814 same precedence, associated to a given IPv6 link and a given bundle 815 of TX-cells. When a packet is received from an higher layer for 816 transmission, 6top inserts that packet in the outgoing queue which 817 matches the packet best (DSCP can therefore be used). At each 818 scheduled transmit slot, 6top looks for the frame in all the outgoing 819 queues that best matches the cells. If a frame is found, it is given 820 to the TSCH MAC for transmission. 822 7.5. Distributing the reservation of cells 824 6TiSCH expects a high degree of scalability together with a 825 distributed routing functionality based on RPL. To achieve this 826 goal, the spectrum must be allocated in a way that allows for spatial 827 reuse between zones that will not interfere with one another. In a 828 large and spatially distributed network, a 6TiSCH node is often in a 829 good position to determine usage of spectrum in its vicinity. 831 Use cases for distributed routing are often associated with a 832 statistical distribution of best-effort traffic with variable needs 833 for bandwidth on each individual link. With 6TiSCH, the link 834 abstraction is implemented as a bundle of cells; the size of a bundle 835 is optimal when both the energy wasted idle listening and the packet 836 drops due to congestion loss are minimized. This can be maintained 837 if the number of cells in a bundle is adapted dynamically, and with 838 enough reactivity, to match the variations of best-effort traffic. 839 In turn, the agility to fulfil the needs for additional cells 840 improves when the number of interactions with other devices and the 841 protocol latencies are minimized. 843 6TiSCH limits that interaction to RPL parents that will only 844 negotiate with other RPL parents, and performs that negotiation by 845 groups of cells as opposed to individual cells. The 6TiSCH 846 architecture allows RPL parents to adjust dynamically, and 847 independently from the PCE, the amount of bandwidth that is used to 848 communicate between themselves and their children, in both 849 directions; to that effect, an allocation mechanism enables a RPL 850 parent to obtain the exclusive use of a portion of a CDU matrix 851 within its interference domain. 853 The 6TiSCH architecture introduces the concept of chunks 854 [I-D.ietf-6tisch-terminology]) to operate such spectrum distribution 855 for a whole group of cells at a time. The CDU matrix is formatted 856 into a set of chunks, each of them identified uniquely by a chunk-ID. 857 The knowledge of this formatting is shared between all the nodes in a 858 6TiSCH network. 6TiSCH also defines the process of chunk ownership 859 appropriation whereby a RPL parent discovers a chunk that is not used 860 in its interference domain (e.g lack of energy detected in reference 861 cells in that chunk); then claims the chunk, and then defends it in 862 case another RPL parent would attempt to appropriate it while it is 863 in use. The chunks is the basic unit of ownership that is used in 864 that process. 866 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 867 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| 868 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 869 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| 870 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 871 ... 872 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 873 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| 874 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 875 0 1 2 3 4 5 6 M 877 Figure 8: CDU matrix Partitioning in Chunks 879 As a result of the process of chunk ownership appropriation, the RPL 880 parent has exclusive authority to decide which cell in the 881 appropriated chunk can be used by which node in its interference 882 domain. In other words, it is implicitly delegated the right to 883 manage the portion of the CDU matrix that is represented by the 884 chunk. The RPL parent may thus orchestrate which transmissions occur 885 in any of the cells in the chunk, by allocating cells from the chunk 886 to any form of communication (unicast, multicast) in any direction 887 between itself and its children. Initially, those cells are added to 888 the heap of free cells, then dynamically placed into existing 889 bundles, in new bundles, or allocated opportunistically for one 890 transmission. 892 The appropriation of a chunk can also be requested explicitly by the 893 PCE to any node. In that case, the node still may need to perform 894 the appropriation process to validate that no other node has claimed 895 that chunk already. After a successful appropriation, the PCE owns 896 the cells in that chunk, and may use them as hard cells to set up 897 tracks. 899 8. Schedule Management Mechanisms 901 6TiSCH uses 4 paradigms to manage the TSCH schedule of the LLN nodes: 902 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring 903 and scheduling management, and Hop-by-hop scheduling. Multiple 904 mechanisms are defined that implement the associated Interaction 905 Models, and can be combined and used in the same LLN. Which 906 mechanism(s) to use depends on application requirements. 908 8.1. Minimal Static Scheduling 910 In the simplest instantiation of a 6TiSCH network, a common fixed 911 schedule may be shared by all nodes in the network. Cells are 912 shared, and nodes contend for slot access in a slotted aloha manner. 914 A static TSCH schedule can be used to bootstrap a network, as an 915 initial phase during implementation, or as a fall-back mechanism in 916 case of network malfunction. This scheduled can be preconfigured or 917 learnt by a node when joining the network. Regardless, the schedule 918 remains unchanged after the node has joined a network. The Routing 919 Protocol for LLNs (RPL) is used on the resulting network. This 920 "minimal" scheduling mechanism that implements this paradigm is 921 detailed in [I-D.ietf-6tisch-minimal]. 923 8.2. Neighbor-to-neighbor Scheduling 925 In the simplest instantiation of a 6TiSCH network described in 926 Section 8.1, nodes may expect a packet at any cell in the schedule 927 and will waste energy idle listening. In a more complex 928 instantiation of a 6TiSCH network, a matching portion of the schedule 929 is established between peers to reflect the observed amount of 930 transmissions between those nodes. The aggregation of the cells 931 between a node and a peer forms a bundle that the 6top layer uses to 932 implement the abstraction of a link for IP. The bandwidth on that 933 link is proportional to the number of cells in the bundle. 935 If the size of a bundle is configured to fit an average amount of 936 bandwidth, peak emissions will be destroyed. If the size is 937 configured to allow for peak emissions, energy is be wasted idle 938 listening. 940 In the most efficient instantiation of a 6TiSCH network, the size of 941 the bundles that implement the links may be changed dynamically in 942 order to adapt to the need of end-to-end flows routed by RPL. An 943 optional On-The-Fly (OTF) component may be used to monitor bandwidth 944 usage and perform requests for dynamic allocation by the 6top 945 sublayer. The OTF component is not part of the 6top sublayer. It 946 may be collocated on the same device or may be partially or fully 947 offloaded to an external system. 949 The 6top sublayer [I-D.wang-6tisch-6top-sublayer] defines a protocol 950 for neighbor nodes to reserve soft cells to one another. Because 951 this reservation is done without global knowledge of the schedule of 952 nodes in the LLN, scheduling collisions are possible. 6top defines a 953 monitoring process which continuously tracks the packet delivery 954 ratio of soft cells. It uses these statistics to trigger the 955 relocation of a soft cell in the schedule, using a negotiation 956 protocol between the neighbors nodes communicating over that cell. 958 Monitoring and relocation is done in the 6top layer. For the upper 959 layer, the connection between two neighbor nodes appears as an number 960 of cells. Depending on traffic requirements, the upper layer can 961 request 6top to add or delete a number of cells scheduled to a 962 particular neighbor, without being responsible for choosing the exact 963 slotOffset/channelOffset of those cells. 965 8.3. Remote Monitoring and Schedule Management 967 The 6top interface document [I-D.ietf-6tisch-6top-interface] 968 specifies the generic data model that can be used to monitor and 969 manage resources at the 6top sublayer. Abstract methods are 970 suggested for use by a management entity in the device. The data 971 model also enables remote control operations on the 6top sublayer. 973 Being able to interact with the 6top sublayer of a node multiple hops 974 away can be used for monitoring, scheduling, or a combination of 975 both. The architecture supports variations on the deployment model, 976 and focuses on the flows rather than whether there is a proxy or a 977 translational operation on the way. 979 [I-D.ietf-6tisch-coap] defines an mapping of 6top's set of commands 980 described in [I-D.ietf-6tisch-6top-interface] to CoAP resources. 981 This allows an entity to interact with the 6top layer of a node that 982 is multiple hops away in a RESTful fashion. 984 [I-D.ietf-6tisch-coap] defines a basic set CoAP resources and 985 associated RESTful access methods (GET/PUT/POST/DELETE). The payload 986 (body) of the CoAP messages is encoded using the CBOR format. The 987 draft also defines the concept of "profiles" to allow for future or 988 specific extensions, as well as a mechanism for a CoAP client to 989 discover the profiles installed on a node. 991 The entity issuing the CoAP requests can be a central scheduling 992 entity (e.g. a PCE), a node multiple hops away with the authority to 993 modify the TSCH schedule (e.g. the head of a local cluster), or a 994 external device monitoring the overall state of the network (e.g. 995 NME). The architecture allows for different types of interactions 996 between this CoAP client and a node in the network: 998 8.4. Hop-by-hop Scheduling 1000 A node can reserve a track to a destination node multiple hops away 1001 by installing soft cells at each intermediate node. This forms a 1002 track of soft cells. It is the responsibility of the 6top sublayer 1003 of each node on the track to monitor these soft cells and trigger 1004 relocation when needed. 1006 This hop-by-hop reservation mechanism is similar to [RFC2119] and 1007 [RFC5974]. The protocol for a node to trigger hop-by-hop scheduling 1008 is not yet defined. 1010 9. Centralized vs. Distributed Routing 1012 6TiSCH supports a mixed model of centralized routes and distributed 1013 routes. Centralized routes can for example computed by a entity such 1014 as a PCE. Distributed routes are computed by RPL. 1016 Both methods may inject routes in the Routing Tables of the 6TiSCH 1017 routers. In either case, each route is associated with a 6TiSCH 1018 topology that can be a RPL Instance topology or a track. The 6TiSCH 1019 topology is indexed by a Instance ID, in a format that reuses the 1020 RPLInstanceID as defined in RPL [RFC6550]. 1022 Both RPL and PCE rely on shared sources such as policies to define 1023 Global and Local RPLInstanceIDs that can be used by either method. 1024 It is possible for centralized and distributed routing to share a 1025 same topology. Generally they will operate in different slotFrames, 1026 and centralized routes will be used for scheduled traffic and will 1027 have precedence over distributed routes in case of conflict between 1028 the slotFrames. 1030 9.1. Packet Marking and Handling 1032 All packets inside a 6TiSCH domain MUST carry the Instance ID that 1033 identifies the 6TiSCH topology that is to be used for routing and 1034 forwarding that packet. The location of that information MUST be the 1035 same for all packets forwarded inside the domain. 1037 For packets that are routed by RPL [RFC6550], that information is the 1038 RPLInstanceID that is carried as part of the RPL Packet Information, 1039 which is defined in section 11.2 "Loop Avoidance and Detection". 1041 At the time of this writing, there are 2 methods to transport the RPL 1042 Packet Information in an IPv6 packet, either in a IPv6 Hop-By-Hop 1043 Header, or encoded in a compressed fashion in the IPv6 Flow Label. 1045 The former method places a RPL option [RFC6553] in the IPv6 Hop-By- 1046 Hop Header. It MUST be used if at least one RPL Instance uses a 1047 MinHopRankIncrease that is less than DEFAULT_MIN_HOP_RANK_INCREASE 1048 (defined to 256 in [RFC6550]), which bars the capability to compress 1049 the SenderRank in the RPL Packet Information to a single octet. If 1050 that is not the case, it is RECOMMENDED to use the latter method of 1051 encoding the RPL Packet Information in the Flow Label, which is 1052 specified in [I-D.thubert-6man-flow-label-for-rpl]. 1054 Either way, the method and format used for encoding the RPLInstanceID 1055 is generalized to all 6TiSCH topological Instances, which include 1056 both RPL Instances and Tracks. 1058 10. IANA Considerations 1060 This specification does not require IANA action. 1062 11. Security Considerations 1064 This specification is not found to introduce new security threat. 1066 12. Contributors 1068 The editors and authors wish to recognize the contribution of 1070 Xavier Vilajosana who lead the design of the minimal support with 1071 RPL and contributed deeply to the 6top design. 1073 Qin Wang who lead the design of the 6top sublayer and contributed 1074 related text that was moved and/or adapted in this document. 1076 13. Acknowledgements 1078 This specification is the result interactions in particular during 1079 the 6TiSCH (bi)Weekly call. The authors wish to thank: Alaeddine 1080 Weslati, Alfredo Grieco, Bert Greevenbosch, Cedric Adjih, Diego 1081 Dujovne, Dominique Barthel, Elvis Vogli, Geraldine Texier, Giuseppe 1082 Piro, Guillaume Gaillard, Herman Storey, Ines Robles, Jonathan Simon, 1083 Kazushi Muraoka, Ken Bannister, Kuor Hsin Chang, Laurent Toutain, 1084 Maik Seewald, Maria Rita Palattella, Michael Behringer, Michael 1085 Richardson, Nancy Cam Winget, Nicola Accettura, Nicolas Montavont, 1086 Oleg Hahm, Pat Kinney, Patrick Wetterwald, Paul Duffy, Peter van der 1087 Stock, Pieter de Mil, Pouria Zand, Rouhollah Nabati, Rafa Marin- 1088 Lopez, Raghuram Sudhaakar, Rene Struik, Sedat Gormus, Shitanshu Shah, 1089 Steve Simlo, Subir Das, Tengfei Chang, Tina Tsou, Tom Phinney, Xavier 1090 Lagrange and Yoshihiro Ohba for their various participation. 1092 14. References 1094 14.1. Normative References 1096 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1097 Requirement Levels", BCP 14, RFC 2119, March 1997. 1099 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1100 (IPv6) Specification", RFC 2460, December 1998. 1102 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1103 Information Models and Data Models", RFC 3444, January 1104 2003. 1106 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 1107 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 1108 4080, June 2005. 1110 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1111 Architecture", RFC 4291, February 2006. 1113 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 1114 Proxies (ND Proxy)", RFC 4389, April 2006. 1116 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1117 for IPv6", RFC 4429, April 2006. 1119 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1120 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1121 September 2007. 1123 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1124 Address Autoconfiguration", RFC 4862, September 2007. 1126 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 1127 2007. 1129 [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 1130 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1131 Overview, Assumptions, Problem Statement, and Goals", RFC 1132 4919, August 2007. 1134 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1135 Yegin, "Protocol for Carrying Authentication for Network 1136 Access (PANA)", RFC 5191, May 2008. 1138 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1139 Hoc Networks", RFC 5889, September 2010. 1141 [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS 1142 Signaling Layer Protocol (NSLP) for Quality-of-Service 1143 Signaling", RFC 5974, October 2010. 1145 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1146 in IPv6", RFC 6275, July 2011. 1148 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 1149 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1150 September 2011. 1152 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1153 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 1154 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1155 Lossy Networks", RFC 6550, March 2012. 1157 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 1158 Protocol for Low-Power and Lossy Networks (RPL)", RFC 1159 6552, March 2012. 1161 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1162 Power and Lossy Networks (RPL) Option for Carrying RPL 1163 Information in Data-Plane Datagrams", RFC 6553, March 1164 2012. 1166 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS 1167 SAVI: First-Come, First-Served Source Address Validation 1168 Improvement for Locally Assigned IPv6 Addresses", RFC 1169 6620, May 2012. 1171 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 1172 "Neighbor Discovery Optimization for IPv6 over Low-Power 1173 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1174 November 2012. 1176 14.2. Informative References 1178 [I-D.chakrabarti-nordmark-6man-efficient-nd] 1179 Chakrabarti, S., Nordmark, E., Thubert, P., and M. 1180 Wasserman, "IPv6 Neighbor Discovery Optimizations for 1181 Wired and Wireless Networks", draft-chakrabarti-nordmark- 1182 6man-efficient-nd-05 (work in progress), February 2014. 1184 [I-D.ietf-6tisch-6top-interface] 1185 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 1186 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 1187 6top-interface-00 (work in progress), March 2014. 1189 [I-D.ietf-6tisch-coap] 1190 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 1191 Interaction using CoAP", draft-ietf-6tisch-coap-00 (work 1192 in progress), May 2014. 1194 [I-D.ietf-6tisch-minimal] 1195 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 1196 Configuration", draft-ietf-6tisch-minimal-00 (work in 1197 progress), November 2013. 1199 [I-D.ietf-6tisch-terminology] 1200 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 1201 "Terminology in IPv6 over the TSCH mode of IEEE 1202 802.15.4e", draft-ietf-6tisch-terminology-01 (work in 1203 progress), February 2014. 1205 [I-D.ietf-6tisch-tsch] 1206 Watteyne, T., Palattella, M., and L. Grieco, "Using 1207 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 1208 Statement and Goals", draft-ietf-6tisch-tsch-00 (work in 1209 progress), November 2013. 1211 [I-D.ietf-ipv6-multilink-subnets] 1212 Thaler, D. and C. Huitema, "Multi-link Subnet Support in 1213 IPv6", draft-ietf-ipv6-multilink-subnets-00 (work in 1214 progress), July 2002. 1216 [I-D.ietf-roll-rpl-industrial-applicability] 1217 Phinney, T., Thubert, P., and R. Assimiti, "RPL 1218 applicability in industrial networks", draft-ietf-roll- 1219 rpl-industrial-applicability-02 (work in progress), 1220 October 2013. 1222 [I-D.svshah-tsvwg-lln-diffserv-recommendations] 1223 Shah, S. and P. Thubert, "Differentiated Service Class 1224 Recommendations for LLN Traffic", draft-svshah-tsvwg-lln- 1225 diffserv-recommendations-02 (work in progress), February 1226 2014. 1228 [I-D.thubert-6lowpan-backbone-router] 1229 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 1230 6lowpan-backbone-router-03 (work in progress), February 1231 2013. 1233 [I-D.thubert-6man-flow-label-for-rpl] 1234 Thubert, P., "The IPv6 Flow Label within a RPL domain", 1235 draft-thubert-6man-flow-label-for-rpl-03 (work in 1236 progress), May 2014. 1238 [I-D.thubert-roll-forwarding-frags] 1239 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 1240 Recovery", draft-thubert-roll-forwarding-frags-02 (work in 1241 progress), September 2013. 1243 [I-D.wang-6tisch-6top-sublayer] 1244 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 1245 Operation Sublayer (6top)", draft-wang-6tisch-6top- 1246 sublayer-00 (work in progress), February 2014. 1248 14.3. External Informative References 1250 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 1251 a group of specifications for industrial process and 1252 control devices administered by the HART Foundation", . 1254 [IEEE802.1TSNTG] 1255 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 1256 Networks Task Group", March 2013, 1257 . 1259 [IEEE802154e] 1260 IEEE standard for Information Technology, "IEEE std. 1261 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 1262 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 1263 2012. 1265 [ISA100.11a] 1266 ISA/ANSI, "Wireless Systems for Industrial Automation: 1267 Process Control and Related Applications - ISA100.11a-2011 1268 - IEC 62734", 2011, . 1271 [WirelessHART] 1272 www.hartcomm.org, "Industrial Communication Networks - 1273 Wireless Communication Network and Communication Profiles 1274 - WirelessHART - IEC 62591", 2010. 1276 Authors' Addresses 1278 Pascal Thubert (editor) 1279 Cisco Systems, Inc 1280 Building D 1281 45 Allee des Ormes - BP1200 1282 MOUGINS - Sophia Antipolis 06254 1283 FRANCE 1285 Phone: +33 497 23 26 34 1286 Email: pthubert@cisco.com 1288 Thomas Watteyne 1289 Linear Technology, Dust Networks Product Group 1290 30695 Huntwood Avenue 1291 Hayward, CA 94544 1292 USA 1294 Phone: +1 (510) 400-2978 1295 Email: twatteyne@linear.com 1297 Robert Assimiti 1298 Centero 1299 961 Indian Hills Parkway 1300 Marietta, GA 30068 1301 USA 1303 Phone: +1 404 461 9614 1304 Email: robert.assimiti@centerotech.com