Subject: [6tisch] charter 2.00

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 7 Oct 2015 16:47:00 +0000

Dear all:

Please find below the result of our discussions on the new charter.
Our goal is to conclude the adoption of the text at the call on Friday
And ship it to the IESG. Fire at will!

"
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, eventually 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" specification to enable a distributed dynamic
scheduling of time slots for IP traffic, with the capability for IoT routers
to appropriate chunks of the matrix without starving, or interfering with,
other 6TiSCH nodes.

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 may maintain a number of running, often-respun 
documents, that evolve as the technology is refined for work items that 
do not affect the milestone work items:
- Interop sustaining guides: these document would carry such information as
packet captures and disambiguation of language from external standards to
help interop tests such as PlugTests and PlugFests.
- implementers guide: this document will collect clarifying information 
based on input from implementers, in particular as it becomes available 
from interoperability events. This guide will contain information about 
test harnesses used for interoperability testing.
- coexistence guide: this document will provide information on how 
6TiSCH can be operated in an environment shared with other protocols 
that use the same or a similar TSCH MAC, and/or operate on the same 
frequency band.

The WG will welcome requirements for dynamic timeslot operation, for 
example for centralized schedule computation.
"

Pascal

---

From: "Brett, Patricia (PA62)" <[email-masked]>
Date: Wed, 7 Oct 2015 17:23:38 +0000

Pascal:
Nicely written - just 2 comments:

1. IT and OT don't necessarily need to converge.  They do however need to easily integrate.

2. Not all communication must be explicitly allocate to a particular node.  Please refer to ISA100.11a for such an example.

Regards,
Pat
-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Wednesday, October 07, 2015 12:47 PM
To: [email-masked]
Cc: Thomas Watteyne
Subject: [6tisch] charter 2.00

Dear all:

Please find below the result of our discussions on the new charter.
Our goal is to conclude the adoption of the text at the call on Friday And ship it to the IESG. Fire at will!

"

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.

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, eventually 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" specification to enable a distributed dynamic scheduling of time slots for IP traffic, with the capability for IoT routers to appropriate chunks of the matrix without starving, or interfering with, other 6TiSCH nodes.

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.

The Working Group may maintain a number of running, often-respun documents, that evolve as the technology is refined for work items that do not affect the milestone work items:
- Interop sustaining guides: these document would carry such information as packet captures and disambiguation of language from external standards to help interop tests such as PlugTests and PlugFests.
- implementers guide: this document will collect clarifying information based on input from implementers, in particular as it becomes available from interoperability events. This guide will contain information about test harnesses used for interoperability testing.
- coexistence guide: this document will provide information on how 6TiSCH can be operated in an environment shared with other protocols that use the same or a similar TSCH MAC, and/or operate on the same frequency band.

The WG will welcome requirements for dynamic timeslot operation, for example for centralized schedule computation.
"

Pascal 

_______________________________________________
6tisch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6tisch

---

From: "Wang, Chonggang" <[email-masked]>
Date: Thu, 8 Oct 2015 15:16:28 +0000

Hi Pascal,

Thanks for the good write-up. I had a quick review and some points the group has discussed and kind of agreed are not captured in "charter 2.0". For example,

"3. Produce an "On-the-fly" specification to enable a distributed dynamic scheduling of time slots for IP traffic, with the capability for IoT routers to appropriate chunks of the matrix without starving, or interfering with, other 6TiSCH nodes."

There were email discussions on removing "for IP traffic" and you agreed as well.

Thanks,

Chonggang

-----Original Message-----

To: [email-masked]

Cc: Thomas Watteyne <[email-masked]>

Dear all:

"

Background/Introduction:

------------------------

Work Items:

-----------

The group will:

"

Pascal

6tisch mailing list

[email-masked]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Oct 2015 09:23:24 +0000

No I actually disagreed ChongGang;

Removing it means that we do OTF on tracks, that is on hard cell. But we can’t since they are defined by the PCE by definition.

To go beyond that simple limitation we’d need to :

-        Define tracks properly (that’s one of the goals of the work you and I have to merge, ASAP now!)

-        Allow the 6TiSCH nodes to complement the hard cells by hard cells. We never said we’d do that

So my suggestion is to focus on the dynamics of IP traffic s routed eg by RPL, and work on defining tracks and pushing reqs to detnet.
Then we will see if and how the OTF work can be used to complement hard cells, or whether the PCE should manage itself the dynamics of its own flows.

That will be one subject at the call : )

Cheers,

Pascal

From: Wang, Chonggang [mailto:[email-masked]]
Sent: jeudi 8 octobre 2015 17:16
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Cc: Thomas Watteyne <[email-masked]>
Subject: RE: charter 2.00

Hi Pascal,

There were email discussions on removing “for IP traffic” and you agreed as well.

Thanks,

Chonggang

