Subject: [6tsch] the 4th control flow

From: Qin Wang <[email-masked]>
Date: Sat, 24 Aug 2013 01:36:13 +0800

Hi all,

During today's call, we presented three control flows between Management
Entity (ME) and 6top, i.e. Action Flow, Query Flow, and Report Flow, and
started to talk about the 4th control flow. The thread will continue the
discussion about 4th flow.

Here is the scenario: when a node finds that more cells are needed, e.g.
nodes wants to send 10pkt/s report at some time, it should be able to ask
ME to install more bandwidth.

I can see two approaches:
(1) Managed by ME, without 4th Control Flow. Assume BandwidthUsageRate is a
attribute in 6top. Then, ME can get the information via Query Flow or
Report Flow, and adjust the bandwidth of the node via Action Flow.
(2) Managed by 6top, with 4th Control Flow. 6top sends Bandwidth Request to
ME, and then ME install more bandwidth. This is the 4th control flow.

What do you think? Which one makes more sense?

Qin

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Fri, 23 Aug 2013 10:47:43 -0700

Hi Qin, I like your (2).

Note also that there are situations that might have some differences.

1-the track already exists.
2-the track between the two entities does not exists

in either case I think that the node that requires certain BW to another
node should talk to 6top, which processes that request and sends a request
to the ME, the ME installs that new track.

does it make sense. Do you see any drawback on that approach?

X

On Fri, Aug 23, 2013 at 10:36 AM, Qin Wang <[email-masked]> wrote:

> (1) Managed by ME, without 4th Control Flow. Assume BandwidthUsageRate is
> a attribute in 6top. Then, ME can get the information via Query Flow or
> (2) Managed by 6top, with 4th Control Flow. 6top sends Bandwidth Request
> to ME, and then ME install more bandwidth. This is the 4th control flow.
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Qin Wang <[email-masked]>
Date: Sat, 24 Aug 2013 02:00:04 +0800

Xavi,

Approach-(2) is more flexible and likely covers more situations. But, it
may bring some complexity to 6top, because 6top has to make decision on the
bandwidth request (add/delete), which needs some metrics, some
intelligence.

What do you think?

Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 27 Aug 2013 11:24:12 -0700

Please correct me if I'm wrong:
- Action Flow (ME->6top). ME asks 6top to execute some command. Typical
commands are add/delete cells.
- Query Flow (ME->6top). ME asks 6top for some information. Typical queries
are about current cells usage or statistics.
- Report Flow (6top->ME). 6top tell ME how it is doing. Typical reported
information covers cells usage or statistics.

Questions:
- Looks like Query and Report flows contain the same information. In normal
operation, the Report flow should be enough, the Query flow only being used
in special cases, for example when the ME has lost state (just booted, bug,
etc). Agreed?
- The ME should be able to configure the report flow. Configuration could
be "send report every X seconds" or "send report when variable X larger
than Y". I imagine this could be done over the action flow? Agreed?
- A node will want to report an urgent event to the ME. One such events is
"the topology appears to have changed". There any many cases where
this information needs to be sent immediately, i.e. no time to wait for the
next report cycle. We can consider this to be an asynchronous report, or
part of a new "Event" flow.
- Same for the mote asking the ME for a schedule update.

Thoughts?

Thomas

On Fri, Aug 23, 2013 at 11:00 AM, Qin Wang <[email-masked]> wrote:

>>> (1) Managed by ME, without 4th Control Flow. Assume BandwidthUsageRate
>>> is a attribute in 6top. Then, ME can get the information via Query Flow or

---

From: Qin Wang <[email-masked]>
Date: Wed, 28 Aug 2013 05:09:44 +0800

Thomas,

I agree with almost all. Only some comments on "Report Flow".

As you mentioned, there are two kinds of report scenarios, one is
periodically report, another one is burst report or called as event-driven
report. I have no question on how periodically report works, which you
described. But I'm not sure what the best way to handle event-driven report
is. I think we don't want to assume 6top sublayer is very intelligent, in
another word, the events and the trigger of events should be configured by
ME, just like the interval of periodically report. Make sense?

If you agree to it, the remained issue is  when and how the bandwidth for
sending event-driven reports is reserved. Here are two ways I can see.
(1) when a event is triggered, node sends a request to ME and ask some BW
to send the report. I believe that is how the 4th control flow works.
(2) when ME configure the events and their triggers, ME also provisions
some BW for the node which allows the node to send the report triggered by
some event.

I have no strong opinion on which one is better. But, the bottom line is
the configuration of the set of events and their triggers should be out of
6top scope. Thought?

Thanks
Qin

On Wed, Aug 28, 2013 at 2:20 AM, Thomas Watteyne <[email-masked]>wrote:

