Subject: [6tisch] Proposing text on Tracks for the architecture draft

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 23 Jan 2017 18:11:47 +0000

Dear all :

Now is the time to refresh the architecture draft. Part of what's missing is related to the https://tools.ietf.org/html/draft-thubert-6tisch-4detnet-01 draft, which we are chartered to produce but not turn to an RFC.

In particular, we need to reflect the capabilities for replication and elimination that echo the work at detnet.

Please let me know if the text below fails to represent your understanding of our work so far, and in which fashion:

4.5.  On Tracks

4.5.1.  General Behavior of Tracks

   The architecture introduces the concept of a Track, which is a
   directed path from a source 6TiSCH node to a destination 6TiSCH node
   across a 6TiSCH LLN.  A Track is the 6TiSCH instantiation of the
   concept of a Deterministic Path as described in
   [I-D.ietf-detnet-architecture].  Constrained resources such as memory
   buffers are reserved for that Track in intermediate 6TiSCH nodes to
   avoid loss related to limited capacity.  A 6TiSCH node along a Track
   not only knows which bundles of cells it should use to receive
   packets from a previous hop, but also knows which bundle(s) it should
   use to send packets to its next hop along the Track.

   A Track is composed of bundles of cells with related schedules and
   logical relationships and that ensure that a packet that is injected
   in a Track will progress in due time all the way to destination.
   Multiple cells may be scheduled in a Track for the transmission of a
   single packet, in which case the normal operation of IEEE std
   802.15.4 Automatic Repeat-reQuest (ARQ) can take place; the
   acknowledgment may be omitted in some cases, for instance if there is
   no scheduled cell for a possible retry.

   There are several benefits for using a Track to forward a packet from
   a source node to the destination node.

   1.  Track forwarding, as further described in Section 4.6.1, 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.

   2.  Since channel resources, i.e. bundles of cells, have been
       reserved for communications between 6TiSCH nodes of each hop on
       the Track, the throughput and the maximum latency of the traffic
       along a Track are guaranteed and the jitter is maintained small.

   3.  By knowing the scheduled time slots of incoming bundle(s) and
       outgoing bundle(s), 6TiSCH nodes on a Track could save more
       energy by staying in sleep state during in-active slots.

   4.  Tracks are protected from interfering with one another if a cell
       belongs to at most one Track, and congestion loss is avoided if
       at most one packet can be presented to the MAC to use that cell.
       Tracks enhance the reliability of transmissions and thus further
       improve the energy consumption in LLN Devices by reducing the
       chances of retransmission.

4.5.2.  Serial Track

   A Serial (or simple) Track is the 6TiSCH version of a circuit; a
   bundle of cells that are programmed to receive (RX-cells) is uniquely
   paired to a bundle of cells that are set to transmit (TX-cells),
   representing a Layer-2 forwarding state which can be used regardless
   of the network layer protocol.

   A Serial Track is thus formed end-to-end as a succession of paired
   bundles, a receive bundle from the previous hop and a transmit bundle
   to the next hop along the Track.  For a given iteration of the device
   schedule, the effective channel of the cell is obtained by adding a
   pseudo-random number to the channelOffset of the cell, which results
   in a rotation of the frequency that used for transmission.

   The bundles may be computed so as to accommodate both variable rates
   and retransmissions, so they might not be fully used at a given
   iteration of the schedule.

4.5.3.  Complex Track with Replication and Elimination

   As opposed to a Serial Track that is a sequence of nodes and links, a
   Complex Track is shaped as a directed acyclic graph towards a
   destination to support multi-path forwarding and route around
   failures.

   A Complex Track may also branch off and rejoin, for the purpose of
   the DetNet Packet Replication and Elimination (PRE), over non
   congruent branches.  PRE may be used to complement Layer-2 ARQ to
   meet industrial expectations in Packet Delivery Ratio (PDR), in
   particular when the Track extends beyond the 6TiSCH network in a
   larger DetNet network.

   The art of Deterministic Networks already include PRE techniques.
   Example standards include the Parallel Redundancy Protocol (PRP) and
   the High-availability Seamless Redundancy (HSR) [IEC62439].

   At each 6TiSCH hop along the Track, the PCE may schedule more than
   one timeslot for a packet, so as to support Layer-2 retries (ARQ).
   It is also possible that the field device only uses the second branch
   if sending over the first branch fails.

   In the art of TSCH, a path does not necessarily support PRE but it is
   almost systematically multi-path.  This means that a Track is
   scheduled so as to ensure that each hop has at least two forwarding
   solutions, and the forwarding decision is to try the preferred one
   and use the other in case of Layer-2 transmission failure as detected
   by ARQ.

