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

[Thomas Watteyne <[e-mail]>]

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 <[e-mail]> wrote:

> 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 <
> [e-mail]> 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:* [e-mail] [mailto:[e-mail]] *On
>> Behalf Of *Thomas Watteyne
>> *Sent:* Tuesday, September 10, 2013 6:24 AM
>> *To:* [e-mail]
>> *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 <[e-mail]> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tsch****
>>
>> ** **
>>
>> _______________________________________________
>> 6tsch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>