> Qin,
> - Query Flow (ME->6top). ME asks 6top for some information. Typical
> queries are about current cells usage or statistics.
> - Looks like Query and Report flows contain the same information. In
> normal operation, the Report flow should be enough, the Query flow only
> being used in special cases, for example when the ME has lost state (just
> booted, bug, etc). Agreed?
>>>> During today's call, we presented three control flows between
>>>> Management Entity (ME) and 6top, i.e. Action Flow, Query Flow, and Report
>>>> Flow, and started to talk about the 4th control flow. The thread will
>>>> continue the discussion about 4th flow.
>>>>
>>>> Here is the scenario: when a node finds that more cells are needed,
>>>> e.g. nodes wants to send 10pkt/s report at some time, it should be able to
>>>> ask ME to install more bandwidth.
>>>>
>>>> (2) Managed by 6top, with 4th Control Flow. 6top sends Bandwidth
>>>> Request to ME, and then ME install more bandwidth. This is the 4th control
>>>> flow.
>>>>
> --
> Thomas Watteyne, Ph. D
> Sr. Networking Design Engineer
> Dust Networks / Linear Technology
> 30695 Huntwood Ave
> Hayward, CA 94544-7021
> +1 (510) 400-2978
> [email-masked]
>
> This e-mail transmission, and any documents, files or previous e-mail
> messages attached to it may contain confidential information that is
> legally privileged. If you are not the intended recipient, or a person
> responsible for delivering it to the intended recipient, you are hereby
> notified that any disclosure, copying, distribution or use of any of the
> information contained in or attached to this transmission is STRICTLY
> PROHIBITED. If you have received this transmission in error, please
> immediately notify me by reply e-mail, or by telephone at (510) 400-2978,
> and destroy the original transmission and its attachments without reading
> or saving in any manner. Thank you.
>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Tue, 27 Aug 2013 17:29:01 -0400

Qin, Thomas,
      Alternative (1) adds delay to define the slots to send the event
to the ME (propagate the new schedule),
while alternative (2)  keeps reserved slots waiting for the event to happen.
I think both alternatives should be included, and configured by the ME depending
on the network requirements.

More thoughts?

Diego Dujovne

2013/8/27 Qin Wang <[email-masked]>:
> (1) when a event is triggered, node sends a request to ME and ask some BW to
> send the report. I believe that is how the 4th control flow works.
> (2) when ME configure the events and their triggers, ME also provisions some
> BW for the node which allows the node to send the report triggered by some
> event.
>
> I have no strong opinion on which one is better. But, the bottom line is the
> configuration of the set of events and their triggers should be out of 6top
> scope. Thought?
>
> Thanks
> Qin
>
>
>
>
>
>
>> be "send report every X seconds" or "send report when variable X larger than
>> Y". I imagine this could be done over the action flow? Agreed?
>> "the topology appears to have changed". There any many cases where this
>> information needs to be sent immediately, i.e. no time to wait for the next
>> report cycle. We can consider this to be an asynchronous report, or part of
>> a new "Event" flow.
>>> bandwidth request (add/delete), which needs some metrics, some intelligence.
>>>
>>> What do you think?
>>>
>>> Qin
>>>
>>>
>>>
>>> On Sat, Aug 24, 2013 at 1:47 AM, Xavier Vilajosana Guillen
>>> <[email-masked]> wrote:
>>>>
>>>> Hi Qin, I like your (2).
>>>>
>> messages attached to it may contain confidential information that is legally
>> privileged. If you are not the intended recipient, or a person responsible
>> for delivering it to the intended recipient, you are hereby notified that
>> any disclosure, copying, distribution or use of any of the information
>> contained in or attached to this transmission is STRICTLY PROHIBITED. If you
>> have received this transmission in error, please immediately notify me by
>> reply e-mail, or by telephone at (510) 400-2978, and destroy the original
>> transmission and its attachments without reading or saving in any manner.
>> Thank you.
>
>
>

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: <[email-masked]>
Date: Tue, 27 Aug 2013 21:48:00 +0000

Qin, Thomas,
Let me enter to your discussion.

First, let me see if I am on the same track. Does ME mean the Management Entity to send management flows to the PCE (in centralized approach) and to Signaling protocol or higher layers (in distributed approach). Am I right?
I completely agree with Qin description.
Regarding to two specified ways (by Qin) to ask bandwidth for sending event-driven reports, I think way (2) makes more sense. Because the events should be send through the multi-hop path (track), toward the network manager (i.e. PCE). Am I right? For sure, way (1) takes more time to reserve potential resources (either in a distributed or centralized manner) for delivering those events toward the final destination (i.e. PCE). By considering way (2), the PCE or higher layers can reserve some shared cells or extra dedicated cells beforehand, for delivering potential event, from node A toward the final destination (i.e. PCE) along the track.
Am I missing anything?

Best Wishes,
Pouria

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: Tuesday, August 27, 2013 11:10 PM
To: Thomas Watteyne
Cc: [email-masked]; Xavier Vilajosana Guillen
Subject: Re: [6tsch] the 4th control flow

Thomas,

As you mentioned, there are two kinds of report scenarios, one is periodically report, another one is burst report or called as event-driven report. I have no question on how periodically report works, which you described. But I'm not sure what the best way to handle event-driven report is. I think we don't want to assume 6top sublayer is very intelligent, in another word, the events and the trigger of events should be configured by ME, just like the interval of periodically report. Make sense?

If you agree to it, the remained issue is  when and how the bandwidth for sending event-driven reports is reserved. Here are two ways I can see.
(1) when a event is triggered, node sends a request to ME and ask some BW to send the report. I believe that is how the 4th control flow works.
(2) when ME configure the events and their triggers, ME also provisions some BW for the node which allows the node to send the report triggered by some event.

I have no strong opinion on which one is better. But, the bottom line is the configuration of the set of events and their triggers should be out of 6top scope. Thought?

Thanks
Qin

On Wed, Aug 28, 2013 at 2:20 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Qin,

