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

Qin Wang <qinwang@berkeley.edu> Wed, 11 September 2013 15:07 UTC

Return-Path: <qinwang@berkeley.edu>
X-Original-To: 6tsch@ietfa.amsl.com
Delivered-To: 6tsch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4086121E8118 for <6tsch@ietfa.amsl.com>; Wed, 11 Sep 2013 08:07:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.074
X-Spam-Level:
X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnaesQMuJIpx for <6tsch@ietfa.amsl.com>; Wed, 11 Sep 2013 08:07:04 -0700 (PDT)
Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by ietfa.amsl.com (Postfix) with ESMTP id 12F6F11E8181 for <6tsch@ietf.org>; Wed, 11 Sep 2013 08:07:03 -0700 (PDT)
Received: by mail-ie0-f181.google.com with SMTP id y16so13362838ieg.26 for <6tsch@ietf.org>; Wed, 11 Sep 2013 08:07:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=YfmKqxDZjwztaTnnc/FAQVKJUOuS8xIjnmA5uCRPSo0=; b=XvUT4ZVvSAlYFn8ZvEQugJxId7mj5dxDy0oZeVq2XFd+CN6WCJRFyBc6XRaz9qxTrp yR63pa8jCCdyx+mfL+lFsnEPTmBRG6czzguNN/mungvtNuJFGZBQa0KuSCg1jwLLk7F4 /Z08bhZweUKObTYU9nmpN+dxoKf5sA/jKLMAo4+H2c9sE7YCEjeZW0DyYuXNjtrvYwzw Lp11p/dsxFsY+hLdQkiHUsKCZrkb/wMVCXsrYTRwye1mOB+oJxTNKIPZEnwE8yniui6U O2T3zJb5DKi4YTpj2xniJDYgw7CFWc6tars62i/lKsJTh3vdBzB5x7noC9nPCKEKz6ES JceQ==
X-Gm-Message-State: ALoCoQnm1YhqSntpWtHdN0Xak9yNXxbSULF8Gtkz+T7VgAbXIq3Nza+MjiO8H80iFvkWkazegNgn
MIME-Version: 1.0
X-Received: by 10.50.73.41 with SMTP id i9mr496623igv.30.1378912022379; Wed, 11 Sep 2013 08:07:02 -0700 (PDT)
Received: by 10.64.139.234 with HTTP; Wed, 11 Sep 2013 08:07:02 -0700 (PDT)
In-Reply-To: <CADJ9OA9zO1jiP1d7swxOa4jQjrA1iwU+4dZK2wG4M1OJbZqetA@mail.gmail.com>
References: <CAAzoce6CvKLUxr2SDD0pp4NGRGhd8n2+XXzCep6EDjUF3+d67Q@mail.gmail.com> <CADJ9OA8Ectu1Phk7XkVsm0oa50ry084gPF7Hb7DUUZ=Nv=rLnA@mail.gmail.com> <F085911F642A6847987ADA23E611780D1859AB93@hoshi.uni.lux> <CAAzoce4Lio-6g1-0-hM44z1St6bgwvc15tWiY4+-06Hn3560pg@mail.gmail.com> <CADJ9OA9zO1jiP1d7swxOa4jQjrA1iwU+4dZK2wG4M1OJbZqetA@mail.gmail.com>
Date: Wed, 11 Sep 2013 23:07:02 +0800
Message-ID: <CAAzoce6ZXEGjtQiFOVepPbJQLTvzgot8yrM91zxxWWWaPG9esA@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Content-Type: multipart/alternative; boundary=089e013a027045583904e61cf9d4
Cc: "6tsch@ietf.org" <6tsch@ietf.org>
Subject: Re: [6tsch] Is generic management method possible?
X-BeenThere: 6tsch@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tsch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tsch>, <mailto:6tsch-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/6tsch>
List-Post: <mailto:6tsch@ietf.org>
List-Help: <mailto:6tsch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tsch>, <mailto:6tsch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Sep 2013 15:07:08 -0000

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 <watteyne@eecs.berkeley.edu
> 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 <qinwang@berkeley.edu> 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 <
>> maria-rita.palattella@uni.lu> 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:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On
>>> Behalf Of *Thomas Watteyne
>>> *Sent:* Tuesday, September 10, 2013 6:24 AM
>>> *To:* 6tsch@ietf.org
>>> *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 <qinwang@berkeley.edu> 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
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch****
>>>
>>> ** **
>>>
>>> _______________________________________________
>>> 6tsch mailing list
>>> 6tsch@ietf.org
>>> https://www.ietf.org/mailman/listinfo/6tsch
>>>
>>>
>>
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>