Re: [6tsch] About the special type of event to ask PCE to create a track

Thomas Watteyne <watteyne@eecs.berkeley.edu> Wed, 04 September 2013 21:30 UTC

Return-Path: <twatteyne@gmail.com>
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 3B48611E8205 for <6tsch@ietfa.amsl.com>; Wed, 4 Sep 2013 14:30:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.591
X-Spam-Level:
X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, NO_RELAYS=-0.001]
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 DS9RhWWHZgrf for <6tsch@ietfa.amsl.com>; Wed, 4 Sep 2013 14:30:14 -0700 (PDT)
Received: from mail-pb0-x22b.google.com (mail-pb0-x22b.google.com [IPv6:2607:f8b0:400e:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 786BE11E8204 for <6tsch@ietf.org>; Wed, 4 Sep 2013 14:30:14 -0700 (PDT)
Received: by mail-pb0-f43.google.com with SMTP id md4so870678pbc.30 for <6tsch@ietf.org>; Wed, 04 Sep 2013 14:30:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=rQ6bLGUVnAfqS4wHW4OhpFxIJSjET01aka50NjcS2eg=; b=AYDfWeYshZu/sUXdQjjIV+nsiBLkSNaFMb1K0rCMhlALq8MDj46Aflp+FRYPCyICyk 5qR1COrL+Yi53enk3JtHVsZyjpEf72iRhZ0FoisoIhs8/ZJ658xLDhxXoyvFf2x8Gt8/ 82aq72s847TioRyHEAq9WjXt2sMHkce/eCXn2v80LNOrsmzDJmKKxCeGPAmaTHLMEsnc QHeDWcYZ4i42qd+OR4JdOIQZWij21siBy6w7ziLru+nZj434Pyi2eROFVyj6uC9CTciM VDs6qS5gx0lkkG2YA7MKq0HRh5QILvPneyw84pDPQ5d6VuYgdeh+zL6c1aCLm6ymyslI QjtQ==
X-Received: by 10.66.176.143 with SMTP id ci15mr5321768pac.146.1378330214198; Wed, 04 Sep 2013 14:30:14 -0700 (PDT)
MIME-Version: 1.0
Sender: twatteyne@gmail.com
Received: by 10.66.147.193 with HTTP; Wed, 4 Sep 2013 14:29:54 -0700 (PDT)
In-Reply-To: <CAAzoce7OMcoydnrbo1LvHfKtwOi_4W2MMEwgp8PyVaF68hvF2Q@mail.gmail.com>
References: <E045AECD98228444A58C61C200AE1BD841433684@xmb-rcd-x01.cisco.com> <CAAzoce6x7hNZX+GV1xcf9nyDZok2h57SjFh_AjbJXvzM=sUuzQ@mail.gmail.com> <CADJ9OA-7=b2zycBcGrjOeUVzuH23ADx6Yt5a6gyPtvB7ULzYKA@mail.gmail.com> <CAAzoce7OMcoydnrbo1LvHfKtwOi_4W2MMEwgp8PyVaF68hvF2Q@mail.gmail.com>
From: Thomas Watteyne <watteyne@eecs.berkeley.edu>
Date: Wed, 04 Sep 2013 14:29:54 -0700
X-Google-Sender-Auth: 7Nrn0tn3gtuLf5s8vh4U4KTbU-0
Message-ID: <CADJ9OA9fmgmr9xFy0QM=NL4=DD4jG7=vH8i74KGoJEngXGOZaw@mail.gmail.com>
To: "6tsch@ietf.org" <6tsch@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bd75160ccf69d04e59582a4"
Subject: Re: [6tsch] About the special type of event to ask PCE to create a track
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, 04 Sep 2013 21:30:15 -0000

I would agree that a 5th flow makes sense, especially because it allows us
to use different transport mechanisms for the report flow (CoAP?) and this
new flows (CoAP now? maybe PCEP later?).

Do what do we call this new flow? "Schedule update request" is a bit long.

Thomas


On Wed, Sep 4, 2013 at 2:12 PM, Qin Wang <qinwang@berkeley.edu> wrote:

> Hi Thomas,
>
> Thanks for your explanation. You are saying the request packet from node
> is generated by the upper layer of 6top, correct?
>
> If so, since the request packet is generated by upper layer of 6top,
> instead of 6top internal events like alarm, I think it is reasonable to add
> the 5th control flow.
>
> What do you think?
>
> Qin
>
>
> On Wed, Sep 4, 2013 at 10:12 AM, Thomas Watteyne <
> watteyne@eecs.berkeley.edu> wrote:
>
>> Qin,
>>
>> Thanks for bringing that up. Allow me to answer in Pascal's place. We are
>> talking about the format of the packets exchanged between the ME and the
>> nodes. In the centralized case, these are application-level packets, i.e.
>> packet generated by an entity a couple of layer above 6top. That entity
>> talks with the PCE over the network, and with 6top through the API
>> (internal to the node) as defined in
>> http://tools.ietf.org/html/draft-wang-6tsch-6top-00#section-2.4.
>>
>> If we agree on that, the question is whether the packet the node sends to
>> establish a new track is part of the event flow, or not. In both cases, it
>> would originate from this application-level entity, but possibly
>> transported in different ways.
>>
>> Thomas
>>
>> On Fri, Aug 30, 2013 at 11:01 AM, Qin Wang <qinwang@berkeley.edu> wrote:
>>
>>> Hi Pascal,
>>>
>>> My understanding is that 6top is a passive role in dealing with
>>> cell/track reservation. In another word, the 6top in a node can report its
>>> state, including neighbor table, cell usage, and other statistics
>>> information, but can not make decision on if some cells/track should be
>>> added or removed, which should be the responsibility of PCE in centralized
>>> case or upper layer in distributed case. Thus, I can not see when the 5th
>>> flow will be used. Can you explain more?
>>>
>>> Thanks
>>> Qin
>>>
>>>
>>> On Sat, Aug 31, 2013 at 12:08 AM, Pascal Thubert (pthubert) <
>>> pthubert@cisco.com> wrote:
>>>
>>>> Dear all,
>>>>
>>>> We discussed at the call that the(PCEP?) request to ask for a track
>>>> establishment could be seen as an event, or could be a new flow.
>>>> At the call, I suggested that it could be a new, 5th flow. My arguments
>>>> are that this flow:
>>>> - Probably yields different data format. The demand carries and points,
>>>> end to end latency and bandwidth. That's quite specific.
>>>> - Probably yields a different flow. Events do not necessarily have a
>>>> response.
>>>> - Probably uses a different transport as well (PCEP vs. CoAP)
>>>>
>>>> What do you think?
>>>>
>>>> Pascal
>>>> _______________________________________________
>>>> 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
>>
>>  <https://www.ietf.org/mailman/listinfo/6tsch>
>>
>> _______________________________________________
>> 6tsch mailing list
>> 6tsch@ietf.org
>> https://www.ietf.org/mailman/listinfo/6tsch
>>
>>
>