Chonggang Wang
Member Technical Staff
InterDigital Communications, Inc.
781 Third Ave
King of Prussia, PA 19406
T: +1 610.878.5731
[email-masked]<mailto:[email-masked]>
www.InterDigital.com<http://www.interdigital.com>

This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature.

-----Original Message-----

To: [email-masked]<mailto:[email-masked]>

Cc: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>

Dear all:

"

Background/Introduction:

------------------------

Work Items:

-----------

The group will:

"

Pascal

6tisch mailing list

[email-masked]<mailto:[email-masked]>

---

From: "Wang, Chonggang" <[email-masked]>
Date: Fri, 9 Oct 2015 13:56:02 +0000

Thanks a lot, Pascal, for your quick feedback. I added a few comments inline below (which we can also discuss in today’s call)

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Friday, October 09, 2015 5:23 AM
To: Wang, Chonggang <[email-masked]>; [email-masked]
Cc: Thomas Watteyne <[email-masked]>
Subject: RE: charter 2.00

Removing it means that we do OTF on tracks, that is on hard cell. But we can’t since they are defined by the PCE by definition.
[CW: I meant to use OTF on a track of soft cells. A Track can be hard cells and soft cells. As described in section 8.1.4 of 6TiSCH architecture draft, hop-by-hop scheduling can reserve a track from a source node to a destination node multiple hops away by installing soft cells at each intermediate node. This forms a track of soft cells.
]

-          Define tracks properly (that’s one of the goals of the work you and I have to merge, ASAP now!)
[CW: Fully agree. Shall we submit a draft together in IETF 94? I actually sent a few emails to your back in July/August but did not hear from you ☺]

-          Allow the 6TiSCH nodes to complement the hard cells by hard cells. We never said we’d do that
[CW: sorry but not quite understand what “complement the hard cells by hard cells” means]

So my suggestion is to focus on the dynamics of IP traffic s routed eg by RPL, and work on defining tracks and pushing reqs to detnet.
[CW: I think Track management is better studied in 6TiSCH, and the solutions can influence the design of DetNet. As mentioned in the DetNet charter, DetNet collaborates with IEEE802.1 Time Sensitive Networking (TSN), which is responsible for Layer 2 operations, to define a common architecture for both Layer 2 and Layer 3. Track in 6TiSCH is targeted to Low-power and Lossy Networks (LLNs) , solutions in DetNet must be customized/tailored for Track management in 6TiSCH considering
–        Low-power consumption; TSCH MAC; Constrained devices with limited buffer and computation strength
]

Cheers,

Pascal

To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

Hi Pascal,

Thanks,

Chonggang

Chonggang Wang
Member Technical Staff

-----Original Message-----

Dear all:

"

Background/Introduction:

------------------------

Work Items:

-----------

The group will:

"

Pascal

6tisch mailing list

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 9 Oct 2015 15:21:43 +0000

Hello ChongGang:

Please see below

Removing it means that we do OTF on tracks, that is on hard cell. But we can’t since they are defined by the PCE by definition.
[CW: I meant to use OTF on a track of soft cells. A Track can be hard cells and soft cells. As described in section 8.1.4 of 6TiSCH architecture draft, hop-by-hop scheduling can reserve a track from a source node to a destination node multiple hops away by installing soft cells at each intermediate node. This forms a track of soft cells.
]
<Pascal> We do not have tracks of soft cell in our architecture. We can add that concept but first we need to define what it is, which protocols are used to reserve the cells, connect them, etc… That day we’ll understand what the dynamic needs are and what kind of “OF” can help if any. Assuming that the current OTF is what that thing would need is quite premature. Now, I agree with you and pat about the fact that the charter does not prevent that work in the future, we just do not have the means to do it today.

-        Define tracks properly (that’s one of the goals of the work you and I have to merge, ASAP now!)
[CW: Fully agree. Shall we submit a draft together in IETF 94? I actually sent a few emails to your back in July/August but did not hear from you ☺]
<Pascal>> My bad, always thought I’ll do it tomorrow when I’m done with that urgent thing, and blah…
I’ll ceme back to you.

-        Allow the 6TiSCH nodes to complement the hard cells by hard cells. We never said we’d do that
[CW: sorry but not quite understand what “complement the hard cells by hard cells” means]
<Pascal>Typo : )  I meant to write complement hard cells with soft cells to accommodate with bad networking conditions

<Pascal>yes, agreed. We need to define the tracks and their operations so we can havethe right data and interaction models fitting in DetNet.

Cool then: let me propose something on a separate thread about not preventing work on non IP traffic in the future.

Cheers,

Pascal

Hi Pascal,

Thanks,

Chonggang

Chonggang Wang
Member Technical Staff

-----Original Message-----

Dear all:

"

Background/Introduction:

------------------------

Work Items:

-----------

The group will:

"

Pascal

6tisch mailing list