Re: [6tisch] charter 2.00

["Pascal Thubert (pthubert)" <[e-mail]>]

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.

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!)
[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

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
]



<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

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


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



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

[cid:image001.png@01D102B6.D1558040]
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-----

From: 6tisch [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)

Sent: Wednesday, October 07, 2015 12:47 PM

To: [e-mail]<mailto:[e-mail]>

Cc: Thomas Watteyne <[e-mail]<mailto:[e-mail]>>

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!





"

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



_______________________________________________

6tisch mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/6tisch