Re: [6tisch] draft charter as of oct 12. Any more comments?

[Thomas Watteyne <[e-mail]>]

Pascal,
Per our discussion on Friday, we need to do a slight rewording of WP 2&3 to
take into account the new terminology introduced in
https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02.
For that, we need to agree on a new name for OF. I'll start a 24h polling
period in a separate e-mail, then we'll have the final proposed rewording.
Thomas

On Mon, Oct 12, 2015 at 1:35 PM, Pascal Thubert (pthubert) <
[e-mail]> wrote:

> 6TiSCH: "IPv6 over the TSCH mode of IEEE 802.15.4e".
>
> Background/Introduction:
> ------------------------
>
> Low-power and Lossy Networks (LLNs) interconnect a possibly large number
> of resource-constrained nodes to form a wireless mesh network. The
> 6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at
> various layers of the protocol stack, including an IPv6 adaptation
> layer, a routing protocol and a web transfer protocol. This protocol
> stack has been used with IEEE802.15.4 low-power radios.
>
> The Timeslotted Channel Hopping (TSCH) mode was introduced in 2012 as an
> amendment to the Medium Access Control (MAC) portion of the IEEE802.15.4
> standard. TSCH is the emerging standard for industrial automation and
> process control LLNs, with a direct inheritance from WirelessHART and
> ISA100.11a. Defining IPv6 over TSCH, 6TiSCH is a key to enable the
> further adoption of IPv6 in industrial standards and the convergence of
> Operational Technology (OT) with Information Technology (IT).
>
> The nodes in a IEEE802.15.4 TSCH network communicate by following a
> Time Division Multiple Access (TDMA) schedule. A timeslot in this
> schedule provides a unit of bandwidth that is allocated for
> communication between neighbor nodes. The allocation can be programmed
> such that the predictable transmission pattern matches the traffic. This
> avoids idle listening, and extends battery lifetime for constrained
> nodes. Channel-hopping improves reliability in the presence of narrow-
> band interference and multi-path fading.
>
> These techniques enable a new range of use cases for LLNs, including:
> - Control loops in a wireless process control network, in which high
> reliability and a fully deterministic behavior are required.
> - Service Provider networks transporting data from different independent
> clients, and for which an operator needs flow isolation and traffic
> shaping.
> - Networks comprising energy harvesting nodes, which require an
> extremely low and predictable average power consumption.
>
> IEEE802.15.4 only defines the link-layer mechanisms. It does not define
> how the network communication schedule is built and matched to the
> traffic requirements of the network.
>
> Description of Working Group:
> -----------------------------
>
> The Working Group will focus on enabling IPv6 over the TSCH mode of the
> IEEE802.15.4 standard. The extent of the problem space for the WG is
> one or more LLNs, possibly federated through a common backbone link
> via one or more LLN Border Routers (LBRs). The WG will rely on, and if
> necessary extend, existing mechanisms for authenticating LBRs.
>
> Initially, the WG has limited its scope to distributed routing over a
> static schedule using the Routing Protocol for LLNs (RPL) on the resulting
> network. This new charter allows for the dynamic allocation of cells and
> their exchange between adjacent peers to accommodate the available
> bandwidth
> to the variations of throughput in IP traffic.
>
> The WG will continue working on securing the join process and making that
> fit
> within the constraints of high latency, low throughput and small frame
> sizes
> that characterize IEEE802.15.4 TSCH.
>
> Additionally, IEEE802.15.4 TSCH being a deterministic MAC, it is envisioned
> that 6TiSCH will benefit from the work of detnet WG to establish the
> so-called
> deterministic tracks. The group will define the objects and methods that
> needs
> to be configured, and provide the associated requirements to detnet.
>
> The WG will interface with other appropriate groups in the IETF
> Internet, Operations and Management, Routing and Security areas.
>
> Work Items:
> -----------
>
> The group will:
>
> 1. Produce "6TiSCH architecture" to describe the design of 6TiSCH
> networks. This document will highlight the different architectural
> blocks and signaling flows, including the operation of the network in
> the presence of multiple LBRs. The existing document will be augmented
> to cover dynamic scheduling and application of the DetNet work.
>
> 2. Produce an Information Model containing the management requirements
> of a 6TiSCH node. This includes describing how an entity can manage the
> TSCH schedule on a 6TiSCH node, and query timeslot information from that
> node. MAC-layer interactions to negotiate Time Slots between peers will
> be proposed, to be eventually continued at IEEE.
>
> 3. Produce an "On-the-fly" (OTF) specification to enable a distributed
> dynamic
> scheduling of time slots, negotiated between adjacent peers, with the
> capability
> for 6TiSCH routers to appropriate chunks of the Time/frequency matrix
> without
> starving, or interfering with, other 6TiSCH nodes.
> This particular work will focus on IP traffic since the work on tracks is
> not
> yet advanced enough to specify their requirements for OTF operations.
>
> 4. Produce a specification for a secure 6TiSCH network bootstrap, adapted
> to the constraints of 6TiSCH nodes and leveraging existing art when
> possible.
>
> 5. Produce requirements to the detnet WG, detailing the 6TiSCH tracks and
> the
> data models to manipulate them from a central controller such as a PCE.
>
>
> The work will include a best practice configuration for RPL and OF0
> operation over the static schedule. Based on that experience the group
> may produce a requirements draft for OF0 extensions, to be studied in ROLL.
>
> Non-milestone work items:
> -------------------------
>
> The Working Group will develop 6TiSCH Test Description documents which
> will be
> updated as the technology evolves, and will be used for running
> interoperability
> events, under ETSI support (i.e., 6TiSCH ETSI Plugtests).
>
> Such documents will be helpful for implementers, providing details and
> clarifications, needed for running code, and implementing the 6TiSCH
> technology.
>
> Each document may address specific 6TiSCH features, in scope of the
> specific
> Plugtest's edition.
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>