idnits 2.17.1 draft-ietf-6tisch-architecture-01.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 169 has weird spacing: '...scribed in...' == Line 699 has weird spacing: '...ance is deplo...' -- The document date (February 14, 2014) is 3717 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: 'RFC4919' is mentioned on line 151, but not defined == Missing Reference: 'RFC4903' is mentioned on line 157, but not defined == Missing Reference: 'RFC6275' is mentioned on line 157, but not defined == Missing Reference: 'RFC4389' is mentioned on line 158, but not defined == Missing Reference: 'RFC6620' is mentioned on line 161, but not defined == Missing Reference: 'RFC4429' is mentioned on line 162, but not defined == Missing Reference: 'IEEE802154e' is mentioned on line 1105, but not defined == Missing Reference: 'I-D.roll-rpl-industrial-applicability' is mentioned on line 359, but not defined == Missing Reference: 'HART' is mentioned on line 1096, but not defined == Missing Reference: 'RFC 6550' is mentioned on line 626, but not defined == Missing Reference: 'RFC 6552' is mentioned on line 627, but not defined == Missing Reference: 'IEEE802.1TSNTG' is mentioned on line 1100, but not defined == Unused Reference: 'RFC6552' is defined on line 1014, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-rpl-industrial-applicability' is defined on line 1048, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-6tisch-security' is defined on line 1054, but no explicit reference was found in the text == Unused Reference: 'I-D.svshah-tsvwg-lln-diffserv-recommendations' is defined on line 1065, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 1070, 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 4080 ** 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-04 == 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 (-01) exists of draft-ohba-6tisch-security-00 == Outdated reference: A later version (-01) exists of draft-sudhaakar-6tisch-coap-00 == Outdated reference: A later version (-04) exists of draft-svshah-tsvwg-lln-diffserv-recommendations-01 == Outdated reference: A later version (-02) exists of draft-wang-6tisch-6top-interface-01 Summary: 5 errors (**), 0 flaws (~~), 28 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: August 16, 2014 Linear Technology 6 RA. Assimiti 7 Centero 8 February 14, 2014 10 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e 11 draft-ietf-6tisch-architecture-01 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 August 16, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Applications and Goals . . . . . . . . . . . . . . . . . . . . 4 68 4. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 5 69 5. Communication Paradigms and Interaction Models . . . . . . . . 8 70 6. Forwarding Models . . . . . . . . . . . . . . . . . . . . . . 9 71 6.1. Track Forwarding . . . . . . . . . . . . . . . . . . . . . 9 72 6.1.1. Transport Mode . . . . . . . . . . . . . . . . . . . . 9 73 6.1.2. Tunnel Mode . . . . . . . . . . . . . . . . . . . . . 10 74 6.1.3. Tunnel Metadata . . . . . . . . . . . . . . . . . . . 11 75 6.2. Fragment Forwarding . . . . . . . . . . . . . . . . . . . 12 76 6.3. IPv6 Forwarding . . . . . . . . . . . . . . . . . . . . . 13 77 7. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . . . 13 78 7.1. 6top . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 7.2. 6top and RPL Objective Function operations . . . . . . . . 14 80 7.3. Network Synchronization . . . . . . . . . . . . . . . . . 15 81 7.4. Slotframes and Priorities . . . . . . . . . . . . . . . . 16 82 7.5. Packet Marking and Handling . . . . . . . . . . . . . . . 16 83 7.6. Distributing the reservation of timeslots . . . . . . . . 17 84 8. Schedule Management Mechanisms . . . . . . . . . . . . . . . . 18 85 8.1. Minimal Static Scheduling . . . . . . . . . . . . . . . . 18 86 8.2. Neighbor-to-neighbor Scheduling . . . . . . . . . . . . . 19 87 8.3. Remote Monitoring and Schedule Management . . . . . . . . 19 88 8.4. Hop-by-hop Scheduling . . . . . . . . . . . . . . . . . . 20 89 9. Centralized vs. Distributed Routing . . . . . . . . . . . . . 20 90 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 91 11. Security Considerations . . . . . . . . . . . . . . . . . . . 21 92 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 93 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 94 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 95 13.2. Informative References . . . . . . . . . . . . . . . . . 22 96 13.3. External Informative References . . . . . . . . . . . . . 23 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 99 1. Introduction 100 The emergence of radio technology enabled a large variety of new 101 types of devices to be interconnected, at a very low marginal cost 102 compared to wire, at any range from Near Field to interplanetary 103 distances, and in circumstances where wiring would be less than 104 practical, for instance rotating devices. 106 At the same time, a new breed of Time Sensitive Networks is being 107 developed to enable traffic that is highly sensitive to jitter and 108 quite sensitive to latency. Such traffic is not limited to voice and 109 video, but also includes command and control operations such as found 110 in industrial automation or in-vehicle sensors and actuators. 112 At IEEE802.1, the "Audio/Video Task Group", was renamed TSN for Time 113 Sensitive Networking to address Deterministic Ethernet. The 114 IEEE802.15.4 Medium access Control (MAC) has evolved with 115 IEEE802.15.4e that provides in particular the Timeslotted Channel 116 Hopping (TSCH) mode for industrial-type applications. 118 Though at a different time scale, both standards provide 119 Deterministic capabilities to the point that a packet that pertains 120 to a certain flow crosses the network from node to node following a 121 very precise schedule, as a train that leaves intermediate stations 122 at precise times along its path. With TSCH, time is formatted into 123 timeslots, and an individual timeslot is allocated to unicast or 124 broadcast communication at the MAC level. The time slotted operation 125 reduces collisions, saves energy, and enables to more closely 126 engineer the network for deterministic properties. The channel 127 hopping aspect is a simple and efficient technique to combat 128 multipath fading and external interference (for example by WiFi 129 emitters). 131 This document presents an architecture for an IPv6 Multi-Link subnet 132 that is composed of a high speed powered backbone and a number of 133 IEEE802.15.4e TSCH wireless networks attached and synchronized by 134 backbone routers. Route Computation may be achieved in a centralized 135 fashion by a Path Computation Element (PCE), in a distributed fashion 136 using the Routing Protocol for Low Power and Lossy Networks (RPL), or 137 in a mixed mode. The Backbone Routers perform proxy IPv6 neighbor 138 Discovery (ND) operations over the backbone on behalf of the wireless 139 devices, so they can share a same IPv6 subnet and appear to be 140 connected to the same backbone as classical devices. Timeslots and 141 other device resources are managed by an abstract Network Management 142 Entity (NME) that may cooperate with the PCE in order to minimize the 143 interaction with and the load on the constrained device. 145 2. Terminology 147 Readers are expected to be familiar with all the terms and concepts 148 that are discussed in "neighbor Discovery for IP version 6" 149 [RFC4861], "IPv6 over Low-Power Wireless Personal Area Networks 150 (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" 151 [RFC4919], neighbor Discovery Optimization for Low-power and Lossy 152 Networks [RFC6775] and "Multi-link Subnet Support in IPv6" [I-D.ietf- 153 ipv6-multilink-subnets]. 155 Readers may benefit from reading the "RPL: IPv6 Routing Protocol for 156 Low-Power and Lossy Networks" [RFC6550] specification; "Multi-Link 157 Subnet Issues" [RFC4903]; "Mobility Support in IPv6" [RFC6275]; 158 "neighbor Discovery Proxies (ND Proxy)" [RFC4389]; "IPv6 Stateless 159 Address Autoconfiguration" [RFC4862]; "FCFS SAVI: First-Come, First- 160 Served Source Address Validation Improvement for Locally Assigned 161 IPv6 Addresses" [RFC6620]; and "Optimistic Duplicate Address 162 Detection" [RFC4429] prior to this specification for a clear 163 understanding of the art in ND-proxying and binding. 165 The draft uses terminology defined or referenced in [I-D.ietf-6tisch- 166 terminology], [I-D.chakrabarti-nordmark-6man-efficient-nd], [I-D 167 .roll-rpl-industrial-applicability], [RFC5191] and [RFC4080]. 169 The draft also conforms to the terms and models described in 170 [RFC3444] and [RFC5889] and uses the vocabulary and the concepts 171 defined in [RFC4291] for the IPv6 Architecture. 173 3. Applications and Goals 175 The architecture derives from existing industrial standards for 176 Process Control by its focus on Deterministic Networking, in 177 particular with the use of the IEEE802.15.4e TSCH MAC [IEEE802154e] 178 and the centralized PCE. This approach leverages the TSCH MAC 179 benefits for high reliability against interference, low-power 180 consumption on deterministic traffic, and its Traffic Engineering 181 capabilities. Deterministic Networking applies in particular to open 182 and closed control loops, as well as supervisory control flows and 183 management. 185 An incremental set of industrial requirements are addressed with the 186 addition of an autonomic and distributed routing operation based on 187 RPL. These use cases include plant setup and decommissioning, as well 188 as monitoring of lots of lesser importance measurements such as 189 corrosion and events. RPL also enables mobile use cases such as 190 mobile workers and cranes. 192 A Backbone Router is included in order to scale the factory plant 193 subnet to address large deployments, with proxy ND and time 194 synchronization over a high speed backbone. 196 The architecture also applies to building automation that leverage 197 RPL's storing mode to address multipath over a large number of hops, 198 in-vehicle command and control that can be as demanding as industrial 199 applications, commercial automation and asset Tracking with mobile 200 scenarios, home automation and domotics which become more reliable 201 and thus provide a better user experience, and resource management 202 (energy, water, etc.). 204 4. Overview and Scope 206 The scope of the present work is a subnet that, in its basic 207 configuration, is made of a IEEE802.15.4e Timeslotted Channel Hopping 208 (TSCH) [I-D.ietf-6tisch-tsch] MAC Low Power Lossy Network (LLN). 210 ---+-------- ............ ------------ 211 | External Network | 212 | +-----+ 213 +-----+ | NME | 214 | | LLN Border | | 215 | | router +-----+ 216 +-----+ 217 o o o 218 o o o o 219 o o LLN o o o 220 o o o o 221 o 223 The LLN devices communicate over IPv6 [RFC2460] using the 6LoWPAN 224 Header Compression (6LoWPAN HC) [RFC6282]. From the perspective of 225 Layer 3, a single LLN interface (typically an IEEE802.15.4-compliant 226 radio) may be seen as a collection of Links with different 227 capabilities for unicast or multicast services. An IPv6 subnet spans 228 over multiple links, effectively forming a Multi-Link subnet. Within 229 that subnet, neighbor Devices are discovered with 6LoWPAN neighbor 230 Discovery (6LoWPAN ND) [RFC6775]. RPL [RFC6550] enables routing 231 within the LLN, typically within the Multi-Link subnet in the so 232 called Route Over fashion. RPL forms Destination Oriented Directed 233 Acyclic Graphs (DODAGs) within Instances of the protocol, each 234 Instance being associated with an Objective Function (OF) to form a 235 routing topology. A particular LLN device, the LLN Border Router 236 (LBR), acts as RPL root, 6LoWPAN HC terminator, and LLN Border Router 237 (LBR) to the outside. The LBR is usually powered. More on RPL 238 Instances can be found in RPL [RFC6550], sections "3.1.2. RPL 239 Identifiers" and "3.1.3. Instances, DODAGs, and DODAG Versions". 241 An extended configuration of the subnet comprises multiple LLNs. The 242 LLNs are interconnected and synchronized over a backbone, that can be 243 wired or wireless. The backbone can be a classical IPv6 network, 244 with neighbor Discovery operating as defined in [RFC4861] and 245 [RFC4862]. The backbone can also support Efficiency-aware IPv6 246 neighbor Discovery Optimizations [I-D.chakrabarti-nordmark-6man- 247 efficient-nd] in mixed mode as described in [I-D.thubert-6lowpan- 248 backbone-router]. 250 Security is often handled at layer 2 and Layer 4. Authentication 251 during the join process can be handled by the Protocol for Carrying 252 Authentication for Network access (PANA) [RFC5191]. 254 The LLN devices are time-synchronized at the MAC level. The LBR that 255 serves as time source is a RPL parent in a particular RPL instance 256 that serves for time synchronization; this way, the time 257 synchronization starts at the RPL root and follows the RPL DODAGs 258 with no timing loop. 260 In the extended configuration, the functionality of the LBR is 261 enhanced to that of Backbone Router (BBR). A BBR is an LBR, but also 262 an Energy Aware Default Router (NEAR) as defined in [I-D.chakrabarti- 263 nordmark-6man-efficient-nd]. The BBR performs ND proxy operations 264 between the registered devices and the classical ND devices that are 265 located over the backbone. 6TiSCH BBRs synchronize with one another 266 over the backbone, so as to ensure that the multiple LLNs that form 267 the IPv6 subnet stay tightly synchronized. If the Backbone is 268 Deterministic (such as defined by the Time Sensitive Networking WG at 269 IEEE), then the Backbone Router ensures that the end-to-end 270 deterministic behavior is maintained between the LLN and the 271 backbone. 273 ---+-------- ............ ------------ 274 | External Network | 275 | +-----+ 276 | +-----+ | NME | 277 +-----+ | +-----+ | | 278 | | Router | | PCE | +-----+ 279 | | +--| | 280 +-----+ +-----+ 281 | | 282 | Subnet Backbone | 283 +--------------------+------------------+ 284 | | | 285 +-----+ +-----+ +-----+ 286 | | Backbone | | Backbone | | Backbone 287 o | | router | | router | | router 288 +-----+ +-----+ +-----+ 289 o o o o o 290 o o o o o o o o o o o 291 o o o LLN o o o o 292 o o o o o o o o o o o o 294 The main architectural blocks are arranged as follows: 296 +-----+-----+-----+-----+-------+-----+ 297 |PCEP | CoAP |PANA |6LoWPAN| RPL | 298 | PCE |DTLS | | | ND | | 299 +-----+-----+-----+-----+-------+-----+-----+ 300 | TCP | UDP | ICMP |RSVP | 301 +-----+-----+-----+-----+-------+-----+-----+ 302 | IPv6 | 303 +-------------------------------------------+ 304 | 6LoWPAN HC | 305 +-------------------------------------------+ 306 | 6top | 307 +-------------------------------------------+ 308 | IEEE802.15.4e TSCH | 309 +-------------------------------------------+ 311 RPL is the routing protocol of choice for LLNs. (TBD RPL) whether 312 there is a need to define a 6TiSCH OF. 314 (tbd NME) COMAN is working on network Management for LLN. They are 315 considering the Open Mobile Alliance (OMA) Lightweight M2M (LWM2M) 316 Object system. This standard includes DTLS, CoAP (core plus Block 317 and Observe patterns), SenML and CoAP Resource Directory. 319 (tbd PCE) need to work with PCE WG to define flows to PCE, and define 320 how to accommodate PCE routes and reservation. Will probably look a 321 lot like GMPLS. 323 (tbd PANA) There is a debate whether PANA (layer 3) or IEEE802.1x 324 (layer 2) should be used in the join process. There is also a debate 325 whether the node should be able to send any unprotected packet on the 326 medium. Regardless, the security model must ensure that, prior to a 327 join process, packets from a untrusted device must be controlled in 328 volume and in reachability. 330 (tbd Backbone Router) need to work with 6MAN to define ND proxy. 331 Also need BBR sync sync between deterministic Ethernet and 6TiSCH 332 LLNs. 334 IEEE802.1TSN: external, maintain consistency. See also AVnu. 336 IEEE802.15.4: external, (tbd need updates?). 338 ISA100.20 Common Network Management: external, maintain consistency. 340 The 6TiSCH Operation sublayer (6top) [I-D.wang-6tisch-6top-sublayer] 341 is an Logical Link Control (LLC) or a portion thereof that provides 342 the abstraction of an IP link over a TSCH MAC. 344 5. Communication Paradigms and Interaction Models 346 [I-D.ietf-6tisch-terminology] defines the terms of Communication 347 Paradigms and Interaction Models, which can be placed in parallel to 348 the Information Models and Data Models that are defined in 349 [RFC3444]. 351 A Communication Paradigms would be an abstract view of a protocol 352 exchange, and would come with an Information Model for the 353 information that is being exchanged. In contrast, an Interaction 354 Models would be more refined and could point on standard operation 355 such as a Representational state transfer (REST) "GET" operation and 356 would match a Data Model for the data that is provided over the 357 protocol exchange. 359 [I-D.roll-rpl-industrial-applicability] section 2.1.3. and next 360 discusses appplication-layer paradigms, such as Source-sink (SS) that 361 is a Multipeer to Multipeer (MP2MP) model that is primarily used for 362 alarms and alerts, Publish-subscribe (PS, or pub/sub) that is 363 typically used for sensor data, as well as Peer-to-peer (P2P) and 364 Peer-to-multipeer (P2MP) communications. Additional considerations 365 on Duocast and its N-cast generalization are also provided. Those 366 paradigms are frequently used in industrial automation, which is a 367 major use case for IEEE802.15.4e TSCH wireless networks with 368 [ISA100.11a] and [HART]. 370 This specification focuses on Communication Paradigms and Interaction 371 Models for packet forwarding and TSCH resources (cells) management. 372 L ink-layer and Network-layer Packet forwarding interactions are 373 discussed in Section 6, whereas Link-layer (one-hop), Network-layer 374 (multithop along a track), and Application-layer (remote control) 375 management mechanisms for the TSCH schedule are discussed in Section 376 8. 378 6. Forwarding Models 380 6TiSCH supports three different forwarding model, G-MPLS Track 381 Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 Forwarding 382 (6F). 384 6.1. Track Forwarding 386 Track Forwarding is the simplest and fastest. A set of input cells 387 are uniquely bound to a set of output cells, representing a 388 forwarding state that can be used regardless of the upper layer 389 protocol. This model can effectively be seen as a G-MPLS operation 390 in that the information used to switch is not an explicit label, but 391 rather related to other properties of the way the packet was 392 received, a particular cell in the case of 6TiSCH. As a result, as 393 long as the TSCH MAC (and Layer 2 security) accepts a frame, that 394 frame can be switched regardless of the protocol, whether this is an 395 IPv6 packet, a 6LoWPAN fragment, or a frame from an alternate 396 protocol such as WirelessHART of ISA100.11a. 398 A Track is defined end-to-end as a succession of timeslots. A 399 timeslot belongs to at most one Track. For a given iteration of a 400 slotframe, the timeslot is associated uniquely with a cell, which 401 indicates the channel at which the timeslot operates for that 402 iteration. 404 A data frame that is forwarded along a Track has a destination MAC 405 address set to broadcast or a multicast address depending on MAC 406 support. This way, the MAC layer in the intermediate nodes accepts 407 the incoming frame and 6top switches it without incurring a change in 408 the MAC header. In the case of IEEE802.15.4e, this means effectively 409 broadcast, so that along the Track the short address for the 410 destination is set to 0xFFFF. 412 Conversely, a frame that is received along a Track with a destination 413 MAC address set to this node is extracted from the Track stream and 414 delivered to the upper layer. A frame with an unrecognized MAC 415 address is ignored at the MAC layer and thus is not received at the 416 6top sublayer. 418 There are 2 modes for a Track, transport mode and tunnel mode. 420 6.1.1. Transport Mode 421 In transport mode, the PDU is associated flow information that refers 422 uniquely to the Track, so the 6top sublayer can place the frame in 423 the appropriate timeslot without ambiguity. In the case of IPv6 424 traffic, flow identification is transported in the Flow Label of the 425 IPv6 header. Associated with the source IPv6 address, the flow label 426 forms a globally unique identifier for that particular Track that is 427 validated at egress before restoring the destination MAC address 428 (dmac) and punting to the upper layer. 430 | ^ 431 +--------------+ | | 432 | IPv6 | | | 433 +--------------+ | | 434 | 6LoWPAN HC | | | 435 +--------------+ ingress egress 436 | 6top | sets +----+ +----+ restores 437 +--------------+ dmac to | | | | dmac to 438 | TSCH MAC | brdcst | | | | self 439 +--------------+ | | | | | | 440 | LLN PHY | +-------+ +--...-----+ +-------+ 441 +--------------+ 443 6.1.2. Tunnel Mode 445 In tunnel mode, the frames originate from an arbitrary protocol over 446 a compatible MAC that may or may not be synchronized with the 6TiSCH 447 network. An example of this would be a router with a dual radio that 448 is capable of receiving and sending WirelessHART or ISA100.11a frames 449 with the second radio, by presenting itself as an access Point or a 450 Backbone Router, respectively. 452 In that mode, some entity (e.g. PCE) can coordinate with a 453 WirelessHART Network Manager or an ISA100.11a System Manager to 454 specify the flows that are to be transported transparently over the 455 Track. 457 +--------------+ 458 | IPv6 | 459 +--------------+ 460 | 6LoWPAN HC | 461 +--------------+ set restore 462 | 6top | +dmac+ +dmac+ 463 +--------------+ | | | | 464 | TSCH MAC | | | | | 465 +--------------+ | | | | 466 | LLN PHY | +-------+ +--...-----+ +-------+ 467 +--------------+ | ingress egress | 468 | | 469 +--------------+ | | 470 | LLN PHY | | | 471 +--------------+ | | 472 | TSCH MAC | | | 473 +--------------+ | | 474 |ISA100/WiHART | | v 475 +--------------+ 477 In that case, the flow information that identifies the Track is 478 uniquely derived from the information at the receiving end, for 479 instance the incoming timeslots, or an ISA100.11a ContractId. At the 480 ingress 6TiSCH router, the packet destination is recognized as self 481 but the flow information indicates that the frame must be tunnelled 482 over a particular 6top Track so the packet is not punted to upper 483 layer. Instead, it is passed to the 6top sublayer for switching. 484 The 6top sublayer in the ingress router overrides the destination MAC 485 to broadcast and forwards. 487 At the egress 6top router, the reverse operation occurs. Based on 488 metadata associated to the Track, the frame is passed to the 489 appropriate link layer with the destination MAC restored. 491 6.1.3. Tunnel Metadata 493 Metadata coming with the Track configuration is expected to provide 494 the destination MAC address of the egress endpoint as well as the 495 tunnel mode and specific data depending on the mode, for instance a 496 service access point for frame delivery at egress. If the tunnel 497 egress point does not have a MAC address that matches the 498 configuration, the Track installation fails. 500 In transport mode, if the final layer 3 destination is the tunnel 501 termination, then it is possible that the IPv6 address of the 502 destination is compressed at the 6LoWPAN sublayer based on the MAC 503 address. It is thus mandatory at the ingress point to validate that 504 the MAC address that was used at the 6LoWPAN sublayer for compression 505 matches that of the tunnel egress point. For that reason, the node 506 that injects a packet on a Track checks that the destination is 507 effectively that of the tunnel egress point before it overwrites it 508 to broadcast. The 6top sublayer at the tunnel egress point reverts 509 that operation to the MAC address obtained from the tunnel metadata. 511 6.2. Fragment Forwarding 513 Considering that 6LoWPAN packets can be as large as 1280 bytes (the 514 IPv6 MTU), and that the non-storing mode of RPL implies Source 515 Routing that requires space for routing headers, and that a 516 IEEE802.15.4 frame with security may carry in the order of 80 bytes 517 of effective payload, an IPv6 packet might be fragmented into more 518 than 16 fragments at the 6LoWPAN sublayer. 520 This level of fragmentation is much higher than that traditionally 521 experienced over the Internet with IPv4 fragments, where 522 fragmentation is already known as harmful. 524 In the case to a multihop route within a 6TiSCH network, Hop-by-Hop 525 recomposition occurs at each hop in order to reform the packet and 526 route it. This creates additional latency and forces intermediate 527 nodes to store a portion of a packet for an undetermined time, thus 528 impacting critical resources such as memory and battery. 530 [I-D.thubert-roll-forwarding-frags] describes a mechanism whereby the 531 datagram tag in the 6LoWPAN Fragment is used as a label for switching 532 at the 6LoWPAN sublayer. The draft allows for a degree of flow 533 control base on an Explicit Congestion Notification, as well as end- 534 to-end individual fragment recovery. 536 | ^ 537 +--------------+ | | 538 | IPv6 | | +----+ +----+ | 539 +--------------+ | | | | | | 540 | 6LoWPAN HC | | learn learn | 541 +--------------+ | | | | | | 542 | 6top | | | | | | | 543 +--------------+ | | | | | | 544 | TSCH MAC | | | | | | | 545 +--------------+ | | | | | | 546 | LLN PHY | +-------+ +--...-----+ +-------+ 547 +--------------+ 549 In that model, the first fragment is routed based on the IPv6 header 550 that is present in that fragment. The 6LoWPAN sublayer learns the 551 next hop selection, generates a new datagram tag for transmission to 552 the next hop, and stores that information indexed by the incoming MAC 553 address and datagram tag. The next fragments are then switched based 554 on that stored state. 556 | ^ 557 +--------------+ | | 558 | IPv6 | | | 559 +--------------+ | | 560 | 6LoWPAN HC | | replay replay | 561 +--------------+ | | | | | | 562 | 6top | | | | | | | 563 +--------------+ | | | | | | 564 | TSCH MAC | | | | | | | 565 +--------------+ | | | | | | 566 | LLN PHY | +-------+ +--...-----+ +-------+ 567 +--------------+ 569 A bitmap and an ECN echo in the end-to-end acknowledgement enable the 570 source to resend the missing fragments selectively. The first 571 fragment may be resent to carve a new path in case of a path failure. 572 The ECN echo set indicates that the number of outstanding fragments 573 should be reduced. 575 6.3. IPv6 Forwarding 577 As the packets are routed at layer 3, traditional QoS and RED 578 operations are expected to prioritize flows with differentiated 579 services. A new class of service for Deterministic Forwarding is 580 being defined to that effect in [I-D.svshah-tsvwg-lln-diffserv- 581 recommendations]. 583 | ^ 584 +--------------+ | | 585 | IPv6 | | +-QoS+ +-QoS+ | 586 +--------------+ | | | | | | 587 | 6LoWPAN HC | | | | | | | 588 +--------------+ | | | | | | 589 | 6top | | | | | | | 590 +--------------+ | | | | | | 591 | TSCH MAC | | | | | | | 592 +--------------+ | | | | | | 593 | LLN PHY | +-------+ +--...-----+ +-------+ 594 +--------------+ 596 7. TSCH and 6top 598 7.1. 6top 599 6top is a logical link control sitting between the IP layer and the 600 TSCH MAC layer, which provides the link abstraction that is required 601 for IP operations. The 6top operations are specified in [I-D.wang- 602 6tisch-6top-sublayer]. In particular, 6top provides a management 603 interface that enables an external management entity to schedule 604 cells and Slotframes, and allows the addition of complementary 605 functionality, for instance to support a dynamic schedule management 606 based on observed resource usage as discussed in section Section 8.2. 607 The 6top data model and management interfaces are further discussed 608 in Section 8.3. 610 If the scheduling entity explicitly specifies the slotOffset/ 611 channelOffset of the cells to be added/deleted, those cells are 612 marked as "hard". 6top cannot move hard cells in the TSCH schedule. 613 Hard cells are for example used by a central PCE. 615 6top contains a monitoring process which monitors the performance of 616 cells, and can move a cell in the TSCH schedule when it performs bad. 617 This is only applicable to cells which are marked as "soft". To 618 reserve a soft cell, the higher layer does not indicate the exact 619 slotOffset/channelOffset of the cell to add, but rather the resulting 620 bandwidth and QoS requirements. When the monitoring process triggers 621 a cell reallocation, the two neighbor motes communicating over this 622 cell negotiate its new position in the TSCH schedule. 624 7.2. 6top and RPL Objective Function operations 626 An implementation of a RPL [RFC 6550] Objective Function (OF), such 627 as the RPL Objective Function Zero (OF0) [RFC 6552] that is used in 628 the Minimal 6TiSCH Configuration [I-D.ietf-6tisch-minimal] to 629 support RPL over a static schedule, may leverage, for its internal 630 computation, the information maintained by 6top. 632 In particular, 6top creates and maintains an abstract neighbor table. 633 A neighbor table entry contains a set of statistics with respect to 634 that specific neighbor including the ASN when the last packet has 635 been received from that neighbor, a set of cell quality metrics 636 (RSSI, LQI), the number of packets sent to the neighbor or the number 637 of packets received from it. This information can be obtained 638 through 6top management APIs as detailed in the 6top sublayer 639 specification [I-D.wang-6tisch-6top-sublayer] and used to compute a 640 Rank Increment that will determine the selection of the preferred 641 parent. 643 6top provides statistics about the underlying layer so the OF can be 644 tuned to the nature of the TSCH MAC layer. 6top also enables the RPL 645 OF to influence the MAC behaviour, for instance by configuring the 646 periodicity of EBs. By augmenting the EB periodicity, it is possible 647 to change the network dynamics so as to improve the support of mobile 648 devices. 650 Some RPL control messages, such as the DODAG Information Object (DIO) 651 are broadcast to all neighbor nodes. The broadcast channel 652 requirement is addressed by 6top by configuring TSCH to provide such 653 a channel, as opposed to, for instance, carrying DIO messages in 654 Enhance Beacons. 656 In the TSCH schedule, each cell has the LinkType attribute. Setting 657 the LinkType to ADVERTISING indicates that the cell MAY be used to 658 send an Enhanced Beacon. When a node forms its Enhanced Beacon, the 659 cell, with LinkType=ADVERTISING, SHOULD be included in the 660 FrameAndLinkIE, and its LinkOption field SHOULD be set to the 661 combination of "Receive" and "Timekeeping". The receiver of the 662 Enhanced Beacon MAY be listening at the cell to get the Enhanced 663 Beacon ([IEEE802154e]). 6top takes this way to establish broadcast 664 channel, which not only allows TSCH to broadcast Enhanced Beacons, 665 but also allows an upper layer like RPL. 667 To support DIO and DAO broadcasts, 6top uses the payload of a Data 668 Packet to carry the DIO or DAO. The message is inserted into the 669 queue associated with the cells which LinkType is set to ADVERTISING. 670 Then, taking advantage of the broadcast cell feature established with 671 FrameAndLinkIE (as described above), the data packet with DIO or DAO 672 in the payload can be received by neighbors, which enforces the 673 maintenance of DODAG. 675 A LinkOption combining "Receive" and "Timekeeping" bits indicates to 676 the receivers of the Enhanced Beacon that the cell MUST be used as a 677 broadcast cell. The frequency of sending Enhanced Beacons or other 678 broadcast messages by the upper layer is determined by the timers 679 associated with the messages. For example, the transmission of 680 Enhance Beacons is triggered by a timer in 6top; transmission of a 681 DIO message is triggered by the trickle timer of RPL. 683 7.3. Network Synchronization 685 Nodes in a TSCH network must be time synchronized. A node keeps 686 synchronized to its time source neighbor through a combination of 687 frame-based and acknowledgement-based synchronization. In order to 688 maximize battery life and network throughput, it is advisable that 689 RPL ICMP discovery and maintenance traffic (governed by the trickle 690 timer) be somehow coordinated with the transmission of time 691 synchronization packets (especially with enhanced beacons). This 692 could be achieved through an interaction of the 6top sublayer and the 693 RPL objective Function, or could be controlled by a management 694 entity. 696 Time distribution requires a loop-less structure. Nodes taken in a 697 synchronization loop will rapidly desynchronize from the network and 698 become isolated. It is expected that a RPL DAG with a dedicated 699 global Instance is deployed for the purpose of time synchronization. 700 That Instance is referred to as the Time Synchronization Global 701 Instance (TSGI). The TSGI can be operated in either of the 3 modes 702 that are detailed in RPL [RFC6550] section "3.1.3. Instances, 703 DODAGs, and DODAG Versions". Multiple uncoordinated DODAGs with 704 independent roots may be used if all the roots share a common time 705 source such as the Global Positioning System (GPS). In the absence of 706 a common time source, the TSGI should form a single DODAG with a 707 virtual root. A backbone network is then used to synchronize and 708 coordinate RPL operations between the backbone routers that act as 709 sinks for the LLN. 711 A node that has not joined the TSGI advertises a MAC level Join 712 Priority of 0xFF to notify its neighbors that is is not capable of 713 serving as time parent. A node that has joined the TSGI advertises a 714 MAC level Join Priority set to its DAGRank() in that Instance, where 715 DAGRank() is the operation specified in [RFC6550], section "3.5.1. 716 Rank Comparison". 718 A root is configured or obtains by some external means the knowledge 719 of the RPLInstanceID for the TSGI. The root advertises its DagRank in 720 the TSGI, that MUST be less than 0xFF, as its Join Priority (JP) in 721 its IEEE802.15.4e Extended Beacons (EB). We'll note that the JP is 722 now specified between 0 and 0x3F leaving 2 bit sin the octet unused 723 in the IEEE802.15.4e specification. After consultation with IEEE 724 authors, it was asserted that 6TiSCH can make a full use of the octet 725 to carry an integer value up to 0xFF. 727 A node that reads a Join Priority of less than 0xFF should join the 728 neighbor with the lesser Join Priority and use it as time parent. If 729 the node is configured to serve as time parent, then the node should 730 join the TSGI, obtain a Rank in that Instance and start advertising 731 its own DagRank in the TSGI as its Join Priority in its EBs. 733 7.4. Slotframes and Priorities 735 6top uses priority queues to manage concurrent data flows of 736 different priorities. When a packet is received from an higher layer 737 for transmission, the I-MUX module of 6top inserts that packet in the 738 outgoing queue which matches the packet best (DSCP can therefore be 739 used). At each scheduled transmit slot, the MUX module looks for the 740 frame in all the outgoing queues that best matches the cells. If a 741 frame is found, it is given to TSCH for transmission. 743 7.5. Packet Marking and Handling 744 reservation Deterministic flow allocation (hard reservation of 745 timeslots) eg centralized RSVP? metrics? Hop-by-hop interaction with 746 6top. Lazy reservation (use shared slots to transport extra burst 747 and then dynamically (de)allocate) Classical QoS (dynamic based on 748 observation) 750 7.6. Distributing the reservation of timeslots 752 6TiSCH expects a high degree of scalability together with a 753 distributed routing functionality based on the RPL routing protocol. 754 To achieve this goal, the spectrum must be allocated in a way that 755 allows for spatial reuse between zones that will not interfere with 756 one another. In a large and spatially distributed network, a 6TiSCH 757 node is often in a good position to determine usage of spectrum in 758 its vicinity. 760 Use cases for distributed routing are often associated with a 761 statistical distribution of best-effort traffic with variable needs 762 for bandwidth on each individual link. With 6TiSCH, the link 763 abstraction is implemented as a bundle of cells; the size of a bundle 764 is optimal when both the energy wasted idle listening and the packet 765 drops due to congestion loss are minimized. This can be maintained 766 if the number of cells in a bundle is adapted dynamically, and with 767 enough reactivity, to match the variations of best-effort traffic. 768 In turn, the agility to fulfill the needs for additional cells 769 improves when the number of interactions with other devices and the 770 protocol latencies are minimized. 772 6TiSCH limits that interaction to RPL parents that will only 773 negotiate with other RPL parents, and performs that negotiation by 774 groups of cells as opposed to individual cells. The 6TiSCH 775 architecture allows RPL parents to adjust dynamically, and 776 independently from the PCE, the amount of bandwidth that is used to 777 communicate between themselves and their children, in both 778 directions; to that effect, an allocation mechanism enables a RPL 779 parent to obtain the exclusive use of a portion of an abstract 780 channel usage/distribution (CUD) matrix of timeslots within its 781 interference domain. 783 The 6TiSCH architecture introduces the concept of chunks [I-D.ietf- 784 6tisch-terminology]) to operate such spectrum distribution for a 785 whole group of cells at a time. The CUD matrix is formatted into a 786 set of chunks, each of them identified uniquely by a chunk-ID. The 787 knowledge of this formatting is shared between all the nodes in a 788 6TiSCH network. 6TiSCH also defines the process of chunk ownership 789 appropriation whereby a RPL parent discovers a chunk that is not used 790 in its interference domain (e.g lack of energy detected in reference 791 cells in that chunk); then claims the chunk, and then defends it in 792 case another RPL parent would attempt to appropriate it while it is 793 in use. The chunks is the basic unit of ownership that is used in 794 that process. 796 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 797 chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ| 798 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 799 chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1| 800 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 801 ... 802 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 803 chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG| 804 +-----+-----+-----+-----+-----+-----+-----+ +-----+ 805 0 1 2 3 4 5 6 M 807 As a result of the process of chunk ownership appropriation, the RPL 808 parent has exclusive authority to decide which cell in the 809 appropriated chunk can be used by which node in its interference 810 domain. In other words, it is implicitly delegated the right to 811 manage the portion of the slotframe that is represented by the chunk. 812 The RPL parent may thus orchestrate which transmissions occur in any 813 of the cells in the chunk, by allocating cells from the chunk to any 814 form of communication (unicast, multicast) in any direction between 815 itself and its children. Initially, those cells are added to the 816 heap of free cells, then dynamically placed into existing bundles, in 817 new bundles, or allocated opportunistically for one transmission. 819 The appropriation of a chunk can also be requested explicitly by the 820 PCE to any node. In that case, the node still may need to perform 821 the appropriation process to validate that no other node has claimed 822 that chunk already. After a successful appropriation, the PCE owns 823 the cells in that chunk, and may use them as hard cells to set up 824 tracks. 826 8. Schedule Management Mechanisms 828 6TiSCH uses 4 paradigms to manage the TSCH schedule of the LLN nodes: 829 Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring 830 and scheduling management, and Hop-by-hop scheduling. Multiple 831 mechanisms are defined that implement the associated Interaction 832 Models, and can be combined and used in the same LLN. Which 833 mechanism(s) to use depends on application requirements. 835 8.1. Minimal Static Scheduling 837 In the simplest instantiation of a 6TiSCH network, a common fixed 838 schedule may be shared by all nodes in the network. Cells are 839 shared, and nodes contend for slot access in a slotted aloha manner. 841 A static TSCH schedule can be used to bootstrap a network, as an 842 initial phase during implementation, or as a fall-back mechanism in 843 case of network malfunction. This scheduled can be preconfigured or 844 learnt by a node when joining the network. Regardless, the schedule 845 remains unchanged after the node has joined a network. The Routing 846 Protocol for LLNs (RPL) is used on the resulting network. This 847 "minimal" scheduling mechanism that implements this paradigm is 848 detailed in [I-D.ietf-6tisch-minimal]. 850 8.2. Neighbor-to-neighbor Scheduling 852 In the simplest instantiation of a 6TiSCH network described in 853 Section 8.1, nodes may expect a packet at any cell in the schedule 854 and will waste energy idle listening. In a more complex 855 instantiation of a 6TiSCH network, a matching portion of the schedule 856 is established between peers to reflect the observed amount of 857 transmissions between those nodes. The aggregation of the cells 858 between a node and a peer forms a bundle that the 6top layer uses to 859 implement the abstraction of a link for IP. The bandwidth on that 860 link is proportional to the number of cells in the bundle. 862 If the size of a bundle is configured to fit an average amount of 863 bandwidth, peak emissions will be destroyed. If the size is 864 configured to allow for peak emissions, energy is be wasted idle 865 listening. 867 In the most efficient instantiation of a 6TiSCH network, the size of 868 the bundles that implement the links may be changed dynamically in 869 order to adapt to the need of end-to-end flows routed by RPL. An 870 optional On-The-Fly (OTF) component may be used to monitor bandwidth 871 usage and perform requests for dynamic allocation by the 6top 872 sublayer. The OTF component is not part of the 6top sublayer. It 873 may be collocated on the same device or may be partially or fully 874 offloaded to an external system. 876 The 6top sublayer [I-D.wang-6tisch-6top-sublayer] defines a protocol 877 for neighbor nodes to reserve soft cells to one another. Because 878 this reservation is done without global knowledge of the schedule of 879 nodes in the LLN, scheduling collisions are possible. 6top defines a 880 monitoring process which continuously tracks the packet delivery 881 ratio of soft cells. It uses these statistics to trigger the 882 relocation of a soft cell in the schedule, using a negotiation 883 protocol between the neighbors nodes communicating over that cell. 885 Monitoring and relocation is done in the 6top layer. For the upper 886 layer, the connection between two neighbor nodes appears as an number 887 of cells. Depending on traffic requirements, the upper layer can 888 request 6top to add or delete a number of cells scheduled to a 889 particular neighbor, without being responsible for choosing the exact 890 slotOffset/channelOffset of those cells. 892 8.3. Remote Monitoring and Schedule Management 893 The 6top interface document [I-D.wang-6tisch-6top-interface] 894 specifies the generic data model that can be used to monitor and 895 manage resources at the 6top sublayer. Abstract methods are 896 suggested for use by a management entity in the device. The data 897 model also enables remote control operations on the 6top sublayer. 899 Being able to interact with the 6top sublayer of a node multiple hops 900 away can be used for monitoring, scheduling, or a combination of 901 both. The architecture supports variations on the deployment model, 902 and focuses on the flows rather than whether there is a proxy or a 903 translational operation on the way. 905 [I-D.sudhaakar-6tisch-coap] defines an mapping of 6top's set of 906 commands described in [I-D.wang-6tisch-6top-interface] to CoAP 907 resources. This allows an entity to interact with the 6top layer of 908 a node that is multiple hops away in a RESTful fashion. 910 [I-D.sudhaakar-6tisch-coap] defines a basic set CoAP resources and 911 associated RESTful access methods (GET/PUT/POST/DELETE). The payload 912 (body) of the CoAP messages is encoded using the CBOR format. The 913 draft also defines the concept of "profiles" to allow for future or 914 specific extensions, as well as a mechanism for a CoAP client to 915 discover the profiles installed on a node. 917 The entity issuing the CoAP requests can be a central scheduling 918 entity (e.g. a PCE), a node multiple hops away with the authority to 919 modify the TSCH schedule (e.g. the head of a local cluster), or a 920 external device monitoring the overall state of the network (e.g. 921 NME). The architecture allows for different types of interactions 922 between this CoAP client and a node in the network: 924 8.4. Hop-by-hop Scheduling 926 A node can reserve a track to a destination node multiple hops away 927 by installing soft cells at each intermediate node. This forms a 928 track of soft cells. It is the responsibility of the 6top sublayer 929 of each node on the track to monitor these soft cells and trigger 930 relocation when needed. 932 This hop-by-hop reservation mechanism is similar to [RFC2119] and 933 [RFC5974]. The protocol for a node to trigger hop-by-hop scheduling 934 is not yet defined. 936 9. Centralized vs. Distributed Routing 938 6TiSCH supports a mixed model of centralized routes and distributed 939 routes. Centralized routes can for example computed by a entity such 940 as a PCE. Distributed routes are computed by the RPL routing 941 protocol. 943 Both may inject routes in the Routing Tables of the 6TiSCH routers. 944 In either case, each route is associated with a topology that is 945 indexed by an RPLInstanceID, as defined in RPL [RFC6550]. RPL and 946 PCE rely on shared sources to define Global and Local RPLInstanceIDs. 948 It is possible for centralized and distributed routing to share a 949 same topology. In this case, centralized routes have precedence over 950 distributed routes in case of conflict. 952 Inside the 6TiSCH domain, the flow label is used to indicate the 953 topology that must be used for routing. The associated Routing 954 Tables are discussed in [I-D.thubert-roll-flow-label]. 956 10. IANA Considerations 958 This specification does not require IANA action. 960 11. Security Considerations 962 This specification is not found to introduce new security threat. 964 12. Acknowledgements 966 13. References 968 13.1. Normative References 970 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 971 Requirement Levels", BCP 14, RFC 2119, March 1997. 973 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 974 6 (IPv6) Specification", RFC 2460, December 1998. 976 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 977 Information Models and Data Models", RFC 3444, January 978 2003. 980 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J. and S. Van den 981 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 982 4080, June 2005. 984 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 985 Architecture", RFC 4291, February 2006. 987 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 988 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 989 September 2007. 991 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless 992 Address Autoconfiguration", RFC 4862, September 2007. 994 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. 995 Yegin, "Protocol for Carrying Authentication for Network 996 Access (PANA)", RFC 5191, May 2008. 998 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 999 Hoc Networks", RFC 5889, September 2010. 1001 [RFC5974] Manner, J., Karagiannis, G. and A. McDonald, "NSIS 1002 Signaling Layer Protocol (NSLP) for Quality-of-Service 1003 Signaling", RFC 5974, October 2010. 1005 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 1006 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 1007 September 2011. 1009 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 1010 Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. 1011 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 1012 Lossy Networks", RFC 6550, March 2012. 1014 [RFC6552] Thubert, P., "Objective Function Zero for the Routing 1015 Protocol for Low-Power and Lossy Networks (RPL)", RFC 1016 6552, March 2012. 1018 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann, 1019 "Neighbor Discovery Optimization for IPv6 over Low-Power 1020 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 1021 November 2012. 1023 13.2. Informative References 1025 [I-D.chakrabarti-nordmark-6man-efficient-nd] 1026 Chakrabarti, S., Nordmark, E., Thubert, P. and M. 1027 Wasserman, "Wired and Wireless IPv6 Neighbor Discovery 1028 Optimizations", Internet-Draft draft-chakrabarti-nordmark- 1029 6man-efficient-nd-04, October 2013. 1031 [I-D.ietf-6tisch-minimal] 1032 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 1033 Configuration", Internet-Draft draft-ietf-6tisch- 1034 minimal-00, November 2013. 1036 [I-D.ietf-6tisch-terminology] 1037 Palattella, M., Thubert, P., Watteyne, T. and Q. Wang, 1038 "Terminology in IPv6 over the TSCH mode of IEEE 1039 802.15.4e", Internet-Draft draft-ietf-6tisch- 1040 terminology-00, November 2013. 1042 [I-D.ietf-6tisch-tsch] 1043 Watteyne, T., Palattella, M. and L. Grieco, "Using 1044 IEEE802.15.4e TSCH in an LLN context: Overview, Problem 1045 Statement and Goals", Internet-Draft draft-ietf-6tisch- 1046 tsch-00, November 2013. 1048 [I-D.ietf-roll-rpl-industrial-applicability] 1049 Phinney, T., Thubert, P. and R. Assimiti, "RPL 1050 applicability in industrial networks", Internet-Draft 1051 draft-ietf-roll-rpl-industrial-applicability-02, October 1052 2013. 1054 [I-D.ohba-6tisch-security] 1055 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P. and 1056 A. Yegin, "Security Framework and Key Management Protocol 1057 Requirements for 6TiSCH", Internet-Draft draft-ohba- 1058 6tisch-security-00, October 2013. 1060 [I-D.sudhaakar-6tisch-coap] 1061 Sudhaakar, R. and P. Zand, "6TiSCH Data Model for CoAP", 1062 Internet-Draft draft-sudhaakar-6tisch-coap-00, October 1063 2013. 1065 [I-D.svshah-tsvwg-lln-diffserv-recommendations] 1066 Shah, S. and P. Thubert, "Differentiated Service Class 1067 Recommendations for LLN Traffic", Internet-Draft draft- 1068 svshah-tsvwg-lln-diffserv-recommendations-01, August 2013. 1070 [I-D.thubert-6lowpan-backbone-router] 1071 Thubert, P., "6LoWPAN Backbone Router", Internet-Draft 1072 draft-thubert-6lowpan-backbone-router-03, February 2013. 1074 [I-D.thubert-roll-flow-label] 1075 Thubert, P., "Use of the IPv6 Flow Label within an LLN", 1076 Internet-Draft draft-thubert-roll-flow-label-02, November 1077 2012. 1079 [I-D.thubert-roll-forwarding-frags] 1080 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 1081 Recovery", Internet-Draft draft-thubert-roll-forwarding- 1082 frags-02, September 2013. 1084 [I-D.wang-6tisch-6top-interface] 1085 Wang, Q., Vilajosana, X. and T. Watteyne, "6TiSCH 1086 Operation Sublayer (6top) Interface", Internet-Draft 1087 draft-wang-6tisch-6top-interface-01, February 2014. 1089 [I-D.wang-6tisch-6top-sublayer] 1090 Wang, Q., Vilajosana, X. and T. Watteyne, "6TiSCH 1091 Operation Sublayer (6top)", Internet-Draft draft-wang- 1092 6tisch-6top-00, October 2013. 1094 13.3. External Informative References 1096 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 1097 a group of specifications for industrial process and 1098 control devices administered by the HART Foundation", . 1100 [IEEE802.1TSNTG] 1101 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 1102 Networks Task Group", March 2013, . 1105 [IEEE802154e] 1106 IEEE standard for Information Technology, "IEEE std. 1107 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 1108 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 1109 2012. 1111 [ISA100.11a] 1112 ISA, "ISA100, Wireless Systems for Automation", May 2008, 1113 . 1116 Authors' Addresses 1118 Pascal Thubert, editor 1119 Cisco Systems, Inc 1120 Building D 1121 45 Allee des Ormes - BP1200 1122 MOUGINS - Sophia Antipolis, 06254 1123 FRANCE 1125 Phone: +33 497 23 26 34 1126 Email: pthubert@cisco.com 1128 Thomas Watteyne 1129 Linear Technology, Dust Networks Product Group 1130 30695 Huntwood Avenue 1131 Hayward, CA 94544 1132 USA 1134 Phone: +1 (510) 400-2978 1135 Email: twatteyne@linear.com 1137 Robert Assimiti 1138 Centero 1139 961 Indian Hills Parkway 1140 Marietta, GA 30068 1141 USA 1143 Phone: +1 404 461 9614 1144 Email: robert.assimiti@centerotech.com