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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
