Subject: [6tisch] Rechartering Discussion

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 Sep 2015 10:08:16 +0000

Dear all:

This is the continuation if the discussion we had at the interim on Friday 9/25
(see published minutes @ https://www.ietf.org/proceedings/interim/2015/09/25/6tisch/minutes/minutes-interim-2015-6tisch-13 and
slides @ https://www.ietf.org/proceedings/interim/2015/09/25/6tisch/slides/slides-interim-2015-6tisch-13-0.pdf ).

The highlighted / colored text below is an inline copy of the slides in the above pdf so you may use that source as well.

To the point; the current charter has the following:

"

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. Initially, the document will focus on
distributed routing operation over a static TSCH schedule.

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. A data model mapping for an existing protocol (such as Concise
Binary Object Representation (CBOR) over the Constrained Application
Protocol (CoAP)) will be provided.

3.    Produce "Minimal 6TiSCH Configuration" defining how to build a 6TiSCH
network using the Routing Protocol for LLNs (RPL) and a static TSCH
schedule. It is expected that RPL and the Objective Function 0 (OF0)
will be reused as-is.

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 tasks in red were never started and apparently did not raise interest in the group.
The tasks in green are mostly complete.
In particular,  the minimal draft was officially submitted to the IESG for review.
Now we need to make room for new work in security and dynamic scheduling.
So at the interim we proposed to update the charter as follows:

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 applicability of 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. A data model mapping for an existing protocol (such as Concise
Binary Object Representation (CBOR) over the Constrained Application
Protocol (CoAP)) will be provided. 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.

The text in blue are proposed additions that made consensus at the call.

The questions left were about items in red and yellow, and we are specifically asking for advice on those,
though advice on the rest of the proposal is welcome as well.

A suggestion was made to discontinue the work on the coap draft. Reason advanced was that the CoMI work would make the draft mostly void.
Any comment on that?

Another suggestion would be to remove the text in Yellow that limits the OTF work to IP bundles (aka track0 or best effort).
Again, comments are welcome.

Finally, there the text about non chatrtered 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:
- 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.
- Text on Interop test ?
The WG will welcome requirements for dynamic timeslot operation, for
example for centralized schedule computation.

A question was whether to keep them, another was whether to mention documents on interop tests,
since the appeared to be very useful in Prague.

What do you guys think?

Take care;

Pascal, on behalf of the chairs

---

From: Michael Richardson <[email-masked]>
Date: Mon, 28 Sep 2015 11:15:54 -0400

I have read the proposed changes to the charter, and they seem to make sense
to me.

The Blue/Yellow/Red changes do not come through email. (nor should they)

I assumed that the slides are accurate in this regard, but this is what I
found in red in the slides:
> operation over the static schedule. Based on that experience the group may
> produce a requirements draft for OF0 extensions, to be studied in ROLL

and I'm having difficulty seeing that as controversial.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Wang, Chonggang" <[email-masked]>
Date: Mon, 28 Sep 2015 15:41:02 +0000

Hi Pascal and All,

Sorry that I missed the interim on Friday 9/25. As for the re-chartering, the drafted bullets look like a nice continuation of existing 6TiSCH work. I had a few questions/comments below.

1. 6TiSCH architecture: the latest version seems to have content related to existing charter and re-chartering. Wonder if a short version of existing 6TiSCH architecture will be published first as the output of existing charter. If that's the case, wonder which part of existing 6TiSCH architecture will be shortened or removed.

2. 6TiSCH Architecture: "...including the operation of the network in the presence of multiple LBRs...". Wonder which kind of "operations" will be considered and whether they are unique to 6TiSCH.

3. 6TiSCH Architecture: "...The existing document will be augmented to cover dynamic scheduling and applicability of DetNet work". Wonder what's the definition of "dynamic scheduling" here.  Also, for "applicability of DetNet work", wonder if dynamic scheduling work will be proposed within 6TiSCH and will be applied to future DetNet WG.

4. Information Model: "A data model mapping for an existing protocol (such as Concise Binary Object Representation (CBOR) over the Constrained Application Protocol (CoAP)) will be provided". I suggested removing "such as Concise Binary Object Representation (CBOR) over the Constrained Application Protocol (CoAP)" since it's mentioned at the end of Pascal's email that CoAP draft will not be continued; also ICMP protocol or other protocols could be good options too.

5. On-the-Fly: "Produce an “On-the-fly" specification to enable a distributed dynamic scheduling of time slots for IP traffic". Agree to remove "for IP traffic".

6. Security: "Produce a specification for a secure 6TiSCH network bootstrap...". First, 6LO seems to have a work on constrained device bootstrap. In addition, security for 6TiSCH networks in layer 2/3 has multiple aspects and bootstrap is one of them. For re-chartering, should we also consider other security aspects such as secure centralized or dynamic scheduling, secure forwarding or routing, etc.

7. Centralized vs Distributed Scheduling: I feel 6TiSCH has a variety of use cases. Some use cases have small networks with a small number of devices  (centralized could work) and others with a larger scale (more devices and distributed scheduling may be better). In addition, for different applications, both centralized and distributed scheduling have pros and cons. From 6TiSCH perspective, either scheme or both could be standardized.

Sorry for the long email.

Thanks,

Chonggang

________________________________
From: 6tisch [[email-masked]] on behalf of Pascal Thubert (pthubert) [[email-masked]]
Sent: Monday, September 28, 2015 6:08 AM
To: [email-masked]
Subject: [6tisch] Rechartering Discussion

Dear all:

“

The group will:

“

The group will:

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.

What do you guys think?

Take care;

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 Sep 2015 15:42:06 +0000

The work is not controversial, Michael.

It just happens that minimal uses OF0 as is and no change was suggested. 

That text is thus useless/ obsolete since minimal has shipped to IESG.

Take care,

Pascal

> Le 28 sept. 2015 à 17:16, Michael Richardson <[email-masked]> a écrit :
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 Sep 2015 16:11:10 +0000

Hello Qing

Please see below:

Pascal
> Le 28 sept. 2015 à 17:41, Wang, Chonggang <[email-masked]> a écrit :
> 
> Hi Pascal and All,
> 
> 
> 

We tried but Ralph's review was considered a push back and we followed his advice to ship the complete architecture when 6TiSCH completes.

> 2. 6TiSCH Architecture: "...including the operation of the network in the presence of multiple LBRs...". Wonder which kind of "operations" will be considered and whether they are unique to 6TiSCH.

They are not but so far only 6TiSCH documented its architecture. That is actually complete as part of the first charter.

> 3. 6TiSCH Architecture: "...The existing document will be augmented to cover dynamic scheduling and applicability of DetNet work". Wonder what's the definition of "dynamic scheduling" here.  Also,…
 the dynamic scheduling is when the nodes define their schedule whereas DetNet is when the PCE does it.
This is by opposition to minimal that used a static schedule.

> 4. Information Model: "A data model mapping for an existing protocol (such as Concise Binary Object Representation (CBOR) over the Constrained Application Protocol (CoAP)) will be provided". I sugg…
Well noted. Fine with me.

> 5. On-the-Fly: "Produce an “On-the-fly" specification to enable a distributed dynamic scheduling of time slots for IP traffic". Agree to remove "for IP traffic".

+1 : )

