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

[Qin Wang <[e-mail]>]

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 <[e-mail]
> 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.
>
> 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
>>>
>>>
>>
>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>
>