One document matched: draft-thubert-6tisch-4detnet-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="no"?>
<?rfc subcompact="no"?>
<?rfc authorship="yes"?>
<?rfc tocappendix="yes"?>
<rfc category="info" docName="draft-thubert-6tisch-4detnet-01" ipr="trust200902">
<front>
<title abbrev="6tisch-4detnet">6TiSCH requirements for DetNet</title>
<author initials="P" surname="Thubert" fullname="Pascal Thubert" role="editor">
<organization abbrev="Cisco">Cisco Systems, Inc</organization>
<address>
<postal>
<street>Building D</street>
<street>45 Allee des Ormes - BP1200 </street>
<city>MOUGINS - Sophia Antipolis</city>
<code>06254</code>
<country>FRANCE</country>
</postal>
<phone>+33 497 23 26 34</phone>
<email>pthubert@cisco.com</email>
</address>
</author>
<date/>
<area>Internet Area</area>
<workgroup>6TiSCH</workgroup>
<keyword>Draft</keyword>
<abstract>
<t>
This document builds on the 6TiSCH architecture that defines, among
others, mechanisms to establish and maintain deterministic routing and
scheduling in a centralized fashion. The document details dependencies
on DetNet and PCE controller to express topologies and capabilities,
as well as abstract state that the controller must be able to program
into the network devices to enable deterministic forwarding operations.
<!--
Backbone Routers perform proxy Neighbor Discovery operations over
the backbone on behalf of the wireless devices, so they can share a same
subnet and appear to be connected to the same backbone as classical devices.
-->
</t>
</abstract>
<note title="Requirements Language">
<t>
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 <xref target="RFC2119">RFC 2119</xref>.
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>
The emergence of wireless technology has enabled a variety of new
devices to get interconnected, at a very low marginal cost per device,
at any distance ranging from Near Field to interplanetary, and in
circumstances where wiring may not be practical, for instance
on fast-moving or rotating devices.
</t>
<t>
At the same time, a new breed of Time Sensitive Networks is being
developed to enable traffic that is highly sensitive to jitter,
quite sensitive to latency, and with a high degree of operational
criticality so that loss should be minimized at all times.
Such traffic is not limited to professional Audio/ Video networks, but
is also found in command and control operations such as industrial
automation and vehicular sensors and actuators.
</t>
<t>
At IEEE802.1, the <xref target="IEEE802.1TSNTG">Audio/Video Task Group
</xref>
Time Sensitive Networking (TSN) to address Deterministic Ethernet.
The Medium access Control (MAC) of IEEE802.15.4
<xref target="IEEE802154"/> has evolved with the new
<xref target="I-D.ietf-6tisch-tsch">
TimeSlotted Channel Hopping (TSCH)</xref> mode
for deterministic industrial-type applications. TSCH was introduced
with the IEEE802.15.4e <xref target="IEEE802154e"/> amendment and will
be wrapped up in the next revision of the IEEE802.15.4 standard.
For all practical purpose, this document
is expected to be insensitive to the future versions of
the IEEE802.15.4 standard, which is thus referenced undated.
</t>
<t>
Though at a different time scale, both TSN and TSCH standards provide
Deterministic capabilities to the point that a packet that pertains
to a certain flow crosses the network from node to node following
a very precise schedule, as a train that leaves intermediate stations
at precise times along its path. With TSCH, time is formatted into
timeSlots, and an individual cell is allocated to unicast or
broadcast communication at the MAC level. The time-slotted operation
reduces collisions, saves energy, and enables to more closely engineer
the network for deterministic properties.
The channel hopping aspect is a simple and efficient technique to combat
multi-path fading and co-channel interferences (for example by
Wi-Fi emitters).
</t>
<t>
The <xref target="I-D.ietf-6tisch-architecture"> 6TiSCH Architecture </xref>
defines a remote monitoring and scheduling management of a TSCH network
by a Path Computation Element (PCE), which cooperates with an abstract
Network Management Entity (NME) to manage timeSlots and device resources
in a manner that minimizes the interaction with and the load placed on the
constrained devices.
</t>
<t>
This Architecture applies the concepts of Deterministic Networking on a
TSCH network to enable the switching of timeSlots in a G-MPLS manner.
This document details the dependencies that 6TiSCH has on
<xref target="PCE">PCE</xref> and
<xref target="I-D.finn-detnet-architecture">DetNet</xref> to provide the
necessary capabilities that may be specific to such networks.
In turn, DetNet is expected to integrate and maintain consistency with the
work that has taken place and is continuing at IEEE802.1TSN and AVnu.
</t>
</section>
<section title="Terminology">
<t>
Readers are expected to be familiar with all the terms and concepts
that are discussed in <xref target="I-D.ietf-ipv6-multilink-subnets">
"Multi-link Subnet Support in IPv6"</xref>.
</t>
<t>
The draft uses terminology defined or referenced in
<xref target="I-D.ietf-6tisch-terminology"/> and
<xref target="I-D.ietf-roll-rpl-industrial-applicability"/>.
</t>
<t>
The draft also conforms to the terms and models described in
<xref target="RFC3444"/> and uses the vocabulary and the concepts
defined in <xref target="RFC4291"/> for the IPv6 Architecture.
</t>
</section>
<section title="6TiSCH Overview">
<t>
The scope of the present work is a subnet that, in its basic
configuration, is made of a
<xref target="I-D.ietf-6tisch-tsch">TSCH</xref>
MAC Low Power Lossy Network (LLN).
</t>
<t>
<figure anchor="fig1" title="Basic Configuration of a 6TiSCH Network">
<artwork><![CDATA[
---+-------- ............ ------------
| External Network |
| +-----+
+-----+ | NME |
| | LLN Border | |
| | router +-----+
+-----+
o o o
o o o o
o o LLN o o o
o o o o
o
]]></artwork>
</figure>
</t>
<t>
In the extended configuration, a Backbone Router (6BBR) federates
multiple 6TiSCH in a single subnet over a backbone.
6TiSCH 6BBRs synchronize with one another over the backbone, so as
to ensure that the multiple LLNs that form the IPv6 subnet stay
tightly synchronized.
</t>
<t>
<figure anchor="fig2" title="Extended Configuration of a 6TiSCH Network">
<artwork><![CDATA[
---+-------- ............ ------------
| External Network |
| +-----+
| +-----+ | NME |
+-----+ | +-----+ | |
| | Router | | PCE | +-----+
| | +--| |
+-----+ +-----+
| |
| 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 LLN o o o o
o o o o o o o o o o o o
]]></artwork>
</figure>
</t>
<t>
If the Backbone is Deterministic, then the
Backbone Router ensures that the end-to-end deterministic
behavior is maintained between the LLN and the backbone.
This SHOULD be done in conformance to the
<xref target="I-D.finn-detnet-architecture">DetNet Architecture</xref>
which studies Layer-3 aspects of Deterministic Networks, and covers
networks that span multiple Layer-2 domains.
One particular requirement is that the PCE MUST be able to compute a
deterministic path and to end across the TSCH network and an IEEE802.1
TSN Ethernet backbone, and DetNet MUST enable end-to-end deterministic
forwarding.
</t>
<t>
6TiSCH defines the concept of a Track, which is a complex form of a
uni-directional Circuit (<xref target="I-D.ietf-6tisch-terminology"/>).
As opposed to a simple circuit that is a sequence
of nodes and links, a Track is shaped as a directed acyclic graph towards
a destination to support multi-path forwarding and route around failures.
A Track may also branch off and rejoin, for the purpose of the so-called
Packet Replication and Elimination (PRE), over non congruent branches.
PRE may be used to complement layer-2 Automatic Repeat reQuest (ARQ)
to meet industrial expectations in Packet Delivery Ratio (PDR), in
particular when the Track extends beyond the 6TiSCH network.
</t>
<t>
<figure anchor="fig3" title="End-to-End deterministic Track">
<artwork><![CDATA[
+-----+
| 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
]]></artwork>
</figure>
</t>
<t>In the example above, a Track is laid out from a field device in a
6TiSCH network to an IoT gateway that is located on a IEEE802.1 TSN
backbone.
</t>
<t>
The Replication function in the field device 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.
</t>
<t>
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.
</t>
<t>
In current deployments, a TSCH Track does not necessarily support PRE but
is 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.
</t>
<section title="TSCH and 6top">
<t>
6top is a logical link control sitting between the IP layer and the
TSCH MAC layer, which provides the link abstraction that is required
for IP operations. The 6top operations are specified in
<xref target="I-D.wang-6tisch-6top-sublayer"/>.
</t>
<t>
The 6top data model and management interfaces are further discussed
in <xref target="I-D.ietf-6tisch-6top-interface"/> and
<xref target="I-D.ietf-6tisch-coap"/>.
</t>
<t>
The architecture defines "soft" cells and "hard" cells. "Hard" cells
are owned and managed by an separate scheduling entity (e.g. a PCE)
that specifies the slotOffset/channelOffset of the cells to be
added/moved/deleted, in which case 6top can only act as instructed,
and may not move hard cells in the TSCH schedule on its own.
</t>
</section>
<section anchor="slotFrames" title="SlotFrames and Priorities">
<t>A slotFrame is the base object that the PCE needs to manipulate
to program a schedule into an LLN node. Elaboration on that concept
can be fond in section "SlotFrames and Priorities" of
<xref target="I-D.ietf-6tisch-architecture"/>
</t>
<t>
IEEE802.15.4 TSCH avoids contention on the medium by formatting time
and frequencies in cells of transmission of equal duration.
In order to describe that formatting of time and frequencies, the
6TiSCH architecture defines a global concept that is called a Channel
Distribution and Usage (CDU) matrix; a CDU matrix is a matrix of
cells with an height equal to the number of available channels
(indexed by ChannelOffsets) and a width (in timeSlots) that is the
period of the network scheduling operation (indexed by slotOffsets) for
that CDU matrix. The size of a cell is a timeSlot duration, and
values of 10 to 15 milliseconds are typical in 802.15.4 TSCH to
accommodate for the transmission of a frame and an ack, including the
security validation on the receive side which may take up to a few
milliseconds on some device architecture.
</t>
<t>
The frequency used by a cell in the matrix rotates in a pseudo-random
fashion, from an initial position at an epoch time, as the matrix
iterates over and over.
</t>
<t>
A CDU matrix is computed by the PCE, but unallocated timeSlots may be
used opportunistically by the nodes for classical best effort IP
traffic. The PCE has precedence in the allocation in case of a conflict.
</t>
<t>
In a given network, there might be multiple CDU matrices that operate
with different width, so they have different durations and represent
different periodic operations.
It is recommended that all CDU matrices in a 6TiSCH domain operate with
the same cell duration and are aligned, so as to reduce the
chances of interferences from slotted-aloha operations.
The PCE MUST compute the CDU matrices and shared that knowledge with
all the nodes. The matrices are used in particular to define slotFrames.
</t>
<t>
A slotFrame is a MAC-level abstraction that is common to all nodes and
contains a series of timeSlots of equal length and precedence.
It is characterized by a slotFrame_ID, and a slotFrame_size.
A slotFrame aligns to a CDU matrix for its parameters, such as number
and duration of timeSlots.
</t>
<t>
Multiple slotFrames can coexist in a node schedule, i.e., a node can
have multiple activities scheduled in different slotFrames, based on
the precedence of the 6TiSCH topologies. The slotFrames may be
aligned to different CDU matrices and thus have different width.
There is typically one slotFrame for scheduled traffic that has the
highest precedence and one or more slotFrame(s) for RPL traffic.
The timeSlots in the slotFrame are indexed by the SlotOffset;
the first cell is at SlotOffset 0.
</t>
<t>
The 6TiSCH architecture introduces the concept of chunks
(<xref target="I-D.ietf-6tisch-terminology"/>) to operate
such spectrum distribution for a whole group of cells at a time.
The CDU matrix is formatted into a set of chunks, each of them
identified uniquely by a chunk-ID.
The PCE MUST compute the partitioning of CDU matrices into chunks and
shared that knowledge with all the nodes in a 6TiSCH network.
</t>
<t>
<figure anchor="fig10" title="CDU matrix Partitioning in Chunks">
<artwork>
<![CDATA[
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 0 |chnkA|chnkP|chnk7|chnkO|chnk2|chnkK|chnk1| ... |chnkZ|
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 1 |chnkB|chnkQ|chnkA|chnkP|chnk3|chnkL|chnk2| ... |chnk1|
+-----+-----+-----+-----+-----+-----+-----+ +-----+
...
+-----+-----+-----+-----+-----+-----+-----+ +-----+
chan.Off. 15 |chnkO|chnk6|chnkN|chnk1|chnkJ|chnkZ|chnkI| ... |chnkG|
+-----+-----+-----+-----+-----+-----+-----+ +-----+
0 1 2 3 4 5 6 M
]]>
</artwork>
</figure>
</t>
<t>
The appropriation of a chunk can be requested explicitly by the
PCE to any node. After a successful appropriation, the PCE owns the
cells in that chunk, and may use them as hard cells to set up Tracks.
</t>
</section>
<section anchor="schd" title="Schedule Management by a PCE">
<t>
6TiSCH supports a mixed model of centralized routes and distributed routes.
Centralized routes can for example be computed by a entity such as a PCE.
Distributed routes are computed by RPL.
</t>
<t>
Both methods may inject routes in the Routing Tables of the 6TiSCH routers.
In either case, each route is associated with a 6TiSCH topology that can
be a RPL Instance topology or a track. The 6TiSCH topology is
indexed by a Instance ID, in a format that reuses the RPLInstanceID as
defined in <xref target="RFC6550">RPL</xref>.
</t>
<t>
Both RPL and PCE rely on shared sources such as policies to define Global
and Local RPLInstanceIDs that can be used by either method. It is possible
for centralized and distributed routing to share a same topology.
Generally they will operate in different slotFrames, and centralized
routes will be used for scheduled traffic and will have precedence over
distributed routes in case of conflict between the slotFrames.
</t>
<t>
Section "Schedule Management Mechanisms" of the 6TiSCH architecture
describes 4 paradigms to manage the TSCH schedule of the LLN nodes:
Static Scheduling, neighbor-to-neighbor Scheduling, remote monitoring
and scheduling management, and Hop-by-hop scheduling. The Track operation
for DetNet corresponds to a remote monitoring and scheduling management
by a PCE.
</t>
<t>
The 6top interface document
<xref target="I-D.ietf-6tisch-6top-interface"/>
specifies the generic data model that can be used to monitor and manage
resources of the 6top sublayer. Abstract methods are suggested for use
by a management entity in the device. The data model also enables
remote control operations on the 6top sublayer.
</t>
<t>
<xref target="I-D.ietf-6tisch-coap"/> defines an mapping of
the 6top set of commands, which is described in
<xref target="I-D.ietf-6tisch-6top-interface"/>, to CoAP resources.
This allows an entity to interact with the 6top layer of a node that
is multiple hops away in a RESTful fashion.
</t>
<t>
<xref target="I-D.ietf-6tisch-coap"/> also defines a basic set CoAP
resources and associated RESTful access methods
(GET/PUT/POST/DELETE). The payload (body) of the CoAP messages
is encoded using the CBOR format.
The PCE commands are expected to be issued directly as CoAP requests
or to be mapped back and forth into CoAP by a gateway function at
the edge of the 6TiSCH network. For instance, it is possible that a
mapping entity on the backbone transforms a non-CoAP protocol such
as PCEP into the RESTful interfaces that the 6TiSCH devices support.
This architecture will be refined to comply with
<xref target="I-D.finn-detnet-architecture">DetNet</xref>
when the work is formalized.
</t>
</section>
<section anchor="fwd" title="Track Forwarding">
<t>
By forwarding, this specification means the per-packet operation that
allows to deliver a packet to a next hop or an upper layer in this node.
Forwarding is based on pre-existing state that was installed as a
result of the routing computation of a Track by a PCE.
The 6TiSCH architecture supports three different forwarding model,
G-MPLS Track Forwarding (TF), 6LoWPAN Fragment Forwarding (FF) and
IPv6 Forwarding (6F) which is the classical IP operation.
The DetNet case relates to the Track Forwarding operation under the
control of a PCE.
</t>
<t>
A Track is a unidirectional path between a source and a destination.
In a Track cell, the normal operation of IEEE802.15.4
Automatic Repeat-reQuest (ARQ) usually happens, though the
acknowledgment may be omitted in some cases, for instance if there
is no scheduled cell for a retry.
</t>
<t>
Track Forwarding is the simplest and fastest. A bundle of cells set
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 that can be used regardless of the network layer protocol.
This model can effectively be seen as a Generalized Multi-protocol
Label Switching (G-MPLS) operation in that the information used to
switch a frame is not an explicit label, but rather related to other
properties of the way the packet was received, a particular cell in
the case of 6TiSCH.
As a result, as long as the TSCH MAC (and Layer-2 security) accepts
a frame, that frame can be switched regardless of the protocol,
whether this is an IPv6 packet, a 6LoWPAN fragment, or a frame from
an alternate protocol such as WirelessHART or ISA100.11a.
</t>
<t>
A data frame that is forwarded along a Track normally has
a destination MAC address that is set to broadcast -
or a multicast address depending on MAC support.
This way, the MAC layer in the intermediate nodes accepts the
incoming frame and 6top switches it without incurring a change in
the MAC header. In the case of IEEE802.15.4, this means effectively
broadcast, so that along the Track the short address for the
destination of the frame is set to 0xFFFF.
</t>
<t>
A 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, and a cell in such a bundle belongs to
at most one 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.
The 6TiSCH architecture provides additional means to avoid waste of
cells as well as overflows in the transmit bundle, as follows:
</t>
<t>
In one hand, a TX-cell that is not needed for the current iteration
may be reused opportunistically on a per-hop basis for routed
packets.
When all of the frame that were received for a given Track are
effectively transmitted, any available TX-cell for that Track
can be reused for upper layer traffic for which the next-hop router
matches the next hop along the Track. In that case, the cell
that is being used is effectively a TX-cell from the Track, but the
short address for the destination is that of the next-hop router.
It results that a frame that is received in a RX-cell of a Track
with a destination MAC address set to this node as opposed to
broadcast must be extracted from the Track and delivered to the
upper layer (a frame with an unrecognized MAC address is dropped at
the lower MAC layer and thus is not received at the 6top sublayer).
</t>
<t>On the other hand, it might happen that there are not enough
TX-cells in the transmit bundle to accommodate the Track traffic,
for instance if more retransmissions are needed than provisioned.
In that case, the frame can be placed for transmission in the
bundle that is used for layer-3 traffic towards the next hop along
the track as long as it can be routed by the upper layer, that is,
typically, if the frame transports an IPv6 packet. The MAC address
should be set to the next-hop MAC address to avoid confusion.
It results that a frame that is received over a layer-3 bundle may
be in fact associated to a Track. In a classical IP link such as an
Ethernet, off-track traffic is typically in excess over reservation
to be routed along the non-reserved path based on its QoS setting.
But with 6TiSCH, since the use of the layer-3 bundle may be due to
transmission failures, it makes sense for the receiver to recognize
a frame that should be re-tracked, and to place it back on the
appropriate bundle if possible.
A frame should be re-tracked if the Per-Hop-Behavior
group indicated in the Differentiated Services Field in the
IPv6 header is set to Deterministic Forwarding, as discussed in
<xref target="pmh"/>.
A frame is re-tracked by scheduling it for transmission over the
transmit bundle associated to the Track,
with the destination MAC address set to broadcast.
</t>
<t>
There are 2 modes for a Track, transport mode and tunnel mode.
</t>
<section title="Transport Mode">
<t>
In transport mode, the Protocol Data Unit (PDU) is associated
with flow-dependant meta-data that refers uniquely to the Track,
so the 6top sublayer can place the frame in the appropriate cell
without ambiguity. In the case of IPv6 traffic, this flow
identification is transported in the Flow Label of the IPv6
header.
Associated with the source IPv6 address, the Flow Label forms a
globally unique identifier for that particular Track that is
validated at egress before restoring
the destination MAC address (DMAC) and punting to the upper layer.
</t>
<t>
<figure title="Track Forwarding, Transport Mode">
<artwork><![CDATA[
| ^
+--------------+ | |
| IPv6 | | |
+--------------+ | |
| 6LoWPAN HC | | |
+--------------+ ingress egress
| 6top | sets +----+ +----+ restores
+--------------+ dmac to | | | | dmac to
| TSCH MAC | brdcst | | | | self
+--------------+ | | | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+
]]></artwork>
</figure>
</t>
</section>
<section title="Tunnel Mode">
<t>
In tunnel mode, the frames originate from an arbitrary protocol over a compatible MAC
that may or may not be synchronized with the 6TiSCH network. An example of
this would be a router with a dual radio that is capable of receiving and sending WirelessHART
or ISA100.11a frames with the second radio, by presenting itself as an access
Point or a Backbone Router, respectively.
</t>
<t>
In that mode, some entity (e.g. PCE) can coordinate with a
WirelessHART Network Manager or an ISA100.11a System Manager to
specify the flows that are to be transported transparently
over the Track.
</t>
<t>
<figure anchor="fig6" title="Track Forwarding, Tunnel Mode">
<artwork><![CDATA[
+--------------+
| IPv6 |
+--------------+
| 6LoWPAN HC |
+--------------+ set restore
| 6top | +dmac+ +dmac+
+--------------+ to|brdcst to|nexthop
| TSCH MAC | | | | |
+--------------+ | | | |
| LLN PHY | +-------+ +--...-----+ +-------+
+--------------+ | ingress egress |
| |
+--------------+ | |
| LLN PHY | | |
+--------------+ | |
| TSCH MAC | | |
+--------------+ | dmac = | dmac =
|ISA100/WiHART | | nexthop v nexthop
+--------------+
]]></artwork>
</figure>
</t>
<t>
In that case, the flow information that identifies the Track at
the ingress 6TiSCH router is derived from the RX-cell. The dmac
is set to this node but the flow information indicates that the
frame must be tunneled over a particular Track so the frame is
not passed to the upper layer. Instead, the dmac is forced to
broadcast and the frame is passed to the 6top sublayer for switching.
</t>
<t>
At the egress 6TiSCH router, the reverse operation occurs. Based
on metadata associated to the Track, the frame is passed to the
appropriate link layer with the destination MAC restored.
</t>
</section>
<section title="Tunnel Metadata">
<t>
Metadata coming with the Track configuration is expected to provide the destination MAC address
of the egress endpoint as well as the tunnel mode and specific data depending on the mode,
for instance a service access point for frame delivery at egress.
If the tunnel egress point does not have a MAC address that matches the configuration,
the Track installation fails.
</t>
<t>
In transport mode, if the final layer-3 destination is the tunnel termination, then it is possible
that the IPv6 address of the destination is compressed at the 6LoWPAN sublayer based on the MAC address.
It is thus mandatory at the ingress point to validate that the MAC address that was used at the 6LoWPAN
sublayer for compression matches that of the tunnel egress point. For that reason, the node that injects
a packet on a Track checks that the destination is effectively that of the tunnel egress point
before it overwrites it to broadcast.
The 6top sublayer at the tunnel egress point reverts that operation to the MAC address obtained
from the tunnel metadata.
</t>
</section>
</section>
</section>
<section anchor="detnet" title="Operations of Interest for DetNet and PCE">
<t>In a classical system, the 6TiSCH device does not place the request for
bandwidth between self and another device in the network. Rather, an Operation
Control System invoked through an Human/Machine Interface (HMI) indicates the
Traffic Specification, in particular in terms of latency and reliability, and
the end nodes. With this, the PCE must compute a Track between the end nodes
and provision the network with per-flow state that describes the per-hop
operation for a given packet, the corresponding timeSlots, and the flow
identification that enables to recognize when a certain packet belongs to a
certain Track, sort out duplicates, etc...
</t>
<t>
For a static configuration that serves a certain purpose for a long period of time,
it is expected that a node will be provisioned in one shot with a full schedule,
which incorporates the aggregation of its behavior for multiple Tracks. 6TiSCH
expects that the programing of the schedule will be done over COAP
as discussed in <xref target="I-D.ietf-6tisch-coap">6TiSCH Resource
Management and Interaction using CoAP</xref>.
</t>
<t>
But an Hybrid mode may be required as well whereby a single Track is added,
modified, or removed, for instance if it appears that a Track does not
perform as expected for, say, PDR.
For that case, the expectation is that a protocol that flows along a Track
(to be), in a fashion similar to classical Traffic Engineering (TE)
<xref target="CCAMP"/>, may be used to update the state in the devices.
6TiSCH provides means for a device to negotiate a timeSlot with
a neighbor, but in general that flow was not designed and no protocol was
selected and it is expected that DetNet will determine the appropriate
end-to-end protocols to be used in that case.
</t>
<figure align="center" anchor="NorthSouth">
<preamble>Stream Management Entity</preamble>
<artwork align="left"><![CDATA[
Operational System and HMI
-+-+-+-+-+-+-+ Northbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
PCE PCE PCE PCE
-+-+-+-+-+-+-+ Southbound -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
--- 6TiSCH------6TiSCH------6TiSCH------6TiSCH--
6TiSCH / Device Device Device Device \
Device- - 6TiSCH
\ 6TiSCH 6TiSCH 6TiSCH 6TiSCH / Device
----Device------Device------Device------Device--
]]></artwork>
</figure>
<section anchor="pmh" title="Packet Marking and Handling">
<t>
Section "Packet Marking and Handling" of
<xref target="I-D.ietf-6tisch-architecture"/> describes the packet tagging and
marking that is expected in 6TiSCH networks.
</t>
<section anchor="pmhft" title="Tagging Packets for Flow Identification">
<t>
For packets that are routed by a PCE along a Track, the tuple formed by the
IPv6 source address and a local RPLInstanceID is tagged in the packets
to identify uniquely the Track and associated transmit bundle of timeSlots.
</t>
<t>
It results that the tagging that is used for a DetNet flow outside the
6TiSCH LLN MUST be swapped into 6TiSCH formats and back as the packet
enters and then leaves the 6TiSCH network.
</t>
<t>
Note: The method and format used for encoding the RPLInstanceID at 6lo
is generalized to all 6TiSCH topological Instances, which includes Tracks.
</t>
</section>
<section anchor="pmhrre" title="Replication, Retries and Elimination">
<t>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.
</t>
<t>
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.
</t>
<t>
The semantics of the configuration MUST enable correlated timeSlots to be
grouped for transmit (and respectively receive) with a 'OR' relations,
and then a 'AND' relation MUST 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.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="pmhds" title="Differentiated Services Per-Hop-Behavior">
<t>
Additionally, an IP packet that is sent along a Track uses the
Differentiated Services Per-Hop-Behavior Group called
Deterministic Forwarding, as described in
<xref target="I-D.svshah-tsvwg-deterministic-forwarding"/>.
</t>
</section>
</section>
<section anchor="topo" title="Topology and capabilities">
<t>6TiSCH nodes are usually IoT devices, characterized by very limited amount
of memory, just enough buffers to store one or a few IPv6 packets, and
limited bandwidth between peers. It results that a node will maintain only a
small number of peering information, and will not be able to store many
packets waiting to be forwarded. Peers can be identified through MAC or IPv6
addresses, but a Cryptographically Generated Address <xref target="RFC3972"/>
(CGA) may also be used.
</t>
<t>
Neighbors can be discovered over the radio using mechanism such as beacons,
but, though the neighbor information is available in the 6TiSCH interface
data model, 6TiSCH does not describe a protocol to pro-actively push the
neighborhood information to a PCE.
This protocol should be described and should operate over CoAP. The protocol
should be able to carry multiple metrics, in particular the same metrics as
used for RPL operations <xref target="RFC6551"/>
</t>
<t>
The energy that the device consumes in sleep, transmit and receive modes can
be evaluated and reported. So can the amount of energy that is stored in the
device and the power that it can be scavenged from the environment. The PCE
SHOULD be able to compute Tracks that will implement policies on how the
energy is consumed, for instance balance between nodes, ensure that the spent
energy does not exceeded the scavenged energy over a period of time, etc...
</t>
</section>
</section>
<section title="IANA Considerations">
<t>
This specification does not require IANA action.
</t>
</section>
<section anchor='sec' title="Security Considerations">
<t>On top of the classical protection of control signaling that can be
expected to support DetNet, it must be noted that 6TiSCH networks operate on
limited resources that can be depleted rapidly if an attacker manages to
operate a DoS attack on the system, for instance by placing a rogue device in
the network, or by obtaining management control and to setup extra paths.
</t>
</section>
<section title="Acknowledgments">
<t>This specification derives from the 6TiSCH architecture,
which is the result of multiple interactions, in
particular during the 6TiSCH (bi)Weekly Interim call, relayed through
the 6TiSCH mailing list at the IETF.
</t>
<t>
The authors wish to thank:
Kris Pister, Thomas Watteyne, Xavier Vilajosana, Qin Wang, Tom Phinney,
Robert Assimiti, Michael Richardson, Zhuo Chen, Malisa Vucinic,
Alfredo Grieco, Martin Turon, Dominique Barthel, Elvis Vogli,
Guillaume Gaillard, Herman Storey, Maria Rita Palattella,
Nicola Accettura, Patrick Wetterwald, Pouria Zand, Raghuram Sudhaakar,
and Shitanshu Shah for their participation and various contributions.
</t>
</section>
</middle>
<back>
<references title="Normative References">
<!-- 6TiSCH -->
<?rfc include='reference.I-D.ietf-6tisch-terminology'?>
<?rfc include='reference.I-D.ietf-6tisch-tsch'?>
<?rfc include='reference.I-D.ietf-6tisch-architecture'?>
<?rfc include='reference.I-D.ietf-6tisch-6top-interface'?>
<?rfc include='reference.I-D.ietf-6tisch-coap'?>
<!-- others -->
<?rfc include="reference.RFC.2119"?> <!-- MUST HAVE -->
<?rfc include="reference.RFC.2460"?> <!-- Internet Protocol, Version 6 (IPv6) Specification -->
</references>
<references title="Informative References">
<?rfc include="reference.RFC.2474"?> <!-- Differentiated Services Field -->
<?rfc include="reference.RFC.3209"?> <!-- RSVP TE -->
<?rfc include="reference.RFC.4291"?> <!-- IP Version 6 Addressing Architecture -->
<?rfc include="reference.RFC.3444"?> <!-- On the Difference between Information Models and Data Models -->
<?rfc include="reference.RFC.3972"?> <!-- Cryptographically Generated Addresses -->
<?rfc include="reference.RFC.4919"?> <!-- IPv6 over Low-Power Wireless Personal Area Networks -->
<?rfc include="reference.RFC.4903"?> <!-- IPv6 Multi-Link Subnet Issues -->
<?rfc include="reference.RFC.6282"?> <!-- Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks -->
<?rfc include="reference.RFC.6550"?> <!-- RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks -->
<?rfc include="reference.RFC.6551"?> <!-- RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks -->
<?rfc include="reference.RFC.6775"?> <!-- neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks -->
<!-- others -->
<?rfc include='reference.I-D.finn-detnet-architecture'?>
<?rfc include='reference.I-D.ietf-ipv6-multilink-subnets'?>
<?rfc include='reference.I-D.ietf-roll-rpl-industrial-applicability'?>
<?rfc include='reference.I-D.thubert-6lowpan-backbone-router'?>
<?rfc include='reference.I-D.svshah-tsvwg-deterministic-forwarding'?>
<?rfc include='reference.I-D.wang-6tisch-6top-sublayer'?>
</references>
<references title="Other Informative References">
<reference anchor="IEEE802154">
<front>
<title>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
</title>
<author>
<organization>IEEE standard for Information Technology</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="IEEE802154e">
<front>
<title>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 as amended by IEEE std.
802.15.4e, Part. 15.4: Low-Rate Wireless Personal Area
Networks (LR-WPANs) Amendment 1: MAC sublayer
</title>
<author>
<organization>IEEE standard for Information Technology</organization>
</author>
<date month="April" year="2012"/>
</front>
</reference>
<reference anchor="IEEE802.1TSNTG" target="http://www.ieee802.org/1/pages/avbridges.html">
<front>
<title>IEEE 802.1 Time-Sensitive Networks Task Group</title>
<author>
<organization>IEEE Standards Association</organization>
</author>
<date day="08" month="March" year="2013" />
</front>
</reference>
<reference anchor="WirelessHART">
<front>
<title>Industrial Communication Networks - Wireless Communication Network and Communication Profiles - WirelessHART - IEC 62591</title>
<author>
<organization>www.hartcomm.org</organization>
</author>
<date year="2010" />
</front>
</reference>
<reference anchor="HART">
<front>
<title>Highway Addressable remote Transducer, a group of specifications for industrial process and control devices administered by the HART Foundation</title>
<author>
<organization>www.hartcomm.org</organization>
</author>
<date></date>
</front>
</reference>
<reference anchor="ISA100.11a" target="http://www.isa.org/Community/SP100WirelessSystemsforAutomation">
<front>
<title>Wireless Systems for Industrial Automation: Process Control and Related Applications - ISA100.11a-2011 - IEC 62734</title>
<author>
<organization>ISA/ANSI</organization>
</author>
<date year="2011" />
</front>
</reference>
<reference anchor="ISA100" target="https://www.isa.org/isa100/">
<front>
<title>ISA100, Wireless Systems for Automation</title>
<author>
<organization>ISA/ANSI</organization>
</author>
<date/>
</front>
</reference>
<reference anchor="TEAS" target="https://datatracker.ietf.org/doc/charter-ietf-teas/">
<front>
<title>Traffic Engineering Architecture and Signaling</title>
<author>
<organization>IETF</organization>
</author>
<date></date>
</front>
</reference>
<reference anchor="PCE" target="https://datatracker.ietf.org/doc/charter-ietf-pce/">
<front>
<title>Path Computation Element</title>
<author>
<organization>IETF</organization>
</author>
<date></date>
</front>
</reference>
<reference anchor="CCAMP" target="https://datatracker.ietf.org/doc/charter-ietf-ccamp/">
<front>
<title>Common Control and Measurement Plane</title>
<author>
<organization>IETF</organization>
</author>
<date></date>
</front>
</reference>
<reference anchor="DICE" target="https://datatracker.ietf.org/doc/charter-ietf-dice/">
<front>
<title>DTLS In Constrained Environments</title>
<author>
<organization>IETF</organization>
</author>
<date></date>
</front>
</reference>
<reference anchor="ACE" target="https://datatracker.ietf.org/doc/charter-ietf-ace/">
<front>
<title>Authentication and Authorization for Constrained Environments</title>
<author>
<organization>IETF</organization>
</author>
<date></date>
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 03:24:36 |