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]