Subject: [6tsch] charter-ietf-6tsch: draft uploaded

From: Thomas Watteyne <[email-masked]>
Date: Sat, 6 Apr 2013 18:21:35 -0700

All,

As discussed during the webex yesterday, you will find the draft for a
6TSCH charter at:

https://bitbucket.org/6tsch/charter-ietf-6tsch/src

Looking forward to receiving your comments on the ML,

Thomas

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 7 Apr 2013 16:15:30 +0800

some comments on the charter below, marked <MB>

Marc.

Background/Introduction:
------------------------

Low power and Lossy Networks (LLNs) interconnect a possibly large number of
resource-constrained devices to form a wireless mesh network. A small number of
border routers (BR) serve as gateways between the LLN and the Internet. There
is a wide scope of application areas for LLNs, including building automation,
home automation, industrial process control and urban applications.

A chief component of these networks is the wireless communication technology.
The 6LoWPAN, ROLL and CoRE IETF Working Groups have defined protocols at
various layers of the LLN 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 so far, the limitation of which in
mesh-networking conditions however has become apparent recently.

To this end, IEEE802.15.4e Timeslotted Channel Hopping (TSCH) has been made a
recent amendment to the Medium Access Control protocol of the IEEE802.15.4
standard, inheriting from long-standing industrial process control standards
such as WirelessHART and ISA100.11a.

IEEE802.15.4e enhances the IEEE802.15.4 standard through:
- high reliability: 99.999% end-to-end reliability is commonplace.
- determinism: a clear definition of link-layer resources allows independence
of data flows.
- low-power: devices can have duty cycles well below 1%, thereby extending
battery lifetime to multiple years.

<MB>It should appropriate to have a short paragraph on what TSCH exactly does: ie. a more detailed description of how the timeslots are done, and how the channel hopping is.  The intent is not to get a full description, but a grisp of what is new or different using this new LL stack. Right now, the current text says: "this is great, we need a new adaptation layer", but does not specify really what are the main characteristics and challenges of this version of 802.15.4. If the intro becomes too long, I would add that paragraph and remove or shrink the first two paragraphs.</MB>

These characteristics translate into a new range of use cases for LLNs,
including:
- Control loops in a wireless process control network, in which high
reliability and determinism are required.
- Umbrella urban networks transporting data from different independent clients,
and for which an operator needs flow isolation and traffic shaping.
- Energy harvesting networks, which require an extremely low and predictable
average power consumption.

IEEE802.15.4e only defines the link-layer mechanisms. It does not define how
the network communication schedule is built and matched to the traffic
requirement of the network. The definition of an adaptation layer and
architectural recommendations are needed for those highly efficient LLN
networks to transition to end-to-end IPv6-based solutions.

Description of Working Group:
-----------------------------

The Working Group focuses only on the TSCH mode of the IEEE802.15.4e standard.
The WG will define a framework for managing the TSCH schedule. This framework
will consist of an adaptation layer which allows a central or a distributed
forwarding entity to match the bandwidth, latency and reliability requirements
of the different data flows transported in the LLN.

The WG will focus on three scheduling approaches: 
- a central Path Computation Entity builds and maintains the communication
schedule, and distributes it to the nodes. This schedule includes routing
information; RPL operations only apply to emergency repair actions when the
reference topology becomes unusable.
- a distributed resource reservation and signaling protocol establishes pipes
between source and destination nodes along multi-hop routes identified by RPL.
- a best effort resource reservation is used to transport data frames along
multi-hop routes identified by RPL.

The Working Group focuses only on an IPv6-based architecture, which includes
6LoWPAN header compression and the RPL routing protocol for routing. The WG
will produce architectural recommendations defining how IPv6 packets are
labeled and transported over the LLN, and how an LLN can support multiple BRs.
It will also address how IPv6 prefixes can be shared between LLNs and how nodes
maintain synchronization in the presence of multiple BRs.

<MB>I think here we should be cautious. I would rephrase or add the fact that these new definitions will only be done if they are really needed. It may not be obvious that the addition of TSCH have the impact of defining another way the IPv6 prefixes will be used.  Maybe some text like: "Only required changes or additions to the 6lowpan/rpl will be developed.</MB>

The WG will informally coordinate on requirements with organizations including
IPSO Alliance, IoT6, ISA, IEEE and other SDOs and organizations. The WG will
closely coordinate with other IETF WGs including ROLL, 6LoWPAN, CoRE, PCE,
COMAN, LWIG and other appropriate groups in the IETF Internet, Routing and
Security areas.

Work Items:
-----------

1. Produce "6tus Adaptation Layer Specification" to define the operation of
the adaptation layer between the 6LoWPAN/RPL networking layer and the
IEEE802.15.4e TSCH MAC layer. 
<MB>6tus here is the first time that keyword is used. Might want to expand it</MB>

This document (or documents) will define how to
bootstrap a 6TSCH network, and how nodes maintain synchronization, including
in the presence of multiple BRs. It will define the hooks for an upper
scheduling layer to modify the underlying TSCH schedule, as well as the
monitoring functions to gather link quality statistics and possibly act
accordingly.
This document or documents will be a proposed standard.

2. Produce "6TSCH centralized management" to define the mechanism by which an
external Path Computation Entity can communicate with the 6tus protocol layer
of the different nodes in the network (1) to modify their TSCH schedule and
(2) to gather link quality statistics and data flow requirements.  The WG will
initially look at PCEP and CoAP.
Depending on the applicability of PCEP, this document will either be
informational or a proposed standard.

<MB>Looks like a protocol. I would suggest setting it for now as Proposed Standard. and then see later if relevant to downgrade it to informational</MB>

3. Produce "6TSCH distributed management" to define the mechanism by which a
source node reserves MAC-layer resources along a pre-established RPL multi-hop
path to a destination node. The WG will initially look at RSVP and NSIS.
Depending on the applicability of RSVP and NSIS, this document will either be
informational or a proposed standard.

<MB>same comment</MB>

4. Produce "6TSCH minimal operation" to define how to build a 6TSCH network
when no PCE or distributed scheduling protocol is available. The communication
schedule can be either pre-set (possibly using shared resources), or resource
requirements can be determined on the fly by traffic analysis at the nodes.
This document will be informational.

5. Produce "6TSCH architecture" to describe the design and implementation of
6TSCH networks. This document will highlight the different data and signaling
flows, the operation of the network in the presence of multiple BRs,
and the labeling of packets travelling over the 6TSCH network.
This document will be informational.

6. Produce "TSCH overview" to describe the IEEE802.15.4e TSCH standard in the
LLN context. This document will present protocol highlights, and identify
the elements that need to be handled by the upper layers.
This document will be informational.

The working group will continue to reuse existing protocols and mechanisms
whenever reasonable and possible.

Non-milestone work items:
-------------------------

The Working Group will keep two running, often-respun documents:
- implementers guide, collecting clarifying information based on input from
implementers, in particular as it becomes available from interoperability
events.
- interoperability guide, providing information for interoperability
events, such as temporary interoperability testing strategies or
information about test harnesses used for interoperability testing.

Both documents will be WG documents.

<MB>This last part looks weird. If there are wg documents, then they should be published as RFC, informational as I see. Why not? </MB>

Le 2013-04-07 à 09:21, Thomas Watteyne <[email-masked]> a écrit :

> All,
> 
> As discussed during the webex yesterday, you will find the draft for a 6TSCH charter at:
> 
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch