[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

6TiSCH                                              G. Papadopoulos, Ed.
Internet-Draft                                              N. Montavont
Intended status: Informational                            IMT Atlantique
Expires: January 3, 2018                                      P. Thubert
                                                            July 2, 2017

   Exploiting Packet Replication and Elimination in Complex Tracks in
                              6TiSCH LLNs


   6TiSCH Packet Replication and Elimination mechanism consists in
   duplicating data packets into several paths in the network to
   increase reliability and provide low jitter.  Over a wireless medium,
   this technique can take advantage of communication overhearing, when
   parallel transmissions over two adjacent paths are scheduled.  This
   document presents the concept and details the required changes to the
   current specifications that will be necessary to enable this.

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, 2018.

Copyright Notice

   Copyright (c) 2017 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents

Papadopoulos, et al.     Expires January 3, 2018                [Page 1]

Internet-Draft        Address Protection ND for LLN            July 2017

   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.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Tracks  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Tracks Overview . . . . . . . . . . . . . . . . . . . . .   3
     3.2.  Complex Tracks  . . . . . . . . . . . . . . . . . . . . .   3
   4.  Packet Replication and Elimination principles . . . . . . . .   3
     4.1.  Packet Replication  . . . . . . . . . . . . . . . . . . .   4
     4.2.  Packet Elimination  . . . . . . . . . . . . . . . . . . .   5
     4.3.  Promiscuous Overhearing . . . . . . . . . . . . . . . . .   5
   5.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Requirements Related to Alternative Parent Selection  . .   6
     5.2.  Requirements Related to Promiscuous Overhearing . . . . .   6
     5.3.  Requirements Related to Cells without ACKs  . . . . . . .   7
     5.4.  Requirements Related to Packet Elimination  . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  Informative references  . . . . . . . . . . . . . . . . .   8
     8.2.  Other Informative References  . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   Some applications (such as Wireless Industrial IoT) require robust
   communications framework that guarantees data packet delivery in a
   given delay.  For example, a periodic process may need to be repeated
   identically every time.  To reach this ambition, the network must not
   only be reliable but also deterministic.

   A deterministic network ensures that the transported data packet will
   be carried out in a pre-defined and in a tight window of time,
   whatever the quality of the wireless links and the network
   congestion.  The goal of such network is to exhibit ultra-low jitter
   performance, i.e., close to 0.  IEEE std. 802.15.4 [IEEE802154-2015]
   has provision to provide guarantees for deterministic networks.
   Time-Slotted Channel Hopping (TSCH) provides transmission schedule to
   avoid random access to the medium and channel diversity to fight
   interferences.  However, TSCH is prone to retransmissions when the
   actual transmission was unsuccessful, due to external interference or

Papadopoulos, et al.     Expires January 3, 2018                [Page 2]

Internet-Draft        Address Protection ND for LLN            July 2017

   potential collision and, consequently, it increases the end-to-end
   delay performance.

   This document is mainly motivated by the ongoing work in the 6TiSCH
   working group.  The architecture of a 6TiSCH network is detailed in
   6TiSCH Architecture [I-D.ietf-6tisch-architecture] draft, which is
   used for the remainder of this document.  In this specification, we
   focus on Complex Track with Replication and Elimination.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3.  Tracks

3.1.  Tracks Overview

   The 6TiSCH architecture introduces the concept of Tracks in 6TiSCH
   Architecture [I-D.ietf-6tisch-architecture].  A simple track is
   composed of a sequence of cells (a combination of a transmitter, a
   receiver and a given channel offset) to ensure the transmission of a
   single packet from a source 6TiSCH node to a destination 6TiSCH node
   across a 6TiSCH multihop path.

3.2.  Complex Tracks

   A Complex Track is designed as a directed acyclic graph from a source
   6TiSCH node towards a destination 6TiSCH node to support multi-path
   forwarding, as introduced in 6TiSCH Architecture
   [I-D.ietf-6tisch-architecture].  By employing DetNet Packet
   Replication and Elimination (PRE) techniques, several paths may be
   computed, and these paths may be more or less independent.  For
   example, a complex Track may branch off and rejoin over non-congruent
   paths (branches).

   In the following Section, we will detail Deterministic Networks PRE

4.  Packet Replication and Elimination principles

   In a nutshell, PRE consists in establishing several paths in a
   network to provide redundancy and parallel transmissions to bound the
   delay to traverse the network.  Optionnally, promiscuous listening
   between paths is possible, such that the nodes on one path may
   overhear transmissions along the other path.  Considering the
   scenario depicted in Figure 1, many different paths are possible for

Papadopoulos, et al.     Expires January 3, 2018                [Page 3]

Internet-Draft        Address Protection ND for LLN            July 2017

   S to reach R.  A simple way to take benefit from this topology could
   be to use the two independent paths via nodes A, C, E and via B, D,
   F.  But more complex paths are possible by interleaving transmissions
   from one level of the path to the upper level in a ship-in-the-night
   fashion.  The 6TiSCH PRE may also take advantage to the shared
   properties of the medium to compensate for the potential loss that is
   incurred with radio transmissions.  For instance, when the source
   sends to A, B may listen and get a second chance to receive the frame
   without an additional transmission.  Note that B would not have to
   listen if it already received that particular frame at an earlier
   time slot.

                               (A)   (C)   (E)

                 source (S)                       (R) (root)

                               (B)   (D)   (F)

    Figure 1: A Typical Ladder Shape with Two Parallel Paths Toward the

   PRE model can be implemented in both centralized and distributed
   scheduling approach.  In the centralized approach, a scheduler
   calculates the routes and schedules the communication among the nodes
   along a circuit such as a Label switched path.  In the distributed
   approach, each node selects its route to the destination.  In both
   cases, a default parent and alternate parent(s) should be selected to
   set up complex tracks.

   In the following Subsections, detailed description of all required
   operations defined by PRE, namely, Alternative Path Selection, Packet
   Replication, Packet Elimination and Promiscuous Overhearing, will be

4.1.  Packet Replication

   The objective of PRE is to offer deterministic networking properties,
   with high reliability and bounded latency.  To achieve this goal,
   determinism in every level of the forwarding path should be
   guaranteed.  By employing Packet Replication procedure, each node
   transmits (i.e., replicates) each data packet to both its Default
   Parent (DP) and Alternative Parent (AP).  To do so, each node (i.e.,
   source and intermediate 6TiSCH nodes) transmits the data packet twice
   in unicast to each parent.  For instance, in Figure 2, the source
   6TiSCH node S is transmitting the packet to both parents, nodes A and

Papadopoulos, et al.     Expires January 3, 2018                [Page 4]

Internet-Draft        Address Protection ND for LLN            July 2017

   B, in two different timeslots within the same TSCH slotframe.  Thus,
   the packet eventually obtains parallel paths to the destination.

                      ===> (A) ====> (C) ====> (E) ====
                    //                                 \\
          source (S)                                     (R) (root)
                    \\                                 //
                      ===> (B) ====> (D) ====> (F) ====

   Figure 2: Packet Replication: S transmits twice the same data packet,
                     to its DP (A) and to its AP (B).

4.2.  Packet Elimination

   The replication operation increases the traffic load in the network,
   due to packet duplications.  Thus, Packet Elimination operation
   should be applied at each RPL DAG level to reduce the unnecessary
   traffic.  To this aim, once a node receives the first copy of a data
   packet, it discards the following copies.  Because the first copy
   that reaches a node is the one that counts, and thus will be the only
   copy that will be forwarded upward.

4.3.  Promiscuous Overhearing

   Considering that the wireless medium is broadcast by nature, any
   neighbor of a transmitter may overhear a transmission.  By employing
   the Promiscuous Overhearing operation, DP and AP eventually have more
   chances to receive the data packets.  In Figure 3, when node A is
   transmitting to its DP (node C), the AP (node D) and its Sibling
   (node B) may decode this data packet as well.  As a result, by
   employing correlated paths, a node may have multiple opportunities to
   receive a given data packet.  This feature not only enhances the end-
   to-end reliability but also it reduces the end-to-end delay.

                      ===> (A) ====> (C) ====> (E) ====
                    //     ^ | \\                      \\
          source (S)       | |   \\                      (R) (root)
                    \\     | v     \\                  //
                      ===> (B) ====> (D) ====> (F) ====

    Figure 3: Unicast to DP with Overhearing: by employing Promiscuous
   Overhearing, DP, AP and the Sibling nodes have more opportunities to
                       receive the same data packet.

Papadopoulos, et al.     Expires January 3, 2018                [Page 5]

Internet-Draft        Address Protection ND for LLN            July 2017

5.  Requirements

5.1.  Requirements Related to Alternative Parent Selection

   To perform the Replication procedure, it is necessary to define the
   Alternative Parent(s) and, consequently, the path to the destination
   6TiSCH node, for each node in the 6TiSCH network.  An AP can be
   selected in many different ways, and is dependent on the
   implementation.  However, control packets should give some metrics to
   discriminate between different neighbors.

   Related requirements are:

   Req1.1: To design such algorithm, RPL DODAG Information Object (DIO)
   message format SHOULD be extended with an option to allow for a
   6TiSCH node to learn additional information for its potential parent
   and its list of parents.

   Req1.2: The routing protocol SHOULD be extended to allow for each
   6TiSCH node to select AP(s) and duplicate a packet to several next

5.2.  Requirements Related to Promiscuous Overhearing

   As stated previously, to further increase the 6TiSCH network
   reliability and to achieve deterministic packet deliveries at the
   destination 6TiSCH node, promiscuous overhearing can be considered.

   As it is described in BCP 210 [RFC8180], in TSCH mode, the data
   frames are transmitted in unicast mode and are acknowledged by the
   receiving neighbor.  To perform the promiscuous overhearing
   procedure, there SHOULD be an option for the transmitted frames,
   i.e., in unicast, to be overheard by the potential neighborhood
   6TiSCH node.

   Related requirements are:

   Req2.1: The 6top Protocol [I-D.ietf-6tisch-6top-protocol] SHOULD be
   extended to allow optionally a cell reservation with two receivers,
   i.e., DP and AP.  Considering that each frame may be transmitted
   twice in unicast to each parent, then depending the transmission,
   either DP will acknowledge the frame or AP will.

   Req2.2: Next, to request the overhearing cells, the 6P ADD Request
   Format SHOULD be transmitted either twice to each parent, i.e., DP
   and AP, or once in multicast to both parents.

Papadopoulos, et al.     Expires January 3, 2018                [Page 6]

Internet-Draft        Address Protection ND for LLN            July 2017

5.3.  Requirements Related to Cells without ACKs

   As stated in BCP 210 [RFC8180], each date frame is acknowledged by
   the receiving 6TiSCH node.  However, by employing promiscuous
   overhearing operation, particular attention should be given to who
   will acknowledge a transmission, i.e., the DP, and / or one of the

   Related requirements are:

   Req4.1: To avoid the ACK collision, the TSCH Schedule as per BCP 210
   [RFC8180], only the DP MUST acknowledge the data packet.

   Req4.2: Alternatively, to achieve further consistency the overheard
   transmission need be acknowledged by both parents, i.e., DP and AP.
   To do so, BCP 210 [RFC8180] SHOULD be extended accordingly.

5.4.  Requirements Related to Packet Elimination

   By employing packet replication operation, the 6TiSCH network expects
   to perform the packet elimination operation along a complex Track to
   bound the number of the duplicated packets, i.e., the unnecessary

   Related requirements are:

   Req5.1: As per 6TiSCH Architecture [I-D.ietf-6tisch-architecture],
   6TiSCH has no position about how the sequence numbers would be tagged
   in the packet.  However, it comes with Tagging Packets for Flow
   Identification.  More specifically, a 6TiSCH network expects that
   timeslots corresponding to copies of a same frame along a complex
   Track are correlated by configuration and, thus, does not need to
   process the sequence numbers.

6.  Security Considerations


7.  IANA Considerations

   This document has no IANA considerations.

8.  References

Papadopoulos, et al.     Expires January 3, 2018                [Page 7]

Internet-Draft        Address Protection ND for LLN            July 2017

8.1.  Informative references

              Wang, Q., Vilajosana, X., and T. Watteyne, "6top Protocol
              (6P)", draft-ietf-6tisch-6top-protocol-07 (work in
              progress), June 2017.

              Thubert, P., "An Architecture for IPv6 over the TSCH mode
              of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work
              in progress), January 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,

   [RFC8180]  Vilajosana, X., Ed., Pister, K., and T. Watteyne, "Minimal
              IPv6 over the TSCH Mode of IEEE 802.15.4e (6TiSCH)
              Configuration", BCP 210, RFC 8180, DOI 10.17487/RFC8180,
              May 2017, <http://www.rfc-editor.org/info/rfc8180>.

