idnits 2.17.1 draft-thubert-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 168 has weird spacing: '...scribed in...' == Line 625 has weird spacing: '...ance is deplo...' -- The document date (October 21, 2013) is 3838 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 150, but not defined == Missing Reference: 'RFC4903' is mentioned on line 156, but not defined == Missing Reference: 'RFC6275' is mentioned on line 156, but not defined == Missing Reference: 'RFC4389' is mentioned on line 157, but not defined == Missing Reference: 'RFC6620' is mentioned on line 160, but not defined == Missing Reference: 'RFC4429' is mentioned on line 161, but not defined == Missing Reference: 'I-D.roll-rpl-industrial-applicability' is mentioned on line 349, but not defined == Missing Reference: 'IEEE802154e' is mentioned on line 936, but not defined == Missing Reference: 'HART' is mentioned on line 927, but not defined == Missing Reference: 'IEEE802.1TSNTG' is mentioned on line 931, but not defined == Unused Reference: 'I-D.ietf-roll-rpl-industrial-applicability' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-6tisch-security' is defined on line 874, but no explicit reference was found in the text == Unused Reference: 'I-D.svshah-tsvwg-lln-diffserv-recommendations' is defined on line 890, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 896, but no explicit reference was found in the text == Unused Reference: 'I-D.vilajosana-6tisch-minimal' is defined on line 910, 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-01 == Outdated reference: A later version (-02) exists of draft-ietf-roll-rpl-industrial-applicability-01 == 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-00 == Outdated reference: A later version (-02) exists of draft-thubert-roll-forwarding-frags-01 Summary: 5 errors (**), 0 flaws (~~), 24 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 22, 2014 Linear Technology 6 RA. Assimiti 7 Centero 8 October 21, 2013 10 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e 11 draft-thubert-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. Route Computation may be achieved in a centralized 19 fashion by a Path Computation Element, in a distributed fashion using 20 the Routing Protocol for Low Power and Lossy Networks, or in a mixed 21 mode. The Backbone Routers perform proxy Neighbor Discovery 22 operations over the backbone on behalf of the wireless device, 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 22, 2014. 50 Copyright Notice 51 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Applications and Goals . . . . . . . . . . . . . . . . . . . . 4 68 4. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 4 69 5. Communication Paradigms and Interaction Models . . . . . . . . 7 70 6. Forwarding Models . . . . . . . . . . . . . . . . . . . . . . 8 71 6.1. Track Forwarding . . . . . . . . . . . . . . . . . . . . . 8 72 6.1.1. Transport Mode . . . . . . . . . . . . . . . . . . . . 9 73 6.1.2. Tunnel Mode . . . . . . . . . . . . . . . . . . . . . 9 74 6.1.3. Tunnel Metadata . . . . . . . . . . . . . . . . . . . 10 75 6.2. Fragment Forwarding . . . . . . . . . . . . . . . . . . . 11 76 6.3. IPv6 Forwarding . . . . . . . . . . . . . . . . . . . . . 12 77 7. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . . . 12 78 7.1. 6top . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 7.2. Network Synchronization . . . . . . . . . . . . . . . . . 13 80 7.3. Slotframes and Priorities . . . . . . . . . . . . . . . . 14 81 7.4. Packet Marking and Handling . . . . . . . . . . . . . . . 14 82 8. Schedule Management Mechanisms . . . . . . . . . . . . . . . . 14 83 8.1. Minimal Static Scheduling . . . . . . . . . . . . . . . . 14 84 8.2. Neighbor-to-Neighbor Scheduling . . . . . . . . . . . . . 15 85 8.3. Remote Monitoring and Schedule Management . . . . . . . . 15 86 8.4. Hop-by-hop Scheduling . . . . . . . . . . . . . . . . . . 16 87 9. Centralized vs. Distributed Routing . . . . . . . . . . . . . 16 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 89 11. Security Considerations . . . . . . . . . . . . . . . . . . . 17 90 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 91 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 92 13.1. Normative References . . . . . . . . . . . . . . . . . . 17 93 13.2. Informative References . . . . . . . . . . . . . . . . . 18 94 13.3. External Informative References . . . . . . . . . . . . . 19 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Introduction 99 The emergence of radio technology enabled a large variety of new 100 types of devices to be interconnected, at a very low marginal cost 101 compared to wire, at any range from Near Field to interplanetary 102 distances, and in circumstances where wiring would be less than 103 practical, for instance rotating devices. 105 At the same time, a new breed of Time Sensitive Networks is being 106 developed to enable traffic that is highly sensitive to jitter and 107 quite sensitive to latency. Such traffic is not limited to voice and 108 video, but also includes command and control operations such as found 109 in industrial automation or in-vehicle sensors and actuators. 111 At IEEE802.1, the "Audio/Video Task Group", was renamed TSN for Time 112 Sensitive Networking to address Deterministic Ethernet. The 113 IEEE802.15.4 Medium access Control (MAC) has evolved with 114 IEEE802.15.4e that provides in particular the Timeslotted Channel 115 Hopping (TSCH) mode for industrial-type applications. 117 Though at a different time scale, both standards provide 118 Deterministic capabilities to the point that a packet that pertains 119 to a certain flow crosses the network from node to node following a 120 very precise schedule, as a train that leaves intermediate stations 121 at precise times along its path. With TSCH, time is formatted into 122 timeslots, and an individual timeslot is allocated to unicast or 123 broadcast communication at the MAC level. The time slotted operation 124 reduces collisions, saves energy, and enables to more closely 125 engineer the network for deterministic properties. The channel 126 hopping aspect is a simple and efficient technique to combat 127 multipath fading and external interference (for example by WiFi 128 emitters). 130 This document presents an architecture for an IPv6 Multi-Link subnet 131 that is composed of a high speed powered backbone and a number of 132 IEEE802.15.4e TSCH wireless networks attached and synchronized by 133 backbone routers. Route Computation may be achieved in a centralized 134 fashion by a Path Computation Element (PCE), in a distributed fashion 135 using the Routing Protocol for Low Power and Lossy Networks (RPL), or 136 in a mixed mode. The Backbone Routers perform proxy IPv6 Neighbor 137 Discovery (ND) operations over the backbone on behalf of the wireless 138 devices, so they can share a same IPv6 subnet and appear to be 139 connected to the same backbone as classical devices. Timeslots and 140 other device resources are managed by an abstract Network Management 141 Entity (NME) that may cooperate with the PCE in order to minimize the 142 interaction with and the load on the constrained device. 144 2. Terminology 146 Readers are expected to be familiar with all the terms and concepts 147 that are discussed in "Neighbor Discovery for IP version 6" 148 [RFC4861], "IPv6 over Low-Power Wireless Personal Area Networks 149 (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" 150 [RFC4919], Neighbor Discovery Optimization for Low-power and Lossy 151 Networks [RFC6775] and "Multi-link Subnet Support in IPv6" [I-D.ietf- 152 ipv6-multilink-subnets]. 154 Readers may benefit from reading the "RPL: IPv6 Routing Protocol for 155 Low-Power and Lossy Networks" [RFC6550] specification; "Multi-Link 156 Subnet Issues" [RFC4903]; "Mobility Support in IPv6" [RFC6275]; 157 "Neighbor Discovery Proxies (ND Proxy)" [RFC4389]; "IPv6 Stateless 158 Address Autoconfiguration" [RFC4862]; "FCFS SAVI: First-Come, First- 159 Served Source Address Validation Improvement for Locally Assigned 160 IPv6 Addresses" [RFC6620]; and "Optimistic Duplicate Address 161 Detection" [RFC4429] prior to this specification for a clear 162 understanding of the art in ND-proxying and binding. 164 The draft uses terminology defined or referenced in [I-D.palattella- 165 6tisch-terminology], [I-D.chakrabarti-nordmark-6man-efficient-nd], 166 [I-D.roll-rpl-industrial-applicability], [RFC5191] and [RFC4080]. 168 The draft also conforms to the terms and models described in 169 [RFC3444] and [RFC5889] and uses the vocabulary and the concepts 170 defined in [RFC4291] for the IPv6 Architecture. 172 3. Applications and Goals 174 The architecture derives from existing industrial standards for 175 Process Control by its focus on Deterministic Networking, in 176 particular with the use of the IEEE802.15.4e TSCH MAC [IEEE802154e] 177 and the centralized PCE. This approach leverages the TSCH MAC 178 benefits for high reliability against interference, low-power 179 consumption on deterministic traffic, and its Traffic Engineering 180 capabilities. Deterministic Networking applies in particular to open 181 and closed control loops, as well as supervisory control flows and 182 management. 184 An incremental set of industrial requirements are addressed with the 185 addition of an autonomic and distributed routing operation based on 186 RPL. These use cases include plant setup and decommissioning, as well 187 as monitoring of lots of lesser importance measurements such as 188 corrosion and events. RPL also enables mobile use cases such as 189 mobile workers and cranes. 191 A Backbone Router is included in order to scale the factory plant 192 subnet to address large deployments, with proxy ND and time 193 synchronization over a high speed backbone. 195 The architecture also applies to building automation that leverage 196 RPL's storing mode to address multipath over a large number of hops, 197 in-vehicle command and control that can be as demanding as industrial 198 applications, commercial automation and asset Tracking with mobile 199 scenarios, home automation and domotics which become more reliable 200 and thus provide a better user experience, and resource management 201 (energy, water, etc.). 203 4. Overview and Scope 204 The scope of the present work is a subnet that, in its basic 205 configuration, is made of a IEEE802.15.4e Timeslotted Channel Hopping 206 (TSCH) [I-D.watteyne-6tisch-tsch] MAC Low Power Lossy Network (LLN). 208 ---+-------- ............ ------------ 209 | External Network | 210 | +-----+ 211 +-----+ | NME | 212 | | LLN Border | | 213 | | router +-----+ 214 +-----+ 215 o o o 216 o o o o 217 o o LLN o o o 218 o o o o 219 o 221 The LLN devices communicate over IPv6 [RFC2460] using the 6LoWPAN 222 Header Compression (6LoWPAN HC) [RFC6282]. From the perpective of 223 Layer 3, a single LLN interface (typically an IEEE802.15.4-compliant 224 radio) may be seen as a collection of Links with different 225 capabilities for unicast or multicast services. An IPv6 subnet spans 226 over multiple links, effectively forming a Multi-Link subnet. Within 227 that subnet, Neighbor Devices are discovered with 6LoWPAN Neighbor 228 Discovery (6LoWPAN ND) [RFC6775]. The Routing Protocol for Low Power 229 and Lossy Networks (RPL) [RFC6550] enables routing within the LLN, 230 typically within the Multi-Link subnet in the so called Route Over 231 fashion. RPL forms Destination Oriented Directed Acyclic Graphs 232 (DODAGs) within Instances of the protocol, each Instance being 233 associated with an Objective Function (OF) to form a routing 234 topology. A particular LLN device, the LLN Border Router (LBR), acts 235 as RPL root, 6LoWPAN HC terminator, and LLN Border Router (LBR) to 236 the outside. The LBR is usually powered. More on RPL Instances can 237 be found in [RFC6550], sections "3.1.2. RPL Identifiers" and "3.1.3. 238 Instances, DODAGs, and DODAG Versions". 240 An extended configuration of the subnet comprises multiple LLNs. The 241 LLNs are interconnected and synchronized over a backbone, that can be 242 wired or wireless. The backbone can be a classical IPv6 network, 243 with Neighbor Discovery operating as defined in [RFC4861] and 244 [RFC4862]. The backbone can also support Efficiency-aware IPv6 245 Neighbor Discovery Optimizations [I-D.chakrabarti-nordmark-6man- 246 efficient-nd] in mixed mode as described in [I-D.thubert-6lowpan- 247 backbone-router]. 249 Security is often handled at layer 2 and Layer 4. Authentication 250 during the join process can be handled by the Protocol for Carrying 251 Authentication for Network access (PANA) [RFC5191]. 253 The LLN devices are time-synchronized at the MAC level. The LBR that 254 serves as time source is a RPL parent in a particular RPL instance 255 that serves for time synchronization; this way, the time 256 synchronization starts at the RPL root and follows the RPL DODAGs 257 with no timing loop. 259 In the extended configuration, the functionality of the LBR is 260 enhanced to that of Backbone Router (BBR). A BBR is an LBR, but also 261 an Energy Aware Default Router (NEAR) as defined in [I-D.chakrabarti- 262 nordmark-6man-efficient-nd]. The BBR performs ND proxy operations 263 between the registered devices and the classical ND devices that are 264 located over the backbone. 6TiSCH BBRs synchronize with one another 265 over the backbone, so as to ensure that the multiple LLNs that form 266 the IPv6 subnet stay tightly synchronized. If the Backbone is 267 Deterministic (such as defined by the Time Sensitive Networking WG at 268 IEEE), then the Backbone Router ensures that the end-to-end 269 deterministic behavior is maintained between the LLN and the 270 backbone. 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 The main architectural blocks are arranged as follows: 295 +-----+-----+-----+-----+-------+-----+ 296 |PCEP | CoAP |PANA |6LoWPAN| RPL | 297 | PCE |DTLS | | | ND | | 298 +-----+-----+-----+-----+-------+-----+-----+ 299 | TCP | UDP | ICMP |RSVP | 300 +-----+-----+-----+-----+-------+-----+-----+ 301 | IPv6 | 302 +-------------------------------------------+ 303 | 6LoWPAN HC | 304 +-------------------------------------------+ 305 | 6top | 306 +-------------------------------------------+ 307 | IEEE802.15.4e TSCH | 308 +-------------------------------------------+ 310 RPL is the routing protocol of choice for LLNs. (TBD RPL) whether 311 there is a need to define a 6TiSCH OF. 313 (tbd NME) COMAN is working on network Management for LLN. They are 314 considering the Open Mobile Alliance (OMA) Lightweight M2M (LWM2M) 315 Object system. This standard includes DTLS, CoAP (core plus Block 316 and Observe patterns), SenML and CoAP Resource Directory. 318 (tbd PCE) need to work with PCE WG to define flows to PCE, and define 319 how to accommodate PCE routes and reservation. Will probably look a 320 lot like GMPLS. 322 (tbd Backbone Router) need to work with 6MAN to define ND proxy. 323 Also need BBR sync sync between deterministic Ethernet and 6TiSCH 324 LLNs. 326 IEEE802.1TSN: external, maintain consistency. See also AVnu. 328 IEEE802.15.4: external, (tbd need updates?). 330 ISA100.20 Common Network Management: external, maintain consistency. 332 IoT6 European Project: external, maintain consistency. 334 5. Communication Paradigms and Interaction Models 336 [I-D.palattella-6tisch-terminology] defines the terms of 337 Communication Paradigms and Interaction Models, which can be placed 338 in parallel to the Information Models and Data Models that are 339 defined in [RFC3444]. 341 A Communication Paradigms would be an abstract view of a protocol 342 exchange, and would come with an Information Model for the 343 information that is being exchanged. In contrast, an Interaction 344 Models would be more refined and could point on standard operation 345 such as a Representational state transfer (REST) "GET" operation and 346 would match a Data Model for the data that is provided over the 347 protocol exchange. 349 [I-D.roll-rpl-industrial-applicability] section 2.1.3. and next 350 discusses appplication-layer paradigms, such as Source-sink (SS) that 351 is a Multipeer to Multipeer (MP2MP) model that is primarily used for 352 alarms and alerts, Publish-subscribe (PS, or pub/sub) that is 353 typically used for sensor data, as well as Peer-to-peer (P2P) and 354 Peer-to-multipeer (P2MP) communications. Additional considerations 355 on Duocast and its N-cast generalization are also provided. Those 356 paradigms are frequently used in industrial automation, which is a 357 major use case for IEEE802.15.4e TSCH wireless networks with 358 [ISA100.11a] and [HART]. 360 This specification focusses on Communication Paradigms and 361 Interaction Models for packet forwarding and TSCH resources (cells) 362 management. L ink-layer and Network-layer Packet forwarding 363 interactions are discussed in Section 6, whereas Link-layer (one- 364 hop), Network-layer (multithop along a track), and Application-layer 365 (remote control) management mechanisms for the TSCH schedule are 366 discussed in Section 8. 368 6. Forwarding Models 370 6TiSCH supports three different forwarding model, G-MPLS Track 371 Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 Forwarding 372 (6F). 374 6.1. Track Forwarding 376 Track Forwarding is the simplest and fastest. A set of input cells 377 are uniquely bound to a set of output cells, representing a 378 forwarding state that can be used regardless of the upper layer 379 protocol. This model can effectively be seen as a G-MPLS operation 380 in that the information used to switch is not an explicit label, but 381 rather related to other properties of the way the packet was 382 received, a particular cell in the case of 6TiSCH. As a result, as 383 long as the TSCH MAC (and Layer 2 security) accepts a frame, that 384 frame can be switched regardless of the protocol, whether this is an 385 IPv6 packet, a 6LoWPAN fragment, or a frame from an alternate 386 protocol such as WirelessHART of ISA100.11a. 388 A Track is defined end-to-end as a succession of timeslots. A 389 timeslot belongs to at most one Track. For a given iteration of a 390 Slotframe, the timeslot is associated uniquely with a cell, which 391 indicates the channel at which the timeslot operates for that 392 iteration. 394 A data frame that is forwarded along a Track has a destination MAC 395 address set to broadcast or a multicast address depending on MAC 396 support. This way, the MAC layer in the intermediate nodes accepts 397 the incoming frame and 6top switches it without incurring a change in 398 the MAC header. In the case of IEEE802.15.4e, this means effectively 399 broadcast, so that along the Track the short address for the 400 destination is set to 0xFFFF. 402 Conversely, a frame that is received along a Track with a destination 403 MAC address set to this node is extracted from the Track stream and 404 delivered to the upper layer. A frame with an unrecognised MAC 405 address is ignored at the MAC layer and thus is not received at the 406 6top sublayer. 408 There are 2 modes for a Track, transport mode and tunnel mode. 410 6.1.1. Transport Mode 412 In transport mode, the PDU is associated flow information that refers 413 uniquely to the Track, so the 6top sublayer can place the frame in 414 the appropriate timeslot without ambiguity. In the case of IPv6 415 traffic, flow identification is transported in the Flow Label of the 416 IPv6 header. Associated with the source IPv6 address, the flow label 417 forms a globally unique identifier for that particular Track that is 418 validated at egress before restoring the destination MAC address 419 (dmac) and punting to the upper layer. 421 | ^ 422 +--------------+ | | 423 | IPv6 | | | 424 +--------------+ | | 425 | 6LoWPAN HC | | | 426 +--------------+ ingress egress 427 | 6top | sets +----+ +----+ restores 428 +--------------+ dmac to | | | | dmac to 429 | TSCH MAC | brdcst | | | | self 430 +--------------+ | | | | | | 431 | LLN PHY | +-------+ +--...-----+ +-------+ 432 +--------------+ 434 6.1.2. Tunnel Mode 436 In tunnel mode, the frames originate from an arbitrary protocol over 437 a compatible MAC that may or may not be synchronized with the 6TiSCH 438 network. An example of this would be a router with a dual radio that 439 is capable of receiving and sending WirelessHART or ISA100.11a frames 440 with the second radio, by presenting itself as an access Point or a 441 Backbone Router, respectively. 443 In that mode, some entity (e.g. PCE) can coordinate with a 444 WirelessHART Network Manager or an ISA100.11a System Manager to 445 specify the flows that are to be transported transparently over the 446 Track. 448 +--------------+ 449 | IPv6 | 450 +--------------+ 451 | 6LoWPAN HC | 452 +--------------+ set restore 453 | 6top | +dmac+ +dmac+ 454 +--------------+ | | | | 455 | TSCH MAC | | | | | 456 +--------------+ | | | | 457 | LLN PHY | +-------+ +--...-----+ +-------+ 458 +--------------+ | ingress egress | 459 | | 460 +--------------+ | | 461 | LLN PHY | | | 462 +--------------+ | | 463 | TSCH MAC | | | 464 +--------------+ | | 465 |ISA100/WiHART | | v 466 +--------------+ 468 In that case, the flow information that identifies the Track is 469 uniquely derived from the information at the receiving end, for 470 instance the incoming timeslots, or an ISA100.11a ContractId. At the 471 ingress 6TiSCH router, the packet destination is recognized as self 472 but the flow information indicates that the frame must be tunnelled 473 over a particular 6top Track so the packet is not punted to upper 474 layer. Instead, it is passed to the 6top sublayer for switching. 475 The 6top sublayer in the ingress router overrides the destination MAC 476 to broadcast and forwards. 478 At the egress 6top router, the reverse operation occurs. Based on 479 metadata associated to the Track, the frame is passed to the 480 appropriate link layer with the destination MAC restored. 482 6.1.3. Tunnel Metadata 484 Metadata coming with the Track configuration is expected to provide 485 the destination MAC address of the egress endpoint as well as the 486 tunnel mode and specific data depending on the mode, for instance a 487 service access point for frame delivery at egress. If the tunnel 488 egress point does not have a MAC address that matches the 489 configuration, the Track installation fails. 491 In transport mode, if the final layer 3 destination is the tunnel 492 termination, then it is possible that the IPv6 address of the 493 destination is compressed at the 6LoWPAN sublayer based on the MAC 494 address. It is thus mandatory at the ingress point to validate that 495 the MAC address that was used at the 6LoWPAN sublayer for compression 496 matches that of the tunnel egress point. For that reason, the node 497 that injects a packet on a Track checks that the destination is 498 effectively that of the tunnel egress point before it overwrites it 499 to broadcast. The 6top sublayer at the tunnel egress point reverts 500 that operation to the MAC address obtained from the tunnel metadata. 502 6.2. Fragment Forwarding 504 Considering that 6LoWPAN packets can be as large as 1280 bytes (the 505 IPv6 MTU), and that the non-storing mode of RPL implies Source 506 Routing that requires space for routing headers, and that a 507 IEEE802.15.4 frame with security may carry in the order of 80 bytes 508 of effective payload, an IPv6 packet might be fragmented into more 509 than 16 fragments at the 6LoWPAN sublayer. 511 This level of fragmentation is much higher than that traditionally 512 experienced over the Internet with IPv4 fragments, where 513 fragmentation is already known as harmful. 515 In the case to a multihop route within a 6TiSCH network, Hop-by-Hop 516 recomposition occurs at each hop in order to reform the packet and 517 route it. This creates additional latency and forces intermediate 518 nodes to store a portion of a packet for an undetermined time, thus 519 impacting critical resources such as memory and battery. 521 [I-D.thubert-roll-forwarding-frags] describes a mechanism whereby the 522 datagram tag in the 6LoWPAN Fragment is used as a label for switching 523 at the 6LoWPAN sublayer. The draft allows for a degree of flow 524 control base on an Explicit Congestion Notification, as well as end- 525 to-end individual fragment recovery. 527 | ^ 528 +--------------+ | | 529 | IPv6 | | +----+ +----+ | 530 +--------------+ | | | | | | 531 | 6LoWPAN HC | | learn learn | 532 +--------------+ | | | | | | 533 | 6top | | | | | | | 534 +--------------+ | | | | | | 535 | TSCH MAC | | | | | | | 536 +--------------+ | | | | | | 537 | LLN PHY | +-------+ +--...-----+ +-------+ 538 +--------------+ 539 In that model, the first fragment is routed based on the IPv6 header 540 that is present in that fragment. The 6LoWPAN sublayer learns the 541 next hop selection, generates a new datagram tag for transmission to 542 the next hop, and stores that information indexed by the incoming MAC 543 address and datagram tag. The next fragments are then switched based 544 on that stored state. 546 | ^ 547 +--------------+ | | 548 | IPv6 | | | 549 +--------------+ | | 550 | 6LoWPAN HC | | replay replay | 551 +--------------+ | | | | | | 552 | 6top | | | | | | | 553 +--------------+ | | | | | | 554 | TSCH MAC | | | | | | | 555 +--------------+ | | | | | | 556 | LLN PHY | +-------+ +--...-----+ +-------+ 557 +--------------+ 559 A bitmap and an ECN echo in the end-to-end acknowledgement enable the 560 source to resend the missing fragments selectively. The first 561 fragment may be resent to carve a new path in case of a path failure. 562 The ECN echo set indicates that the number of outstanding fragments 563 should be reduced. 565 6.3. IPv6 Forwarding 567 As the packets are routed at layer 3, traditional QoS and RED 568 operations are expected to prioritize flows with differentiated 569 services. A new class of service for Deterministic Forwarding is 570 being defined to that effect in [I-D.svshah-tsvwg-lln-diffserv- 571 recommendations]. 573 | ^ 574 +--------------+ | | 575 | IPv6 | | +-QoS+ +-QoS+ | 576 +--------------+ | | | | | | 577 | 6LoWPAN HC | | | | | | | 578 +--------------+ | | | | | | 579 | 6top | | | | | | | 580 +--------------+ | | | | | | 581 | TSCH MAC | | | | | | | 582 +--------------+ | | | | | | 583 | LLN PHY | +-------+ +--...-----+ +-------+ 584 +--------------+ 586 7. TSCH and 6top 588 7.1. 6top 589 6top is a sublayer which is the next higher layer to TSCH and which 590 offers a set of commands defining data and management interfaces. 591 The management interface of 6top enables an upper layer to schedule 592 cells and Slotframes in the TSCH schedule. 6top is defined in [I-D 593 .wang-6tisch-6top]. 595 If the scheduling entity explicitly specifies the slotOffset/ 596 channelOffset of the cells to be added/deleted, those cells are 597 marked as "hard". 6top cannot move hard cells in the TSCH schedule. 598 Hard cells are for example used by a central PCE. 600 6top contains a monitoring process which monitors the performance of 601 cells, and can move a cell in the TSCH schedule when it performs bad. 602 This is only applicable to cells which are marked as "soft". To 603 reserve a soft cell, the higher layer does not indicate the exact 604 slotOffset/channelOffset of the cell to add, but rather the resulting 605 bandwidth and QoS requirements. When the monitoring process triggers 606 a cell reallocation, the two neighbor motes communicating over this 607 cell negotiate its new position in the TSCH schedule. 609 7.2. Network Synchronization 611 Nodes in a TSCH network must be time synchronized. A node keeps 612 synchronized to its time source neighbor through a combination of 613 frame-based and acknowledgement-based synchronization. In order to 614 maximize battery life and network throughput, it is advisable that 615 RPL ICMP discovery and maintenance traffic (governed by the trickle 616 timer) be somehow coordinated with the transmission of time 617 synchronization packets (especially with enhanced beacons). This 618 could be achieved through an interaction of the 6top sublayer and the 619 RPL objective Function, or could be controlled by a management 620 entity. 622 Time distribution requires a loop-less structure. Nodes taken in a 623 synchronization loop will rapidly desynchronize from the network and 624 become isolated. It is expected that a RPL DAG with a dedicated 625 global Instance is deployed for the purpose of time synchronization. 626 That Instance is referred to as the Time Synchronization Global 627 Instance (TSGI). The TSGI can be operated in either of the 3 modes 628 that are detailed in RPL [RFC6550] section "3.1.3. Instances, 629 DODAGs, and DODAG Versions". Multiple uncoordinated DODAGs with 630 independent roots may be used if all the roots share a common time 631 source such as the Global Positioning System (GPS). In the absence of 632 a common time source, the TSGI should form a single DODAG with a 633 virtual root. A backbone network is then used to synchronize and 634 coordinate RPL operations between the backbone routers that act as 635 sinks for the LLN. 637 A node that has not joined the TSGI advertises a MAC level Join 638 Priority of 0xFF to notify its neighbors that is is not capable of 639 serving as time parent. A node that has joined the TSGI advertises a 640 MAC level Join Priority set to its DAGRank() in that Instance, where 641 DAGRank() is the operation specified in [RFC6550], section "3.5.1. 642 Rank Comparison". 644 A root is configured or obtains by some external means the knowledge 645 of the RPLInstanceID for the TSGI. The root advertises its DagRank in 646 the TSGI, that MUST be less than 0xFF, as its Join Priority (JP) in 647 its IEEE802.15.4e Extended Beacons (EB). We'll note that the JP is 648 now specified between 0 and 0x3F leaving 2 bit sin the octet unused 649 in the IEEE802.15.4e specification. After concertation with IEEE 650 authors, it was asserted that 6TiSCH can make a full use of the octet 651 to carry an integer value up to 0xFF. 653 A node that reads a Join Priority of less than 0xFF should join the 654 neighbor with the lesser Join Priority and use it as time parent. If 655 the node is configured to serve as time parent, then the node should 656 join the TSGI, obtain a Rank in that Instance and start advertising 657 its own DagRank in the TSGI as its Join Priority in its EBs. 659 7.3. Slotframes and Priorities 661 6top uses priority queues to manage concurrent data flows of 662 different priorities. When a packet is received from an higher layer 663 for transmission, the I-MUX module of 6top inserts that packet in the 664 outgoing queue which matches the packet best (DSCP can therefore be 665 used). At each scheduled transmit slot, the MUX module looks for the 666 frame in all the outgoing queues that best matches the cells. If a 667 frame is found, it is given to TSCH for transmission. 669 7.4. Packet Marking and Handling 671 reservation Deterministic flow allocation (hard reservation of 672 timeslots) eg centralized RSVP? metrics? Hop-by-hop interaction with 673 6top. Lazy reservation (use shared slots to transport extra burst 674 and then dynamically (de)allocate) Classical QoS (dynamic based on 675 observation) 677 8. Schedule Management Mechanisms 679 6TiSCH uses 4 paradigms to manage the TSCH schedule of the LLN nodes: 680 Static Scheduling, Neighbor-to-Neighbor Scheduling, Multihop 681 Monitoring and Scheduling, and Hop-by-hop Scheduling. Multiple 682 mechanisms are proposed that implement the associated Interaction 683 Models, and can be combined and used in the same LLN. Which 684 mechanism(s) are used depends on application requirements. 686 8.1. Minimal Static Scheduling 687 A static TSCH schedule can be used to bootstrap a network, as a 688 initial phase during implementation, or as a fall-back mechanism in 689 case of network malfunction. This scheduled can be preconfigured, or 690 learnt by a node when joining the network, but it remains unchanged 691 after the node has joined a network. The Routing Protocol for LLNs 692 (RPL) is used on the resulting network. This "minimal" scheduling 693 mechanism that implements this paradigm is detailed in [I-D 694 .vilajosana-6tisch-minimal]. 696 8.2. Neighbor-to-Neighbor Scheduling 698 The 6top sublayer [I-D.wang-6tisch-6top] defines a protocol for 699 neighbor nodes to reserve soft cells to one another. Because this 700 reservation is done without global knowledge of the schedule of nodes 701 in the LLN, scheduling collisions are possible. 6top defines a 702 monitoring process which continuously tracks the packet delivery 703 ratio of soft cells. It uses these statistics to trigger the 704 relocation of a soft cell in the schedule, using a negotiation 705 protocol between the neighbors nodes communicating over that cell. 707 Monitoring and relocation is done in the 6top layer. For the upper 708 layer, the connection between two neighbor node appears as an number 709 of cells. Depending on the traffic requirements, the upper layer can 710 request 6top to add or delete a number of cells scheduled to a 711 particular neighbor, without being responsible for choosing the exact 712 slotOffset/channelOffset of those cells. 714 8.3. Remote Monitoring and Schedule Management 716 [I-D.sudhaakar-6tisch-coap] defines an mapping of 6top's set of 717 commands to CoAP resources. This allows an entity to interact with 718 the 6top layer of a node that is multiple hops away. [I-D.sudhaakar- 719 6tisch-coap] defines the CoAP resources and associated methods (GET/ 720 PUT/POST/DELETE). The payload of those signalling packets use CBOR to 721 encode the different fields sent and received. 723 Being able to interact with the 6top sublayer of a node multiple hops 724 away can be used for monitoring, scheduling, or a combination of 725 both. The architecture supports variations on the deployment model, 726 and focuses on the flows rather than the whether there is a proxy or 727 a translational operation on the way. 729 The entity issuing the CoAP requests can be a central scheduling 730 entity (e.g. a PCE), a node multiple hops away with the authority to 731 modify the TSCH schedule (e.g. the head of a local cluster), or a 732 external device monitoring the overall state of the network (e.g. 733 NME). The architecture allows for different types of interactions 734 between this CoAP client and a node in the network: 736 Query The CoAP client may retrieve information from a specific node 737 in the network. This is typically a CoAP GET request issued on 738 the appropriate resource on the node. 740 Report The CoAP client may register for periodic updates from a 741 resource, for example to monitor the state of some statistics 742 maintained by the node. This is typically done through CoAP 743 Observe. 745 Action The CoAP client may request the node to take some action, for 746 example add a cell to its TSCH schedule. This is typically a 747 CoAP PUT/POST/DELETE request issued on the appropriate resource 748 on the node. 750 Request The node may issue a request to the client to trigger some 751 action, for example the calculation of a multi-hop route. This 752 is typically a CoAP POST request issued by the node on the 753 appropriate resource on the CoAP client. 755 Event The node may indicate the occurrence of a specific event to the 756 CoAP client, for example the discovery of a new neighbor. This 757 is typically a CoAP PUT request issued by the node on the 758 appropriate resource on the CoAP client. 760 [I-D.sudhaakar-6tisch-coap] defines the a basic set of CoAP 761 resources. For cases where extra functionality is needed, the draft 762 also defines the concept of "profiles", as well as a mechanism for a 763 CoAP client to discover the profiles installed on a node. 765 8.4. Hop-by-hop Scheduling 767 A node can reserve a track to a destination node multiple hops away 768 by installing soft cells at each intermediate node. This forms a 769 track of soft cells. It is the responsibility of the 6top sublayer 770 of each node on the track to monitor these soft cells and trigger 771 reallocations when needed. 773 This hop-by-hop reservation mechanism is similar to [RFC2119] and 774 [RFC5974]. The protocol for a node to trigger hop-by-hop scheduling 775 is not defined yet. 777 9. Centralized vs. Distributed Routing 779 6TiSCH supports a mixed model of centralized routes and distributed 780 routes. Centralized routes can for example computed by a entity such 781 as a PCE. Distributed routes are computed by the RPL routing 782 protocol. 784 Both may inject routes in the Routing Tables of the 6TiSCH routers. 785 In either case, each route is associated with a topology that is 786 indexed by an RPLInstanceID, as defined in RPL [RFC6550]. RPL and 787 PCE rely on shared sources to define Global and Local RPLInstanceIDs. 789 It is possible for centralized and distributed routing to share a 790 same topology. In this case, centralizes routes have precedence over 791 distributed routes in case of a conflict. 793 Inside the 6TiSCH domain, the flow label is used to indicate the 794 topology that must be used for routing. The associated Routing 795 Tables are discussed in [I-D.thubert-roll-flow-label]. 797 10. IANA Considerations 799 This specification does not require IANA action. 801 11. Security Considerations 803 This specification is not found to introduce new security threat. 805 12. Acknowledgements 807 13. References 809 13.1. Normative References 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, March 1997. 814 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 815 6 (IPv6) Specification", RFC 2460, December 1998. 817 [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between 818 Information Models and Data Models", RFC 3444, January 819 2003. 821 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J. and S. Van den 822 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 823 4080, June 2005. 825 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 826 Architecture", RFC 4291, February 2006. 828 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 829 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 830 September 2007. 832 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless 833 Address Autoconfiguration", RFC 4862, September 2007. 835 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. 836 Yegin, "Protocol for Carrying Authentication for Network 837 Access (PANA)", RFC 5191, May 2008. 839 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 840 Hoc Networks", RFC 5889, September 2010. 842 [RFC5974] Manner, J., Karagiannis, G. and A. McDonald, "NSIS 843 Signaling Layer Protocol (NSLP) for Quality-of-Service 844 Signaling", RFC 5974, October 2010. 846 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 847 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 848 September 2011. 850 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 851 Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. 852 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 853 Lossy Networks", RFC 6550, March 2012. 855 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann, 856 "Neighbor Discovery Optimization for IPv6 over Low-Power 857 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 858 November 2012. 860 13.2. Informative References 862 [I-D.chakrabarti-nordmark-6man-efficient-nd] 863 Chakrabarti, S., Nordmark, E. and M. Wasserman, 864 "Efficiency aware IPv6 Neighbor Discovery Optimizations", 865 Internet-Draft draft-chakrabarti-nordmark-6man-efficient- 866 nd-01, November 2012. 868 [I-D.ietf-roll-rpl-industrial-applicability] 869 Phinney, T., Thubert, P. and R. Assimiti, "RPL 870 applicability in industrial networks", Internet-Draft 871 draft-ietf-roll-rpl-industrial-applicability-01, September 872 2013. 874 [I-D.ohba-6tisch-security] 875 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P. and 876 A. Yegin, "Security Framework and Key Management Protocol 877 Requirements for 6TiSCH", Internet-Draft draft-ohba- 878 6tisch-security-00, October 2013. 880 [I-D.palattella-6tisch-terminology] 881 Palattella, M., Thubert, P., Watteyne, T. and Q. Wang, 882 "Terminology in IPv6 over the TSCH mode of IEEE 883 802.15.4e", Internet-Draft draft-palattella-6tisch- 884 terminology-00, October 2013. 886 [I-D.sudhaakar-6tisch-coap] 887 Watteyne, T., "6TiSCH Data Model for CoAP", Internet-Draft 888 draft-sudhaakar-6tisch-coap-00, October 2013. 890 [I-D.svshah-tsvwg-lln-diffserv-recommendations] 891 Shah, S. and P. Thubert, "Differentiated Service Class 892 Recommendations for LLN Traffic", Internet-Draft draft- 893 svshah-tsvwg-lln-diffserv-recommendations-00, February 894 2013. 896 [I-D.thubert-6lowpan-backbone-router] 897 Thubert, P., "6LoWPAN Backbone Router", Internet-Draft 898 draft-thubert-6lowpan-backbone-router-03, February 2013. 900 [I-D.thubert-roll-flow-label] 901 Thubert, P., "Use of the IPv6 Flow Label within an LLN", 902 Internet-Draft draft-thubert-roll-flow-label-02, November 903 2012. 905 [I-D.thubert-roll-forwarding-frags] 906 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 907 Recovery", Internet-Draft draft-thubert-roll-forwarding- 908 frags-01, February 2013. 910 [I-D.vilajosana-6tisch-minimal] 911 Vilajosana, X. and K. Pister, "Minimal 6TiSCH 912 Configuration", Internet-Draft draft-vilajosana-6tisch- 913 minimal-00, October 2013. 915 [I-D.wang-6tisch-6top] 916 Wang, Q., Vilajosana, X. and T. Watteyne, "6TiSCH 917 Operation Sublayer (6top)", Internet-Draft draft-wang- 918 6tisch-6top-00, October 2013. 920 [I-D.watteyne-6tisch-tsch] 921 Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context: 922 Overview, Problem Statement and Goals", Internet-Draft 923 draft-watteyne-6tisch-tsch-00, October 2013. 925 13.3. External Informative References 927 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 928 a group of specifications for industrial process and 929 control devices administered by the HART Foundation", . 931 [IEEE802.1TSNTG] 932 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 933 Networks Task Group", March 2013, . 936 [IEEE802154e] 937 IEEE standard for Information Technology, "IEEE std. 938 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 939 Networks (LR-WPANs) Amendament 1: MAC sublayer", April 940 2012. 942 [ISA100.11a] 943 ISA, "ISA100, Wireless Systems for Automation", May 2008, 944 . 947 Authors' Addresses 948 Pascal Thubert, editor 949 Cisco Systems, Inc 950 Building D 951 45 Allee des Ormes - BP1200 952 MOUGINS - Sophia Antipolis, 06254 953 FRANCE 955 Phone: +33 497 23 26 34 956 Email: pthubert@cisco.com 958 Thomas Watteyne 959 Linear Technology, Dust Networks Product Group 960 30695 Huntwood Avenue 961 Hayward, CA 94544 962 USA 964 Phone: +1 (510) 400-2978 965 Email: twatteyne@linear.com 967 Robert Assimiti 968 Centero 969 961 Indian Hills Parkway 970 Marietta, GA 30068 971 USA 973 Phone: +1 404 461 9614 974 Email: robert.assimiti@centerotech.com