6TiSCH Z. Chen Internet-Draft C. Wang Intended status: Standards Track InterDigital Communications, LLC Expires: September 7, 2015 March 6, 2015 Use Cases and Requirements for using Track in 6TiSCH Networks draft-wang-6tisch-track-use-cases-00 Abstract This document further analyzes the 6TiSCH requirements related to Track through the use of examples and use cases. The goal of this document is to trigger discussions in 6TiSCH working group so that all relevant considerations are take into account when design Track reservation schemes in 6TiSCH. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 7, 2015. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Chen & Wang Expires September 7, 2015 [Page 1] Internet-Draft 6tisch-track-use-cases March 2015 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terms used in this document . . . . . . . . . . . . . . . . . 3 3. Use Cases: Industrial Networks . . . . . . . . . . . . . . . 3 3.1. Industry process control and automation applications . . 3 3.2. Industrial monitoring applications . . . . . . . . . . . 4 4. Handling Tracks in 6TiSCH Networks . . . . . . . . . . . . . 5 4.1. General Behavior of Tracks . . . . . . . . . . . . . . . 5 4.2. Track Reservation . . . . . . . . . . . . . . . . . . . . 5 4.2.1. Remote Track Management . . . . . . . . . . . . . . . 6 4.2.2. Hop-by-hop Track Management . . . . . . . . . . . . . 6 5. Requirement for Track reservation schemes . . . . . . . . . . 6 5.1. Centralized Track reservation . . . . . . . . . . . . . . 6 5.2. Distributed Track reservation . . . . . . . . . . . . . . 6 6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 7 9.3. External Informative References . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction IEEE802.15.4e [IEEE802154e] was published in 2012 as an amendment to the Medium Access Control (MAC) protocol defined by the IEEE802.15.4-2011 [IEEE802154] standard. IEEE802.15.4e will be rolled into the next revision of IEEE802.15.4, scheduled to be published in 2015. The Timeslotted Channel Hopping (TSCH) mode of IEEE802.15.4e is the object of this document. The 6TiSCH working group is chartered to enable IPv6 over the TSCH mode of the IEEE802.15.4e standard. The requirements for 6TiSCH are well documented [I-D.ietf-6tisch-tsch]. Initially, the WG will limit its scope to distributed routing over a static schedule. In this draft, we focus and expand discussions pertaining to Track. We propose requirements and use cases for different type of Track reservation schemes. Chen & Wang Expires September 7, 2015 [Page 2] Internet-Draft 6tisch-track-use-cases March 2015 2. Terms used in this document The draft uses terminologies defined in [I-D.ietf-6tisch-terminology]. The following are definition of terminologies used in this draft. Centralized Track reservation: The reservation of a track done by the central controller of the network, e.g. PCE. Distributed Track reservation: A reservation of a track done by one or more in-network entities (typically a connection endpoint). Track: A determined sequence of cells along a multi-hop path. It is typically the result of a reservation. The node that initializes the process for establishing a Track is the owner of the track. The latter assigns a unique identifier to the Track, called TrackID 3. Use Cases: Industrial Networks An industry network is a good use case for a 6TiSCH network. In an industry network as shown in Figure 1, many devices are LLN devices, e.g. sensors and actuators. There are many types of applications in an industry network, such as industry process control and automation applications, e.g. an automation assembly line, and industry monitor applications, e.g. a safety monitoring application. 3.1. Industry process control and automation applications In an industry process control and automation application as shown in Figure 1, LLN Devices are actuator and sensors in an automation assemble line. An LLN Device, for example LLN Device 1, MAY periodically send signalling packets to another actuator, e.g. LLN Device 2. For example, LLN Device 1 locate at the step 1 of the automation assemble line, whenever it finishes a task, it will send singling packets to LLN Device 2 located at the step 2 of the automation assemble line to trigger the next action in the automation assembly line. The delay of these packets are extremely important for the performance of the automation assembly line. Also the reliability of these signalling packets are extremely important since a packet loss may result products with defects. Reserving a Track between LLN device 1 and LLN device 2 can not only guarantee the delay of these signalling packets but also improve the reliability of these packet due to less interference. Moreover, by reserving a Track, battery powered LLN Devices are able to wake up and sleep based on its TSCH schedule to save energy. In these cases, the Tracks reserved are deterministic, unless the topology of the network changes. Chen & Wang Expires September 7, 2015 [Page 3] Internet-Draft 6tisch-track-use-cases March 2015 3.2. Industrial monitoring applications In an industrial monitoring application, sensors such as LLN 1 and 2, monitor the status of each machine or plant and send data to the Control Controller as shown in Figure 1. An LLN Device, for example LLN Device 1, MAY detect a critical event, and sends a signalling emergency message to the Central Controller in the network. After that the LLN Device may send monitoring data to the Central Controller. The singling packets that contains an emergency message SHOULD arrive at the Central Controller with minimum delay and highest reliability. Therefore, multiple Tacks may be reserved between these sensors and the Central Controller. Moreover, a bursty traffic that contains monitoring data MAY follow the critical message. These data packets also require low latency and high reliability, thus a high bandwidth Track SHOULD be quickly set-up between these LLN Devices and the Central Controller. Therefore, the Track reservation scheme has to react faster in a more dynamic way. ---+-------- ............ ------------ | External Network | | +-----+ | +-----+ | NME | +-----+ | +-----+ | | | | Central | | PCE | +-----+ | | Controller +--| | +-----+ +-----+ | | | Subnet Backbone | +--------------------+------------------+ | | | +-----+ +-----+ +-----+ | | Backbone | | Backbone | | Backbone o | | router | | router | | router +-----+ +-----+ +-----+ o o o o o o o o o o o o o o o o o o o LLN Device 1 o o LLN Device 2 o o o o o o o o o o o o o Figure 1: Use Case of an Industry Network Chen & Wang Expires September 7, 2015 [Page 4] Internet-Draft 6tisch-track-use-cases March 2015 4. Handling Tracks in 6TiSCH Networks 4.1. General Behavior of Tracks In this section, we discuss the behavior and the benefits of Tracks. As discussed in [I-D.ietf-6tisch-architecture], Track is first a multi-hop paths from the source LLN Device to the destination LLN Device. Second, some resources of LLN Devices on the path are reserved by configuring their TSCH schedule. Therefore, an LLN Device on the Track not only knows what cells it should use to receive packets from its previous hop, but also knows what cells it should use to send packets to its next hop. There are several benefits for using Track to forward a packet from the source LLN Device to the destination LLN Device. First, Track forwarding as described in Section 10.1 in [I-D.ietf-6tisch-architecture] is a layer-2 forwarding scheme, which introduces less process delay and overhead than layer-3 forwarding scheme. Therefore, LLN Devices can save more energy and resource, which is critical for resource constrained devices. Second, since channel resources, i.e. cells, have been reserved for communications between LLN devices of each hop on the Track, the packets traverse along the Track as a train passes each stations along the rail track. Therefore, the throughput and delay of the traffic on a Track is guaranteed and the jitter of the traffic is small. These are extremely important features for time-sensitive applications, which require packets arrives on time. Third, by knowing the scheduled time slots of incoming cell and outgoing cell, LLN devices on a Track could save more energy by staying in sleep state during in-active slots. This is extreme important for LLN Devices that are battery powered. Fourth, by allocating scheduled channel frequency, both inter-Track and intra-Track interference can be reduced. This will enhance the reliability of transmissions on a Track and reduce energy consumption of LLN Devices by decreasing the number of retransmissions. 4.2. Track Reservation Cells along a Track have to be reserved before any packet transmissions. How to efficiently allocate resources along a Track becomes a challenging problem. Generally, there are both remote Track management and hop-by-hop Track management described in [I-D.ietf-6tisch-architecture] to solve the Track reservation issue. Chen & Wang Expires September 7, 2015 [Page 5] Internet-Draft 6tisch-track-use-cases March 2015 4.2.1. Remote Track Management In the remote Track management scheme in section 9.3 in [I-D.ietf-6tisch-architecture], a central controller of the network, e.g. Path Computation Element (PCE) in Figure 1, can allocate hard cells of LLN Devices on a Track remotely. The network may be globally optimized by the central controller of the network. 4.2.2. Hop-by-hop Track Management In the hop-by-hop Track management scheme in section 9.4 in [I-D.ietf-6tisch-architecture], LLN Devices can negotiate and reserve Soft Cells in their TSCH Schedule by communicating with each other. By configuring the TSCH Schedule of LLN Devices on a route, a Track can be reserved to enhance the multi-hop communications between the source and the destination. The hop-by-hop Track management schemes may be more scalable and robust than the remote Track management scheme since it does not rely on the central controller of the network. 5. Requirement for Track reservation schemes The track reservation schemes are required to support both deterministic traffics such as periodical transmissions for industry process control and automation applications and dynamic traffics such as bursty transmissions for industrial monitoring applications. 5.1. Centralized Track reservation Need a protocol for LLN devices to report their topology and TSCH schedule information to the central controller as shown in Figure 1. The central controller need the topology information to obtain a path from the source to the destination and the network can be better optimized if the central controller is aware of the TSCH schedule of all or part of LLN Devices in the network. Need a lightweight protocol for the central controller to configure hard cells of LLN Devices using 6top interface defined in [I-D.ietf-6tisch-6top-interface]. The central controller has to configure hard cells of LLN Devices on the track remotely and LLN Devices are usually constrained devices which may not support heavyweight protocol such as RFC 5440 [RFC5440] 5.2. Distributed Track reservation Need a fast reaction protocol to reserve a Track. LLN Devices have limited information about the topology of the network and the TSCH schedule of other LLN Devices on the path. The protocol should Chen & Wang Expires September 7, 2015 [Page 6] Internet-Draft 6tisch-track-use-cases March 2015 quickly detect a Track reservation failure. Need an efficient negotiation protocol between LLN Devices multi-hop away from each other. LLN Devices on the path have to negotiate in order to reserve a Track, which may bring extra overhead to constrained devices. 6. Conclusions A Track can provide low latency, guaranteed throughput and high reliable for end-to-end communications. There are many use cases that can show the benefit of using a Track, such as industry networks, home networks, structure networks, health networks and vehicular networks. Moreover, different Track reservation schemes, such as centralized and distributed schemes, need to be proposed to handle a large variety of requirements. 7. Security Considerations This draft discussed the design considerations and operations of using Track in 6TiSCH networks. It does not introduce new security threats. 8. IANA Considerations This specification does not require IANA action. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 9.2. Informative References [I-D.ietf-6tisch-6top-interface] Wang, Q., Vilajosana, X., and T. Watteyne, "6TiSCH Operation Sublayer (6top) Interface", draft-ietf-6tisch- 6top-interface-02 (work in progress), October 2014. [I-D.ietf-6tisch-architecture] Thubert, P., Watteyne, T., Struik, R., and M. Richardson, "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4e", draft-ietf-6tisch-architecture-05 (work in progress), January 2015. Chen & Wang Expires September 7, 2015 [Page 7] Internet-Draft 6tisch-track-use-cases March 2015 [I-D.ietf-6tisch-terminology] Palattella, M., Thubert, P., Watteyne, T., and Q. Wang, "Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", draft-ietf-6tisch-terminology-03 (work in progress), January 2015. [I-D.ietf-6tisch-tsch] Watteyne, T., Palattella, M., and L. Grieco, "Using IEEE802.15.4e TSCH in an IoT context: Overview, Problem Statement and Goals", draft-ietf-6tisch-tsch-05 (work in progress), January 2015. [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009. 9.3. External Informative References [IEEE802154] IEEE standard for Information Technology, "IEEE std. 802.15.4, Part. 15.4: Wireless Medium Access Control (MAC) and Physical Layer (PHY) Specifications for Low-Rate Wireless Personal Area Networks", June 2011. [IEEE802154e] IEEE standard for Information Technology, "IEEE std. 802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area Networks (LR-WPANs) Amendment 1: MAC sublayer", April 2012. Authors' Addresses Zhuo Chen InterDigital Communications, LLC 781 Third Ave King of Prussia, PA 19406 USA Phone: +1 610 878 5730 Email: Zhuo.Chen@InterDigital.com Chen & Wang Expires September 7, 2015 [Page 8] Internet-Draft 6tisch-track-use-cases March 2015 Chonggang Wang InterDigital Communications, LLC 781 Third Ave King of Prussia, PA 19406 USA Phone: +1 610 878 5831 Email: Chonggang.Wang@InterDigital.com Chen & Wang Expires September 7, 2015 [Page 9]