8.2.  Other Informative References

              IEEE standard for Information Technology, "IEEE standard
              for Information Technology, "IEEE Std 802.15.4-2015
              Standard for Low-Rate Wireless Personal Area Networks
              (WPANs)", December 2015".

Authors' Addresses

   Georgios Papadopoulos (editor)
   IMT Atlantique
   Office B00 - 102A
   2 Rue de la Chataigneraie
   Cesson-Sevigne - Rennes  35510

   Phone: +33 299 12 70 04
   Email: georgios.papadopoulos@imt-atlantique.fr

Papadopoulos, et al.     Expires January 3, 2018                [Page 8]

Internet-Draft        Address Protection ND for LLN            July 2017

   Nicolas Montavont
   IMT Atlantique
   Office B00 - 106A
   2 Rue de la Chataigneraie
   Cesson-Sevigne - Rennes  35510

   Phone: +33 299 12 70 23
   Email: nicolas.montavont@imt-atlantique.fr

   Pascal Thubert
   Cisco Systems, Inc
   Building D
   45 Allee des Ormes - BP1200
   MOUGINS - Sophia Antipolis  06254

   Phone: +33 497 23 26 34
   Email: pthubert@cisco.com

Papadopoulos, et al.     Expires January 3, 2018                [Page 9]

Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/