Please correct me if I'm wrong:
- Action Flow (ME->6top). ME asks 6top to execute some command. Typical commands are add/delete cells.
- Query Flow (ME->6top). ME asks 6top for some information. Typical queries are about current cells usage or statistics.
- Report Flow (6top->ME). 6top tell ME how it is doing. Typical reported information covers cells usage or statistics.

Questions:
- Looks like Query and Report flows contain the same information. In normal operation, the Report flow should be enough, the Query flow only being used in special cases, for example when the ME has lost state (just booted, bug, etc). Agreed?
- The ME should be able to configure the report flow. Configuration could be "send report every X seconds" or "send report when variable X larger than Y". I imagine this could be done over the action flow? Agreed?
- A node will want to report an urgent event to the ME. One such events is "the topology appears to have changed". There any many cases where this information needs to be sent immediately, i.e. no time to wait for the next report cycle. We can consider this to be an asynchronous report, or part of a new "Event" flow.
- Same for the mote asking the ME for a schedule update.

Thoughts?

Thomas

On Fri, Aug 23, 2013 at 11:00 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Xavi,

Approach-(2) is more flexible and likely covers more situations. But, it may bring some complexity to 6top, because 6top has to make decision on the bandwidth request (add/delete), which needs some metrics, some intelligence.

What do you think?

Qin

On Sat, Aug 24, 2013 at 1:47 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin, I like your (2).

in either case I think that the node that requires certain BW to another node should talk to 6top, which processes that request and sends a request to the ME, the ME installs that new track.

X

On Fri, Aug 23, 2013 at 10:36 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

During today's call, we presented three control flows between Management Entity (ME) and 6top, i.e. Action Flow, Query Flow, and Report Flow, and started to talk about the 4th control flow. The thread will continue the discussion about 4th flow.

Here is the scenario: when a node finds that more cells are needed, e.g. nodes wants to send 10pkt/s report at some time, it should be able to ask ME to install more bandwidth.

I can see two approaches:
(1) Managed by ME, without 4th Control Flow. Assume BandwidthUsageRate is a attribute in 6top. Then, ME can get the information via Query Flow or Report Flow, and adjust the bandwidth of the node via Action Flow.
(2) Managed by 6top, with 4th Control Flow. 6top sends Bandwidth Request to ME, and then ME install more bandwidth. This is the 4th control flow.

Qin

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

--
Thomas Watteyne, Ph. D
Sr. Networking Design Engineer
Dust Networks / Linear Technology
30695 Huntwood Ave
Hayward, CA 94544-7021
+1 (510) 400-2978
[email-masked]<mailto:[email-masked]>

This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2978, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 27 Aug 2013 15:39:41 -0700

Qin,

You bring up a good point: over what cells with the reports travel? Another
questions could be: over what cells will the request to install cells
travel? I believe that, whatever the policy in place in the network, there
will always need to be some cells installed for infrequent signaling
traffic. If the report rate is very slow, it might qualify as "infrequent
signaling traffic". For sure, the request to change the schedule qualifies.

Isn't the answer draft-vilajosana-6tsch-basic? That is, the slotted Aloha
schedule indicated in the draft can be used for the signaling traffic
between the nodes and the ME. Of course, if the report rate is very high,
some dedicate track might be installed, but I do not believe this is
needed, certainly not this early on.

I agree with Diego that keeping the solution open to different alternative
is key.

Thomas

On Tue, Aug 27, 2013 at 2:29 PM, Prof. Diego Dujovne <
[email-masked]> wrote:

> some
> the
> than
> legally

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 27 Aug 2013 15:44:16 -0700

Pouria.
Please see *inline*.
Thomas

On Tue, Aug 27, 2013 at 2:48 PM, <[email-masked]> wrote:

>  Qin, Thomas, ****
>
> Let me enter to your discussion.****
>
> ** **
>
> First, let me see if I am on the same track. Does ME mean the Management
> Entity to send management flows to the PCE (in centralized approach) and to
> Signaling protocol or higher layers (in distributed approach). Am I right?
>

*I believe we haven't been very rigorous, thanks for pointing that out. ME
(Management Entity) was defined by Qin as either some distributed layer, or
a centralized PCE. We want to make sure that the format we need to define
for work item 1 is generic enough for both the centralized and distributed
case, hence the use of the term ME. In this thread, we are mainly talking
about the protocol between the node and the PCE.*

> ****
>
> I completely agree with Qin description.****
>
> Regarding to two specified ways (by Qin) to ask bandwidth for sending
> event-driven reports, I think way (2) makes more sense. Because the events
> should be send through the *multi-hop* path (track), toward the network
> manager (i.e. PCE). Am I right? For sure, way (1) takes more time to
> reserve potential resources (either in a distributed or centralized manner)
> for delivering those events toward the final destination (i.e. PCE). By
> considering way (2), the PCE or higher layers can reserve some shared cells
> or extra dedicated cells beforehand, for delivering potential event, from
> node A toward the final destination (i.e. PCE) along the track.****
>
> Am I missing anything?
>

*I believe this sums it up nicely.*

