Subject: [6tsch] Is generic management method possible?

From: Qin Wang <[email-masked]>
Date: Tue, 10 Sep 2013 04:57:46 +0800

Hi All,

In the previous discussion, we have figured out 5 control flows between PCE
and node, which were expressed in the context of centralized case.
Obviously, it will be great if the messages in those identified control
flows are generic, suitable for both centralized and distributed case.
During last Friday's call, it was mentioned but is still a open issue. I
propose to continue the discussion in this thread.

Comparing the role of PCE in centralized case,I think RSVP/NSIS will play
similar role in distributed case. In another word, instead of exchanging
message with PCE via a network, 6top Management Entity will exchange
message with a Reservation Entity like RSVP/NSIS inside the same node. The
question is if it is possible to use same design in the two cases.  (I'm
not expert on RSVP and NSIS, please input your opinions).

Firstly, I think the contents of messages in the centralized and
distributed case are overlap in a big portion. For example, both of them
need to send action flow, both of them need statistics data, and so on.

Secondly, in terms of Message Exchange, the two cases are similar. The only
difference is, in centralized case, the control messages are carried by
CoAP as payload; and in distributed case, the control messages are "sent"
via internal pointer.

Make sense?

Qin

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 9 Sep 2013 21:23:33 -0700

Qin,

I fully agree that being able to reuse some formats in the distributed case
is important. The question about the exact protocol to use for negotiation
between neighbors in the distributed case is a very broad one. It is too
early to discuss that. We can, however, keep the distributed case in mind
when proposing formats.

Thomas

On Mon, Sep 9, 2013 at 1:57 PM, Qin Wang <[email-masked]> wrote:

> Hi All,
>
> In the previous discussion, we have figured out 5 control flows between
> PCE and node, which were expressed in the context of centralized case.
> Secondly, in terms of Message Exchange, the two cases are similar. The
> only difference is, in centralized case, the control messages are carried
> by CoAP as payload; and in distributed case, the control messages are
> "sent" via internal pointer.
>
> Make sense?
>
> Qin
>
>
>
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Tue, 10 Sep 2013 06:45:51 +0000

Qin, I agree too about defining the formats in a way that we can reuse them for the distributed case. But, for the time being, I would be focused on the centralized approach and try to find a solution for it. And then, move to the distributed one (that for sure will raise other issues up).
Let's try to solve the problems one by one!
Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Tuesday, September 10, 2013 6:24 AM
To: [email-masked]
Subject: Re: [6tsch] Is generic management method possible?

Qin,

I fully agree that being able to reuse some formats in the distributed case is important. The question about the exact protocol to use for negotiation between neighbors in the distributed case is a very broad one. It is too early to discuss that. We can, however, keep the distributed case in mind when proposing formats.

Thomas

On Mon, Sep 9, 2013 at 1:57 PM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi All,

In the previous discussion, we have figured out 5 control flows between PCE and node, which were expressed in the context of centralized case. Obviously, it will be great if the messages in those identified control flows are generic, suitable for both centralized and distributed case. During last Friday's call, it was mentioned but is still a open issue. I propose to continue the discussion in this thread.

