idnits 2.17.1 draft-ietf-6tisch-architecture-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 3) being 60 lines 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 178 has weird spacing: '...scribed in...' == Line 696 has weird spacing: '...ance is deplo...' == Line 1013 has weird spacing: '...hop and a tr...' -- The document date (October 27, 2014) is 3467 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 1509, but not defined == Missing Reference: 'WirelessHART' is mentioned on line 1521, but not defined == Missing Reference: 'HART' is mentioned on line 1500, but not defined == Missing Reference: 'IEEE802.1TSNTG' is mentioned on line 1504, but not defined == Unused Reference: 'I-D.finn-detnet-problem-statement' is defined on line 1426, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipv6-multilink-subnets' is defined on line 1458, but no explicit reference was found in the text == Unused Reference: 'I-D.svshah-tsvwg-deterministic-forwarding' is defined on line 1469, but no explicit reference was found in the text == Unused Reference: 'I-D.svshah-tsvwg-lln-diffserv-recommendations' is defined on line 1474, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 1484, but no explicit reference was found in the text ** 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 3610 ** 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 ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) == Outdated reference: A later version (-07) exists of draft-chakrabarti-nordmark-6man-efficient-nd-04 == Outdated reference: A later version (-05) exists of draft-finn-detnet-problem-statement-01 == 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-00 == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-00 == Outdated reference: A later version (-04) exists of draft-svshah-tsvwg-deterministic-forwarding-01 == Outdated reference: A later version (-04) exists of draft-svshah-tsvwg-lln-diffserv-recommendations-01 Summary: 10 errors (**), 0 flaws (~~), 23 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: April 28, 2015 Linear Technology 6 RA. Assimiti 7 Centero 8 October 27, 2014 10 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e 11 draft-ietf-6tisch-architecture-04 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 April 28, 2015. 50 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Applications and Goals . . . . . . . . . . . . . . . . . . . . 4 68 4. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5 69 5. 6LoWPAN (and RPL) . . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. RPL Leaf Support in 6LoWPAN ND . . . . . . . . . . . . . . 9 71 5.2. registration Failures Due to Movement . . . . . . . . . . 9 72 5.3. Proxy registration . . . . . . . . . . . . . . . . . . . . 9 73 5.4. Target Registration . . . . . . . . . . . . . . . . . . . 10 74 5.5. RPL root vs. 6LBR . . . . . . . . . . . . . . . . . . . . 10 75 5.6. Securing the Registration . . . . . . . . . . . . . . . . 11 76 6. Communication Paradigms and Interaction Models . . . . . . . . 11 77 7. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7.1. 6top . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 7.2. 6top and RPL Objective Function operations . . . . . . . . 13 80 7.3. Network Synchronization . . . . . . . . . . . . . . . . . 14 81 7.4. SlotFrames and Priorities . . . . . . . . . . . . . . . . 15 82 7.5. Distributing the reservation of cells . . . . . . . . . . 16 83 8. Schedule Management Mechanisms . . . . . . . . . . . . . . . . 18 84 8.1. Minimal Static Scheduling . . . . . . . . . . . . . . . . 18 85 8.2. Neighbor-to-neighbor Scheduling . . . . . . . . . . . . . 19 86 8.3. Remote Monitoring and Schedule Management . . . . . . . . 19 87 8.4. Hop-by-hop Scheduling . . . . . . . . . . . . . . . . . . 20 88 9. Forwarding Models . . . . . . . . . . . . . . . . . . . . . . 20 89 9.1. Track Forwarding . . . . . . . . . . . . . . . . . . . . . 21 90 9.1.1. Transport Mode . . . . . . . . . . . . . . . . . . . . 22 91 9.1.2. Tunnel Mode . . . . . . . . . . . . . . . . . . . . . 22 92 9.1.3. Tunnel Metadata . . . . . . . . . . . . . . . . . . . 23 93 9.2. Fragment Forwarding . . . . . . . . . . . . . . . . . . . 24 94 9.3. IPv6 Forwarding . . . . . . . . . . . . . . . . . . . . . 25 95 10. Centralized vs. Distributed Routing . . . . . . . . . . . . . 25 96 10.1. Packet Marking and Handling . . . . . . . . . . . . . . . 26 97 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 98 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 99 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 100 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 101 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 15.1. Normative References . . . . . . . . . . . . . . . . . . 27 103 15.2. Informative References . . . . . . . . . . . . . . . . . 29 104 15.3. External Informative References . . . . . . . . . . . . . 30 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 108 1. Introduction 110 The emergence of radio technology enabled a large variety of new 111 types of devices to be interconnected, at a very low marginal cost 112 compared to wire, at any range from Near Field to interplanetary 113 distances, and in circumstances where wiring would be less than 114 practical, for instance rotating devices. 116 At the same time, a new breed of Time Sensitive Networks is being 117 developed to enable traffic that is highly sensitive to jitter and 118 quite sensitive to latency. Such traffic is not limited to voice and 119 video, but also includes command and control operations such as found 120 in industrial automation or in-vehicle sensors and actuators. 122 At IEEE802.1, the "Audio/Video Task Group", was renamed TSN for Time 123 Sensitive Networking to address Deterministic Ethernet. The 124 IEEE802.15.4 Medium access Control (MAC) has evolved with 125 IEEE802.15.4e that provides in particular the timeSlotted Channel 126 Hopping (TSCH) mode for industrial-type applications. 128 Though at a different time scale, both standards provide 129 Deterministic capabilities to the point that a packet that pertains 130 to a certain flow crosses the network from node to node following a 131 very precise schedule, as a train that leaves intermediate stations 132 at precise times along its path. With TSCH, time is formatted into 133 timeSlots, and an individual cell is allocated to unicast or 134 broadcast communication at the MAC level. The time slotted operation 135 reduces collisions, saves energy, and enables to more closely 136 engineer the network for deterministic properties. The channel 137 hopping aspect is a simple and efficient technique to combat 138 multipath fading and external interference (for example by WiFi 139 emitters). 141 This document presents an architecture for an IPv6 Multi-Link subnet 142 that is composed of a high speed powered backbone and a number of 143 IEEE802.15.4e TSCH wireless networks attached and synchronized by 144 backbone routers. Route Computation may be achieved in a centralized 145 fashion by a Path Computation Element (PCE), in a distributed fashion 146 using the Routing Protocol for Low Power and Lossy Networks (RPL), or 147 in a mixed mode. The Backbone Routers perform proxy IPv6 neighbor 148 Discovery (ND) operations over the backbone on behalf of the wireless 149 devices, so they can share a same IPv6 subnet and appear to be 150 connected to the same backbone as classical devices. timeSlots and 151 other device resources are managed by an abstract Network Management 152 Entity (NME) that may cooperate with the PCE in order to minimize the 153 interaction with and the load on the constrained device. 155 2. Terminology 156 Readers are expected to be familiar with all the terms and concepts 157 that are discussed in "neighbor Discovery for IP version 6" 158 [RFC4861], "IPv6 over Low-Power Wireless Personal Area Networks 159 (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" 160 [RFC4919], neighbor Discovery Optimization for Low-power and Lossy 161 Networks [RFC6775] and "Multi-link Subnet Support in IPv6" [I-D.ietf- 162 ipv6-multilink-subnets]. 164 Readers may benefit from reading the "RPL: IPv6 Routing Protocol for 165 Low-Power and Lossy Networks" [RFC6550] specification; "Multi-Link 166 Subnet Issues" [RFC4903]; "Mobility Support in IPv6" [RFC6275]; 167 "neighbor Discovery Proxies (ND Proxy)" [RFC4389]; "IPv6 Stateless 168 Address Autoconfiguration" [RFC4862]; "FCFS SAVI: First-Come, First- 169 Served Source Address Validation Improvement for Locally Assigned 170 IPv6 Addresses" [RFC6620]; and "Optimistic Duplicate Address 171 Detection" [RFC4429] prior to this specification for a clear 172 understanding of the art in ND-proxying and binding. 174 The draft uses terminology defined or referenced in [I-D.ietf-6tisch- 175 terminology], [I-D.chakrabarti-nordmark-6man-efficient-nd], [I-D 176 .ietf-roll-rpl-industrial-applicability], [RFC5191] and [RFC4080]. 178 The draft also conforms to the terms and models described in 179 [RFC3444] and [RFC5889] and uses the vocabulary and the concepts 180 defined in [RFC4291] for the IPv6 Architecture. 182 3. Applications and Goals 184 The architecture derives from existing industrial standards for 185 Process Control by its focus on Deterministic Networking, in 186 particular with the use of the IEEE802.15.4e TSCH MAC [IEEE802154e] 187 and the centralized PCE. This approach leverages the TSCH MAC 188 benefits for high reliability against interference, low-power 189 consumption on deterministic traffic, and its Traffic Engineering 190 capabilities. Deterministic Networking applies in particular to open 191 and closed control loops, as well as supervisory control flows and 192 management. 194 An incremental set of industrial requirements are addressed with the 195 addition of an autonomic and distributed routing operation based on 196 RPL. These use cases include plant setup and decommissioning, as well 197 as monitoring of lots of lesser importance measurements such as 198 corrosion and events. RPL also enables mobile use cases such as 199 mobile workers and cranes. 201 A Backbone Router is included in order to scale the factory plant 202 subnet to address large deployments, with proxy ND and time 203 synchronization over a high speed backbone. 205 The architecture also applies to building automation that leverage 206 RPL's storing mode to address multipath over a large number of hops, 207 in-vehicle command and control that can be as demanding as industrial 208 applications, commercial automation and asset Tracking with mobile 209 scenarios, home automation and domotics which become more reliable 210 and thus provide a better user experience, and resource management 211 (energy, water, etc.). 213 4. Overview and Scope 215 The scope of the present work is a subnet that, in its basic 216 configuration, is made of a IEEE802.15.4e timeSlotted Channel Hopping 217 (TSCH) [I-D.ietf-6tisch-tsch] MAC Low Power Lossy Network (LLN). 219 ---+-------- ............ ------------ 220 | External Network | 221 | +-----+ 222 +-----+ | NME | 223 | | LLN Border | | 224 | | router +-----+ 225 +-----+ 226 o o o 227 o o o o 228 o o LLN o o o 229 o o o o 230 o 232 The LLN devices communicate over IPv6 [RFC2460] using the 6LoWPAN 233 Header Compression ( 6LoWPAN HC) [RFC6282]. From the perspective of 234 Layer 3, a single LLN interface (typically an IEEE802.15.4-compliant 235 radio) may be seen as a collection of Links with different 236 capabilities for unicast or multicast services. An IPv6 subnet spans 237 over multiple links, effectively forming a Multi-Link subnet. Within 238 that subnet, neighbor Devices are discovered with 6LoWPAN Neighbor 239 Discovery [RFC6775] (6LoWPAN ND). RPL [RFC6550] enables routing 240 within the LLN, in the so called Route Over fashion, either in 241 storing (stateful) or non-storing (stateless, with routing headers) 242 mode. 244 RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) 245 within Instances of the protocol, each Instance being associated with 246 an Objective Function (OF) to form a routing topology. A particular 247 LLN device, the LLN Border Router (LBR), acts as RPL root, 6LoWPAN HC 248 terminator, and LLN Border Router (LBR) to the outside. The LBR is 249 usually powered. More on RPL Instances can be found in section 3.1 250 of RPL [RFC6550], in particular "3.1.2. RPL Identifiers" and "3.1.3. 251 Instances, DODAGs, and DODAG Versions". 253 An extended configuration of the subnet comprises multiple LLNs. The 254 LLNs are interconnected and synchronized over a backbone, that can be 255 wired or wireless. The backbone can be a classical IPv6 network, 256 with neighbor Discovery operating as defined in [RFC4861] and 257 [RFC4862]. The backbone can also support Efficiency-aware IPv6 258 neighbor Discovery Optimizations [I-D.chakrabarti-nordmark-6man- 259 efficient-nd] in mixed mode as described in [I-D.thubert-6lowpan- 260 backbone-router]. 262 Security is often handled at layer 2 and Layer 4. Authentication 263 during the join process can be handled by the Protocol for Carrying 264 Authentication for Network access (PANA) [RFC5191]. 266 The LLN devices are time-synchronized at the MAC level. The LBR that 267 serves as time source is a RPL parent in a particular RPL Instance 268 that serves for time synchronization; this way, the time 269 synchronization starts at the RPL root and follows the RPL DODAGs 270 with no timing loop. 272 ---+-------- ............ ------------ 273 | External Network | 274 | +-----+ 275 | +-----+ | NME | 276 +-----+ | +-----+ | | 277 | | Router | | PCE | +-----+ 278 | | +--| | 279 +-----+ +-----+ 280 | | 281 | Subnet Backbone | 282 +--------------------+------------------+ 283 | | | 284 +-----+ +-----+ +-----+ 285 | | Backbone | | Backbone | | Backbone 286 o | | router | | router | | router 287 +-----+ +-----+ +-----+ 288 o o o o o 289 o o o o o o o o o o o 290 o o o LLN o o o o 291 o o o o o o o o o o o o 293 In the extended configuration, the functionality of the LBR is 294 enhanced to that of Backbone Router (BBR). A BBR is an LBR, but also 295 an Energy Aware Default Router (NEAR) as defined in [I-D.chakrabarti- 296 nordmark-6man-efficient-nd]. The BBR performs ND proxy operations 297 between the registered devices and the classical ND devices that are 298 located over the backbone. 6TiSCH BBRs synchronize with one another 299 over the backbone, so as to ensure that the multiple LLNs that form 300 the IPv6 subnet stay tightly synchronized. If the Backbone is 301 Deterministic (such as defined by the Time Sensitive Networking WG at 302 IEEE), then the Backbone Router ensures that the end-to-end 303 deterministic behavior is maintained between the LLN and the 304 backbone. 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 RPL is the routing protocol of choice for LLNs. (TBD RPL) whether 324 there is a need to define a 6TiSCH OF. 326 (tbd NME) COMAN is working on network Management for LLN. They are 327 considering the Open Mobile Alliance (OMA) Lightweight M2M (LWM2M) 328 Object system. This standard includes DTLS, CoAP (core plus Block 329 and Observe patterns), SenML and CoAP Resource Directory. 331 (tbd PCE) need to work with PCE WG to define flows to PCE, and define 332 how to accommodate PCE routes and reservation. Will probably look a 333 lot like GMPLS. 335 (tbd PANA) There is a debate whether PANA (layer 3) or IEEE802.1x 336 (layer 2) should be used in the join process. There is also a debate 337 whether the node should be able to send any unprotected packet on the 338 medium. Regardless, the security model must ensure that, prior to a 339 join process, packets from a untrusted device must be controlled in 340 volume and in reachability. 342 (tbd Backbone Router) need to work with 6MAN to define ND proxy. 343 Also need BBR sync sync between deterministic Ethernet and 6TiSCH 344 LLNs. 346 IEEE802.1TSN: external, maintain consistency. See also AVnu. 348 IEEE802.15.4: external, (tbd need updates?). 350 ISA100.20 Common Network Management: external, maintain consistency. 352 The 6TiSCH Operation sublayer (6top) [I-D.wang-6tisch-6top-sublayer] 353 is an Logical Link Control (LLC) or a portion thereof that provides 354 the abstraction of an IP link over a TSCH MAC. 356 5. 6LoWPAN (and RPL) 358 This architecture expects that a 6LoWPAN node can connect as a leaf 359 to a RPL network, where the leaf support is the minimal functionality 360 to connect as a host to a RPL network without the need to participate 361 to the full routing protocol. The support of leaf can be implemented 362 as a minor increment to 6LoWPAN ND, with the additional capability to 363 carry a sequence number that is used to track the movements of the 364 device, and optionally some information about the RPL topology that 365 this device will join. 367 The root of the RPL topology is logically separated from the 6BBR 368 that is used to connect the RPL topology to the backbone. The RPL 369 root can use Efficient ND as the interface to register an LLN node in 370 its topology to the 6BBR for whatever operation the 6BBR performs, 371 such as ND proxy operations, or injection in a routing protocol. It 372 results that, as illustrated in Figure 4, the periodic signaling 373 could start at the leaf node with 6LoWPAN ND, then would be carried 374 over RPL to the RPL root, and then with Efficient-ND to the 6BBR. 375 Efficient ND being an adaptation of 6LoWPAN ND, it makes sense to 376 keep those two homogeneous in the way they use the source and the 377 target addresses in the Neighbor Solicitation (NS) messages for 378 registration, as well as in the options that they use for that 379 process. 381 6LoWPAN Node 6LR 6LBR 6BBR 382 (RPL leaf) (router) (root) 383 | | | | 384 | 6LoWPAN ND |6LoWPAN ND+RPL | Efficient ND | IPv6 ND 385 | LLN link |Route-Over mesh| IPv6 link | Backbone 386 | | | | 387 | NS(ARO) | | | 388 |-------------->| | | 389 | 6LoWPAN ND | DAR (then DAO)| | 390 | |-------------->| | 391 | | | NS(ARO) | 392 | | |-------------->| 393 | | | | DAD 394 | | | |------> 395 | | | | 396 | | | NA(ARO) | 397 | | |<--------------| 398 | | DAC | | 399 | |<--------------| | 400 | NA(ARO) | | | 401 |<--------------| | | 403 As the network builds up, a node should start as a leaf to join the 404 RPL network, and may later turn into both a RPL-capable router and a 405 6LR, so as to accept leaf nodes to recursively join the network. 407 5.1. RPL Leaf Support in 6LoWPAN ND 409 RPL needs a set of information in order to advertise a leaf node 410 through a DAO message and establish reachability. 412 At the bare minimum the leaf device must provide a sequence number 413 that matches the RPL specification in section 7. Section 4.1 of [I-D 414 .chakrabarti-nordmark-6man-efficient-nd], on the Address Registration 415 Option (ARO), already incorporates that addition with a new field in 416 the option called the Transaction ID. 418 If for some reason the node is aware of RPL topologies, then 419 providing the RPL InstanceID for the instances to which the node 420 wishes to participate would be a welcome addition. In the absence of 421 such information, the RPL router must infer the proper instanceID 422 from external rules and policies. 424 On the backbone, the InstanceID is expected to be mapped onto a 425 VLANID. Neither WiFi nor Efficient ND do provide a mapping to 426 VLANIDs, and it is unclear, when a wireless node attaches to a 427 backbone where VLANs are defined, which VLAN the wireless device 428 attaches to. Considering that a VLAN is effectively the IP link on 429 the backbone, adding the InstanceID to both specifications could be a 430 welcome addition. 432 5.2. registration Failures Due to Movement 434 Registration to the 6LBR through DAR/DAC messages [RFC6775] may 435 percolate slowly through an LLN mesh, and it might happen that in the 436 meantime, the 6LoWPAN node moves and registers somewhere else. Both 437 RPL and 6LoWPAN ND lack the capability to indicate that the same node 438 is registered elsewhere, so as to invalidate states down the 439 deprecated path. 441 In its current expression and functionality, 6LoWPAN ND considers 442 that the registration is used for the purpose of DAD only as opposed 443 to that of achieving reachability, and as long as the same node 444 registers the IPv6 address, the protocol is functional. In order to 445 act as a RPL leaf registration protocol and achieve reachability, the 446 device must use the same TID for all its concurrent registrations, 447 and registrations with a past TID should be declined. The state for 448 an obsolete registration in the 6LR, as well as the RPL routers on 449 the way, should be invalidated. This can only be achieved with the 450 addition of a new Status in the DAC message, and a new error/clean-up 451 flow in RPL. 453 5.3. Proxy registration 454 The 6BBR provides the capability to defend an address that is owned 455 by a 6LoWPAN Node, and attract packets to that address, whether it is 456 done by proxying ND over a MultiLink Subnet, redistributing the 457 address in a routing protocol or advertising it through an alternate 458 proxy registration such as the Locator/ID Separation Protocol 459 [RFC6830] (LISP) or Mobility Support in IPv6 [RFC6275] (MIPv6). In a 460 LLN, it makes sense to piggyback the request to proxy/defend an 461 address with its registration. 463 5.4. Target Registration 465 In their current incarnations, both 6LoWPAN ND and Efficient ND 466 expect that the address being registered is the source of the NS(ARO) 467 message and thus impose that a Source Link-Layer Address (SLLA) 468 option be present in the message. In a mesh scenario where the 6LBR 469 is physically separated from the 6LoWPAN Node, the 6LBR does not own 470 the address being registered. This suggests that [I-D.chakrabarti- 471 nordmark-6man-efficient-nd] should evolve to register the Target of 472 the NS message as opposed to the Source Address. From another 473 perspective, it may happen, in the use case of a Star topology, that 474 the 6LR, 6LBR and 6BBR are effectively collapsed and should support 475 6LoWPAN ND clients. The convergence of efficient ND and 6LoWPAN ND 476 into a single protocol is thus highly desirable. 478 In any case, as long as the DAD process is not complete for the 479 address used as source of the packet, it is against the current 480 practice to advertise the SLLA, since this may corrupt the ND cache 481 of the destination node, as discussed in the Optimistic DAD 482 specification [RFC4429] with regards to the TENTATIVE state. 484 This may look like a chicken and an egg problem, but in fact 6LoWPAN 485 ND acknowledges that the Link-Local Address that is based on an 486 EUI-64 address of a LLN node may be autoconfigured without the need 487 for DAD. It results that a node could use that Address as source, 488 with an SSLA option in the message if required, to register any other 489 addresses, either Global or Unique-Local Addresses, which would be 490 indicated in the Target. 492 The suggested change is to register the target of the NS message, and 493 use Target Link-Layer Address (TLLA) in the NS as opposed to the SLLA 494 in order to install a Neighbor Cache Entry. This would apply to both 495 Efficient ND and 6LoWPAN ND in a very same manner, with the caveat 496 that depending on the nature of the link between the 6LBR and the 497 6BBR, the 6LBR may resort to classical ND or DHCPv6 to obtain the 498 address that it uses to source the NS registration messages, whether 499 for itself or on behalf of LLN nodes. 501 5.5. RPL root vs. 6LBR 503 6LoWPAN ND is unclear on how the 6LBR is discovered, and how the 504 liveliness of the 6LBR is asserted over time. On the other hand, the 505 discovery and liveliness of the RPL root are obtained through the RPL 506 protocol. 508 When 6LoWPAN ND is coupled with RPL, it makes sense to collocate the 509 6LBR and the RPL root functionalities. The DAR/DAC exchange becomes 510 a preamble to the DAO messages that are used from then on to 511 reconfirm the registration, thus eliminating a duplication of 512 functionality between DAO and DAR messages. 514 5.6. Securing the Registration 516 A typical attack against IPv6 ND is address spoofing, whereby a rogue 517 node claims the IPv6 Address of another node in and hijacks its 518 traffic. 520 SEcure Neighbor Discovery (SEND) [RFC3971] is designed to protect 521 each individual ND lookup/advertisement in a peer to peer model where 522 each lookup may be between different parties. This is not the case 523 in a 6LoWPAN ND LLN where, as illustrated in Figure 4, the 6LBR 524 terminates all the flows and may store security information for later 525 validation. 527 Additionally SEND requires considerably enlarged ND messages to carry 528 cryptographic material, and requires that each protected address is 529 generated cryptographically, which implies the computation of a 530 different key for each Cryptographically Generated Address (CGA). 531 SEND as defined in [RFC3971] is thus largely unsuitable for 532 application in a LLN. 534 Once an Address is registered, the 6LBR maintains a state for that 535 Address and is in position to bind securely the first registration 536 with the Node that placed it, whether the Address is CGA or not. It 537 should thus be possible to protect the ownership of all the addresses 538 of a 6LoWPAN Node with a single key, and there should not be a need 539 to carry the cryptographic material more than once to the 6LBR. 541 The energy constraint is usually a foremost factor, and attention 542 should be paid to minimize the burden on the CPU. Hardware-assisted 543 support of variants of the Counter with CBC-MAC [RFC3610] (CCM) 544 authenticated encryption block cipher mode such as CCM* are common in 545 LowPower ship-set implementations, and 6LoWPAN ND security mechanism 546 should be capable to reuse them when applicable. 548 Finally, the code footprint in the device being also an issue, the 549 capability to reuse not only hardware-assist mechanisms but also 550 software across layers has to be considered. For instance, if code 551 has to be present for upper-layer operations, e.g AES-CCM Cipher 552 Suites for Transport Layer Security (TLS) [RFC6655], then the 553 capability to reuse that code should be considered. 555 6. Communication Paradigms and Interaction Models 557 [I-D.ietf-6tisch-terminology] defines the terms of Communication 558 Paradigms and Interaction Models, which can be placed in parallel to 559 the Information Models and Data Models that are defined in 560 [RFC3444]. 562 A Communication Paradigms would be an abstract view of a protocol 563 exchange, and would come with an Information Model for the 564 information that is being exchanged. In contrast, an Interaction 565 Models would be more refined and could point on standard operation 566 such as a Representational state transfer (REST) "GET" operation and 567 would match a Data Model for the data that is provided over the 568 protocol exchange. 570 section 2.1.3 of [I-D.ietf-roll-rpl-industrial-applicability] and 571 next sections discuss application-layer paradigms, such as Source- 572 sink (SS) that is a Multipeer to Multipeer (MP2MP) model primarily 573 used for alarms and alerts, Publish-subscribe (PS, or pub/sub) that 574 is typically used for sensor data, as well as Peer-to-peer (P2P) and 575 Peer-to-multipeer (P2MP) communications. Additional considerations 576 on Duocast and its N-cast generalization are also provided. Those 577 paradigms are frequently used in industrial automation, which is a 578 major use case for IEEE802.15.4e TSCH wireless networks with 579 [ISA100.11a] and [WirelessHART], that provides a wireless access to 580 [HART] applications and devices. 582 This specification focuses on Communication Paradigms and Interaction 583 Models for packet forwarding and TSCH resources (cells) management. 584 Management mechanisms for the TSCH schedule at Link-layer (one-hop), 585 Network-layer (multithop along a track), and Application-layer 586 (remote control) are discussed in Section 8. Link-layer frame 587 forwarding interactions are discussed in Section 9, and Network-layer 588 Packet routing is addressed in Section 10. 590 7. TSCH and 6top 592 7.1. 6top 594 6top is a logical link control sitting between the IP layer and the 595 TSCH MAC layer, which provides the link abstraction that is required 596 for IP operations. The 6top operations are specified in [I-D.wang- 597 6tisch-6top-sublayer]. In particular, 6top provides a management 598 interface that enables an external management entity to schedule 599 cells and slotFrames, and allows the addition of complementary 600 functionality, for instance to support a dynamic schedule management 601 based on observed resource usage as discussed in Section 8.2. 603 The 6top data model and management interfaces are further discussed 604 in Section 8.3. 606 If the scheduling entity explicitly specifies the slotOffset/ 607 channelOffset of the cells to be added/deleted, those cells are 608 marked as "hard". 6top cannot move hard cells in the TSCH schedule. 609 Hard cells are for example used by a central PCE. 611 6top contains a monitoring process which monitors the performance of 612 cells, and can move a cell in the TSCH schedule when it performs bad. 613 This is only applicable to cells which are marked as "soft". To 614 reserve a soft cell, the higher layer does not indicate the exact 615 slotOffset/channelOffset of the cell to add, but rather the resulting 616 bandwidth and QoS requirements. When the monitoring process triggers 617 a cell reallocation, the two neighbor motes communicating over this 618 cell negotiate its new position in the TSCH schedule. 620 7.2. 6top and RPL Objective Function operations 622 An implementation of a RPL [RFC6550] Objective Function (OF), such as 623 the RPL Objective Function Zero (OF0) [RFC6552] that is used in the 624 Minimal 6TiSCH Configuration [I-D.ietf-6tisch-minimal] to support 625 RPL over a static schedule, may leverage, for its internal 626 computation, the information maintained by 6top. 628 In particular, 6top creates and maintains an abstract neighbor table. 629 A neighbor table entry contains a set of statistics with respect to 630 that specific neighbor including the time when the last packet has 631 been received from that neighbor, a set of cell quality metrics 632 (RSSI, LQI), the number of packets sent to the neighbor or the number 633 of packets received from it. This information can be obtained 634 through 6top management APIs as detailed in the 6top sublayer 635 specification [I-D.wang-6tisch-6top-sublayer] and used to compute a 636 Rank Increment that will determine the selection of the preferred 637 parent. 639 6top provides statistics about the underlying layer so the OF can be 640 tuned to the nature of the TSCH MAC layer. 6top also enables the RPL 641 OF to influence the MAC behaviour, for instance by configuring the 642 periodicity of IEEE802.15.4e Extended Beacons (EB's). By augmenting 643 the EB periodicity, it is possible to change the network dynamics so 644 as to improve the support of devices that may change their point of 645 attachment in the 6TiSCH network. 647 Some RPL control messages, such as the DODAG Information Object (DIO) 648 are ICMPv6 messages that are broadcast to all neighbor nodes. With 649 6TiSCH, the broadcast channel requirement is addressed by 6top by 650 configuring TSCH to provide a broadcast channel, as opposed to, for 651 instance, piggybacking the DIO messages in Enhance Beacons. 653 In the TSCH schedule, each cell has the IEEE802.15.4e LinkType 654 attribute. Setting the LinkType to ADVERTISING indicates that the 655 cell MAY be used to send an Enhanced Beacon. When a node forms its 656 Enhanced Beacon, the cell, with LinkType=ADVERTISING, SHOULD be 657 included in the FrameAndLinkIE, and its LinkOption field SHOULD be 658 set to the combination of "Receive" and "Timekeeping". The receiver 659 of the Enhanced Beacon MAY be listening at the cell to get the 660 Enhanced Beacon ([IEEE802154e]). 6top takes this way to establish 661 broadcast channel, which not only allows TSCH to broadcast Enhanced 662 Beacons, but also allows an upper layer like RPL. 664 To broadcast ICMPv6 control messages used by RPL such as DIO or DAO, 665 6top uses the payload of a Data frames. The message is inserted into 666 the queue associated with the cells which LinkType is set to 667 ADVERTISING. Then, taking advantage of the broadcast cell feature 668 established with FrameAndLinkIE (as described above), the RPL control 669 message can be received by neighbors, which enables the maintenance 670 of RPL DODAGs. 672 A LinkOption combining "Receive" and "Timekeeping" bits indicates to 673 the receivers of the Enhanced Beacon that the cell MUST be used as a 674 broadcast cell. The frequency of sending Enhanced Beacons or other 675 broadcast messages by the upper layer is determined by the timers 676 associated with the messages. For example, the transmission of 677 Enhance Beacons is triggered by a timer in 6top; transmission of a 678 DIO message is triggered by the trickle timer of RPL. 680 7.3. Network Synchronization 682 Nodes in a TSCH network must be time synchronized. A node keeps 683 synchronized to its time source neighbor through a combination of 684 frame-based and acknowledgement-based synchronization. In order to 685 maximize battery life and network throughput, it is advisable that 686 RPL ICMP discovery and maintenance traffic (governed by the trickle 687 timer) be somehow coordinated with the transmission of time 688 synchronization packets (especially with enhanced beacons). This 689 could be achieved through an interaction of the 6top sublayer and the 690 RPL objective Function, or could be controlled by a management 691 entity. 693 Time distribution requires a loop-less structure. Nodes taken in a 694 synchronization loop will rapidly desynchronize from the network and 695 become isolated. It is expected that a RPL DAG with a dedicated 696 global Instance is deployed for the purpose of time synchronization. 697 That Instance is referred to as the Time Synchronization Global 698 Instance (TSGI). The TSGI can be operated in either of the 3 modes 699 that are detailed in section 3.1.3 of RPL [RFC6550], "Instances, 700 DODAGs, and DODAG Versions". Multiple uncoordinated DODAGs with 701 independent roots may be used if all the roots share a common time 702 source such as the Global Positioning System (GPS). In the absence of 703 a common time source, the TSGI should form a single DODAG with a 704 virtual root. A backbone network is then used to synchronize and 705 coordinate RPL operations between the backbone routers that act as 706 sinks for the LLN. 708 A node that has not joined the TSGI advertises a MAC level Join 709 Priority of 0xFF to notify its neighbors that is is not capable of 710 serving as time parent. A node that has joined the TSGI advertises a 711 MAC level Join Priority set to its DAGRank() in that Instance, where 712 DAGRank() is the operation specified in section 3.5.1 of [RFC6550], 713 "Rank Comparison". 715 A root is configured or obtains by some external means the knowledge 716 of the RPLInstanceID for the TSGI. The root advertises its DagRank in 717 the TSGI, that MUST be less than 0xFF, as its Join Priority (JP) in 718 its IEEE802.15.4e Extended Beacons (EB). We'll note that the JP is 719 now specified between 0 and 0x3F leaving 2 bits in the octet unused 720 in the IEEE802.15.4e specification. After consultation with IEEE 721 authors, it was asserted that 6TiSCH can make a full use of the octet 722 to carry an integer value up to 0xFF. 724 A node that reads a Join Priority of less than 0xFF should join the 725 neighbor with the lesser Join Priority and use it as time parent. If 726 the node is configured to serve as time parent, then the node should 727 join the TSGI, obtain a Rank in that Instance and start advertising 728 its own DagRank in the TSGI as its Join Priority in its EBs. 730 7.4. SlotFrames and Priorities 732 6TiSCH enables in essence the capability to use IPv6 over a MAC layer 733 that enables to schedule some of the transmissions. In order to 734 ensure that the medium is free of contending packets when time 735 arrives for a scheduled transmission, a window of time is defined 736 around the scheduled transmission time where the medium must be free 737 of contending energy. 739 One simple way to obtain such a window is to format time and 740 frequencies in cells of transmission of equal duration. This is the 741 method that is adopted in IEEE802.15.4e TSCH as well as the Long Term 742 Evolution (LTE) of cellular networks. 744 In order to describe that formatting of time and frequencies, the 745 6TiSCH architecture defines a global concept that is called a Channel 746 Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of 747 cells with an height equal to the number of available channels 748 (indexed by ChannelOffsets), a timeSlot duration (10-15 milliseconds 749 are typical in 802.15.4e TSCH) and a width (in timeSlots) that is the 750 period of the network scheduling operation (indexed by slotOffsets) 751 for that CDU matrix. 753 A CDU matrix iterates over and over with a pseudo-random rotation 754 from an epoch time. In a given network, there might be multiple CDU 755 matrices that operate with different width, so they have different 756 durations and represent different periodic operations. It is 757 recommended that all CDU matrices in a 6TiSCH domain operate with the 758 same cell duration and are aligned, so as to reduce the chances of 759 interferences from slotted-aloha operations. The knowledge of the 760 CDU matrices is shared between all the nodes and used in particular 761 to define slotFrames. 763 A slotFrame is a MAC-level abstraction that is common to all nodes 764 and contains a series of timeSlots of equal length and precedence. 765 It is characterized by a slotFrame_ID, and a slotFrame_size. A 766 slotFrame aligns to a CDU matrix for its parameters, such as number 767 and duration of timeSlots. 769 Multiple slotFrames can coexist in a node schedule, i.e., a node can 770 have multiple activities scheduled in different slotFrames, based on 771 the precedence of the 6TiSCH topologies. The slotFrames may be 772 aligned to different CDU matrices and thus have different width. 773 There is typically one slotFrame for scheduled traffic that has the 774 highest precedence and one or more slotFrame(s) for RPL traffic. The 775 timeSlots in the slotFrame are indexed by the SlotOffset; the first 776 cell is at SlotOffset 0. 778 A 6TISCH Instance is associated to one slotFrame. A slotFrame may be 779 shared by multiple Instances of equal relative precedence. Within an 780 Instance, 6top uses priority queues to manage concurrent data flows 781 of different priorities within an Instance and between Instances of a 782 same precedence, associated to a given IPv6 link and a given bundle 783 of TX-cells. When a packet is received from an higher layer for 784 transmission, 6top inserts that packet in the outgoing queue which 785 matches the packet best (DSCP can therefore be used). At each 786 scheduled transmit slot, 6top looks for the frame in all the outgoing 787 queues that best matches the cells. If a frame is found, it is given 788 to the TSCH MAC for transmission. 790 7.5. Distributing the reservation of cells 791 6TiSCH expects a high degree of scalability together with a 792 distributed routing functionality based on RPL. To achieve this goal, 793 the spectrum must be allocated in a way that allows for spatial reuse 794 between zones that will not interfere with one another. In a large 795 and spatially distributed network, a 6TiSCH node is often in a good 796 position to determine usage of spectrum in its vicinity. 798 Use cases for distributed routing are often associated with a 799 statistical distribution of best-effort traffic with variable needs 800 for bandwidth on each individual link. With 6TiSCH, the link 801 abstraction is implemented as a bundle of cells; the size of a bundle 802 is optimal when both the energy wasted idle listening and the packet 803 drops due to congestion loss are minimized. This can be maintained 804 if the number of cells in a bundle is adapted dynamically, and with 805 enough reactivity, to match the variations of best-effort traffic. 806 In turn, the agility to fulfill the needs for additional cells 807 improves when the number of interactions with other devices and the 808 protocol latencies are minimized. 810 6TiSCH limits that interaction to RPL parents that will only 811 negotiate with other RPL parents, and performs that negotiation by 812 groups of cells as opposed to individual cells. The 6TiSCH 813 architecture allows RPL parents to adjust dynamically, and 814 independently from the PCE, the amount of bandwidth that is used to 815 communicate between themselves and their children, in both 816 directions; to that effect, an allocation mechanism enables a RPL 817 parent to obtain the exclusive use of a portion of a CDU matrix 818 within its interference domain. Note that a PCE is expected to have 819 precedence in the allocation, so that a RPL parent would only be able 820 to obtain portions that are not in-use by the PCE. 822 The 6TiSCH architecture introduces the concept of chunks [I-D.ietf- 823 6tisch-terminology]) to operate such spectrum distribution for a 824 whole group of cells at a time. The CDU matrix is formatted into a 825 set of chunks, each of them identified uniquely by a chunk-ID. The 826 knowledge of this formatting is shared between all the nodes in a 827 6TiSCH network. 6TiSCH also defines the process of chunk ownership 828 appropriation whereby a RPL parent discovers a chunk that is not used 829 in its interference domain (e.g lack of energy detected in reference 830 cells in that chunk); then claims the chunk, and then defends it in 831 case another RPL parent would attempt to appropriate it while it is 832 in use. The chunk is the basic unit of ownership that is used in 833 that process. 835 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 836 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| 837 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 838 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| 839 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 840 ... 841 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 842 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| 843 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 844 0 1 2 3 4 5 6 M 846 As a result of the process of chunk ownership appropriation, the RPL 847 parent has exclusive authority to decide which cell in the 848 appropriated chunk can be used by which node in its interference 849 domain. In other words, it is implicitly delegated the right to 850 manage the portion of the CDU matrix that is represented by the 851 chunk. The RPL parent may thus orchestrate which transmissions occur 852 in any of the cells in the chunk, by allocating cells from the chunk 853 to any form of communication (unicast, multicast) in any direction 854 between itself and its children. Initially, those cells are added to 855 the heap of free cells, then dynamically placed into existing 856 bundles, in new bundles, or allocated opportunistically for one 857 transmission. 859 The appropriation of a chunk can also be requested explicitly by the 860 PCE to any node. In that case, the node still may need to perform 861 the appropriation process to validate that no other node has claimed 862 that chunk already. After a successful appropriation, the PCE owns 863 the cells in that chunk, and may use them as hard cells to set up 864 tracks. 866 8. Schedule Management Mechanisms 868 6TiSCH uses 4 paradigms to manage the TSCH schedule of the LLN nodes: 869 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring 870 and scheduling management, and Hop-by-hop scheduling. Multiple 871 mechanisms are defined that implement the associated Interaction 872 Models, and can be combined and used in the same LLN. Which 873 mechanism(s) to use depends on application requirements. 875 8.1. Minimal Static Scheduling 877 In the simplest instantiation of a 6TiSCH network, a common fixed 878 schedule may be shared by all nodes in the network. Cells are 879 shared, and nodes contend for slot access in a slotted aloha manner. 881 A static TSCH schedule can be used to bootstrap a network, as an 882 initial phase during implementation, or as a fall-back mechanism in 883 case of network malfunction. This scheduled can be preconfigured or 884 learnt by a node when joining the network. Regardless, the schedule 885 remains unchanged after the node has joined a network. The Routing 886 Protocol for LLNs (RPL) is used on the resulting network. This 887 "minimal" scheduling mechanism that implements this paradigm is 888 detailed in [I-D.ietf-6tisch-minimal]. 890 8.2. Neighbor-to-neighbor Scheduling 892 In the simplest instantiation of a 6TiSCH network described in 893 Section 8.1, nodes may expect a packet at any cell in the schedule 894 and will waste energy idle listening. In a more complex 895 instantiation of a 6TiSCH network, a matching portion of the schedule 896 is established between peers to reflect the observed amount of 897 transmissions between those nodes. The aggregation of the cells 898 between a node and a peer forms a bundle that the 6top layer uses to 899 implement the abstraction of a link for IP. The bandwidth on that 900 link is proportional to the number of cells in the bundle. 902 If the size of a bundle is configured to fit an average amount of 903 bandwidth, peak emissions will be destroyed. If the size is 904 configured to allow for peak emissions, energy is be wasted idle 905 listening. 907 In the most efficient instantiation of a 6TiSCH network, the size of 908 the bundles that implement the links may be changed dynamically in 909 order to adapt to the need of end-to-end flows routed by RPL. An 910 optional On-The-Fly (OTF) component may be used to monitor bandwidth 911 usage and perform requests for dynamic allocation by the 6top 912 sublayer. The OTF component is not part of the 6top sublayer. It 913 may be collocated on the same device or may be partially or fully 914 offloaded to an external system. 916 The 6top sublayer [I-D.wang-6tisch-6top-sublayer] defines a protocol 917 for neighbor nodes to reserve soft cells to one another. Because 918 this reservation is done without global knowledge of the schedule of 919 nodes in the LLN, scheduling collisions are possible. 6top defines a 920 monitoring process which continuously tracks the packet delivery 921 ratio of soft cells. It uses these statistics to trigger the 922 relocation of a soft cell in the schedule, using a negotiation 923 protocol between the neighbors nodes communicating over that cell. 925 Monitoring and relocation is done in the 6top layer. For the upper 926 layer, the connection between two neighbor nodes appears as an number 927 of cells. Depending on traffic requirements, the upper layer can 928 request 6top to add or delete a number of cells scheduled to a 929 particular neighbor, without being responsible for choosing the exact 930 slotOffset/channelOffset of those cells. 932 8.3. Remote Monitoring and Schedule Management 933 The 6top interface document [I-D.ietf-6tisch-6top-interface] 934 specifies the generic data model that can be used to monitor and 935 manage resources of the 6top sublayer. Abstract methods are 936 suggested for use by a management entity in the device. The data 937 model also enables remote control operations on the 6top sublayer. 939 The capability to interact with the node 6top sublayer from multiple 940 hops away can be leveraged for monitoring, scheduling, or a 941 combination of thereof. The architecture supports variations on the 942 deployment model, and focuses on the flows rather than whether there 943 is a proxy or a translation operation en-route. 945 [I-D.ietf-6tisch-coap] defines an mapping of the 6top set of 946 commands, which is described in [I-D.ietf-6tisch-6top-interface], to 947 CoAP resources. This allows an entity to interact with the 6top 948 layer of a node that is multiple hops away in a RESTful fashion. 950 [I-D.ietf-6tisch-coap] defines a basic set CoAP resources and 951 associated RESTful access methods (GET/PUT/POST/DELETE). The payload 952 (body) of the CoAP messages is encoded using the CBOR format. The 953 draft also defines the concept of "profiles" to allow for future or 954 specific extensions, as well as a mechanism for a CoAP client to 955 discover the profiles installed on a node. 957 The entity issuing the CoAP requests can be a central scheduling 958 entity (e.g. a PCE), a node multiple hops away with the authority to 959 modify the TSCH schedule (e.g. the head of a local cluster), or a 960 external device monitoring the overall state of the network (e.g. 961 NME). 963 At the time of this writing, a Deterministic Networking (DetNet) [I-D 964 .finn-detnet-problem-statement] effort as started at the IETF to 965 provide homogeneous flows and services across layers. This 966 architecture will be refined to comply with DetNet when the work is 967 formalized. 969 8.4. Hop-by-hop Scheduling 971 A node can reserve a track to a destination node multiple hops away 972 by installing soft cells at each intermediate node. This forms a 973 track of soft cells. It is the responsibility of the 6top sublayer 974 of each node on the track to monitor these soft cells and trigger 975 relocation when needed. 977 This hop-by-hop reservation mechanism is similar to [RFC2119] and 978 [RFC5974]. The protocol for a node to trigger hop-by-hop scheduling 979 is not yet defined. 981 9. Forwarding Models 983 6TiSCH supports three different forwarding model, G-MPLS Track 984 Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 Forwarding 985 (6F). 987 9.1. Track Forwarding 989 Track Forwarding is the simplest and fastest. A bundle of cells set 990 to receive (RX-cells) is uniquely paired to a bundle of cells that 991 are set to transmit (TX-cells), representing a layer-2 forwarding 992 state that can be used regardless of the network layer protocol. 993 This model can effectively be seen as a Generalized Multi-protocol 994 Label Switching (G-MPLS) operation in that the information used to 995 switch a frame is not an explicit label, but rather related to other 996 properties of the way the packet was received, a particular cell in 997 the case of 6TiSCH. As a result, as long as the TSCH MAC (and Layer 998 2 security) accepts a frame, that frame can be switched regardless of 999 the protocol, whether this is an IPv6 packet, a 6LoWPAN fragment, or 1000 a frame from an alternate protocol such as WirelessHART or 1001 ISA100.11a. 1003 A data frame that is forwarded along a Track normally has a 1004 destination MAC address that is set to broadcast - or a multicast 1005 address depending on MAC support. This way, the MAC layer in the 1006 intermediate nodes accepts the incoming frame and 6top switches it 1007 without incurring a change in the MAC header. In the case of 1008 IEEE802.15.4e, this means effectively broadcast, so that along the 1009 Track the short address for the destination of the frame is set to 1010 0xFFFF. 1012 A Track is thus formed end-to-end as a succession of paired bundles, 1013 a receive bundle from the previous hop and a transmit bundle to the 1014 next hop along the Track, and a cell in such a bundle belongs to at 1015 most one Track. For a given iteration of the device schedule, the 1016 effective channel of the cell is obtained by adding a pseudo-random 1017 number to the channelOffset of the cell, which results in a rotation 1018 of the frequency that used for transmission. The bundles may be 1019 computed so as to accommodate both variable rates and 1020 retransmissions, so they might not be fully used at a given iteration 1021 of the schedule. The 6TiSCH architecture provides additional means 1022 to avoid waste of cells as well as overflows in the transmit bundle, 1023 as follows: 1025 In one hand, a TX-cell that is not needed for the current iteration 1026 may be reused opportunistically on a per-hop basis for routed 1027 packets. When all of the frame that were received for a given Track 1028 are effectively transmitted, any available TX-cell for that Track can 1029 be reused for upper layer traffic for which the next-hop router 1030 matches the next hop along the Track. In that case, the cell that is 1031 being used is effectively a TX-cell from the Track, but the short 1032 address for the destination is that of the next-hop router. It 1033 results that a frame that is received in a RX-cell of a Track with a 1034 destination MAC address set to this node as opposed to broadcast must 1035 be extracted from the Track and delivered to the upper layer (a frame 1036 with an unrecognized MAC address is dropped at the lower MAC layer 1037 and thus is not received at the 6top sublayer). 1039 On the other hand, it might happen that there are not enough TX-cells 1040 in the transmit bundle to accommodate the Track traffic, for instance 1041 if more retransmissions are needed than provisioned. In that case, 1042 the frame can be placed for transmission in the bundle that is used 1043 for layer-3 traffic towards the next hop along the track as long as 1044 it can be routed by the upper layer, that is, typically, if the frame 1045 transports an IPv6 packet. The MAC address should be set to the 1046 next-hop MAC address to avoid confusion. It results that a frame 1047 that is received over a layer-3 bundle may be in fact associated to a 1048 Track. In a classical IP link such as an Ethernet, off-track traffic 1049 is typically in excess over reservation to be routed along the non- 1050 reserved path based on its QoS setting. But with 6TiSCH, since the 1051 use of the layer-3 bundle may be due to transmission failures, it 1052 makes sense for the receiver to recognize a frame that should be re- 1053 tracked, and to place it back on the appropriate bundle if possible. 1054 A frame should be re-tracked if the Per-Hop-Behavior group indicated 1055 in the Differentiated Services Field in the IPv6 header is set to 1056 Deterministic Forwarding, as discussed in Section 10.1. A frame is 1057 re-tracked by scheduling it for transmission over the transmit bundle 1058 associated to the Track, with the destination MAC address set to 1059 broadcast. 1061 There are 2 modes for a Track, transport mode and tunnel mode. 1063 9.1.1. Transport Mode 1065 In transport mode, the Protocol Data Unit (PDU) is associated with 1066 flow-dependant meta-data that refers uniquely to the Track, so the 1067 6top sublayer can place the frame in the appropriate cell without 1068 ambiguity. In the case of IPv6 traffic, this flow identification is 1069 transported in the Flow Label of the IPv6 header. Associated with 1070 the source IPv6 address, the Flow Label forms a globally unique 1071 identifier for that particular Track that is validated at egress 1072 before restoring the destination MAC address (DMAC) and punting to 1073 the upper layer. 1075 | ^ 1076 +--------------+ | | 1077 | IPv6 | | | 1078 +--------------+ | | 1079 | 6LoWPAN HC | | | 1080 +--------------+ ingress egress 1081 | 6top | sets +----+ +----+ restores 1082 +--------------+ dmac to | | | | dmac to 1083 | TSCH MAC | brdcst | | | | self 1084 +--------------+ | | | | | | 1085 | LLN PHY | +-------+ +--...-----+ +-------+ 1086 +--------------+ 1088 9.1.2. Tunnel Mode 1089 In tunnel mode, the frames originate from an arbitrary protocol over 1090 a compatible MAC that may or may not be synchronized with the 6TiSCH 1091 network. An example of this would be a router with a dual radio that 1092 is capable of receiving and sending WirelessHART or ISA100.11a frames 1093 with the second radio, by presenting itself as an access Point or a 1094 Backbone Router, respectively. 1096 In that mode, some entity (e.g. PCE) can coordinate with a 1097 WirelessHART Network Manager or an ISA100.11a System Manager to 1098 specify the flows that are to be transported transparently over the 1099 Track. 1101 +--------------+ 1102 | IPv6 | 1103 +--------------+ 1104 | 6LoWPAN HC | 1105 +--------------+ set restore 1106 | 6top | +dmac+ +dmac+ 1107 +--------------+ | | | | 1108 | TSCH MAC | | | | | 1109 +--------------+ | | | | 1110 | LLN PHY | +-------+ +--...-----+ +-------+ 1111 +--------------+ | ingress egress | 1112 | | 1113 +--------------+ | | 1114 | LLN PHY | | | 1115 +--------------+ | | 1116 | TSCH MAC | | | 1117 +--------------+ | | 1118 |ISA100/WiHART | | v 1119 +--------------+ 1121 In that case, the flow information that identifies the Track at the 1122 ingress 6TiSCH router is derived from the RX-cell. The dmac is set 1123 to this node but the flow information indicates that the frame must 1124 be tunnelled over a particular Track so the frame is not passed to 1125 the upper layer. Instead, the dmac is forced to broadcast and the 1126 frame is passed to the 6top sublayer for switching. 1128 At the egress 6TiSCH router, the reverse operation occurs. Based on 1129 metadata associated to the Track, the frame is passed to the 1130 appropriate link layer with the destination MAC restored. 1132 9.1.3. Tunnel Metadata 1134 Metadata coming with the Track configuration is expected to provide 1135 the destination MAC address of the egress endpoint as well as the 1136 tunnel mode and specific data depending on the mode, for instance a 1137 service access point for frame delivery at egress. If the tunnel 1138 egress point does not have a MAC address that matches the 1139 configuration, the Track installation fails. 1141 In transport mode, if the final layer-3 destination is the tunnel 1142 termination, then it is possible that the IPv6 address of the 1143 destination is compressed at the 6LoWPAN sublayer based on the MAC 1144 address. It is thus mandatory at the ingress point to validate that 1145 the MAC address that was used at the 6LoWPAN sublayer for compression 1146 matches that of the tunnel egress point. For that reason, the node 1147 that injects a packet on a Track checks that the destination is 1148 effectively that of the tunnel egress point before it overwrites it 1149 to broadcast. The 6top sublayer at the tunnel egress point reverts 1150 that operation to the MAC address obtained from the tunnel metadata. 1152 9.2. Fragment Forwarding 1154 Considering that 6LoWPAN packets can be as large as 1280 bytes (the 1155 IPv6 MTU), and that the non-storing mode of RPL implies Source 1156 Routing that requires space for routing headers, and that a 1157 IEEE802.15.4 frame with security may carry in the order of 80 bytes 1158 of effective payload, an IPv6 packet might be fragmented into more 1159 than 16 fragments at the 6LoWPAN sublayer. 1161 This level of fragmentation is much higher than that traditionally 1162 experienced over the Internet with IPv4 fragments, where 1163 fragmentation is already known as harmful. 1165 In the case to a multihop route within a 6TiSCH network, Hop-by-Hop 1166 recomposition occurs at each hop in order to reform the packet and 1167 route it. This creates additional latency and forces intermediate 1168 nodes to store a portion of a packet for an undetermined time, thus 1169 impacting critical resources such as memory and battery. 1171 [I-D.thubert-roll-forwarding-frags] describes a mechanism whereby the 1172 datagram tag in the 6LoWPAN Fragment is used as a label for switching 1173 at the 6LoWPAN sublayer. The draft allows for a degree of flow 1174 control base on an Explicit Congestion Notification, as well as end- 1175 to-end individual fragment recovery. 1177 | ^ 1178 +--------------+ | | 1179 | IPv6 | | +----+ +----+ | 1180 +--------------+ | | | | | | 1181 | 6LoWPAN HC | | learn learn | 1182 +--------------+ | | | | | | 1183 | 6top | | | | | | | 1184 +--------------+ | | | | | | 1185 | TSCH MAC | | | | | | | 1186 +--------------+ | | | | | | 1187 | LLN PHY | +-------+ +--...-----+ +-------+ 1188 +--------------+ 1189 In that model, the first fragment is routed based on the IPv6 header 1190 that is present in that fragment. The 6LoWPAN sublayer learns the 1191 next hop selection, generates a new datagram tag for transmission to 1192 the next hop, and stores that information indexed by the incoming MAC 1193 address and datagram tag. The next fragments are then switched based 1194 on that stored state. 1196 | ^ 1197 +--------------+ | | 1198 | IPv6 | | | 1199 +--------------+ | | 1200 | 6LoWPAN HC | | replay replay | 1201 +--------------+ | | | | | | 1202 | 6top | | | | | | | 1203 +--------------+ | | | | | | 1204 | TSCH MAC | | | | | | | 1205 +--------------+ | | | | | | 1206 | LLN PHY | +-------+ +--...-----+ +-------+ 1207 +--------------+ 1209 A bitmap and an ECN echo in the end-to-end acknowledgement enable the 1210 source to resend the missing fragments selectively. The first 1211 fragment may be resent to carve a new path in case of a path failure. 1212 The ECN echo set indicates that the number of outstanding fragments 1213 should be reduced. 1215 9.3. IPv6 Forwarding 1217 As the packets are routed at layer 3, traditional QoS and RED 1218 operations are expected to prioritize flows; the application of 1219 Differentiated Services is further discussed in [I-D.svshah-tsvwg- 1220 lln-diffserv-recommendations]. 1222 | ^ 1223 +--------------+ | | 1224 | IPv6 | | +-QoS+ +-QoS+ | 1225 +--------------+ | | | | | | 1226 | 6LoWPAN HC | | | | | | | 1227 +--------------+ | | | | | | 1228 | 6top | | | | | | | 1229 +--------------+ | | | | | | 1230 | TSCH MAC | | | | | | | 1231 +--------------+ | | | | | | 1232 | LLN PHY | +-------+ +--...-----+ +-------+ 1233 +--------------+ 1235 10. Centralized vs. Distributed Routing 1237 6TiSCH supports a mixed model of centralized routes and distributed 1238 routes. Centralized routes can for example computed by a entity such 1239 as a PCE. Distributed routes are computed by RPL. 1241 Both methods may inject routes in the Routing Tables of the 6TiSCH 1242 routers. In either case, each route is associated with a 6TiSCH 1243 topology that can be a RPL Instance topology or a track. The 6TiSCH 1244 topology is indexed by a Instance ID, in a format that reuses the 1245 RPLInstanceID as defined in RPL [RFC6550]. 1247 Both RPL and PCE rely on shared sources such as policies to define 1248 Global and Local RPLInstanceIDs that can be used by either method. 1249 It is possible for centralized and distributed routing to share a 1250 same topology. Generally they will operate in different slotFrames, 1251 and centralized routes will be used for scheduled traffic and will 1252 have precedence over distributed routes in case of conflict between 1253 the slotFrames. 1255 10.1. Packet Marking and Handling 1257 All packets inside a 6TiSCH domain MUST carry the Instance ID that 1258 identifies the 6TiSCH topology that is to be used for routing and 1259 forwarding that packet. The location of that information MUST be the 1260 same for all packets forwarded inside the domain. 1262 For packets that are routed by a PCE along a Track, the tuple formed 1263 by the IPv6 source address and a local RPLInstanceID in the packet 1264 identify uniquely the Track and associated transmit bundle. 1265 Additionally, an IP packet that is sent along a Track uses the 1266 Differentiated Services Per-Hop-Behavior Group called Deterministic 1267 Forwarding, as described in [I-D.svshah-tsvwg-deterministic- 1268 forwarding]. 1270 For packets that are routed by RPL, that information is the 1271 RPLInstanceID which is carried in the RPL Packet Information, as 1272 discussed in section 11.2 of [RFC6550], "Loop Avoidance and 1273 Detection". 1275 The RPL Packet Information (RPI) is carried in IPv6 packets as a RPL 1276 option in the IPv6 Hop-By-Hop Header [RFC6553]. 6LoWPAN provides a 1277 Next Header Compression (NHC) for the RPI (RPI-NHC). The RPI-NHC is 1278 specified in [I-D.thubert-6lo-rpl-nhc], and is the compressed 1279 equivalent to the whole HbH header with the RPL option. In a 6LoWPAN 1280 network, the RPI-NHC is the recommended encoding the RPL Packet 1281 Information. 1283 Either way, the method and format used for encoding the RPLInstanceID 1284 is generalized to all 6TiSCH topological Instances, which include 1285 both RPL Instances and Tracks. 1287 11. IANA Considerations 1289 This specification does not require IANA action. 1291 12. Security Considerations 1293 This specification is not found to introduce new security threat. 1295 13. Contributors 1297 The editors and authors wish to recognize the contribution of 1299 Xavier Vilajosana who lead the design of the minimal support with RPL 1300 and contributed deeply to the 6top design. 1302 Qin Wang who lead the design of the 6top sublayer and contributed 1303 related text that was moved and/or adapted in this document. 1305 14. Acknowledgements 1307 This specification is the result interactions in particular during 1308 the 6TiSCH (bi)Weekly call. The authors wish to thank: Alaeddine 1309 Weslati, Alfredo Grieco, Bert Greevenbosch, Cedric Adjih, Diego 1310 Dujovne, Dominique Barthel, Elvis Vogli, Geraldine Texier, Giuseppe 1311 Piro, Guillaume Gaillard, Herman Storey, Ines Robles, Jonathan Simon, 1312 Kazushi Muraoka, Ken Bannister, Kuor Hsin Chang, Laurent Toutain, 1313 Maik Seewald, Maria Rita Palattella, Michael Behringer, Michael 1314 Richardson, Nancy Cam Winget, Nicola Accettura, Nicolas Montavont, 1315 Oleg Hahm, Pat Kinney, Patrick Wetterwald, Paul Duffy, Peter van der 1316 Stock, Pieter de Mil, Pouria Zand, Rouhollah Nabati, Rafa Marin- 1317 Lopez, Raghuram Sudhaakar, Rene Struik, Sedat Gormus, Shitanshu Shah, 1318 Steve Simlo, Subir Das, Tengfei Chang, Tina Tsou, Tom Phinney, Xavier 1319 Lagrange and Yoshihiro Ohba for their various participation. 1321 15. References 1323 15.1. Normative References 1325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1326 Requirement Levels", BCP 14, RFC 2119, March 1997. 1328 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 1329 6 (IPv6) Specification", RFC 2460, December 1998. 1331 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 1332 Information Models and Data Models", RFC 3444, January 1333 2003. 1335 [RFC3610] Whiting, D., Housley, R. and N. Ferguson, "Counter with 1336 CBC-MAC (CCM)", RFC 3610, September 2003. 1338 [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure 1339 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1341 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J. and S. Van den 1342 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 1343 4080, June 2005. 1345 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1346 Architecture", RFC 4291, February 2006. 1348 [RFC4389] Thaler, D., Talwar, M. and C. Patel, "Neighbor Discovery 1349 Proxies (ND Proxy)", RFC 4389, April 2006. 1351 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 1352 for IPv6", RFC 4429, April 2006. 1354 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 1355 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1356 September 2007. 1358 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless 1359 Address Autoconfiguration", RFC 4862, September 2007. 1361 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 1362 2007. 1364 [RFC4919] Kushalnagar, N., Montenegro, G. and C. Schumacher, "IPv6 1365 over Low-Power Wireless Personal Area Networks (6LoWPANs): 1366 Overview, Assumptions, Problem Statement, and Goals", RFC 1367 4919, August 2007. 1369 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. 1370 Yegin, "Protocol for Carrying Authentication for Network 1371 Access (PANA)", RFC 5191, May 2008. 1373 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 1374 Hoc Networks", RFC 5889, September 2010. 1376 [RFC5974] Manner, J., Karagiannis, G. and A. McDonald, "NSIS 1377 Signaling Layer Protocol (NSLP) for Quality-of-Service 1378 Signaling", RFC 5974, October 2010. 1380 [RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support 1381 in IPv6", RFC 6275, July 2011. 1383 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 1384 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1385 September 2011. 1387 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1388 Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. 1389 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1390 Lossy Networks", RFC 6550, March 2012. 1392 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 1393 Protocol for Low-Power and Lossy Networks (RPL)", RFC 1394 6552, March 2012. 1396 [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- 1397 Power and Lossy Networks (RPL) Option for Carrying RPL 1398 Information in Data-Plane Datagrams", RFC 6553, March 1399 2012. 1401 [RFC6620] Nordmark, E., Bagnulo, M. and E. Levy-Abegnoli, "FCFS 1402 SAVI: First-Come, First-Served Source Address Validation 1403 Improvement for Locally Assigned IPv6 Addresses", RFC 1404 6620, May 2012. 1406 [RFC6655] McGrew, D. and D. Bailey, "AES-CCM Cipher Suites for 1407 Transport Layer Security (TLS)", RFC 6655, July 2012. 1409 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann, 1410 "Neighbor Discovery Optimization for IPv6 over Low-Power 1411 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1412 November 2012. 1414 [RFC6830] Farinacci, D., Fuller, V., Meyer, D. and D. Lewis, "The 1415 Locator/ID Separation Protocol (LISP)", RFC 6830, January 1416 2013. 1418 15.2. Informative References 1420 [I-D.chakrabarti-nordmark-6man-efficient-nd] 1421 Chakrabarti, S., Nordmark, E., Thubert, P. and M. 1422 Wasserman, "Wired and Wireless IPv6 Neighbor Discovery 1423 Optimizations", Internet-Draft draft-chakrabarti-nordmark- 1424 6man-efficient-nd-04, October 2013. 1426 [I-D.finn-detnet-problem-statement] 1427 Finn, N. and P. Thubert, "Deterministic Networking Problem 1428 Statement", Internet-Draft draft-finn-detnet-problem- 1429 statement-01, October 2014. 1431 [I-D.ietf-6tisch-6top-interface] 1432 Wang, Q., Vilajosana, X. and T. Watteyne, "6TiSCH 1433 Operation Sublayer (6top) Interface", Internet-Draft 1434 draft-ietf-6tisch-6top-interface-00, March 2014. 1436 [I-D.ietf-6tisch-coap] 1437 Sudhaakar, R. and P. Zand, "6TiSCH Resource Management and 1438 Interaction using CoAP", Internet-Draft draft-ietf-6tisch- 1439 coap-00, May 2014. 1441 [I-D.ietf-6tisch-minimal] 1442 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 1443 Configuration", Internet-Draft draft-ietf-6tisch- 1444 minimal-00, November 2013. 1446 [I-D.ietf-6tisch-terminology] 1447 Palattella, M., Thubert, P., Watteyne, T. and Q. Wang, 1448 "Terminology in IPv6 over the TSCH mode of IEEE 1449 802.15.4e", Internet-Draft draft-ietf-6tisch- 1450 terminology-00, November 2013. 1452 [I-D.ietf-6tisch-tsch] 1453 Watteyne, T., Palattella, M. and L. Grieco, "Using 1454 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 1455 Statement and Goals", Internet-Draft draft-ietf-6tisch- 1456 tsch-00, November 2013. 1458 [I-D.ietf-ipv6-multilink-subnets] 1459 Thaler, D. and C. Huitema, "Multi-link Subnet Support in 1460 IPv6", Internet-Draft draft-ietf-ipv6-multilink- 1461 subnets-00, July 2002. 1463 [I-D.ietf-roll-rpl-industrial-applicability] 1464 Phinney, T., Thubert, P. and R. Assimiti, "RPL 1465 applicability in industrial networks", Internet-Draft 1466 draft-ietf-roll-rpl-industrial-applicability-02, October 1467 2013. 1469 [I-D.svshah-tsvwg-deterministic-forwarding] 1470 Shah, S. and P. Thubert, "Deterministic Forwarding PHB", 1471 Internet-Draft draft-svshah-tsvwg-deterministic- 1472 forwarding-01, March 2014. 1474 [I-D.svshah-tsvwg-lln-diffserv-recommendations] 1475 Shah, S. and P. Thubert, "Differentiated Service Class 1476 Recommendations for LLN Traffic", Internet-Draft draft- 1477 svshah-tsvwg-lln-diffserv-recommendations-01, August 2013. 1479 [I-D.thubert-6lo-rpl-nhc] 1480 Thubert, P. and C. Bormann, "A compression mechanism for 1481 the RPL option", Internet-Draft draft-thubert-6lo-rpl- 1482 nhc-02, October 2014. 1484 [I-D.thubert-6lowpan-backbone-router] 1485 Thubert, P., "6LoWPAN Backbone Router", Internet-Draft 1486 draft-thubert-6lowpan-backbone-router-03, February 2013. 1488 [I-D.thubert-roll-forwarding-frags] 1489 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 1490 Recovery", Internet-Draft draft-thubert-roll-forwarding- 1491 frags-02, September 2013. 1493 [I-D.wang-6tisch-6top-sublayer] 1494 Wang, Q., Vilajosana, X. and T. Watteyne, "6TiSCH 1495 Operation Sublayer (6top)", Internet-Draft draft-wang- 1496 6tisch-6top-00, October 2013. 1498 15.3. External Informative References 1500 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 1501 a group of specifications for industrial process and 1502 control devices administered by the HART Foundation", . 1504 [IEEE802.1TSNTG] 1505 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 1506 Networks Task Group", March 2013, . 1509 [IEEE802154e] 1510 IEEE standard for Information Technology, "IEEE std. 1511 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 1512 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 1513 2012. 1515 [ISA100.11a] 1516 ISA/ANSI, "Wireless Systems for Industrial Automation: 1517 Process Control and Related Applications - ISA100.11a-2011 1518 - IEC 62734", 2011, . 1521 [WirelessHART] 1522 www.hartcomm.org, "Industrial Communication Networks - 1523 Wireless Communication Network and Communication Profiles 1524 - WirelessHART - IEC 62591", 2010. 1526 Authors' Addresses 1528 Pascal Thubert, editor 1529 Cisco Systems, Inc 1530 Building D 1531 45 Allee des Ormes - BP1200 1532 MOUGINS - Sophia Antipolis, 06254 1533 FRANCE 1535 Phone: +33 497 23 26 34 1536 Email: pthubert@cisco.com 1538 Thomas Watteyne 1539 Linear Technology, Dust Networks Product Group 1540 30695 Huntwood Avenue 1541 Hayward, CA 94544 1542 USA 1544 Phone: +1 (510) 400-2978 1545 Email: twatteyne@linear.com 1547 Robert Assimiti 1548 Centero 1549 961 Indian Hills Parkway 1550 Marietta, GA 30068 1551 USA 1553 Phone: +1 404 461 9614 1554 Email: robert.assimiti@centerotech.com