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 protected]] On Behalf Of Pascal Thubert (pthubert) Sent: lundi 23 janvier 2017 19:12 To: [email protected] Subject: [6tisch] Proposing text on Tracks for the architecture draft 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
