idnits 2.17.1 draft-thubert-6tsch-architecture-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 15, 2013) is 3937 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: 'HART' is mentioned on line 779, but not defined == Missing Reference: 'IEEE802.1TSNTG' is mentioned on line 783, but not defined == Unused Reference: 'RFC5974' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'I-D.ohba-6tsch-security' is defined on line 729, but no explicit reference was found in the text == Unused Reference: 'I-D.palattella-6tsch-terminology' is defined on line 735, but no explicit reference was found in the text == Unused Reference: 'I-D.svshah-tsvwg-lln-diffserv-recommendations' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 753, but no explicit reference was found in the text == Unused Reference: 'I-D.vilajosana-6tsch-basic' is defined on line 767, 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 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 (-01) exists of draft-palattella-6tsch-terminology-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 == Outdated reference: A later version (-02) exists of draft-watteyne-6tsch-tsch-lln-context-01 Summary: 4 errors (**), 0 flaws (~~), 15 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TSCH P. Thubert, Ed. 3 Internet-Draft cisco 4 Intended status: Standards Track RA. Assimiti 5 Expires: January 14, 2014 Nivis 6 T. Watteyne 7 Linear Technology / Dust Networks 8 July 15, 2013 10 An Architecture for IPv6 over Timeslotted Channel Hopping 11 draft-thubert-6tsch-architecture-02 13 Abstract 15 This document presents an architecture for an IPv6 multilink 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 January 14, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Applications and Goals . . . . . . . . . . . . . . . . . . . . 3 69 4. Overview and Scope . . . . . . . . . . . . . . . . . . . . . . 4 70 5. Centralized vs. Distributed Routing . . . . . . . . . . . . . 7 71 6. Forwarding Models . . . . . . . . . . . . . . . . . . . . . . 7 72 6.1. Track Forwarding . . . . . . . . . . . . . . . . . . . . . 7 73 6.1.1. Transport Mode . . . . . . . . . . . . . . . . . . . . 8 74 6.1.2. Tunnel Mode . . . . . . . . . . . . . . . . . . . . . 8 75 6.1.3. Tunnel Metadata . . . . . . . . . . . . . . . . . . . 9 76 6.2. Fragment Forwarding . . . . . . . . . . . . . . . . . . . 10 77 6.3. IPv6 Forwarding . . . . . . . . . . . . . . . . . . . . . 11 78 7. Functional Flows . . . . . . . . . . . . . . . . . . . . . . . 12 79 8. Network Synchronization . . . . . . . . . . . . . . . . . . . 12 80 9. TSCH and 6top . . . . . . . . . . . . . . . . . . . . . . . . 12 81 9.1. 6top . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 9.2. Slotframes and Priorities . . . . . . . . . . . . . . . . 13 83 9.3. Centralized Flow Reservation . . . . . . . . . . . . . . . 13 84 9.4. Distributed Flow Reservation . . . . . . . . . . . . . . . 13 85 9.5. Packet Marking and Handling . . . . . . . . . . . . . . . 14 86 10. Management . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 90 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 91 14.1. Normative References . . . . . . . . . . . . . . . . . . 14 92 14.2. Informative References . . . . . . . . . . . . . . . . . 15 93 14.3. External Informative References . . . . . . . . . . . . . 16 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 96 1. Introduction 97 The emergence of radio technology enabled a large variety of new 98 types of devices to be interconnected, at a very low marginal cost 99 compared to wire, at any range from Near Field to interplanetary 100 distances, and in circumstances where wiring could be less than 101 practical, for instance rotating devices. 103 At the same time, a new breed of Time Sensitive Networks is being 104 developped to enable traffic that is highly sensitive to jitter and 105 quite sensitive to latency. Such traffic is not limited to voice and 106 video, but also includes command and control operations such as found 107 in industrial automation or in-vehicule sensors and actuators. 109 At IEEE802.1, the "Audio/Video Task Group", was renamed TSN for Time 110 Sensitive Networking to address Deterministic Ethernet. The 111 IEEE802.15.4 Medium Access Control (MAC) has evolved with 112 IEEE802.15.4e that provides in particular the Timeslotted Channel 113 Hopping (TSCH) mode for industrial-type applications. 115 Though at a different time scale, both standards provide 116 Deterministic capabilities to the point that a packet that pertains 117 to a certain flow will cross the network from node to node following 118 a very precise schedule, like a train leaves intermediate stations at 119 precise times along its path. The time slotted aspect reduces 120 collisions, and saves energy, and enables to more closely engineer 121 the network for deterministic properties. The channel hopping aspect 122 is a simple and efficient technique to get around statistical 123 interference by WiFi emitters. 125 This document presents an architecture for an IPv6 multilink subnet 126 that is composed of a high speed powered backbone and a number of 127 IEEE802.15.4e TSCH wireless networks attached and synchronized by 128 backbone routers. Route Computation may be achieved in a centralized 129 fashion by a Path Computation Element (PCE), in a distributed fashion 130 using the Routing Protocol for Low Power and Lossy Networks (RPL), or 131 in a mixed mode. The Backbone Routers perform proxy Ipv6 Neighbor 132 Discovery (ND) operations over the backbone on behalf of the wireless 133 devices, so they can share a same IPv6 subnet and appear to be 134 connected to the same backbone as classical devices. 136 2. Terminology 138 The draft uses terminology defined in [I-D.palattella-6tsch- 139 terminology], [I-D.chakrabarti-nordmark-6man-efficient-nd], [RFC5191] 140 and [RFC4080]. 142 It conforms to the terms and models described for IPv6 in [RFC5889] 143 and uses the vocabulary and the concepts defined in [RFC4291] for 144 IPv6. 146 3. Applications and Goals 147 The architecture derives from existing industrial standards for 148 Process Control by its focus on Deterministic Networking, in 149 particular with the use of the IEEE802.15.4e TSCH MAC and the 150 centralized path computation element. This approach leverages the 151 TSCH MAC benefits for high reliability against interference, low- 152 power consumption on deterministic traffic, and its Traffic 153 Engineering capabilities. Deterministic Networking applies in 154 particular to open and closed control loops, as well as supervisory 155 control flows, and management. 157 Additional industrial use cases are addressed with the addition of a 158 more autonomic and distributed routing based on RPL. These use cases 159 include plant setup and decommissioning, as well as monitoring of 160 lots of lesser importance measurements such as corrosion and events. 161 RPL also enables mobile use cases such as mobile workers and cranes. 163 A Backbone Router is included in order to scale the factory plant 164 subnet to address large deployments, with proxy ND and time 165 synchronization over a high speed backbone. 167 The architecture also applies to building automation that leverage 168 RPL's storing mode to address multipath over a large number of hops, 169 in-vehicule command and control that can be as demanding as 170 industrial applications, commercial automation and asset Tracking 171 with mobile scenarios, home automation and domotics which become more 172 reliable and thus provide a better user experience, and resource 173 management (energy, water, etc.). 175 4. Overview and Scope 177 The scope of the present work is a subnet that, in its basic 178 configuration, is made of a IEEE802.15.4e Timeslotted Channel Hopping 179 (TSCH) [I-D.watteyne-6tsch-tsch-lln-context] MAC Route-Over Low Power 180 Lossy Network (LLN). 182 +-----+ 183 | | LLN Border 184 | | router 185 +-----+ 186 o o o 187 o o o o 188 o o LLN o o o 189 o o o o 190 o 192 The LLN devices communicate over IPv6 [RFC2460] using the 6LoWPAN 193 Header Compression (6LoWPAN HC) [RFC6282]. From the Layer 3 194 perspective, a single LLN interface (typically an IEEE802.15.4 radio) 195 may be seen as a collection of Links with different capabilities for 196 unicast or multicast services. An IPv6 subnet will span over 197 multiple links, effectively forming a multilink subnet. Within that 198 subnet, Neighbor Devices are discovered with 6LoWPAN Neighbor 199 Discovery (6LoWPAN ND) [RFC6775]. The Routing Protocol for Low Power 200 and Lossy Networks (RPL) [RFC6550] enables routing within the LLN, 201 typically within the multilink subnet in the so called Routing Over 202 fashion. RPL forms Destination Oriented Directed Acyclic Graphs 203 (DODAGs) within instances of the protocol, each instance being 204 associated with an Objective Function (OF) to form a routing 205 topology. A particular LLN device, usually powered, acts as RPL 206 root, 6LoWPAN HC terminator, and LLN Border Router (LBR) to the 207 outside. 209 An extended configuration of the subnet comprises multiple LLNs. The 210 LLNs are interconnected and synchronized over a backbone, that can be 211 wired or wireless. The backbone can be a classical IPv6 network, 212 with Neighbor Discovery operating as defined in [RFC4861] and 213 [RFC4862]. The backbone can also support Efficiency aware IPv6 214 Neighbor Discovery Optimizations [I-D.chakrabarti-nordmark-6man- 215 efficient-nd] in mixed mode as described in [I-D.thubert-6lowpan- 216 backbone-router]. 218 Security is often handled at layer 2 and Layer 4. Authentication 219 during the join process is handled with the Protocol for Carrying 220 Authentication for Network Access (PANA) [RFC5191]. 222 The LLN devices are time-synchronized at MAC level. The MAC 223 coordinator that serves as time source is loosely coupled with the 224 RPL parent; this way, the time synchronization starts at the RPL root 225 and follows the RPL DODAGs with no timing loop. 227 In the extended configuration, the functionality of the LBR is 228 enhanced to that of Backbone Router (BBR). A BBR is an LBR, but also 229 an Energy Aware Default Router (NEAR) as defined in [I-D.chakrabarti- 230 nordmark-6man-efficient-nd]. The BBR performs ND proxy operations 231 between the registered devices and the classical ND devices that are 232 located over the backbone. 6TSCH BBRs synchronize with one another 233 over the backbone, so as to ensure that the multiple LLNs that form 234 the IPv6 subnet stay tightly synchronized. If the Backbone is 235 Deterministic (such as defined by the Time Sensitive Networking WG at 236 IEEE), then the Backbone Router ensures that the end-to-end 237 deterministic behavior is maintained between the LLN and the 238 backbone. 240 ---+------------------------ 241 | External Network 242 | 243 +-----+ +-----+ 244 | | Router | | PCE 245 | | | | 246 +-----+ +-----+ 247 | | 248 | Subnet Backbone | 249 +--------------------+------------------+ 250 | | | 251 +-----+ +-----+ +-----+ 252 | | Backbone | | Backbone | | Backbone 253 o | | router | | router | | router 254 +-----+ +-----+ +-----+ 255 o o o o o 256 o o o o o o o o o o o 257 o o o LLN o o o o 258 o o o o o o o o o o o o 260 The main architectural blocks are arranged as follows: 262 +-----+-----+-----+-----+-------+-----+ 263 |PCEP | CoAP |PANA |6LoWPAN| RPL | 264 | PCC |DTLS | | | ND | | 265 +-----+-----+-----+-----+-------+-----+-----+ 266 | TCP | UDP | ICMP |RSVP | 267 +-----+-----+-----+-----+-------+-----+-----+ 268 | IPv6 | 269 +-------------------------------------------+ 270 | 6LoWPAN HC | 271 +-------------------------------------------+ 272 | 6top | 273 +-------------------------------------------+ 274 | 802.15.4e TSCH | 275 +-------------------------------------------+ 277 RPL is the routing protocol of choice for LLNs. (TBD RPL) whether 278 there is a need to define a 6TSCH OF. 280 (tbd NME) COMAN is working on network Management for LLN. They are 281 considering the Open Mobile Alliance (OMA) Lightweight M2M (LWM2M) 282 Objet system. This standard includes DTLS, CoAP (core plus the Block 283 and Observe patterns), SenML and CoAP Resource Directory. 285 (tbd PCC) need to work with PCE WG to define flows to PCE, and define 286 how to accomodate PCE routes and reservation. Will probably look a 287 lot like GMPLS 289 (tbd Backbone Router) need to work with 6MAN to define ND proxy. 290 Also need BBR sync sync between deterministic ethernet and 6TSCH 291 LLNs. 293 IEEE802.1TSN: external, maintain consistency. 295 IEEE802.15.4: external, (tbd need updates?). 297 ISA100.20 Common Network Management: external, maintain consistency. 299 IoT6 European Project: external, maintain consistency. 301 5. Centralized vs. Distributed Routing 303 6TSCH supports a mix model of centralized routes that are computed by 304 a Path Computation Entity and distributed routes that are computed by 305 RPL over a common physical LLN. 307 Both RPL and the PCE may inject routes in the Routing Tables of the 308 6TSCH routers. In either case, each route is associated with a 309 topology that is indexed by an instanceID, as defined in RPL 310 [RFC6550]. RPL and PCE rely on shared sources to define Global and 311 Local InstanceIDs. 313 It is possible for RPL and PCE to share a same topology, in which 314 case the PCE routes have precedence over RPL routes in case of a 315 conflict. 317 Inside the 6TSCH domain, the flow label is used to indicate the 318 topology that must be used for routing and the associated Routing 319 Tables as discussed in [I-D.thubert-roll-flow-label]. 321 6. Forwarding Models 323 6TSCH supports three different forwarding model, G-MPLS Track 324 Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and IPv6 Forwarding 325 (6F). 327 6.1. Track Forwarding 329 Track Forwarding is the simplest and fastest. A set of input cells 330 are uniquely bound to a set of output cells, representing a 331 forwarding state that can be used regardless of the uppoer layer 332 protocol. This model can effectively be seen as a G-MPLS operation 333 in that the information used to switch is not an explicit label but 334 related to other properties of the way the packet was received, a 335 particular cell in the case of 6TSCH. As a result, as long as the 336 TSCH MAC (and Layer 2 security) accepts a frame, that frame can be 337 switched regardless of the protocol, whether this is an IPv6 packet, 338 a 6LoWPAN fragment, or a frame from an alternate protocol such as 339 WirelessHART of ISA100.11a. 341 A Track is defined end-to-end as a succession of Timeslots and a 342 Timeslot belongs to at most one Track. For a given iteration of a 343 Slotframe, the Timeslot is associated uniquely with a cell which 344 indicates the channel at which the Timeslot operates for that 345 iteration. 347 A frame that is forwarded along a Track has a destination MAC address 348 set to broadcast or a multicast address depending on the MAC support. 349 This way, the MAC layer in the intermediate nodes will accept the 350 incoming frame and 6top will switch it without incurring a change in 351 the MAC header. In the case of 802.15.4e, this means effectively 352 broadcast, so that along the Track the short address for the 353 destination is set to 0xFFFF. 355 Conversely, a frame that is received along a Track with a destination 356 MAC address set to this node is extracted from the Track stream and 357 delivered to the upper layer. A frame with an unrecognized MAC 358 address is just ignored at the MAC layer and thus is not received at 359 the 6top sublayer. 361 There are 2 modes for a Track, transport mode and tunnel mode. 363 6.1.1. Transport Mode 365 | ^ 366 +--------------+ | | 367 | IPv6 | | | 368 +--------------+ | | 369 | 6LoWPAN HC | | | 370 +--------------+ ingress egress 371 | 6top | sets +----+ +----+ restores 372 +--------------+ dmac to | | | | dmac to 373 | TSCH MAC | brdcst | | | | self 374 +--------------+ | | | | | | 375 | LLN PHY | +-------+ +--...-----+ +-------+ 376 +--------------+ 378 In transport mode, the PDU is associated with flow information that 379 refers uniquely to the Track, so the 6top sublayer can place the 380 frame in the appropriate Timeslot without ambiguity. In the case of 381 IPv6 traffic, the identification of that flow information is 382 transported in the Flow Label in the IPv6 header. Associated with 383 the source IPv6 address, the flow label forms a globally unique 384 identifier for that particular Track that is validated at egress 385 before restoring the dmac and punting to the upper layer. 387 6.1.2. Tunnel Mode 388 In tunnel mode, the frames originate from an arbitrary protocol over 389 a compatible MAC that may or may not be perfectly synchronized with 390 the 6TSCH network. An example of this would be a router with a dual 391 radio that is capable to receive and send WirelessHART or ISA100.11a 392 frames with the second radio, by presenting itself as an Access Point 393 or a Backbone Router, respectively. 395 In that mode, the PCE may coordinate with a WirelessHART Network 396 Manager or an ISA100.11a System Manager in order to specify the flows 397 that are to be transported transparently over the Track. 399 +--------------+ 400 | IPv6 | 401 +--------------+ 402 | 6LoWPAN HC | 403 +--------------+ set restore 404 | 6top | +dmac+ +dmac+ 405 +--------------+ | | | | 406 | TSCH MAC | | | | | 407 +--------------+ | | | | 408 | LLN PHY | +-------+ +--...-----+ +-------+ 409 +--------------+ | ingress egress | 410 | | 411 +--------------+ | | 412 | LLN PHY | | | 413 +--------------+ | | 414 | TSCH MAC | | | 415 +--------------+ | | 416 |ISA100/WiHART | | v 417 +--------------+ 419 In that case, the flow information that identifies the Track is 420 uniquely derived from the information at the receiving end, for 421 instance the incoming Timeslots, or an ISA100.11a ContractId. At the 422 ingress 6TSCH router, the packet destination is recognized as self 423 but the flow information indicates that the frame must be tunneled 424 over a particular 6top Track so the packet is not punted to upper 425 layer. Instead, it is passed to the 6top sublayer for switching. 426 The 6top sublayer in the ingress router overrides the destination MAC 427 to broadcast and forwards. 429 At the egress 6top router, the reverse operation occurs. Based on 430 metadata associated to the Track, the frame is passed to the 431 appropriate link layer with the destination MAC restored. 433 6.1.3. Tunnel Metadata 435 Metadata coming with the Track configuration is expected to provide 436 the destination MAC address of the egress endpoint as well as the 437 tunnel mode and specific data depending on the mode, for instance a 438 service acces point for frame delivery at egress. 440 If the tunnel egress point does not have a MAC address that matches 441 the configuration, the Track installation fails. 443 In transport mode, if the final layer 3 destination is the tunnel 444 termination, then it is possible that the IPv6 address of the 445 destination is compressed at the 6LoWPAN sublayer based on the MAC 446 address. It is thus mandatory at the ingress point to validate that 447 the MAC address that was used at the 6LoWPAN sublayer for compression 448 matches that of the tunnel egress point. For that reason, the node 449 that injects a packet on a Track checks that the destination is 450 effectively that of the tunnel egress point before it overwrites it 451 to broadcast. The 6top sublayer at the tunnel egress point reverts 452 that operation to the MAC address obtained from the tunnel metadata. 454 6.2. Fragment Forwarding 456 Considering that 6LoWPAN packets can be as large as 1280 bytes, which 457 is the IPv6 MTU, and that the non-storing mode of RPL implies Source 458 Routing that requires space for routing headers, and that a 802.15.4 459 frame with security may carry in the order of 80 bytes of effective 460 payload, an IPv6 packet might be fragmented into more than 16 461 fragments at the 6LoWPAN sublayer. 463 This level of fragmentation is much higher than that traditionally 464 experienced over the Internet with IPv4 fragments, where 465 fragmentation is already known as harmful. 467 In the case to a multihop route within a 6TSCH network, Hop-by-Hop 468 recomposition would occur at each hop in order to reform the packet 469 and route it. This creates additional latency and forces 470 intermediate nodes to store a portion of a packet for an indetermined 471 time, thus impacting critical resources such as memory and battery. 473 [I-D.thubert-roll-forwarding-frags] describes a mechanism whereby the 474 datagram tag in the 6LoWPAN Fragment is used as a label for switching 475 at the 6LoWPAN sublayer. The draft allows for a degree of flow 476 control base on an Explicit Congestion Notification, as well as end- 477 to-end individual fragment recovery. In that model, the first 478 fragment is routed based on the IPv6 header that is present in that 479 fragment. 481 | ^ 482 +--------------+ | | 483 | IPv6 | | +----+ +----+ | 484 +--------------+ | | | | | | 485 | 6LoWPAN HC | | learn learn | 486 +--------------+ | | | | | | 487 | 6top | | | | | | | 488 +--------------+ | | | | | | 489 | TSCH MAC | | | | | | | 490 +--------------+ | | | | | | 491 | LLN PHY | +-------+ +--...-----+ +-------+ 492 +--------------+ 494 The 6LoWPAN sublayer learns the next hop selection, generates a new 495 datagram tag for transmission to the next hop, and stores that 496 information indexed by the incoming MAC address and datagram tag. 497 The next fragments are then switched based on that stored state. 499 | ^ 500 +--------------+ | | 501 | IPv6 | | | 502 +--------------+ | | 503 | 6LoWPAN HC | | replay replay | 504 +--------------+ | | | | | | 505 | 6top | | | | | | | 506 +--------------+ | | | | | | 507 | TSCH MAC | | | | | | | 508 +--------------+ | | | | | | 509 | LLN PHY | +-------+ +--...-----+ +-------+ 510 +--------------+ 512 A bitmap and an ECN echo in the end-to-end acknowledgement enable the 513 source to resend the missing fragments selectively. The first 514 fragment may be resent to carve a new path in case of a path failure. 515 The ECN echo set indicates that the number of outstanding fragments 516 should be reduced. 518 6.3. IPv6 Forwarding 520 As the packets are routed at layer 3, traditional QoS and RED 521 operations are expected to prioritize flows with differentiated 522 services. A new class of service for Deterministic Forwarding is 523 being defined to that effect in [I-D.svshah-tsvwg-lln-diffserv- 524 recommendations]. 526 | ^ 527 +--------------+ | | 528 | IPv6 | | +-QoS+ +-QoS+ | 529 +--------------+ | | | | | | 530 | 6LoWPAN HC | | | | | | | 531 +--------------+ | | | | | | 532 | 6top | | | | | | | 533 +--------------+ | | | | | | 534 | TSCH MAC | | | | | | | 535 +--------------+ | | | | | | 536 | LLN PHY | +-------+ +--...-----+ +-------+ 537 +--------------+ 539 7. Functional Flows 541 8. Network Synchronization 543 Nodes in a TSCH are time synchronized. A node keeps synchronized to 544 its time source neighbor(s) through a combination of frame-based and 545 acknowledgment-based synchronization. In order to maximize battery 546 life and network throughput, it is advisable that RPL ICMP discovery 547 and maintenance traffic (governed by the trickle timer) be somehow 548 coordinated with the transmission of time synch packets (especially 549 with enhanced beacons). This could be achieved through an 550 interaction of the 6top sublayer and the RPL objective Function, or 551 could be controlled by the Device Management Entity. 553 9. TSCH and 6top 555 9.1. 6top 557 6top is a sublayer which is the next higher layer to TSCH and which 558 offers a set of commands defining data and management interfaces. 559 6top is defined in [I-D.draft-wang-6tsch-6top] 561 The management interface of 6top enables an upper layer to schedule 562 cells and Slotframes in the TSCH schedule. 564 If the scheduling entity explicitly specifies the slotOffset/ 565 channelOffset of the cells to be added/deleted, those cells are 566 marked as "hard". 6top cannot move hard cells in the TSCH schedule. 567 Hard cells are typically used by an central PCE. 569 6top contains a monitoring process which monitors the performance of 570 cells, and can move a cell in the TSCH schedule when it performs bad. 571 This is only applicable to cells which are marked as "soft". To 572 reserve a soft cell, the higher layer does not indicate the 573 slotOffset/channelOffset of the cell to add, but rather the resulting 574 bandwidth and QoS requirements. When the monitoring process triggers 575 a cell reallocation, the two neighbor motes communicating over this 576 cell negociate its new position in the TSCH schedule. 578 9.2. Slotframes and Priorities 580 6top uses priority queues to manage concurrent data flows of 581 different priorities. When a packet is received from an higher layer 582 for transmission, the I-MUX module of 6top inserts that packet in the 583 outgoing queue which matches the packet best (DSCP can therefore be 584 used). At each scheduled transmit slot, the MUX module looks for the 585 frame in all the outgoing queues that best matches the cells. If a 586 frame is found, it is given to TSCH for transmission. 588 9.3. Centralized Flow Reservation 590 In a centralized setting, a PCE computes the TSCH schedule, and 591 communicates with the different nodes in the network to configure 592 their TSCH schedule. Since it has full knowledge of the network's 593 topology, the PCE can compute a collision-free schedule, which 594 results in a high degree of communication determinism. 596 The protocol for the PCE to communicate with the motes is not yet 597 defined. This protocol typically reserves hard cells on the 598 transmitter side of a dedicated cell, and the negociation protocol of 599 6top takes care of reserving the same cell on the receiver node. 601 9.4. Distributed Flow Reservation 603 In a distributed setting, no central PCE in present in the network. 604 Nodes use 6top to reserve soft cells with their neighbors. Since no 605 node has full knowledge of the network's topology and the traffic 606 requirements, scheduling collisions are possible, for example because 607 of a hidden terminal problem. 609 A schedule collision can be detected if two motes have multiple 610 dedicated cells schedule to one another. The monitoring process of 611 6top can be configured to continuously compute the packet delivery 612 ratio of those cells, and it can declare a soft cell to perform bad 613 when the statistics for that cell are significantly worse than for 614 the other cells to the same neighbor. 616 When this happens, the monitoring process of 6top moves the cell to 617 another location in the 6TSCH schedule, through a re-negociation 618 procedure with the neighbor. 620 The entity that builds and maintains the schedule in a distributed 621 fashion is not yet defined. 623 9.5. Packet Marking and Handling 625 ---+---------------- 626 Sender Receiver 627 +-----------+ +----+ +----+ +----+ +-----------+ 628 |Application|---->| R1 |---->| R2 |----->|BBR |----->|Application| 629 | +--+ | |+--+| |+--+| |+--+| | +--+ | 630 | |NE|====|=====||NE||=====||NE||======||NE||======|===|NE| | 631 | +--+ | |+--+| |+--+| |+--+| | +--+ | 632 | |^ | | |^ | | |^ | | |^ | | |^ | 633 | v| | | v| | | v| | | v| | | v| | 634 | +--+ | |+--+| |+--+| |+--+| | +--+ | 635 | |6T| | ||6T|| ||6T|| ||6T|| | |6T| | 636 | |us| | ||us|| ||us|| ||us|| | |us| | 637 | +--+ | |+--+| |+--+| |+--+| | +--+ | 638 +-----------+ +----+ +----+ +----+ +-----------+ 640 +--+ 641 |NE| = NSIS ==== = Signaling ---> = Data flow messages 642 +--+ Entity Messages (unidirectional) 644 +--+ 645 |6T| 6top layer 646 |us| (and IEEE802.15.4e TSCH MAC below) 647 +--+ 649 reservation Deterministic flow allocation (hard reservation of 650 Timeslots) eg centralized RSVP? metrics? Hop-by-hop interaction with 651 6top. Lazy reservation (use shared slots to transport extra burst 652 and then dynamically (de)allocate) Classical QoS (dynamic based on 653 observation) 655 10. Management 657 11. IANA Considerations 659 This specification does not require IANA action. 661 12. Security Considerations 663 This specification is not found to introduce new security threat. 665 13. Acknowledgements 667 14. References 669 14.1. Normative References 671 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 672 Requirement Levels", BCP 14, RFC 2119, March 1997. 674 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 675 6 (IPv6) Specification", RFC 2460, December 1998. 677 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J. and S. Van den 678 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 679 4080, June 2005. 681 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 682 Architecture", RFC 4291, February 2006. 684 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 685 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 686 September 2007. 688 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless 689 Address Autoconfiguration", RFC 4862, September 2007. 691 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. 692 Yegin, "Protocol for Carrying Authentication for Network 693 Access (PANA)", RFC 5191, May 2008. 695 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 696 Hoc Networks", RFC 5889, September 2010. 698 [RFC5974] Manner, J., Karagiannis, G. and A. McDonald, "NSIS 699 Signaling Layer Protocol (NSLP) for Quality-of-Service 700 Signaling", RFC 5974, October 2010. 702 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 703 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 704 September 2011. 706 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 707 Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. 708 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 709 Lossy Networks", RFC 6550, March 2012. 711 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann, 712 "Neighbor Discovery Optimization for IPv6 over Low-Power 713 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 714 November 2012. 716 14.2. Informative References 718 [I-D.chakrabarti-nordmark-6man-efficient-nd] 719 Chakrabarti, S., Nordmark, E. and M. Wasserman, 720 "Efficiency aware IPv6 Neighbor Discovery Optimizations", 721 Internet-Draft draft-chakrabarti-nordmark-6man-efficient- 722 nd-01, November 2012. 724 [I-D.draft-wang-6tsch-6top] 725 Wang, Q., Ed., Vilajosana, X. and T. Watteyne, "6TSCH 726 Operation Sublayer (6top). draft-wang-6tsch-6top-00 (work 727 in progress) ", July 2013. 729 [I-D.ohba-6tsch-security] 730 Chasko, S., Das, S., Lopez, R., Ohba, Y., Thubert, P. and 731 A. Yegin, "Security Framework and Key Management Protocol 732 Requirements for 6TSCH", Internet-Draft draft-ohba-6tsch- 733 security-01, July 2013. 735 [I-D.palattella-6tsch-terminology] 736 Palattella, M., Thubert, P., Watteyne, T. and Q. Wang, 737 "Terminology in IPv6 over Time Slotted Channel Hopping", 738 Internet-Draft draft-palattella-6tsch-terminology-00, 739 March 2013. 741 [I-D.svshah-tsvwg-lln-diffserv-recommendations] 742 Shah, S. and P. Thubert, "Differentiated Service Class 743 Recommendations for LLN Traffic", Internet-Draft draft- 744 svshah-tsvwg-lln-diffserv-recommendations-00, February 745 2013. 747 [I-D.svshah-tsvwg-lln-diffserv-recommendations] 748 Shah, S. and P. Thubert, "Differentiated Service Class 749 Recommendations for LLN Traffic", Internet-Draft draft- 750 svshah-tsvwg-lln-diffserv-recommendations-00, February 751 2013. 753 [I-D.thubert-6lowpan-backbone-router] 754 Thubert, P., "6LoWPAN Backbone Router", Internet-Draft 755 draft-thubert-6lowpan-backbone-router-03, February 2013. 757 [I-D.thubert-roll-flow-label] 758 Thubert, P., "Use of the IPv6 Flow Label within an LLN", 759 Internet-Draft draft-thubert-roll-flow-label-02, November 760 2012. 762 [I-D.thubert-roll-forwarding-frags] 763 Thubert, P. and J. Hui, "LLN Fragment Forwarding and 764 Recovery", Internet-Draft draft-thubert-roll-forwarding- 765 frags-01, February 2013. 767 [I-D.vilajosana-6tsch-basic] 768 Vilajosana, X. and K. Pister, "Minimal 6TSCH 769 Configuration", Internet-Draft draft-vilajosana-6tsch- 770 basic-01, July 2013. 772 [I-D.watteyne-6tsch-tsch-lln-context] 773 Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context: 774 Overview, Problem Statement and Goals", Internet-Draft 775 draft-watteyne-6tsch-tsch-lln-context-01, February 2013. 777 14.3. External Informative References 779 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 780 a group of specifications for industrial process and 781 control devices administered by the HART Foundation", . 783 [IEEE802.1TSNTG] 784 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 785 Networks Task Group", March 2013, . 788 [ISA100.11a] 789 ISA, "ISA100, Wireless Systems for Automation", May 2008, 790 . 793 Authors' Addresses 795 Pascal Thubert, editor 796 Cisco Systems, Inc 797 Building D 798 45 Allee des Ormes - BP1200 799 MOUGINS - Sophia Antipolis, 06254 800 FRANCE 802 Phone: +33 497 23 26 34 803 Email: pthubert@cisco.com 805 Robert Assimiti 806 Nivis 807 1000 Circle 75 Parkway SE, Ste 300 808 Atlanta, GA 30339 809 USA 811 Phone: +1 678 202 6859 812 Email: robert.assimiti@nivis.com 814 Thomas Watteyne 815 Linear Technology / Dust Networks 816 30695 Huntwood Avenue 817 Hayward, CA 94544 818 USA 820 Phone: +1 (510) 400-2978 821 Email: twatteyne@linear.com