4.5.4.  DetNet End-to-end Path

   Ultimately, DetNet should enable to extend a Track beyond the 6TiSCH
   LLN.  Figure 9 illustrates a Track that is laid out from a field
   device in a 6TiSCH network to an IoT gateway that is located on an
   802.1 Time-Sensitive Networking (TSN) backbone.

                     +-=-=-+
                     | IoT |
                     | G/W |
                     +-=-=-+
                        ^  <=== Elimination
                       | |
        Track branch   | |
               +-=-=-=-+ +-=-=-=-=+ Subnet Backbone
               |                  |
            +-=|-=+            +-=|-=+
            |  |  | Backbone   |  |  | Backbone
       o    |  |  | router     |  |  | router
            +-=/-=+            +-=|-=+
       o     /    o     o-=-o-=-=/       o
           o    o-=-o-=/   o      o   o  o   o
      o     \  /     o               o   LLN    o
         o   v  <=== Replication
             o

                 Figure 9: End-to-End deterministic Track

   The Replication function in the 6TiSCH Node sends a copy of each
   packet over two different branches, and the PCE schedules each hop of
   both branches so that the two copies arrive in due time at the
   gateway.  In case of a loss on one branch, hopefully the other copy
   of the packet still makes it in due time.  If two copies make it to
   the IoT gateway, the Elimination function in the gateway ignores the
   extra packet and presents only one copy to upper layers.

<snip>

4.7.1.  Packet Marking and Handling

   All packets inside a 6TiSCH domain must carry the Instance ID that
   identifies the 6TiSCH topology that is to be used for routing and
   forwarding that packet.  The location of that information must be the
   same for all packets forwarded inside the domain.

   For packets that are routed by a PCE along a Track, the tuple formed
   by the IPv6 source address and a local RPLInstanceID in the packet
   identify uniquely the Track and associated transmit bundle.

   For packets that are routed by RPL, that information is the
   RPLInstanceID which is carried in the RPL Packet Information, as
   discussed in section 11.2 of [RFC6550], "Loop Avoidance and
   Detection".

   The RPL Packet Information (RPI) is carried in IPv6 packets as a RPL
  option in the IPv6 Hop-By-Hop Header [RFC6553].

   A compression mechanism for the RPL packet artifacts that integrates
   the compression of IP-in-IP encapsulation and the Routing Header type
   3 [RFC6554] with that of the RPI in a 6LoWPAN dispatch/header type is
   specified in [RFC8025] and [I-D.ietf-roll-routing-dispatch].

   Either way, the method and format used for encoding the RPLInstanceID
   is generalized to all 6TiSCH topological Instances, which include
   both RPL Instances and Tracks.

4.7.2.  Replication, Retries and Elimination

   6TiSCH expects elimination and replication of packets along a complex
   Track, but has no position about how the sequence numbers would be
   tagged in the packet.

   As it goes, 6TiSCH expects that timeSlots corresponding to copies of
   a same packet along a Track are correlated by configuration, and does
   not need to process the sequence numbers.

   The semantics of the configuration will enable correlated timeSlots
   to be grouped for transmit (and respectively receive) with a 'OR'
   relations, and then a 'AND' relation would be configurable between
   groups.  The semantics is that if the transmit (and respectively
   receive) operation succeeded in one timeSlot in a 'OR' group, then
   all the other timeSLots in the group are ignored.  Now, if there are
   at least two groups, the 'AND' relation between the groups indicates
   that one operation must succeed in each of the groups.

   On the transmit side, timeSlots provisioned for retries along a same
   branch of a Track are placed a same 'OR' group.  The 'OR' relation
   indicates that if a transmission is acknowledged, then further
   transmissions should not be attempted for timeSlots in that group.
   There are as many 'OR' groups as there are branches of the Track
   departing from this node.  Different 'OR' groups are programmed for
   the purpose of replication, each group corresponding to one branch of
   the Track.  The 'AND' relation between the groups indicates that
   transmission over any of branches must be attempted regardless of
   whether a transmission succeeded in another branch.  It is also
   possible to place cells to different next-hop routers in a same 'OR'
   group.  This allows to route along multi-path tracks, trying one
   next-hop and then another only if sending to the first fails.

   On the receive side, all timeSlots are programmed in a same 'OR'
   group.  Retries of a same copy as well as converging branches for
   elimination are converged, meaning that the first successful
   reception is enough and that all the other timeSlots can be ignored.

4.7.3.  Differentiated Services Per-Hop-Behavior

   Additionally, an IP packet that is sent along a Track uses the
   Differentiated Services Per-Hop-Behavior Group called Deterministic
   Forwarding, as described in
   [I-D.svshah-tsvwg-deterministic-forwarding].

Many Thanks in advance!

Pascal

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 27 Jan 2017 10:10:33 +0000

Dear all :

Hearing nothing I published the update. Please review / comment the diffs at  https://tools.ietf.org/rfcdiff?url2=draft-ietf-6tisch-architecture-11.txt

Next is to add a discussion on SF and 6P.

Cheers,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: lundi 23 janvier 2017 19:12
To: [email-masked]
Subject: [6tisch] Proposing text on Tracks for the architecture draft

Dear all :

4.5.  On Tracks

4.5.2.  Serial Track

                     +-=-=-+
                     | IoT |
                     | G/W |
                     +-=-=-+
                        ^  <=== Elimination
                       | |
        Track branch   | |

<snip>

Many Thanks in advance!

Pascal