idnits 2.17.1 draft-wang-6tisch-track-use-cases-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 -- The document date (July 2, 2015) is 3214 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'IEEE802154e' is mentioned on line 393, but not defined == Missing Reference: 'IEEE802154' is mentioned on line 387, but not defined == Outdated reference: A later version (-08) exists of draft-finn-detnet-architecture-01 == Outdated reference: A later version (-04) exists of draft-ietf-6tisch-6top-interface-02 == Outdated reference: A later version (-30) exists of draft-ietf-6tisch-architecture-05 == Outdated reference: A later version (-10) exists of draft-ietf-6tisch-terminology-03 == Outdated reference: A later version (-06) exists of draft-ietf-6tisch-tsch-05 Summary: 0 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6TiSCH Z. Chen 3 Internet-Draft C. Wang 4 Intended status: Informational InterDigital Communications, LLC 5 Expires: January 3, 2016 July 2, 2015 7 Use Cases and Requirements for using Track in 6TiSCH Networks 8 draft-wang-6tisch-track-use-cases-01 10 Abstract 12 This document further analyzes the 6TiSCH requirements related to 13 Track through the use of examples and use cases. The goal of this 14 document is to trigger discussions in 6TiSCH working group so that 15 all relevant considerations are take into account when design Track 16 reservation schemes in 6TiSCH. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 22 "OPTIONAL" in this document are to be interpreted as described in RFC 23 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 3, 2016. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terms used in this document . . . . . . . . . . . . . . . . . 3 61 3. Use Cases: Industrial Networks . . . . . . . . . . . . . . . 3 62 3.1. Industry process control and automation applications . . 3 63 3.2. Industrial monitoring applications . . . . . . . . . . . 4 64 4. Handling Tracks in 6TiSCH Networks . . . . . . . . . . . . . 5 65 4.1. General Behavior of Tracks . . . . . . . . . . . . . . . 5 66 4.2. Track Reservation . . . . . . . . . . . . . . . . . . . . 6 67 4.2.1. Remote Track Management . . . . . . . . . . . . . . . 6 68 4.2.2. Hop-by-hop Track Management . . . . . . . . . . . . . 6 69 4.3. Relationship with Detnet . . . . . . . . . . . . . . . . 6 70 5. Requirement for Track reservation schemes . . . . . . . . . . 7 71 5.1. Centralized Track reservation . . . . . . . . . . . . . . 7 72 5.2. Distributed Track reservation . . . . . . . . . . . . . . 7 73 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 78 9.2. Informative References . . . . . . . . . . . . . . . . . 8 79 9.3. External Informative References . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 IEEE802.15.4e [IEEE802154e] was published in 2012 as an amendment to 85 the Medium Access Control (MAC) protocol defined by the 86 IEEE802.15.4-2011 [IEEE802154] standard. IEEE802.15.4e will be 87 rolled into the next revision of IEEE802.15.4, scheduled to be 88 published in 2015. The Timeslotted Channel Hopping (TSCH) mode of 89 IEEE802.15.4e is the object of this document. The 6TiSCH working 90 group is chartered to enable IPv6 over the TSCH mode of the 91 IEEE802.15.4e standard. 93 The requirements for 6TiSCH are well documented 94 [I-D.ietf-6tisch-tsch]. Initially, the WG will limit its scope to 95 distributed routing over a static schedule. In this draft, we focus 96 and expand discussions pertaining to Track. We propose requirements 97 and use cases for different type of Track reservation schemes. 99 2. Terms used in this document 101 The draft uses terminologies defined in 102 [I-D.ietf-6tisch-terminology]. The following are definition of 103 terminologies used in this draft. 105 Centralized Track reservation: The reservation of a track done by the 106 central controller of the network, e.g. PCE. 108 Distributed Track reservation: A reservation of a track done by one 109 or more in-network entities (typically a connection endpoint). 111 Track: A determined sequence of cells along a multi-hop path. It is 112 typically the result of a reservation. The node that initializes the 113 process for establishing a Track is the owner of the track. The 114 latter assigns a unique identifier to the Track, called TrackID 116 3. Use Cases: Industrial Networks 118 An industry network is a good use case for a 6TiSCH network. In an 119 industry network as shown in Figure 1, many devices are LLN devices, 120 e.g. sensors and actuators. There are many types of applications in 121 an industry network, such as industry process control and automation 122 applications, e.g. an automation assembly line, and industry monitor 123 applications, e.g. a safety monitoring application. 125 3.1. Industry process control and automation applications 127 In an industry process control and automation application as shown in 128 Figure 1, LLN Devices are actuator and sensors in an automation 129 assemble line. An LLN Device, for example LLN Device S, MAY 130 periodically send signalling packets to another actuator, e.g. LLN 131 Device D. For example, LLN Device S locate at the step 1 of the 132 automation assemble line, whenever it finishes a task, it will send 133 singling packets to LLN Device D located at the step 2 of the 134 automation assemble line to trigger the next action in the automation 135 assembly line. The delay of these packets are extremely important 136 for the performance of the automation assembly line. As mentioned in 137 RFC 5673 [RFC5673], tens of milliseconds of latency is typical in 138 fast control. In many of these systems, if a packet does not arrive 139 within the specified interval, the system enters an emergency 140 shutdown state, often with substantial financial repercussions. 141 Therefore, Reserving a Track between LLN device S and LLN device D 142 can guarantee the delay of these signalling packets. 144 Moreover, the reliability of these signalling packets are extremely 145 important since a packet loss may result products with defects. 146 Therefore, a backup path may be used when the primary path is broken. 147 Reserving multiple Tracks between LLN device S and LLN device D can 148 also improve the reliability of these packet due to less 149 interference. By reserving a Track, battery powered LLN Devices are 150 able to wake up and sleep based on its TSCH schedule to save energy. 151 In these cases, the Tracks reserved are deterministic, unless the 152 topology of the network changes. 154 3.2. Industrial monitoring applications 156 In an industrial monitoring application, sensors such as LLN M, 157 monitor the status of each machine or plant and send data to the 158 Control Controller as shown in Figure 1. An LLN Device, for example 159 LLN Device M, MAY detect a critical event, and sends a signalling 160 emergency message to the Central Controller in the network via 161 multiple paths. After that the LLN Device may send monitoring data 162 to the Central Controller. The singling packets that contains an 163 emergency message SHOULD arrive at the Central Controller with 164 minimum delay and highest reliability. Therefore, multiple Tacks may 165 be reserved between these sensors and the Central Controller. 166 Moreover, a bursty traffic that contains monitoring data MAY follow 167 the critical message. These data packets also require low latency 168 and high reliability, thus a high bandwidth Track SHOULD be quickly 169 set-up between these LLN Devices and the Central Controller. 170 Therefore, the Track reservation scheme has to react faster in a more 171 dynamic way. 173 ---+-------- ............ ------------ 174 | External Network | 175 | +-----+ 176 | +-----+ | NME | 177 +-----+ | +-----+ | | 178 | | Central | | PCE | +-----+ 179 | | Controller +--| | 180 +-----+ +-----+ 181 | | 182 | Subnet Backbone | 183 +--------------------+------------------+ 184 | | | 185 +-----+ +-----+ +-----+ 186 | | Backbone | | Backbone | | Backbone 187 o | | router | | router | | router 188 +-----+ / +-----+ +-----+ 189 o / / o --- o o o 190 o o -- o --- o o o / \ o o o o 191 o \ / o o o S -- o --- D o o 192 o M o o o o o o o o o o 194 Figure 1: Use Case of an Industry Network 196 4. Handling Tracks in 6TiSCH Networks 198 4.1. General Behavior of Tracks 200 In this section, we discuss the behavior and the benefits of Tracks. 201 As discussed in [I-D.ietf-6tisch-architecture], Track is first a 202 multi-hop paths from the source LLN Device to the destination LLN 203 Device. Second, some resources of LLN Devices on the path are 204 reserved by configuring their TSCH schedule. Therefore, an LLN 205 Device on the Track not only knows what cells it should use to 206 receive packets from its previous hop, but also knows what cells it 207 should use to send packets to its next hop. There are several 208 benefits for using Track to forward a packet from the source LLN 209 Device to the destination LLN Device. 211 First, Track forwarding as described in Section 10.1 in 212 [I-D.ietf-6tisch-architecture] is a layer-2 forwarding scheme, which 213 introduces less process delay and overhead than layer-3 forwarding 214 scheme. Therefore, LLN Devices can save more energy and resource, 215 which is critical for resource constrained devices. 217 Second, since channel resources, i.e. cells, have been reserved for 218 communications between LLN devices of each hop on the Track, the 219 packets traverse along the Track as a train passes each stations 220 along the rail track. Therefore, the throughput and delay of the 221 traffic on a Track is guaranteed and the jitter of the traffic is 222 small. These are extremely important features for time-sensitive 223 applications, which require packets arrives on time. 225 Third, by knowing the scheduled time slots of incoming cell and 226 outgoing cell, LLN devices on a Track could save more energy by 227 staying in sleep state during in-active slots. This is extreme 228 important for LLN Devices that are battery powered. 230 Fourth, by allocating scheduled channel frequency, both inter-Track 231 and intra-Track interference can be reduced. This will enhance the 232 reliability of transmissions on a Track and reduce energy consumption 233 of LLN Devices by decreasing the number of retransmissions. 235 4.2. Track Reservation 237 Cells along a Track have to be reserved before any packet 238 transmissions. How to efficiently allocate resources along a Track 239 becomes a challenging problem. Generally, there are both remote 240 Track management and hop-by-hop Track management described in 241 [I-D.ietf-6tisch-architecture] to solve the Track reservation issue. 243 4.2.1. Remote Track Management 245 In the remote Track management scheme in section 9.3 in 246 [I-D.ietf-6tisch-architecture], a central controller of the network, 247 e.g. Path Computation Element (PCE) in Figure 1, can allocate hard 248 cells of LLN Devices on a Track remotely. The network may be 249 globally optimized by the central controller of the network. 251 4.2.2. Hop-by-hop Track Management 253 In the hop-by-hop Track management scheme in section 9.4 in 254 [I-D.ietf-6tisch-architecture], LLN Devices can negotiate and reserve 255 Soft Cells in their TSCH Schedule by communicating with each other. 256 By configuring the TSCH Schedule of LLN Devices on a route, a Track 257 can be reserved to enhance the multi-hop communications between the 258 source and the destination. The hop-by-hop Track management schemes 259 may be more scalable and robust than the remote Track management 260 scheme since it does not rely on the central controller of the 261 network. 263 4.3. Relationship with Detnet 265 Deterministic Networking (DetNet) [I-D.finn-detnet-architecture] 266 provides a capability to carry specified unicast or multicast data 267 streams for real-time application with extremely low data loss rates 268 and maximum latency. Three techniques are employed by DetNet to 269 achieve theses QoS parameters, zero congestion loss, pinned-down 270 paths and packet replication and deletion. 272 As mentioned by DetNet [I-D.finn-detnet-architecture], Track in 273 6TiSCH network is an instance of a deterministic path. The 274 centralized and distributed path setup solutions in Detnet CAN be 275 used as a reference in 6TiSCH Track reservation solution. However, 276 Track in 6TiSCH is targeted to Low-power and Lossy Networks (LLNs), 277 techniques in Detnet must be customized for Track management in 278 6TiSCH considering low power consumption, TSCH MAC and constrained 279 devices with limited buffer and computation strength. For example, 280 Detnet proposes seamless Redundancy, Replicating packets and sending 281 them along at least two different paths. However, Replicating 282 packets may dramatically increase the energy consumption of the 283 network, which may be a concern for LLN networks. Therefore, Track 284 management should be studied in 6TiSCH WG, and the solutions can 285 influence the design of DetNet. 287 5. Requirement for Track reservation schemes 289 The track reservation schemes are required to support both 290 deterministic traffics such as periodical transmissions for industry 291 process control and automation applications and dynamic traffics such 292 as bursty transmissions for industrial monitoring applications. 294 5.1. Centralized Track reservation 296 Need a protocol for LLN devices to report their topology and TSCH 297 schedule information to the central controller as shown in Figure 1. 298 The central controller need the topology information to obtain a path 299 from the source to the destination and the network can be better 300 optimized if the central controller is aware of the TSCH schedule of 301 all or part of LLN Devices in the network. 303 Need a lightweight protocol for the central controller to configure 304 hard cells of LLN Devices using 6top interface defined in 305 [I-D.ietf-6tisch-6top-interface]. The central controller has to 306 configure hard cells of LLN Devices on the track remotely and LLN 307 Devices are usually constrained devices which may not support 308 heavyweight protocol such as RFC 5440 [RFC5440] 310 5.2. Distributed Track reservation 312 Need a fast reaction protocol to reserve a Track. LLN Devices have 313 limited information about the topology of the network and the TSCH 314 schedule of other LLN Devices on the path. The protocol should 315 quickly detect a Track reservation failure. Need an efficient 316 negotiation protocol between LLN Devices multi-hop away from each 317 other. LLN Devices on the path have to negotiate in order to reserve 318 a Track, which may bring extra overhead to constrained devices. 320 6. Conclusions 322 A Track can provide low latency, guaranteed throughput and high 323 reliable for end-to-end communications. There are many use cases 324 that can show the benefit of using a Track, such as industry 325 networks, home networks, structure networks, health networks and 326 vehicular networks. Moreover, different Track reservation schemes, 327 such as centralized and distributed schemes, need to be proposed to 328 handle a large variety of requirements. 330 7. Security Considerations 332 This draft discussed the design considerations and operations of 333 using Track in 6TiSCH networks. It does not introduce new security 334 threats. 336 8. IANA Considerations 338 This specification does not require IANA action. 340 9. References 342 9.1. Normative References 344 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 345 Requirement Levels", BCP 14, RFC 2119, March 1997. 347 9.2. Informative References 349 [I-D.finn-detnet-architecture] 350 Finn, N., Thubert, P., and M. Teener, "Deterministic 351 Networking Architecture", draft-finn-detnet- 352 architecture-01 (work in progress), March 2015. 354 [I-D.ietf-6tisch-6top-interface] 355 Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH 356 Operation Sublayer (6top) Interface", draft-ietf-6tisch- 357 6top-interface-02 (work in progress), October 2014. 359 [I-D.ietf-6tisch-architecture] 360 Thubert, P., Watteyne, T., Struik, R., and M. Richardson, 361 "An Architecture for IPv6 over the TSCH mode of IEEE 362 802.15.4e", draft-ietf-6tisch-architecture-05 (work in 363 progress), January 2015. 365 [I-D.ietf-6tisch-terminology] 366 Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, 367 "Terminology in IPv6 over the TSCH mode of IEEE 368 802.15.4e", draft-ietf-6tisch-terminology-03 (work in 369 progress), January 2015. 371 [I-D.ietf-6tisch-tsch] 372 Watteyne, T., Palattella, M., and L. Grieco, "Using 373 IEEE802.15.4e TSCH in an IoT context: Overview, Problem 374 Statement and Goals", draft-ietf-6tisch-tsch-05 (work in 375 progress), January 2015. 377 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 378 (PCE) Communication Protocol (PCEP)", RFC 5440, March 379 2009. 381 [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, 382 "Industrial Routing Requirements in Low-Power and Lossy 383 Networks", RFC 5673, October 2009. 385 9.3. External Informative References 387 [IEEE802154] 388 IEEE standard for Information Technology, "IEEE std. 389 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) 390 and Physical Layer (PHY) Specifications for Low-Rate 391 Wireless Personal Area Networks", June 2011. 393 [IEEE802154e] 394 IEEE standard for Information Technology, "IEEE std. 395 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area 396 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 397 2012. 399 Authors' Addresses 401 Zhuo Chen 402 InterDigital Communications, LLC 403 781 Third Ave 404 King of Prussia, PA 19406 405 USA 407 Phone: +1 610 878 5730 408 Email: Zhuo.Chen@InterDigital.com 409 Chonggang Wang 410 InterDigital Communications, LLC 411 781 Third Ave 412 King of Prussia, PA 19406 413 USA 415 Phone: +1 610 878 5831 416 Email: Chonggang.Wang@InterDigital.com