> ****
>
> ** **
>
> Best Wishes,****
>
> Pouria     ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Qin Wang
> *Sent:* Tuesday, August 27, 2013 11:10 PM
> *To:* Thomas Watteyne
> *Cc:* [email-masked]; Xavier Vilajosana Guillen
> *Subject:* Re: [6tsch] the 4th control flow****
>
> ** **
>
> Thomas,****
>
> ** **
>
> I agree with almost all. Only some comments on "Report Flow". ****
>
> ** **
>
> ME, just like the interval of periodically report. Make sense? ****
>
> ** **
>
> sending event-driven reports is reserved. Here are two ways I can see.****
>
> to send the report. I believe that is how the 4th control flow works.****
>
> some event.****
> ** **
> 6top scope. Thought?****
> ** **
> Thanks****
> Qin****
> ** **
> ** **
> ** **
> ** **
> ** **
> On Wed, Aug 28, 2013 at 2:20 AM, Thomas Watteyne <[email-masked]>
> wrote:****
>
> Qin,****
>
> ** **
>
> Please correct me if I'm wrong:****
>
> commands are add/delete cells.****
>
> queries are about current cells usage or statistics.****
>
> information covers cells usage or statistics.****
>
> ** **
>
> Questions:****
>
> booted, bug, etc). Agreed?****
>
> than Y". I imagine this could be done over the action flow? Agreed?****
>
> part of a new "Event" flow.****
>
> - Same for the mote asking the ME for a schedule update.****
>
> ** **
>
> Thoughts?****
>
> ** **
>
> Thomas****
>
> ** **
>
> ** **
>
> On Fri, Aug 23, 2013 at 11:00 AM, Qin Wang <[email-masked]> wrote:**
> **
>
> Xavi,****
>
> ** **
>
> intelligence. ****
> ** **
> What do you think?****
> ** **
> Qin****
> ** **
> ** **
> [email-masked]> wrote:****
>
> Hi Qin, I like your (2). ****
>
>  ****
>
> Note also that there are situations that might have some differences.****
>
> 1-the track already exists.****
>
> 2-the track between the two entities does not exists****
>
> to the ME, the ME installs that new track.****
>
> X ****
> ** **
> On Fri, Aug 23, 2013 at 10:36 AM, Qin Wang <[email-masked]> wrote:**
> **
>
>   Hi all,****
>
> ** **
>
> discussion about 4th flow.****
>
> ** **
>
> ME to install more bandwidth. ****
>
> ** **
>
> I can see two approaches:****
>
> Report Flow, and adjust the bandwidth of the node via Action Flow. ****
>
> to ME, and then ME install more bandwidth. This is the 4th control flow.**
> **
>
> ** **
>
> What do you think? Which one makes more sense?****
>
> ** **
>
> Qin****
>
> ** **
>
> ** **
>
> ** **
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ** **
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>
>
> ****
>
> ** **
>
> -- ****
>
> Thomas Watteyne, Ph. D****
>
> Sr. Networking Design Engineer****
>
> Dust Networks / Linear Technology****
>
> 30695 Huntwood Ave****
>
> Hayward, CA 94544-7021****
>
> +1 (510) 400-2978****
>
> [email-masked]****
>
> ** **
>
> or saving in any manner. Thank you.****
>
> ** **
>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Wed, 28 Aug 2013 09:18:35 +0000

Thomas, Pouria,
I would also go for option (2). IMHO it makes more sense, because option (1) implies for sure both delay and some extra-overhead that we may want to avoid.
Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Wednesday, August 28, 2013 12:44 AM
To: 6TSCH
Subject: Re: [6tsch] the 4th control flow

Pouria.
Please see inline.
Thomas

On Tue, Aug 27, 2013 at 2:48 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Qin, Thomas,
Let me enter to your discussion.

I believe we haven't been very rigorous, thanks for pointing that out. ME (Management Entity) was defined by Qin as either some distributed layer, or a centralized PCE. We want to make sure that the format we need to define for work item 1 is generic enough for both the centralized and distributed case, hence the use of the term ME. In this thread, we are mainly talking about the protocol between the node and the PCE.

I believe this sums it up nicely.

Best Wishes,
Pouria

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Qin Wang
Sent: Tuesday, August 27, 2013 11:10 PM
To: Thomas Watteyne
Cc: [email-masked]<mailto:[email-masked]>; Xavier Vilajosana Guillen
Subject: Re: [6tsch] the 4th control flow

Thomas,

Thanks
Qin

Questions:

Thoughts?

Thomas

What do you think?

Qin

X

Qin

--
Thomas Watteyne, Ph. D
Sr. Networking Design Engineer
Dust Networks / Linear Technology
30695 Huntwood Ave
Hayward, CA 94544-7021
+1 (510) 400-2978<tel:%2B1%20%28510%29%20400-2978>
[email-masked]<mailto:[email-masked]>

This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at (510) 400-2978<tel:%28510%29%20400-2978>, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Wed, 28 Aug 2013 09:38:28 +0000

Thomas, I believe that after defining the message format for each flow,  we will have to address the issue you have just raised up, i.e., the cells to be used for any kind of signaling traffic (i.e., add/delete cells, report traffic, etc.).
Even though we may start using the slotted aloha schedule approach, in the future, we may think about dedicated tracks, to be built according to the requirements of the schedule used for transferring the actual data traffic.
What do you think?
Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Wednesday, August 28, 2013 12:40 AM
To: [email-masked]
Subject: Re: [6tsch] the 4th control flow

Qin,

You bring up a good point: over what cells with the reports travel? Another questions could be: over what cells will the request to install cells travel? I believe that, whatever the policy in place in the network, there will always need to be some cells installed for infrequent signaling traffic. If the report rate is very slow, it might qualify as "infrequent signaling traffic". For sure, the request to change the schedule qualifies.