> 6. Security: "Produce a specification for a secure 6TiSCH network bootstrap...". First, 6LO seems to have a work on constrained device bootstrap. In addition, security for 6TiSCH networks in layer…

This is because the group has been very active on that particular aspect for more than a year, and has a clear leadership on the Matter. 

We may have 6TiSCH specific constraints and our links into 802.15.4 may help us consider interactions with say 802.15.9...

For other aspects of security, the work is much needed but there is no indication that it should take place here.

> 7. Centralized vs Distributed Scheduling: I feel 6TiSCH has a variety of use cases. Some use cases have small networks with a small number of devices  (centralized could work) and others with a lar…

+1

We start with distributed to leave room for DetNet to sort the generic problems

> Sorry for the long email.

Thank YOU Qing, great comments!

Pascal

> 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]
> 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.
> 
>

---

From: "S.V.R.Anand" <[email-masked]>
Date: Tue, 29 Sep 2015 15:47:03 +0530

Hi Pascal,

The updated items that have been considered for the charter are very 
appropriate.

With respect to the the usage of yellow coloured "for IP traffic" in the 
item 3. I get a feeling
that the intent is to provide enough bandwidth for performing essential 
but relatively not-very-critical control/management plane operations 
without hurting the determinism expected from the data plane whatsoever. 
Is my interpretation right ?

