idnits 2.17.1 draft-thubert-6tsch-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 106 has weird spacing: '...ticular the T...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (April 19, 2013) is 4025 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 525, but not defined == Missing Reference: 'IEEE802.1TSNTG' is mentioned on line 529, but not defined == Unused Reference: 'RFC5974' is defined on line 461, but no explicit reference was found in the text == Unused Reference: 'I-D.palattella-6tsch-terminology' is defined on line 487, but no explicit reference was found in the text == Unused Reference: 'I-D.svshah-tsvwg-lln-diffserv-recommendations' is defined on line 493, but no explicit reference was found in the text == Unused Reference: 'I-D.thubert-6lowpan-backbone-router' is defined on line 499, 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 (-01) exists of draft-wang-6tsch-6tus-00 == Outdated reference: A later version (-02) exists of draft-watteyne-6tsch-tsch-lln-context-01 Summary: 4 errors (**), 0 flaws (~~), 14 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: October 19, 2013 Nivis 6 T. Watteyne 7 Linear Technology / Dust Networks 8 April 19, 2013 10 An Architecture for IPv6 over Time Slotted Channel Hopping 11 draft-thubert-6tsch-architecture-01 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 October 19, 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 (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. Functional Flows . . . . . . . . . . . . . . . . . . . . . . . 7 72 7. Network Synchronization . . . . . . . . . . . . . . . . . . . 7 73 8. TSCH and 6TUS . . . . . . . . . . . . . . . . . . . . . . . . 7 74 8.1. 6tus . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 8.2. Slotframes and Priorities . . . . . . . . . . . . . . . . 8 76 8.3. Centralized Flow Reservation . . . . . . . . . . . . . . . 8 77 8.4. Distributed Flow Reservation . . . . . . . . . . . . . . . 8 78 8.5. Packet Marking and Handling . . . . . . . . . . . . . . . 9 79 9. Management . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 81 11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 83 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 13.1. Normative References . . . . . . . . . . . . . . . . . . 9 85 13.2. Informative References . . . . . . . . . . . . . . . . . 10 86 13.3. External Informative References . . . . . . . . . . . . . 11 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Introduction 91 The emergence of radio technology enabled a large variety of new 92 types of devices to be interconnected, at a very low marginal cost 93 compared to wire, at any range from Near Field to interplanetary 94 distances, and in circumstances where wiring could be less than 95 practical, for instance rotating devices. 97 At the same time, a new breed of Time Sensitive Networks is being 98 developped to enable traffic that is highly sensitive to jitter and 99 quite sensitive to latency. Such traffic is not limited to voice and 100 video, but also includes command and control operations such as found 101 in industrial automation or in-vehicule sensors and actuators. 103 At IEEE802.1, the "Audio/Video Task Group", was renamed TSN for Time 104 Sensitive Networking to address Deterministic Ethernet. The 105 IEEE802.15.4 Medium Access Control MAC) has evolved with 106 IEEE802.15.4e that provides in particular the Time Slotted Channel 107 Hopping (TSCH) mode for industrial-type applications. 109 Though at a different time scale, both standards provide 110 Deterministic capabilities to the point that a packet that pertains 111 to a certain flow will cross the network from node to node following 112 a very precise schedule, like a train leaves intermediate stations at 113 precise times along its path. The time slotted aspect reduces 114 collisions, and saves energy, and enables to more closely engineer 115 the network for deterministic properties. The channel hopping aspect 116 is a simple and efficient technique to get around statistical 117 interference by WIFI emitters. 119 This document presents an architecture for an IPv6 multilink subnet 120 that is composed of a high speed powered backbone and a number of 121 IEEE802.15.4e TSCH wireless networks attached and synchronized by 122 backbone routers. Route Computation may be achieved in a centralized 123 fashion by a Path Computation Entity (PCE), in a distributed fashion 124 using the Routing Protocol for Low Power and Lossy Networks (RPL), or 125 in a mixed mode. The Backbone Routers perform proxy Ipv6 Neighbor 126 Discovery (ND) operations over the backbone on behalf of the wireless 127 device, so they can share a same IPv6 subnet and appear to be 128 connected to the same backbone as classical devices. 130 2. Terminology 132 The draft uses terminology defined in [I-D.palattella-6tsch- 133 terminology], [I-D.chakrabarti-nordmark-6man-efficient-nd], [RFC5191] 134 and [RFC4080]. 136 It conforms to the terms and models described for IPv6 in [RFC5889] 137 and uses the vocabulary and the concepts defined in [RFC4291] for 138 IPv6. 140 3. Applications and Goals 141 The architecture derives from existing industrial standards for 142 Process Control by its focus on Deterministic Networking, in 143 particular with the use of the IEEE802.15.4e TSCH MAC and the 144 centralized path computation entity. This approach leverages the 145 TSCH MAC benefits for high reliability against interferences, low- 146 power consumption on deterministic traffic, and its Traffic 147 Engineering capabilities. Deterministic Networking applies in 148 particular to open and close control loops, as well as supervisory 149 control flows, and management. 151 Additional industrial use cases are addressed with the addition of a 152 more autonomic and distributed routing based on RPL. These use cases 153 include plant setup and decommissioning, as well as monitoring of 154 lots of lesser importance measurements such as corrosion and events. 155 RPL also enables mobile use cases such as mobile workers and cranes. 157 A Backbone Router is included in order to scale the factory plant 158 subnet to address large deployments, with proxy ND and time 159 synchronization over a high speed backbone. 161 The architecture also applies to building automation that leverage 162 RPL's storing mode to address multipath over a large number of hops, 163 in-vehicule command and control that can be as demanding as 164 industrial applications, commercial automation and asset tracking 165 with mobile scenarios, home automation and domotics which become more 166 reliable and thus provide a better user experience, and resource 167 management (energy, water, etc...). 169 4. Overview and Scope 171 The scope of the present work is a subnet that, in its basic 172 configuration, is made of a IEEE802.15.4e Time Slotted Channel 173 Hopping (TSCH) [I-D.watteyne-6tsch-tsch-lln-context] MAC Route-Over 174 Low Power Lossy Network (LLN). 176 +-----+ 177 | | LLN Border 178 | | router 179 +-----+ 180 o o o 181 o o o o 182 o o LLN o o o 183 o o o o 184 o 186 The LLN devices communicate over IPv6 [RFC2460] using the 6LoWPAN 187 Header Compression (6LoWPAN HC) [RFC6282]. Neighbor Devices are 188 discovered with 6LoWPAN Neighbor Discovery (6LoWPAN ND) [RFC6775] and 189 the Routing Protocol for Low Power and Lossy Networks (RPL) 190 [RFC6550] enables routing within the LLN. RPL forms Destination 191 Oriented Directed Acyclic Graphs (DODAGs) within instances of the 192 protocol, each instance being associated with an Objective Function 193 (OF) to form a routing topology. A particular LLN device, usually 194 powered, acts as RPL root, 6LoWPAN HC terminator, and LLN Border 195 Router (LBR) to the outside. 197 An extended configuration of the subnet comprises multiple LLNs. The 198 LLNs are interconnected and synchronized over a backbone, that can be 199 wired or wireless. The backbone can be a classical IPv6 network, 200 with Neighbor Discovery operating as defined in [RFC4861] and 201 [RFC4862]. The backbone can also support Efficiency aware IPv6 202 Neighbor Discovery Optimizations [I-D.chakrabarti-nordmark-6man- 203 efficient-nd] in mixed mode as described in [I-D.thubert-6lowpan- 204 backbone-router]. 206 Security is often handled at layer 2 and Layer 4. Authentication 207 during the join process is handled with the Protocol for Carrying 208 Authentication for Network Access (PANA) [RFC5191]. 210 The LLN devices are time-synchronized at MAC level. The MAC 211 coordinator that serves as time source through Enhanced Beacons (EB) 212 is loosely coupled with the RPL parent; this way, the time 213 synchronization starts at the RPL root and follows the RPL DODAGs 214 with no timing loop. 216 In the extended configuration, the functionality of the LBR is 217 enhanced to that of Backbone Router (BBR). A BBR is an LBR, but also 218 an Energy Aware Default Router (NEAR) as defined in [I-D.chakrabarti- 219 nordmark-6man-efficient-nd]. The BBR performs ND proxy operations 220 between the registered devices and the classical ND devices that are 221 located over the backbone. 6TSCH BBRs synchronize with one another 222 over the backbone, so as to ensure that the multiple LLNs that form 223 the IPv6 subnet stay tightly synchronized. If the Backbone is 224 Deterministic (such as defined by the Time Sensitive Networking WG at 225 IEEE), then the Backbone Router ensures that the end-to-end 226 deterministic behavior is maintained between the LLN and the 227 backbone. 229 ---+------------------------ 230 | External Network 231 | 232 +-----+ +-----+ 233 | | Router | | PCE 234 | | | | 235 +-----+ +-----+ 236 | | 237 | Subnet Backbone | 238 +--------------------+------------------+ 239 | | | 240 +-----+ +-----+ +-----+ 241 | | Backbone | | Backbone | | Backbone 242 o | | router | | router | | router 243 +-----+ +-----+ +-----+ 244 o o o o o 245 o o o o o o o o o o o 246 o o o LLN o o o o 247 o o o o o o o o o o o o 249 The main architectural blocks are arranged as follows: 251 +-----+-----+-----+-----+-------+-----+ 252 |PCEP | CoAP |PANA |6LoWPAN| RPL | 253 | PCC |DTLS | | | ND | | 254 +-----+-----+-----+-----+-------+-----+-----+ 255 | TCP | UDP | ICMP |RSVP | 256 +-----+-----+-----+-----+-------+-----+-----+ 257 | IPv6 | 258 +-------------------------------------------+ 259 | 6LoWPAN HC | 260 +-------------------------------------------+ 261 | 6TUS | 262 +-------------------------------------------+ 263 | 802.15.4e TSCH | 264 +-------------------------------------------+ 266 RPL is the routing protocol of choice for LLNs. (TBD RPL) whether 267 there is a need to define a 6TSCH OF. 269 (tbd NME) COMAN is working on network Management for LLN. They are 270 considering the Open Mobile Alliance (OMA) Lightweight M2M (LWM2M) 271 Objet system. This standard includes DTLS, CoAP (core plus the Block 272 and Observe patterns), SenML and CoAP Resource Directory. 274 (tbd PCC) need to work with PCE WG to define flows to PCE, and define 275 how to accomodate PCE routes and reservation. Will probably look a 276 lot like GMPLS 278 (tbd Backbone Router) need to work woth 6MAN to define ND proxy. 279 Also need BBR sync sync between deterministic ethernet and 6TSCH 280 LLNs. 282 IEEE802.1TSN: external, maintain consistency. 284 IEEE802.15.4: external, (tbd need updates?). 286 ISA100.20 Common Network Management: external, maintain consistency. 288 IoT6 European Project: external, maintain consistency. 290 5. Centralized vs. Distributed Routing 292 6. Functional Flows 294 7. Network Synchronization 296 The mechanism(s) used for time synchronization is something that we 297 might have to reconcile with RPL discovery and maintenance traffic. 299 Time synchronization in TSCH is based on three mechanisms: 301 Enhanced Beacons 303 Enhanced ACKs 305 Frame based synchronization 307 If a node communicates intermittently (sleepy, battery operated) it 308 can also proactively ping its time source and receive time stamps. 309 In order to maximize battery life and network throughput, it is 310 advisable that RPL ICMP discovery and maintenance traffic (governed 311 by the trickle timer) be somehow coordinated with the transmission of 312 time synch packets (especially with enhanced beacons). This could be 313 a function of the shim layer or it could be deferred to the device 314 management entity. Any suggestions, ideas on this topic? 316 8. TSCH and 6TUS 318 8.1. 6tus 320 6tus is an adaptation layer which is the next higher layer to TSCH 321 and which offers a set of commands defining a data and management 322 interface. 6tus is defined in [I-D.wang-6tsch-6tus] 324 The management interface of 6tus enables an upper layer to schedule 325 cells and slotframes in the TSCH schedule. 327 If the scheduling entity explicitly specifies the slotOffset/ 328 channelOffset of the cells to be added/deleted, those cells are 329 marked as "hard". 6tus can not move hard cells in the TSCH schedule. 330 Hard cells are typically used by an central PCE. 332 6tus contains a monitoring process which monitors the performance of 333 cells, and can move a cell in the TSCH schedule when it performs bad. 334 This is only applicable to cells which are marked as "soft". To 335 reserve a soft cell, the higher layer does not indicate the 336 slotOffset/channelOffset of the cell to add, but rather the resulting 337 bandwidth and QoS requirements. When the monitoring process triggers 338 an cell reallocation, the two neighbor motes communication over this 339 cells negociate the new position in the TSCH schedule of this cell. 341 8.2. Slotframes and Priorities 343 6tus uses priority queues to manage concurrent data flows of 344 different prioroties. When a packet is received from an higher layer 345 for transmission, the I-MUX module of 6tus inserts that packet in the 346 outgoing queue which matches the packet best (DSCP can therefore be 347 used). At each schedule transmit slot, the MUX module looks for the 348 frame in all the outgoing queues that best matches the cells. If a 349 frame is found, it is given to TSCH for transmission. 351 8.3. Centralized Flow Reservation 353 In a centralized setting, a PCE computes the TSCH schedule, and 354 communicates with the different nodes in the network to configure 355 their TSCH schedule. Since it has full knowledge of the network's 356 topology, the PCE can compute a collision-free schedule, which result 357 in a high degree of communication determinism. 359 The protocol for the PCE to communicate with the motes is not yet 360 defined. This protocol typically reserves hard cells on the 361 transmitter side of a dedicated cell, and the negociation protocol of 362 6tus takes care of reserving the same cell on the receiver node. 364 8.4. Distributed Flow Reservation 366 In a distributed setting, no central PCE in present in the network. 367 Nodes use 6tus to reserve soft cells with their neighbors. Since no 368 node has full knowledge of the network's topology and the traffic 369 requirements, scheduling collisions are possible, for example because 370 of a hidden terminal problem. 372 A schedule collision can be detected if two motes have multiple 373 dedicated cells schedule to one another. The statistics process of 374 6tus can be configure to continuously compute the packet delivery 375 ratio of those cells, and the monitoring process of 6tus can declare 376 a soft cell to perform bad when that statistics for that cell is 377 significantly worse than for the other cell to the same neighbor. 379 When this happens, the monitoring process of 6tus moves the cell to 380 another location in the 6TSCH schedule, through a re-negociation 381 procedure with the neighbor. 383 The entity that builds and maintains the schedule in a distributed 384 fashion is not yet defined. 386 8.5. Packet Marking and Handling 388 ---+---------------- 389 Sender Receiver 390 +-----------+ +----+ +----+ +----+ +-----------+ 391 |Application|---->| R1 |---->| R2 |----->|BBR |----->|Application| 392 | +--+ | |+--+| |+--+| |+--+| | +--+ | 393 | |NE|====|=====||NE||=====||NE||======||NE||======|===|NE| | 394 | +--+ | |+--+| |+--+| |+--+| | +--+ | 395 | |^ | | |^ | | |^ | | |^ | | |^ | 396 | v| | | v| | | v| | | v| | | v| | 397 | +--+ | |+--+| |+--+| |+--+| | +--+ | 398 | |6T| | ||6T|| ||6T|| ||6T|| | |6T| | 399 | |us| | ||us|| ||us|| ||us|| | |us| | 400 | +--+ | |+--+| |+--+| |+--+| | +--+ | 401 +-----------+ +----+ +----+ +----+ +-----------+ 403 +--+ 404 |NE| = NSIS ==== = Signaling ---> = Data flow messages 405 +--+ Entity Messages (unidirectional) 407 +--+ 408 |6T| 6TUS layer 409 |us| (and IEEE802.15.4e TSCH MAC below) 410 +--+ 412 reservation Deterministic flow allocation (hard reservation of time 413 slots) eg centralized RSVP? metrics? Hop-by-hop interaction with 414 6TUS. Lazy reservation (use shared slots to transport extra burst 415 and then dynamically (de)allocate) Classical QoS (dynamic based on 416 observation) 418 9. Management 420 10. IANA Considerations 422 This specification does not require IANA action. 424 11. Security Considerations 426 This specification is not found to introduce new security threat. 428 12. Acknowledgements 430 13. References 432 13.1. Normative References 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 438 6 (IPv6) Specification", RFC 2460, December 1998. 440 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J. and S. Van den 441 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 442 4080, June 2005. 444 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 445 Architecture", RFC 4291, February 2006. 447 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 448 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 449 September 2007. 451 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless 452 Address Autoconfiguration", RFC 4862, September 2007. 454 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H. and A. 455 Yegin, "Protocol for Carrying Authentication for Network 456 Access (PANA)", RFC 5191, May 2008. 458 [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad 459 Hoc Networks", RFC 5889, September 2010. 461 [RFC5974] Manner, J., Karagiannis, G. and A. McDonald, "NSIS 462 Signaling Layer Protocol (NSLP) for Quality-of-Service 463 Signaling", RFC 5974, October 2010. 465 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 466 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 467 September 2011. 469 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 470 Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. 471 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 472 Lossy Networks", RFC 6550, March 2012. 474 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann, 475 "Neighbor Discovery Optimization for IPv6 over Low-Power 476 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 477 November 2012. 479 13.2. Informative References 481 [I-D.chakrabarti-nordmark-6man-efficient-nd] 482 Chakrabarti, S., Nordmark, E. and M. Wasserman, 483 "Efficiency aware IPv6 Neighbor Discovery Optimizations", 484 Internet-Draft draft-chakrabarti-nordmark-6man-efficient- 485 nd-01, November 2012. 487 [I-D.palattella-6tsch-terminology] 488 Palattella, M., Thubert, P., Watteyne, T. and Q. Wang, 489 "Terminology in IPv6 over Time Slotted Channel Hopping", 490 Internet-Draft draft-palattella-6tsch-terminology-00, 491 March 2013. 493 [I-D.svshah-tsvwg-lln-diffserv-recommendations] 494 Shah, S. and P. Thubert, "Differentiated Service Class 495 Recommendations for LLN Traffic", Internet-Draft draft- 496 svshah-tsvwg-lln-diffserv-recommendations-00, February 497 2013. 499 [I-D.thubert-6lowpan-backbone-router] 500 Thubert, P., "6LoWPAN Backbone Router", Internet-Draft 501 draft-thubert-6lowpan-backbone-router-03, February 2013. 503 [I-D.wang-6tsch-6tus] 504 Wang, Q., Vilajosana, X. and T. Watteyne, "6tus Adaptation 505 Layer Specification", Internet-Draft draft-wang-6tsch- 506 6tus-00, March 2013. 508 [I-D.watteyne-6tsch-tsch-lln-context] 509 Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context: 510 Overview, Problem Statement and Goals", Internet-Draft 511 draft-watteyne-6tsch-tsch-lln-context-01, February 2013. 513 [I-D.watteyne-6tsch-tsch-lln-context] 514 Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context: 515 Overview, Problem Statement and Goals", Internet-Draft 516 draft-watteyne-6tsch-tsch-lln-context-01, February 2013. 518 [I-D.watteyne-6tsch-tsch-lln-context] 519 Watteyne, T., "Using IEEE802.15.4e TSCH in an LLN context: 520 Overview, Problem Statement and Goals", Internet-Draft 521 draft-watteyne-6tsch-tsch-lln-context-01, February 2013. 523 13.3. External Informative References 525 [HART] www.hartcomm.org, "Highway Addressable Remote Transducer, 526 a group of specifications for industrial process and 527 control devices administered by the HART Foundation", . 529 [IEEE802.1TSNTG] 530 IEEE Standards Association, "IEEE 802.1 Time-Sensitive 531 Networks Task Group", March 2013, . 534 [ISA100.11a] 535 ISA, "ISA100, Wireless Systems for Automation", May 2008, 536 . 539 Authors' Addresses 540 Pascal Thubert, editor 541 Cisco Systems, Inc 542 Building D 543 45 Allee des Ormes - BP1200 544 MOUGINS - Sophia Antipolis, 06254 545 FRANCE 547 Phone: +33 497 23 26 34 548 Email: pthubert@cisco.com 550 Robert Assimiti 551 Nivis 552 1000 Circle 75 Parkway SE, Ste 300 553 Atlanta, GA 30339 554 USA 556 Phone: +1 678 202 6859 557 Email: robert.assimiti@nivis.com 559 Thomas Watteyne 560 Linear Technology / Dust Networks 561 30695 Huntwood Avenue 562 Hayward, CA 94544 563 USA 565 Phone: +1 (510) 400-2978 566 Email: twatteyne@linear.com