Isn't the answer draft-vilajosana-6tsch-basic? That is, the slotted Aloha schedule indicated in the draft can be used for the signaling traffic between the nodes and the ME. Of course, if the report rate is very high, some dedicate track might be installed, but I do not believe this is needed, certainly not this early on.

I agree with Diego that keeping the solution open to different alternative is key.

Thomas

On Tue, Aug 27, 2013 at 2:29 PM, Prof. Diego Dujovne <[email-masked]<mailto:[email-masked]>> wrote:
Qin, Thomas,

More thoughts?

Diego Dujovne

2013/8/27 Qin Wang <[email-masked]<mailto:[email-masked]>>:
>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>>>
>>>> Hi Qin, I like your (2).
>>>>
>> reply e-mail, or by telephone at (510) 400-2978<tel:%28510%29%20400-2978>, and destroy the original

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
(56 2) 676 8125<tel:%2856%202%29%20676%208125>
_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 28 Aug 2013 11:33:20 +0000

Hello Thomas and all;

If you refer to the industrial applicability statement, there is an expectation that a very autonomic and solid RPL instance will span the network for management purpose.
In the architecture, we could mention that expectation and reserve an instance number (0?) for the spanning management instance.

This way, whatever users do on the other (data) instances, they will not break the management instance and will always be able to reach the devices and manage them.
Autonomic Networking does something similar...

I do agree with Thomas that the basic support can be used to provide the expected instance.
The capability to increase dynamically the number of cells in a bundle would be a great addition for the final solution, though.

Cheers,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: mercredi 28 août 2013 00:40
To: [email-masked]
Subject: Re: [6tsch] the 4th control flow

Qin,

Thomas

More thoughts?

Diego Dujovne

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 28 Aug 2013 12:05:42 +0000

Hello Maria Rita:

There are also schemas that could allow to dynamically adapt the amount of cells in a bundle between 2 peer routers with a few control bits piggy-backed with the existing traffic.
Such schema would avoid the need for out-of-band control traffic and avoid the problem of pre allocating slots for that purpose.

In the simplest case, we would allocate a peak n number of time slots for a bundle but signal with a control bit whether the next slot is actually free in which case both sender and receiver would sleep at that time. By default the devices would send/receive every p <n but if a burst of traffic or additional retries require so, the co-next slot would be activated.

For instance with p = 1 and n = 4 we can quadruple the throughput at peak time.

What do you think?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Maria Rita PALATTELLA
Sent: mercredi 28 août 2013 11:38
To: Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] the 4th control flow

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Wednesday, August 28, 2013 12:40 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] the 4th control flow

Qin,

Thomas

More thoughts?

Diego Dujovne

---

From: Qin Wang <[email-masked]>
Date: Wed, 28 Aug 2013 22:51:21 +0800

Hi Pascal,

I think your "a few control bits piggy-backed with the existing traffic" is
a good idea. Over-provision can increase the throughput at peak time, while
the control bits can reduce the energy consumption for idle-listening (at
least at the beginning of slot) in those unused Tx/Rx cells.

Xavi and Thomas, I think the method can be used to save energy in our
over-provision case, event that is for improving link quality. What do you
think?

Thanks
Qin

On Wed, Aug 28, 2013 at 8:05 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Maria Rita:****
>
> ** **
>
> There are also schemas that could allow to dynamically adapt the amount of
> cells in a bundle between 2 peer routers with a few control bits
> piggy-backed with the existing traffic.****
>
> Such schema would avoid the need for out-of-band control traffic and avoid
> the problem of pre allocating slots for that purpose. ****
>
> ** **
>
> In the simplest case, we would allocate a peak n number of time slots for
> a bundle but signal with a control bit whether the next slot is actually
> free in which case both sender and receiver would sleep at that time. By
> default the devices would send/receive every p <n but if a burst of traffic
> or additional retries require so, the co-next slot would be activated. ***
> *
>
> ** **
>
> For instance with p = 1 and n = 4 we can quadruple the throughput at peak
> time.****
>
> ** **
>
> What do you think?****
>
> ** **
>
> Pascal****
>
> ** **
>
> Of *Maria Rita PALATTELLA
> *Sent:* mercredi 28 août 2013 11:38
> *To:* Thomas Watteyne; [email-masked]
>
> Thomas, I believe that after defining the message format for each flow,
>  we will have to address the issue you have just raised up, i.e., the cells
> to be used for any kind of signaling traffic (i.e., add/delete cells,
> report traffic, etc.).****
>
> Even though we may start using the slotted aloha schedule approach, in the
> future, we may think about dedicated tracks, to be built according to the
> requirements of the schedule used for transferring the actual data traffic.
> ****
>
> What do you think? ****
>
> Maria Rita ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Thomas Watteyne
> *Sent:* Wednesday, August 28, 2013 12:40 AM
> *To:* [email-masked]
> You bring up a good point: over what cells with the reports travel?
> Another questions could be: over what cells will the request to install
> cells travel? I believe that, whatever the policy in place in the network,
> there will always need to be some cells installed for infrequent signaling
> needed, certainly not this early on.****
>
> ** **
>
> is key.****
> [email-masked]> wrote:****
>
> Qin, Thomas,
> 2013/8/27 Qin Wang <[email-masked]>:****
>
> > Thomas,
> >
> > wrote:
> --****
> (56 2) 676 8125****

---