One of the schemes Detnet proposes is seamless redundancy replication 
and elimination. Are we aiming for its realization under 6tisch ?
If we do so, I  suppose it brings in its own set of challenges with 
respect to track and cell management. This is due to the extent of 
replication, when and where it comes into play inside the network, the 
presence of multiple BBRs. Would be very happy to receive your thoughts 
on this aspect.

Anand

On Monday 28 September 2015 03:38 PM, Pascal Thubert (pthubert) wrote:
> (see published minutes @ 
> https://www.ietf.org/proceedings/interim/2015/09/25/6tisch/minutes/minutes-interim-2015-6tisch-13 
> and
>
> slides @ 
> https://www.ietf.org/proceedings/interim/2015/09/25/6tisch/slides/slides-interim-2015-6tisch-13-0.pdf 
> ).
>
> The highlighted / colored text below is an inline copy of the slides 
> in the above pdf so you may use that source as well.
>
> the presence of multiple LBRs.Initially, the document will focus on
> 1.Produce "6TiSCH architecture" to describe the design of 6TiSCH
> 2.Produce an Information Model containing the management requirements
> A suggestion was made to discontinue the work on the coap draft. 
> Reason advanced was that the CoMI work would make the draft mostly void.
>
> Any comment on that?
>
> Another suggestion would be to remove the text in Yellow that limits 
> the OTF work to IP bundles (aka track0 or best effort).
>
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean.
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 29 Sep 2015 11:44:13 +0000

Hello Anand:

The intent of the for IP traffic is really whatever traffic is routed by the motes, as opposed to switched at L2.5 along tracks.

And I agree with you for the rest. We have to define tracks, which can probably be more complex than a simple sequence of hops if we want to enable replication and elimination (PRP like).

I wrote some text in https://www.ietf.org/id/draft-thubert-6tisch-4detnet-01.txt and would really appreciate your review in this matter.

And yes, I think it is important to be able to carve PRP path that go to the same collection point on the backbone via different BBRs... I know of some techniques, some with IPR on them (and this includes PRP actually) that we could discuss in the context of that draft.

Take care;

Pascal

From: S.V.R.Anand [mailto:[email-masked]]
Sent: mardi 29 septembre 2015 12:17
To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
Subject: Re: [6tisch] Rechartering Discussion

Hi Pascal,

The updated items that have been considered for the charter are very appropriate.

With respect to the the usage of yellow coloured "for IP traffic" in the item 3. I get a feeling
that the intent is to provide enough bandwidth for performing essential but relatively not-very-critical control/management plane operations without hurting the determinism expected from the data plane whatsoever. Is my interpretation right ?

One of the schemes Detnet proposes is seamless redundancy replication and elimination. Are we aiming for its realization under 6tisch ?
If we do so, I  suppose it brings in its own set of challenges with respect to track and cell management. This is due to the extent of replication, when and where it comes into play inside the network,  the presence of multiple BBRs. Would be very happy to receive your thoughts on this aspect.

Anand

"

The group will:

"

The group will:

What do you guys think?

Take care;

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

6tisch mailing list

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

