Internet DRAFT - draft-wang-6tisch-track-use-cases
draft-wang-6tisch-track-use-cases
6TiSCH Z. Chen
Internet-Draft C. Wang
Intended status: Informational InterDigital Communications, LLC
Expires: January 3, 2016 July 2, 2015
Use Cases and Requirements for using Track in 6TiSCH Networks
draft-wang-6tisch-track-use-cases-01
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 January 3, 2016.
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 January 3, 2016 [Page 1]
Internet-Draft 6tisch-track-use-cases July 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 . . . . . . . . . . . . . . . . . . . . 6
4.2.1. Remote Track Management . . . . . . . . . . . . . . . 6
4.2.2. Hop-by-hop Track Management . . . . . . . . . . . . . 6
4.3. Relationship with Detnet . . . . . . . . . . . . . . . . 6
5. Requirement for Track reservation schemes . . . . . . . . . . 7
5.1. Centralized Track reservation . . . . . . . . . . . . . . 7
5.2. Distributed Track reservation . . . . . . . . . . . . . . 7
6. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1. Normative References . . . . . . . . . . . . . . . . . . 8
9.2. Informative References . . . . . . . . . . . . . . . . . 8
9.3. External Informative References . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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
Chen & Wang Expires January 3, 2016 [Page 2]
Internet-Draft 6tisch-track-use-cases July 2015
and expand discussions pertaining to Track. We propose requirements
and use cases for different type of Track reservation schemes.
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 S, MAY
periodically send signalling packets to another actuator, e.g. LLN
Device D. For example, LLN Device S locate at the step 1 of the
automation assemble line, whenever it finishes a task, it will send
singling packets to LLN Device D 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. As mentioned in
RFC 5673 [RFC5673], tens of milliseconds of latency is typical in
fast control. In many of these systems, if a packet does not arrive
within the specified interval, the system enters an emergency
shutdown state, often with substantial financial repercussions.
Therefore, Reserving a Track between LLN device S and LLN device D
can guarantee the delay of these signalling packets.
Chen & Wang Expires January 3, 2016 [Page 3]
Internet-Draft 6tisch-track-use-cases July 2015
Moreover, the reliability of these signalling packets are extremely
important since a packet loss may result products with defects.
Therefore, a backup path may be used when the primary path is broken.
Reserving multiple Tracks between LLN device S and LLN device D can
also improve the reliability of these packet due to less
interference. 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.
3.2. Industrial monitoring applications
In an industrial monitoring application, sensors such as LLN M,
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 M, MAY detect a critical event, and sends a signalling
emergency message to the Central Controller in the network via
multiple paths. 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.
Chen & Wang Expires January 3, 2016 [Page 4]
Internet-Draft 6tisch-track-use-cases July 2015
---+-------- ............ ------------
| 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 S -- o --- D o o
o M o o o o o o o o o o
Figure 1: Use Case of an Industry Network
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
Chen & Wang Expires January 3, 2016 [Page 5]
Internet-Draft 6tisch-track-use-cases July 2015
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.
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.
4.3. Relationship with Detnet
Deterministic Networking (DetNet) [I-D.finn-detnet-architecture]
provides a capability to carry specified unicast or multicast data
streams for real-time application with extremely low data loss rates
Chen & Wang Expires January 3, 2016 [Page 6]
Internet-Draft 6tisch-track-use-cases July 2015
and maximum latency. Three techniques are employed by DetNet to
achieve theses QoS parameters, zero congestion loss, pinned-down
paths and packet replication and deletion.
As mentioned by DetNet [I-D.finn-detnet-architecture], Track in
6TiSCH network is an instance of a deterministic path. The
centralized and distributed path setup solutions in Detnet CAN be
used as a reference in 6TiSCH Track reservation solution. However,
Track in 6TiSCH is targeted to Low-power and Lossy Networks (LLNs),
techniques in Detnet must be customized for Track management in
6TiSCH considering low power consumption, TSCH MAC and constrained
devices with limited buffer and computation strength. For example,
Detnet proposes seamless Redundancy, Replicating packets and sending
them along at least two different paths. However, Replicating
packets may dramatically increase the energy consumption of the
network, which may be a concern for LLN networks. Therefore, Track
management should be studied in 6TiSCH WG, and the solutions can
influence the design of DetNet.
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
quickly detect a Track reservation failure. Need an efficient
Chen & Wang Expires January 3, 2016 [Page 7]
Internet-Draft 6tisch-track-use-cases July 2015
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.finn-detnet-architecture]
Finn, N., Thubert, P., and M. Teener, "Deterministic
Networking Architecture", draft-finn-detnet-
architecture-01 (work in progress), March 2015.
[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 January 3, 2016 [Page 8]
Internet-Draft 6tisch-track-use-cases July 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.
[RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney,
"Industrial Routing Requirements in Low-Power and Lossy
Networks", RFC 5673, October 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 January 3, 2016 [Page 9]
Internet-Draft 6tisch-track-use-cases July 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 January 3, 2016 [Page 10]