From: Qin Wang <[email-masked]>
Date: Wed, 28 Aug 2013 22:59:43 +0800

Thomas,

I agree to keep different alternatives, at lease as options.

Regarding to what kinds of cells should be used for conveying the report,
shared cells or dedicated cells, I would like to leave them to
configuration. What do you think?

Thanks
Qin

On Wed, Aug 28, 2013 at 6:39 AM, Thomas Watteyne <[email-masked]

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Wed, 28 Aug 2013 10:49:50 -0700

Hi,

while it sounds to me a great idea, I think it is better first to
concentrate on the basic things. IMHO, we need first to define the signals
to control the flow of data, later if we can define little headers where we
can add this control bits together with data packets would be a good
enhancement.

What do you think?
X

On Wed, Aug 28, 2013 at 7:51 AM, Qin Wang <[email-masked]> wrote:

> Hi Pascal,
>
> I think your "a few control bits piggy-backed with the existing traffic"
> is a good idea. Over-provision can increase the throughput at peak time,
> while the control bits can reduce the energy consumption for idle-listening
> (at least at the beginning of slot) in those unused Tx/Rx cells.
>
>> There are also schemas that could allow to dynamically adapt the amount
>> of cells in a bundle between 2 peer routers with a few control bits
>> Such schema would avoid the need for out-of-band control traffic and
>> avoid the problem of pre allocating slots for that purpose. ****
>>
>> ** **
>>
>> or additional retries require so, the co-next slot would be activated. **
>> **
>>
>> ** **
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Maria Rita PALATTELLA
>> Even though we may start using the slotted aloha schedule approach, in
>> the future, we may think about dedicated tracks, to be built according to
>> the requirements of the schedule used for transferring the actual data
>> traffic.****
>>
>> What do you think? ****
>>
>> Maria Rita ****
>>
>> ** **
>>
>> I agree with Diego that keeping the solution open to different
>> alternative is key.****
>>
>> ** **
>>
>> Thomas****
>>
>> ** **
>>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 28 Aug 2013 11:15:09 -0700

All,

If possible, let's keep things simple and stick closely to the charter,
certainly for now.

I would like to propose the following assumptions:

   - let's assume signaling and data packets are independent.
   IMO, signaling packets are either short and infrequent (events,
   commands), or periodic and large (statistics). Once we have run a number of
   networks, and can quantify the trade-offs, we can consider piggybacking.
   - let's consider the steps highlighted in the charter, for now:
      - draft-vilajosana-6tsch-basic gives us a network with minimal
      connectivity between all nodes in the network. Most of the schedule is
      empty, available ot some dynamic scheduler.
      - the scheduler uses the minimal connectivity to communicate, either
      between neighbors (distributed), or between nodes and the PCE
(centralized)

If we agree with this, I propose we go back to discussing the types of
flows, per the name of this thread. I'd like to call on a rough consensus
for the following 4 flows:

   - ME->node
      - action
      - query
   - node->ME
      - report
      - event

Thomas

On Wed, Aug 28, 2013 at 7:59 AM, Qin Wang <[email-masked]> wrote:

> On Wed, Aug 28, 2013 at 6:39 AM, Thomas Watteyne <
> [email-masked]> wrote:
>
>> Qin,
>>
>> alternative is key.
>>> > On Wed, Aug 28, 2013 at 2:20 AM, Thomas Watteyne <[email-masked]
>>> >
>>> > wrote:
>>> >>
>>> >> Qin,
>>> >>
>>> this

---

From: Qin Wang <[email-masked]>
Date: Thu, 29 Aug 2013 04:48:55 +0800

Thomas,

I agree to the 4 control flows. One more question for the two node->ME
flows: Is a Confirmation from ME to node needed?

Thanks
Qin

On Thu, Aug 29, 2013 at 2:15 AM, Thomas Watteyne <[email-masked]

>       - the scheduler uses the minimal connectivity to communicate,
>       either between neighbors (distributed), or between nodes and the PCE
>       (centralized)
>
>>> Isn't the answer draft-vilajosana-6tsch-basic? That is, the slotted
>>> Aloha schedule indicated in the draft can be used for the signaling traffic

---

From: Xavier Vilajosana Guillen <[email-masked]>
Date: Wed, 28 Aug 2013 15:26:35 -0700

Hi, I also agree with the 4 message flows.
as regards to Confirmation, this would introduce end-to-end confirmation at
L2.5 - 3. I don't think we need that as a mandatory concept. Maybe an
optional feature?

X

On Wed, Aug 28, 2013 at 1:48 PM, Qin Wang <[email-masked]> wrote:

> On Thu, Aug 29, 2013 at 2:15 AM, Thomas Watteyne <
>>> Regarding to what kinds of cells should be used for conveying the
>>> report, shared cells or dedicated cells, I would like to leave them to

---

From: "JP Vasseur (jvasseur)" <[email-masked]>
Date: Thu, 29 Aug 2013 05:24:40 +0000

Hi,

I would just be vary cautious when thinking of piggybacking control information in packet header for control plane purpose as opposed to specifying a "clean"
(if I may use that expression) approach though.

Thanks.

JP.

On Aug 28, 2013, at 7:49 PM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

while it sounds to me a great idea, I think it is better first to concentrate on the basic things. IMHO, we need first to define the signals to control the flow of data, later if we can define little headers where we can add this control bits together with data packets would be a good enhancement.

What do you think?
X