Comparing the role of PCE in centralized case,I think RSVP/NSIS will play similar role in distributed case. In another word, instead of exchanging message with PCE via a network, 6top Management Entity will exchange message with a Reservation Entity like RSVP/NSIS inside the same node. The question is if it is possible to use same design in the two cases.  (I'm not expert on RSVP and NSIS, please input your opinions).

Firstly, I think the contents of messages in the centralized and distributed case are overlap in a big portion. For example, both of them need to send action flow, both of them need statistics data, and so on.

Secondly, in terms of Message Exchange, the two cases are similar. The only difference is, in centralized case, the control messages are carried by CoAP as payload; and in distributed case, the control messages are "sent" via internal pointer.

Make sense?

Qin

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

---

From: Qin Wang <[email-masked]>
Date: Tue, 10 Sep 2013 20:48:55 +0800

Hi Thomas and Maria Rita,

I totally agree with you that we should focus on centralized approach in
the current step. But I cannot see it is very difficult to cover
distributed case. Maybe I miss something.

To be clear, in my mind, the exchanged messages in distributed case is that
between 6top and some Reservation protocol like RSVP/NSIS in upper layer.
In another word, it is about exchanging messages inside a node, instead of
exchanging messages among neighbors. I don't understand why for different
upper layer Reservation protocol, the control flows from/to 6top could be
different significantly. Can you explain a little more?

Thanks
Qin

On Tue, Sep 10, 2013 at 2:45 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>  Qin, I agree too about defining the formats in a way that we can reuse
> them for the distributed case. But, for the time being, I would be focused
> on the centralized approach and try to find a solution for it. And then,
> move to the distributed one (that for sure will raise other issues up).***
> *
>
> Let’s try to solve the problems one by one! ****
>
> Maria Rita ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Thomas Watteyne
> *Sent:* Tuesday, September 10, 2013 6:24 AM
> *To:* [email-masked]
> *Subject:* Re: [6tsch] Is generic management method possible?****
>
> ** **
>
> Qin,****
>
> ** **
>
> I fully agree that being able to reuse some formats in the distributed
> case is important. The question about the exact protocol to use for
> negotiation between neighbors in the distributed case is a very broad one.
> It is too early to discuss that. We can, however, keep the distributed case
> in mind when proposing formats.****
>
> ** **
>
> Thomas****
>
> ** **
>
> On Mon, Sep 9, 2013 at 1:57 PM, Qin Wang <[email-masked]> wrote:****
>
> Hi All,****
>
> ** **
>
> propose to continue the discussion in this thread.****
>
> ** **
>
> not expert on RSVP and NSIS, please input your opinions).****
>
> ** **
>
> need to send action flow, both of them need statistics data, and so on.***
> *
>
> ** **
>
> "sent" via internal pointer. ****
>
> ** **
>
> Make sense?****
>
> ** **
>
> Qin****
>
> ** **
>
> ** **
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>

---

From: Thomas Watteyne <[email-masked]>
Date: Tue, 10 Sep 2013 10:17:01 -0700

Qin,

I think we all largely agree. What follows is some context to make entirely
sure we're talking about the same thing. It's written in -vv mode, so
please be patient.

The following illustrates the different interactions.

  +-----+         +--------------------+         +--------------------+
  | PCE |<==*(3)*==>|      6top ME  ^    |         |                    |
  +-----+         +---------------|----+         +--------------------+
                  |       CoAP    |    |         |       CoAP         |
                  +-------------- | ---+         +--------------------+
                  |          .   *(1)*   |         |          .         |
                  |          .    |    |         |          .         |
                  +-------------- | ---+         +--------------------+
                  |       6top    V    |<==*(2)*==>|       6top         |
                  +--------------------+         +--------------------+
                  | IEEE802.15.4e TSCH |         | IEEE802.15.4e TSCH |
                  +--------------------+         +--------------------+

6top is a sublayer which lives above MAC. It is described in
http://tools.ietf.org/html/draft-wang-6tsch-6top-00 and defines *(1)* the
hooks for an upper layer to interact with the TSCH schedule and *(2)* a
negotiation mechanism between two nodes to manage soft cells allocation. *
(1)* is used by the 6top management entity (6top ME). *(2)* is used by
neighbor nodes to manage soft cells.