--
This message has been scanned for viruses and
dangerous content by MailScanner<http://www.mailscanner.info/>, and is
believed to be clean.

---

From: "S.V.R.Anand" <[email-masked]>
Date: Tue, 29 Sep 2015 21:51:51 +0530

Hi Pascal,

Thank you very much for the clarification and for the valuable inputs!

Looking forward to have a discussion on the topic.

Anand

On Tuesday 29 September 2015 05:14 PM, Pascal Thubert (pthubert) wrote:
>
> Hello Anand:
>
> The intent of the for IP traffic is really whatever traffic is routed 
> by the motes, as opposed to switched at L2.5 along tracks.
>
> And I agree with you for the rest. We have to define tracks, which can 
> probably be more complex than a simple sequence of hops if we want to 
> enable replication and elimination (PRP like).
>
> I wrote some text in 
> https://www.ietf.org/id/draft-thubert-6tisch-4detnet-01.txt and would 
> really appreciate your review in this matter.
>
> And yes, I think it is important to be able to carve PRP path that go 
> to the same collection point on the backbone via different BBRs… I 
> know of some techniques, some with IPR on them (and this includes PRP 
> actually) that we could discuss in the context of that draft.
>
> Take care;
>
> Pascal
>
> *From:*S.V.R.Anand [mailto:[email-masked]]
> *Sent:* mardi 29 septembre 2015 12:17
> *To:* Pascal Thubert (pthubert) <[email-masked]>; [email-masked]
> *Subject:* Re: [6tisch] Rechartering Discussion
>
> Hi Pascal,
>
> that the intent is to provide enough bandwidth for performing 
> essential but relatively not-very-critical control/management plane 
> operations without hurting the determinism expected from the data 
> plane whatsoever. Is my interpretation right ?
>
> replication, when and where it comes into play inside the network,  
> the presence of multiple BBRs. Would be very happy to receive your 
> thoughts on this aspect.
>
> Anand
>
>     The highlighted / colored text below is an inline copy of the
>     slides in the above pdf so you may use that source as well.
>
>     Another suggestion would be to remove the text in Yellow that
>     limits the OTF work to IP bundles (aka track0 or best effort).
>
>     dangerous content by *MailScanner*
>     <http://www.mailscanner.info/>*, and is
>     believed to be clean. *
>
>     *_______________________________________________*
>
>     *6tisch mailing list*
>
>     [email-masked]  <mailto:[email-masked]>*
>
>     *https://www.ietf.org/mailman/listinfo/6tisch*
>
>
> --

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Wed, 30 Sep 2015 08:46:57 +0000

Dear Pascal, all

I agree it should be better to not limit OTF to the best effort track (IP traffic). We may in the future look into more advanced features, and consider other specific tracks.

About the first point on the 6TiSCH Architecture, I have the feeling we should describe better the link between 6TiSCH and DetNet (IMHO applicability of DetNet work doesn't sound clear).

Finally, we could remove the text on non-chartered items (all the content can be kept in a wiki, as per discussion in Prague), but I would add a short sentence referring to the Interop events. If we are planning to keep in organizing them, better to mention it.

Thanks for your work.

Regards,
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Monday, September 28, 2015 12:08 PM
To: [email-masked]
Subject: [6tisch] Rechartering Discussion

Dear all:

"

The group will:

"

The group will:

What do you guys think?

Take care;

---

From: Fabrice Theoleyre <[email-masked]>
Date: Wed, 30 Sep 2015 13:49:25 +0200

Dear all,

+1 to be able to reserve dynamically cells for the non best effort tracks. 
It would be more flexible.

Regards,
Fabrice

> Le 30 sept. 2015 à 10:46, Maria Rita PALATTELLA <[email-masked]> a écrit :
> 
> Dear Pascal, all
>  
> About the first point on the 6TiSCH Architecture, I have the feeling we should describe better the link between 6TiSCH and DetNet (IMHO applicability of DetNet work doesn’t sound clear).
>