idnits 2.17.1 draft-thubert-6tsch-architecture-00.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 (March 11, 2013) is 4063 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 479, but not defined == Missing Reference: 'IEEE802.1TSNTG' is mentioned on line 483, but not defined == Unused Reference: 'RFC5974' is defined on line 423, but no explicit reference was found in the text == Unused Reference: 'I-D.svshah-tsvwg-lln-diffserv-recommendations' is defined on line 460, 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-wang-6tsch-6tus-00 == 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-watteyne-6tsch-tsch-lln-context-01 Summary: 4 errors (**), 0 flaws (~~), 11 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: September 12, 2013 Nivis 6 T. Watteyne 7 Linear Technology / Dust Networks 8 March 11, 2013 10 An Architecture for IPv6 over Time Synchronized Channel Hopping 11 draft-thubert-6tsch-architecture-00 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 September 12, 2013. 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 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Overview and Scope . . . . . . . . . . . . . . . . . . . . . 3 70 4. Centralized vs. Distributed Routing . . . . . . . . . . . . . 6 71 5. Functional Flows . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Network Synchronization . . . . . . . . . . . . . . . . . . . 6 73 7. TSCH and 6TUS . . . . . . . . . . . . . . . . . . . . . . . . 6 74 7.1. 6tus . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 7.2. Slotframes and Priorities . . . . . . . . . . . . . . . . 7 76 7.3. Centralized Flow Reservation . . . . . . . . . . . . . . 7 77 7.4. Distributed Flow Reservation . . . . . . . . . . . . . . 7 78 7.5. Packet Marking and Handling . . . . . . . . . . . . . . . 8 79 8. Management . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 85 12.2. Informative References . . . . . . . . . . . . . . . . . 10 86 12.3. External Informative References . . . . . . . . . . . . 11 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Introduction 91 A new breed of Time Sensitive Networks is being developped to enable 92 traffic that is highly sensitive to jitter and quite sensitive to 93 latency. Such traffic is not limited to voice and video, but also 94 includes command and control operations such as found in industrial 95 automation or in-vehicule sensors and actuators. 97 At IEEE802.1, the "Audio/Video Task Group", was rename TSN for Time 98 Sensitive Networking. The IEEE802.15.4 Medium Access Control (MAC) 99 has evolved with IEEE802.15.4e which provides in particular the Time 100 Synchronized Channel Hopping (TSCH) mode for industrial-type 101 applications. Both provide Deterministic capabities to the point 102 that a packet that pertains to a certain flow will cross the network 103 from node to node following a very precise schedule, like a train 104 leaves intermediate stations at precise times along its path. The 105 time slotted aspect reduce collisions, and saves energy. The channel 106 hopping aspect is a simple and efficient technique to get around 107 statistical interference by WIFI emitters. 109 This document presents an architecture for an IPv6 multilink subnet 110 that is composed of a high speed powered backbone and a number of 111 IEEE802.15.4e TSCH wireless networks attached and synchronized by 112 backbone routers. Route Computation may be achieved in a centralized 113 fashion by a Path Computation Element (PCE), in a distributed fashion 114 using the Routing Protocol for Low Power and Lossy Networks (RPL), or 115 in a mixed mode. The Backbone Routers perform proxy Ipv6 Neighbor 116 Discovery (ND) operations over the backbone on behalf of the wireless 117 device, so they can share a same IPv6 subnet and appear to be 118 connected to the same backbone as classical devices. 120 2. Terminology 122 The draft uses terminology defined in 123 [I-D.palattella-6tsch-terminology], 124 [I-D.chakrabarti-nordmark-6man-efficient-nd], [RFC5191] and 125 [RFC4080]. 127 It conforms to the terms and models described for IPv6 in [RFC5889] 128 and uses the vocabulary and the concepts defined in [RFC4291] for 129 IPv6. 131 3. Overview and Scope 133 The scope of the present work is a subnet that, in its basic 134 configuration, is made of a IEEE802.15.4e Time Synchronized Channel 135 Hopping (TSCH) [I-D.watteyne-6tsch-tsch-lln-context] MAC Route-Over 136 Low Power Lossy Network (LLN). 138 +-----+ 139 | | LLN Border 140 | | router 141 +-----+ 142 o o o 143 o o o o 144 o o LLN o o o 145 o o o o 146 o 148 Figure 1: Basic Configuration 150 The LLN devices communicate over IPv6 [RFC2460] using the 6LoWPAN 151 Header Compression (6LoWPAN HC) [RFC6282]. Neighbor Devices are 152 discovered with 6LoWPAN Neighbor Discovery (6LoWPAN ND) [RFC6775] and 153 the Routing Protocol for Low Power and Lossy Networks (RPL) [RFC6550] 154 enables routing within the LLN. RPL forms Destination Oriented 155 Directed Acyclic Graphs (DODAGs) within instances of the protocol, 156 each instance being associated with an Objective Function (OF) to 157 form a routing topology. A particular LLN device, usually powered, 158 acts as RPL root, 6LoWPAN HC terminator, and LLN Border Router (LBR) 159 to the outside. 161 An extended configuration of the subnet comprises multiple LLNs. The 162 LLNs are interconnected and synchronized over a backbone, that can be 163 wired or wireless. The backbone can be a classical IPv6 network, 164 with Neighbor Discovery operating as defined in [RFC4861] and 165 [RFC4862]. The backbone can also support Efficiency aware IPv6 166 Neighbor Discovery Optimizations 167 [I-D.chakrabarti-nordmark-6man-efficient-nd] in mixed mode as 168 described in [I-D.thubert-6lowpan-backbone-router]. 170 Security is often handled at layer 2 and Layer 4. Authentication 171 during the join process is handled with the Protocol for Carrying 172 Authentication for Network Access (PANA) [RFC5191]. 174 The LLN devices are time-synchronized at MAC level. The MAC 175 coordinator that serves as time source through Enhanced Beacons (EB) 176 is loosely coupled with the RPL parent; this way, the time 177 synchronization starts at the RPL root and follows the RPL DODAGs 178 with no timing loop. 180 In the extended configuration, the functionality of the LBR is 181 enhanced to that of Backbone Router (BBR). A BBR is an LBR, but also 182 an Energy Aware Default Router (NEAR) as defined in 183 [I-D.chakrabarti-nordmark-6man-efficient-nd]. The BBR performs ND 184 proxy operations between the registered devices and the classical ND 185 devices that are located over the backbone. 6TSCH BBRs synchronize 186 with one another over the backbone, so as to ensure that the multiple 187 LLNs that form the IPv6 subnet stay tightly synchronized. If the 188 Backbone is Deterministic (such as defined by the Time Sensitive 189 Networking WG at IEEE), then the Backbone Router ensures that the 190 end-to-end deterministic behavior is maintained between the LLN and 191 the backbone. 193 ---+------------------------ 194 | External Network 195 | 196 +-----+ +-----+ 197 | | Router | | PCE 198 | | | | 199 +-----+ +-----+ 200 | | 201 | Subnet Backbone | 202 +--------------------+------------------+ 203 | | | 204 +-----+ +-----+ +-----+ 205 | | Backbone | | Backbone | | Backbone 206 o | | router | | router | | router 207 +-----+ +-----+ +-----+ 208 o o o o o 209 o o o o o o o o o o o 210 o o o LLN o o o o 211 o o o o o o o o o o o o 213 Figure 2: Extended Configuration 215 The main architactural blocks are arranged as follows: 217 +-----+-----+-----+-----+-----+--------+ 218 |PANA | RPL |RSVP | PCE | IP | 219 | | |/NSIS| /CNM|/ FORWARDING | 220 +-----+-----+-----+-----+--------+-----+-------+ 221 | 6LoWPAN | 6LoWPAN ND | 222 | HC +-------------+ 223 | | 224 +----------------------------------------------+ 225 | 6TUS | 226 +----------------------------------------------+ 227 | 802.15.4e TSCH | 228 +----------------------------------------------+ 230 Figure 3: 6TSCH stack 232 RPL is the routing protocol of choice. TBD whether there is a need 233 to define a 6TSCH OF. 235 PCE => group needs to work with PCE WG to define flows to PCE, and 236 define how to accomodate PCE routes and reservation. 238 BBR => group needs to work woth 6MAN to define ND proxy. Also need 239 BBR sync, time sync between deterministic ethernet and 6TSCH net. 241 IEEE802.1TSN => external, maintain liaison. 243 IEEE802.15.4 => external, maintain liaison. 245 ISA100.20 Common Network Management (CNM) => external, maintain 246 liaison. 248 IoT6 => external, maintain liaison. 250 4. Centralized vs. Distributed Routing 252 5. Functional Flows 254 6. Network Synchronization 256 The mechanism(s) used for time synchronization is something that we 257 might have to reconcile with RPL discovery and maintenance traffic. 259 Time synchronization in TSCH is based on three mechanisms: 261 Enhanced Beacons 263 Enhanced ACKs 265 Frame based synchronization 267 If a node communicates intermittently (sleepy, battery operated) it 268 can also proactively ping its time source and receive time stamps. 269 In order to maximize battery life and network throughput, it is 270 advisable that RPL ICMP discovery and maintenance traffic (governed 271 by the trickle timer) be somehow coordinated with the transmission of 272 time synch packets (especially with enhanced beacons). This could be 273 a function of the shim layer or it could be deferred to the device 274 management entity. Any suggestions, ideas on this topic? 276 7. TSCH and 6TUS 278 7.1. 6tus 280 6tus is an adaptation layer which is the next higher layer to TSCH 281 and which offers a set of commands defining a data and management 282 interface. 6tus is defines in [I-D.draft-wang-6tsch-6tus] 284 The management interface of 6tus enables an upper layer to schedule 285 cells and slotframes in the TSCH schedule. 287 If the scheduling entity explicitly specifies the slotOffset/ 288 channelOffset of the cells to be added/deleted, those cells are 289 marked as "hard". 6tus can not move hard cells in the TSCH schedule. 290 Hard cells are typically used by an central PCE. 292 6tus contains a monitoring process which monitors the performance of 293 cells, and can move a cell in the TSCH schedule when it performs bad. 294 This is only applicable to cells which are marked as "soft". To 295 reserve a soft cell, the higher layer does not indicate the 296 slotOffset/channelOffset of the cell to add, but rather the resulting 297 bandwidth and QoS requirements. When the monitoring process triggers 298 an cell reallocation, the two neighbor motes communication over this 299 cells negociate the new position in the TSCH schedule of this cell. 301 7.2. Slotframes and Priorities 303 6tus uses priority queues to manage concurrent data flows of 304 different prioroties. When a packet is received from an higher layer 305 for transmission, the I-MUX module of 6tus inserts that packet in the 306 outgoing queue which matches the packet best (DSCP can therefore be 307 used). At each schedule transmit slot, the MUX module looks for the 308 frame in all the outgoing queues that best matches the cells. If a 309 frame is found, it is given to TSCH for transmission. 311 7.3. Centralized Flow Reservation 313 In a centralized setting, a PCE computes the TSCH schedule, and 314 communicates with the different nodes in the network to configure 315 their TSCH schedule. Since it has full knowledge of the network's 316 topology, the PCE can compute a collision-free schedule, which result 317 in a high degree of communication determinism. 319 The protocol for the PCE to communicate with the motes is not yet 320 defined. This protocol typically reserves hard cells on the 321 transmitter side of a dedicated cell, and the negociation protocol of 322 6tus takes care of reserving the same cell on the receiver node. 324 7.4. Distributed Flow Reservation 326 In a distributed setting, no central PCE in present in the network. 327 Nodes use 6tus to reserve soft cells with their neighbors. Since no 328 node has full knowledge of the network's topology and the traffic 329 requirements, scheduling collisions are possible, for example because 330 of a hidden terminal problem. 332 A schedule collision can be detected if two motes have multiple 333 dedicated cells schedule to one another. The statistics process of 334 6tus can be configure to continuously compute the packet delivery 335 ratio of those cells, and the monitoring process of 6tus can declare 336 a soft cell to perform bad when that statistics for that cell is 337 significantly worse than for the other cell to the same neighbor. 339 When this happens, the monitoring process of 6tus moves the cell to 340 another location in the 6TSCH schedule, through a re-negociation 341 procedure with the neighbor. 343 The entity that builds and maintains the schedule in a distributed 344 fashion is not yet defined. 346 7.5. Packet Marking and Handling 348 ---+---------------- 349 Sender Receiver 350 +-----------+ +----+ +----+ +----+ +-----------+ 351 |Application|---->| R1 |---->| R2 |----->|BBR |----->|Application| 352 | +--+ | |+--+| |+--+| |+--+| | +--+ | 353 | |NE|====|=====||NE||=====||NE||======||NE||======|===|NE| | 354 | +--+ | |+--+| |+--+| |+--+| | +--+ | 355 | |^ | | |^ | | |^ | | |^ | | |^ | 356 | v| | | v| | | v| | | v| | | v| | 357 | +--+ | |+--+| |+--+| |+--+| | +--+ | 358 | |6T| | ||6T|| ||6T|| ||6T|| | |6T| | 359 | |us| | ||us|| ||us|| ||us|| | |us| | 360 | +--+ | |+--+| |+--+| |+--+| | +--+ | 361 +-----------+ +----+ +----+ +----+ +-----------+ 363 +--+ 364 |NE| = NSIS ==== = Signaling ---> = Data flow messages 365 +--+ Entity Messages (unidirectional) 367 +--+ 368 |6T| 6TUS layer 369 |us| (and IEEE802.15.4e TSCH MAC below) 370 +--+ 372 Figure 4: NSIS flow 374 reservation Deterministic flow allocation (hard reservation of time 375 slots) eg centralized RSVP? metrics? Hop-by-hop interaction with 376 6TUS. Lazy reservation (use shared slots to transport extra burst 377 and then dynamically (de)allocate) Classical QoS (dynamic based on 378 observation) 380 8. Management 382 9. IANA Considerations 384 This specification does not require IANA action. 386 10. Security Considerations 388 This specification is not found to introduce new security threat. 390 11. Acknowledgements 392 12. References 394 12.1. Normative References 396 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 397 Requirement Levels", BCP 14, RFC 2119, March 1997. 399 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 400 6 (IPv6) Specification", RFC 2460, December 1998. 402 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 403 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 404 4080, June 2005. 406 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 407 Architecture", RFC 4291, February 2006. 409 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 410 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 411 September 2007. 413 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 414 Address Autoconfiguration", RFC 4862, September 2007. 416 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 417 Yegin, "Protocol for Carrying Authentication for Network 418 Access (PANA)", RFC 5191, May 2008. 420 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 421 Hoc Networks", RFC 5889, September 2010. 423 [RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS 424 Signaling Layer Protocol (NSLP) for Quality-of-Service 425 Signaling", RFC 5974, October 2010. 427 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 428 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 429 September 2011. 431 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 432 Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. 433 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 434 Lossy Networks", RFC 6550, March 2012. 436 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, 437 "Neighbor Discovery Optimization for IPv6 over Low-Power 438 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 439 November 2012. 441 12.2. Informative References 443 [I-D.chakrabarti-nordmark-6man-efficient-nd] 444 Chakrabarti, S., Nordmark, E., and M. Wasserman, 445 "Efficiency aware IPv6 Neighbor Discovery Optimizations", 446 draft-chakrabarti-nordmark-6man-efficient-nd-01 (work in 447 progress), November 2012. 449 [I-D.draft-wang-6tsch-6tus] 450 Wang, Q., Ed., Vilajosana, X., and T. Watteyne, "6tus 451 Adaptation Layer Specification. draft-wang-6tsch-6tus-00 452 (work in progress) ", March 2013. 454 [I-D.palattella-6tsch-terminology] 455 Palattella, MR., Ed., Thubert, P., Watteyne, T., and Q. 456 Wang, "Terminology in IPv6 over Time Slotted Channel 457 Hopping. draft-palattella-6tsch-terminology-00 (work in 458 progress) ", March 2013. 460 [I-D.svshah-tsvwg-lln-diffserv-recommendations] 461 Shah, S. and P. Thubert, "Differentiated Service Class 462 Recommendations for LLN Traffic", draft-svshah-tsvwg-lln- 463 diffserv-recommendations-00 (work in progress), February 464 2013. 466 [I-D.thubert-6lowpan-backbone-router] 467 Thubert, P., "6LoWPAN Backbone Router", draft-thubert- 468 6lowpan-backbone-router-03 (work in progress), February 469 2013. 471 [I-D.watteyne-6tsch-tsch-lln-context] 472 Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context: 473 Overview, Problem Statement and Goals", draft-watteyne- 474 6tsch-tsch-lln-context-01 (work in progress), February 475 2013. 477 12.3. External Informative References 479 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 480 a group of specifications for industrial process and 481 control devices administered by the HART Foundation", . 483 [IEEE802.1TSNTG] 484 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 485 Networks Task Group", March 2013, < 486 http://www.ieee802.org/1/pages/avbridges.html>. 488 [ISA100.11a] 489 ISA, "ISA100, Wireless Systems for Automation", May 2008, 490 < http://www.isa.org/Community/ 491 SP100WirelessSystemsforAutomation>. 493 Authors' Addresses 495 Pascal Thubert (editor) 496 Cisco Systems, Inc 497 Village d'Entreprises Green Side 498 400, Avenue de Roumanille 499 Batiment T3 500 Biot - Sophia Antipolis 06410 501 FRANCE 503 Phone: +33 497 23 26 34 504 Email: pthubert@cisco.com 506 Robert Assimiti 507 Nivis 508 1000 Circle 75 Parkway SE, Ste 300 509 Atlanta, GA 30339 510 USA 512 Phone: +1 678 202 6859 513 Email: robert.assimiti@nivis.com 514 Thomas Watteyne 515 Linear Technology / Dust Networks 516 30695 Huntwood Avenue 517 Hayward, CA 94544 518 USA 520 Phone: +1 (510) 400-2978 521 Email: twatteyne@linear.com