In a centralized case, the PCE talks to the 6top ME over some
application-level protocol *(3)*. While this is still in debate, CoAP looks
like an interesting choice (Raghu and Xavi will be leading a discussion
about CoAP during this Friday's call).

About the different interactions depicted above:

   - The discussion about the flows we had last week deals with *(3)*. We
   identified 5 flows, and started discussing the contents of the report
   flows, as captured in
   https://bitbucket.org/6tsch/meetings/wiki/report_flow_contents.
   - The interaction marked *(1)* is inside the mote. Since it does not
   involve sending bytes over the air, I would argue that it is
   implementation-specific, and out of scope of what we want to standardize.
   And while http://tools.ietf.org/html/draft-wang-6tsch-6top-00#section-2.4
defines
   a set of commands, an implementation will be compliant as long as it
   trigger the correct "over-the-air" behavior.
   - Since we are working on the centralized case first, and that it makes
   most sense to use hard cells in the centralized case, *(2)* hasn't
   received much attention lately. I believe that we should keep what's
   defined in http://tools.ietf.org/html/draft-wang-6tsch-6top-00 and
   resume working on it when we tackle the distributed case.

Coming back to our discussion about formats, I expect a packet of
interaction to look *(3)* something like:

+------...-------+------+---------+
| several header | CoAP | *payload* |
+------...-------+------+---------+

CoAP will give us "services" such as resource and URIs, method
(GET/POST/PUT/DELETE) and optional confirmable messages. Using those simply
means that the 6top ME will not have to re-define those "services", hence
that the format of the *payload* gets simpler. CoAP is also
"application-agnostic", i.e. it just transports the *payload* between two
end-points, without knowing anything about what that *payload* contains.

The distributed case is a different problem. We are talking about using
protocols such as RSVP/NSIS, which are more than just "transporting" data,
since they come with precise interaction models. Given this, I would argue
that we will not be able to reuse the exact same *payload* format. That
being said, it we opt for flexible encoding of generic information such as
"a request for bandwidth", or "a statistic about cell usage", we might be
able to reuse those as building blocks whenever needed by RSVP/NSIS (or a
simpler version thereof). I believe in the JSON/BSON/CBOR path we are
following, and that it will give us the re-usability we are looking for.

Is this in line with what you're thinking?

Thomas

On Tue, Sep 10, 2013 at 5:48 AM, Qin Wang <[email-masked]> wrote:

> To be clear, in my mind, the exchanged messages in distributed case is
> that between 6top and some Reservation protocol like RSVP/NSIS in upper
> layer. In another word, it is about exchanging messages inside a node,
> instead of exchanging messages among neighbors. I don't understand why for
> different upper layer Reservation protocol, the control flows from/to 6top
> could be different significantly. Can you explain a little more?
>
> Thanks
> Qin
>
>
>
>
>
>
>> move to the distributed one (that for sure will raise other issues up).**
>> **
>>
>> *From:* [email-masked] [mailto:[email-masked]] *On
>> Behalf Of *Thomas Watteyne
>> need to send action flow, both of them need statistics data, and so on.**
>> **
>>
>> ** **
>>

---

From: Qin Wang <[email-masked]>
Date: Wed, 11 Sep 2013 23:07:02 +0800

Hi Thomas,

Thank you very much for the detailed explanation. It is very clear. I agree
with you to leave the discussion about distributed case later.

Thanks
Qin

On Wed, Sep 11, 2013 at 1:17 AM, Thomas Watteyne <[email-masked]
> wrote:

> Qin,
>
> I think we all largely agree. What follows is some context to make
> entirely sure we're talking about the same thing. It's written in -vvmode, so please be patient.
>
> application-level protocol *(3)*. While this is still in debate, CoAP
> looks like an interesting choice (Raghu and Xavi will be leading a
> discussion about CoAP during this Friday's call).
>
>    And while
>    http://tools.ietf.org/html/draft-wang-6tsch-6top-00#section-2.4 defines
>    - Since we are working on the centralized case first, and that it
>    makes most sense to use hard cells in the centralized case, *(2)* hasn't
>>> move to the distributed one (that for sure will raise other issues up).*
>>> ***
>>>
>>> Comparing the role of PCE in centralized case,I think RSVP/NSIS will
>>> play similar role in distributed case. In another word, instead of
>>> exchanging message with PCE via a network, 6top Management Entity will
>>> exchange message with a Reservation Entity like RSVP/NSIS inside the same
>>> node. The question is if it is possible to use same design in the two
>>> cases.  (I'm not expert on RSVP and NSIS, please input your opinions).**
>>> **
>>>
>>> ** **
>>>
>>> need to send action flow, both of them need statistics data, and so on.*
>>> ***
>>>
>>> ** **
>>>