On Wed, Aug 28, 2013 at 7:51 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pascal,

I think your "a few control bits piggy-backed with the existing traffic" is a good idea. Over-provision can increase the throughput at peak time, while the control bits can reduce the energy consumption for idle-listening (at least at the beginning of slot) in those unused Tx/Rx cells.

Xavi and Thomas, I think the method can be used to save energy in our over-provision case, event that is for improving link quality. What do you think?

Thanks
Qin

On Wed, Aug 28, 2013 at 8:05 PM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Maria Rita:

What do you think?

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Maria Rita PALATTELLA
Sent: mercredi 28 août 2013 11:38
To: Thomas Watteyne; [email-masked]<mailto:[email-masked]>

Qin,

Thomas

More thoughts?

Diego Dujovne

www.ingenieria.udp.cl<http://www.ingenieria.udp.cl/>

_______________________________________________
6tsch mailing list
[email-masked]<http://ietf.org>
https://www.ietf.org/mailman/listinfo/6tsch

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 29 Aug 2013 09:00:34 +0000

All, going back to the definition of the 4 control flows, I tried to fill some of the TODO rows of the tables that Qin created so far.

An updated version of these tables is attached. I left also some comments for discussing on.
Any comment is welcome.

Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Xavier Vilajosana Guillen
Sent: Thursday, August 29, 2013 12:27 AM
To: Qin Wang
Cc: Thomas Watteyne; [email-masked]
Subject: Re: [6tsch] the 4th control flow

Hi, I also agree with the 4 message flows.
as regards to Confirmation, this would introduce end-to-end confirmation at L2.5 - 3. I don't think we need that as a mandatory concept. Maybe an optional feature?

X

On Wed, Aug 28, 2013 at 1:48 PM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Thomas,

I agree to the 4 control flows. One more question for the two node->ME flows: Is a Confirmation from ME to node needed?

Thanks
Qin

On Thu, Aug 29, 2013 at 2:15 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
All,

If possible, let's keep things simple and stick closely to the charter, certainly for now.

  *   let's assume signaling and data packets are independent.
IMO, signaling packets are either short and infrequent (events, commands), or periodic and large (statistics). Once we have run a number of networks, and can quantify the trade-offs, we can consider piggybacking.
  *   let's consider the steps highlighted in the charter, for now:

     *   draft-vilajosana-6tsch-basic gives us a network with minimal connectivity between all nodes in the network. Most of the schedule is empty, available ot some dynamic scheduler.
     *   the scheduler uses the minimal connectivity to communicate, either between neighbors (distributed), or between nodes and the PCE (centralized)
If we agree with this, I propose we go back to discussing the types of flows, per the name of this thread. I'd like to call on a rough consensus for the following 4 flows:

  *   ME->node

     *   action
     *   query

  *   node->ME

     *   report
     *   event
Thomas

On Wed, Aug 28, 2013 at 7:59 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Thomas,

Regarding to what kinds of cells should be used for conveying the report, shared cells or dedicated cells, I would like to leave them to configuration. What do you think?

Thanks
Qin

On Wed, Aug 28, 2013 at 6:39 AM, Thomas Watteyne <[email-masked]<mailto:[email-masked]>> wrote:
Qin,

Thomas

More thoughts?

Diego Dujovne

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 Aug 2013 09:40:05 +0000

+1.

I expect that the event flow is the way the device A instructs the controller (the PCE) that it needs a track to device B?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: mercredi 28 août 2013 20:15
To: Qin Wang
Cc: [email-masked]
Subject: Re: [6tsch] the 4th control flow

All,

[] Agreed

     *   draft-vilajosana-6tsch-basic gives us a network with minimal connectivity between all nodes in the network. Most of the schedule is empty, available ot some dynamic scheduler.
     *   the scheduler uses the minimal connectivity to communicate, either between neighbors (distributed), or between nodes and the PCE (centralized)
[] Agreed. Note that if we want to build on that decision for the future, we'll want at some point an extension to Basic TiSCH to make it a little bit more configurable.
If we agree with this, I propose we go back to discussing the types of flows, per the name of this thread. I'd like to call on a rough consensus for the following 4 flows:

  *   ME->node

     *   action
     *   query

  *   node->ME

     *   report
     *   event
Thomas

Thanks
Qin

Thomas

More thoughts?

Diego Dujovne

---

From: Qin Wang <[email-masked]>
Date: Thu, 29 Aug 2013 22:40:44 +0800

Hi Maria Rita,

Thank you very much for the updated version.

Regarding to who triggers Report Flow and Event Flow, I have different
understanding as follows. Being different from Query Flow, both Report Flow
and Event Flow are triggered by nodes themselves, instead of a query from
ME. In particular, the Report Flow will be triggered by a timer, because it
corresponds to periodically reporting behavior; and the Event Flow will be
triggered by some event specified by ME in advance, something like a alarm.

What do you think?

Qin

On Thu, Aug 29, 2013 at 5:00 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>  All, going back to the definition of the 4 control flows, I tried to
> fill some of the TODO rows of the tables that Qin created so far.****
>
> ** **
>
> An updated version of these tables is attached. I left also some comments
> for discussing on.****
>
> Any comment is welcome.****
>
> ** **
>
> Maria Rita****
>
> ** **
>
> Of *Xavier Vilajosana Guillen
> *Sent:* Thursday, August 29, 2013 12:27 AM
> *To:* Qin Wang
> *Cc:* Thomas Watteyne; [email-masked]
>
> as regards to Confirmation, this would introduce end-to-end confirmation
> at L2.5 - 3. I don't think we need that as a mandatory concept. Maybe an
> optional feature?
>
>
> X****
>
>  ** **
>
> On Wed, Aug 28, 2013 at 1:48 PM, Qin Wang <[email-masked]> wrote:***
> *
>
> Thomas,****
>
> ** **
>
> flows: Is a Confirmation from ME to node needed?****
>
> ** **
>
> Thanks****
>
> Qin****
>
> ** **
>
> [email-masked]> wrote:****
>
> All,****
>
> ** **
>
> certainly for now.****
> I would like to propose the following assumptions:****
>
>    - let's consider the steps highlighted in the charter, for now:****
>
>
>       empty, available ot some dynamic scheduler.****
>       (centralized)****
> for the following 4 flows:****
>
>    - ME->node****
>
>
>     - action****
>       - query****
>
>
>    - node->ME****
>
>
>     - report****
>       - event****
>
>  Thomas****
>
> ** **
>
> ** **
>
> On Wed, Aug 28, 2013 at 7:59 AM, Qin Wang <[email-masked]> wrote:***
> *
>
> Thomas,****
>
> ** **
>
> I agree to keep different alternatives, at lease as options.****
>
> ** **
>
> configuration. What do you think?****
>
> ** **
>
> Thanks****
>
> Qin****
>
> ** **
>
> ** **
>
> [email-masked]> wrote:****
>
> Qin,****
>
> ** **
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 29 Aug 2013 15:15:39 +0000

Hello Qin:

I'm with you that the reports and events are initiated by the device.

Then there is the flow that we discussed at the call last week and that triggered this thread. The use case is a new control loop for which a sensor device talks to the controller (the PCE) to request the establishment of a path between self and an actuator.

I imagined that this was considered an event. But maybe not?

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: jeudi 29 août 2013 16:41
To: Maria Rita PALATTELLA
Cc: Thomas Watteyne; [email-masked]; [email-masked]
Subject: Re: [6tsch] the 4th control flow

Hi Maria Rita,

Regarding to who triggers Report Flow and Event Flow, I have different understanding as follows. Being different from Query Flow, both Report Flow and Event Flow are triggered by nodes themselves, instead of a query from ME. In particular, the Report Flow will be triggered by a timer, because it corresponds to periodically reporting behavior; and the Event Flow will be triggered by some event specified by ME in advance, something like a alarm.

What do you think?

Qin

On Thu, Aug 29, 2013 at 5:00 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
All, going back to the definition of the 4 control flows, I tried to fill some of the TODO rows of the tables that Qin created so far.

Maria Rita

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Xavier Vilajosana Guillen
Sent: Thursday, August 29, 2013 12:27 AM
To: Qin Wang
Cc: Thomas Watteyne; [email-masked]<mailto:[email-masked]>

X

Thanks
Qin

  *   ME->node

     *   action
     *   query

  *   node->ME

     *   report
     *   event
Thomas

Thanks
Qin

Thomas

More thoughts?

Diego Dujovne

---

From: Qin Wang <[email-masked]>
Date: Fri, 30 Aug 2013 01:29:36 +0800

Pascal,

You are right, it is one kind of Event Flow.

Thanks
Qin

On Thu, Aug 29, 2013 at 11:15 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

>  Hello Qin:****
>
> ** **
>
> I’m with you that the reports and events are initiated by the device. ****
>
> ** **
>
> Then there is the flow that we discussed at the call last week and that
> triggered this thread. The use case is a new control loop for which a
> sensor device talks to the controller (the PCE) to request the
> establishment of a path between self and an actuator.****
>
> ** **
>
> I imagined that this was considered an event. But maybe not?****
>
> ** **
>
> Pascal****
>
> ** **
>
> *Sent:* jeudi 29 août 2013 16:41
> *To:* Maria Rita PALATTELLA
> *Cc:* Thomas Watteyne; [email-masked]; [email-masked]
>
> Hi Maria Rita,****
> Thank you very much for the updated version.****
>
> ** **
>
> [email-masked]> wrote:****
>
> All, going back to the definition of the 4 control flows, I tried to fill
> some of the TODO rows of the tables that Qin created so far.****
>
>  ****
>
> *Cc:* Thomas Watteyne; [email-masked]****
>
>
> Hi, I also agree with the 4 message flows.****
>
>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 30 Aug 2013 06:38:58 +0000

Thanks Qin and Pascal for your clarification.
Now I am synchronize with you! So, I will think again about specifications for the report and control flow.
Maria Rita

From: Pascal Thubert (pthubert) [mailto:[email-masked]]
Sent: Thursday, August 29, 2013 5:16 PM
To: Qin Wang; Maria Rita PALATTELLA
Cc: Thomas Watteyne; [email-masked]; [email-masked]
Subject: RE: [6tsch] the 4th control flow

Hello Qin:

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Qin Wang
Sent: jeudi 29 août 2013 16:41
To: Maria Rita PALATTELLA
Cc: Thomas Watteyne; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tsch] the 4th control flow

Hi Maria Rita,

What do you think?

Qin

Maria Rita

X

Thanks
Qin

  *   ME->node

     *   action
     *   query

  *   node->ME

     *   report
     *   event
Thomas

Thanks
Qin

Thomas

More thoughts?

Diego Dujovne