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

Qin Wang <qinwang@berkeley.edu> Thu, 05 September 2013 17:44 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 4F9C111E825C for <6tsch@ietfa.amsl.com>; Thu, 5 Sep 2013 10:44:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.592
X-Spam-Level:
X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 S5cuJvILRJiz for <6tsch@ietfa.amsl.com>; Thu, 5 Sep 2013 10:44:47 -0700 (PDT)
Received: from mail-vb0-f54.google.com (mail-vb0-f54.google.com [209.85.212.54]) by ietfa.amsl.com (Postfix) with ESMTP id 12E4B11E824D for <6tsch@ietf.org>; Thu, 5 Sep 2013 10:44:46 -0700 (PDT)
Received: by mail-vb0-f54.google.com with SMTP id q14so1423759vbe.27 for <6tsch@ietf.org>; Thu, 05 Sep 2013 10:44:46 -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=wZ0PPDQj50Nk0j6UUwguGM52lUoOM3MiD2/XB2+WFHk=; b=Wa6KhnEP24oI09Z6ntAEIbePyVYli0+VOpE/4H259vcKbu6sN32ZYeQm3rzw41lzcC ks2VJE5DpuFNJ1DgvANT6gO2NqLtullRGaXQAZvisXaNqrm7CeFYx+8KffwaxSLmVLfd a+6N5RpQxHBMV3mnXv1eIqiZ4EriIm8waw6+CYZypfjR28u2beRybweeEYRjbEN0v1mQ 4KUqxRKuCcPbmZXuYav0zzUso1f6qqC0/uwjCj6uqnQx1CaOiMd6e7OGo2FRNU3HfJ/y xX6HJlNQb9M9u4l2pv1QasE1q9sIFH7GY73pGpu6RailPST7ZFtAw4niooU/FuCL5oJR CB+Q==
X-Gm-Message-State: ALoCoQlxznlHqrdYdaR9g3IcoW+LHDJkBEbJ9kCmEvWLZT59H2t0tGHF16NGadZGLvmzWRG4mhSl
MIME-Version: 1.0
X-Received: by 10.52.227.6 with SMTP id rw6mr3311577vdc.19.1378403086178; Thu, 05 Sep 2013 10:44:46 -0700 (PDT)
Received: by 10.220.116.135 with HTTP; Thu, 5 Sep 2013 10:44:46 -0700 (PDT)
In-Reply-To: <CAH7SZV8jbcd16GKFbTp==772ecbnT0rD4_ohrmkyf4+MWdHMOQ@mail.gmail.com>
References: <E045AECD98228444A58C61C200AE1BD84145A186@xmb-rcd-x01.cisco.com> <CAH7SZV8jbcd16GKFbTp==772ecbnT0rD4_ohrmkyf4+MWdHMOQ@mail.gmail.com>
Date: Fri, 06 Sep 2013 01:44:46 +0800
Message-ID: <CAAzoce5NommNTCqRC=aaWOv-XpLBwNdH8qnfTCrqotCntuxXcw@mail.gmail.com>
From: Qin Wang <qinwang@berkeley.edu>
To: "Prof. Diego Dujovne" <diego.dujovne@mail.udp.cl>
Content-Type: multipart/alternative; boundary="089e011616604f28cf04e5a67ab2"
Cc: Maria Rita PALATTELLA <maria-rita.palattella@uni.lu>, Thomas Watteyne <watteyne@eecs.berkeley.edu>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "6tsch@ietf.org" <6tsch@ietf.org>, "JP Vasseur (jvasseur)" <jvasseur@cisco.com>
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: Thu, 05 Sep 2013 17:44:51 -0000

Hi Thomas and all,

>From above discussion, I feel that two kinds of flows are involved, one is
basic control flow like Action flow and Query flow; another is
combinational control flow, which will call basic control flow, e.g. the
schedule flow will call Action flow.

Should we define basic control flow and combinational control flow
separately?

Thanks
Qin


On Thu, Sep 5, 2013 at 8:40 PM, Prof. Diego Dujovne <
diego.dujovne@mail.udp.cl> wrote:

> Dear All,
>             Then, we have two flows to update the track:
> Schedule flow (6top to ME): An action flow to ask for a new cell/track
> - Execution Confirm (Success/Failure) if requested
> This means that the request was queued.
> Action flow (ME to 6top): An action flow to announce the update of the
> schedule - Execution Confirm (Success/Failure)
> What happens if the queued request cannot be satisfied (e.g. energy
> policy restriction)?
> Comments?
>
>                     Diego Dujovne
>
>
>
> 2013/9/5 Pascal Thubert (pthubert) <pthubert@cisco.com>:
> > Yes…
> >
> >
> >
> > And the aim should be to make sure that the PCE has queued the request to
> > build a track.
> >
> > That request may be served asynchronously, considering that the PCE
> > sometimes needs to defragment / reoptimize multiple flows, and it may
> stack
> > some requests for a short while.
> >
> > When the PCE is finally ready, it computes the track, and pushes it
> through
> > an action flow; but I would consider that a different flow, not an
> embedded
> > flow for the reason above.
> >
> >
> >
> > Makes sense?
> >
> >
> >
> > Pascal
> >
> >
> >
> > From: Maria Rita PALATTELLA [mailto:maria-rita.palattella@uni.lu]
> > Sent: jeudi 5 septembre 2013 09:16
> >
> >
> > To: Pascal Thubert (pthubert); Qin Wang
> > Cc: Thomas Watteyne; 6tsch@ietf.org
> > Subject: RE: [6tsch] About the special type of event to ask PCE to
> create a
> > track
> >
> >
> >
> > It makes sense for me. Even though they are generated by different
> entities,
> > they are both addressed to the PCE, and they have the same final aim.
> >
> > Maria Rita
> >
> >
> >
> > From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
> > Sent: Thursday, September 05, 2013 9:02 AM
> > To: Maria Rita PALATTELLA; Qin Wang
> > Cc: Thomas Watteyne; 6tsch@ietf.org
> > Subject: RE: [6tsch] About the special type of event to ask PCE to
> create a
> > track
> >
> >
> >
> > Fine with me Maria Rita,
> >
> >
> >
> > But note that there is also a flow that fits the name “schedule flow”
> that
> > is stimulated by the Net mgt Entity in the admin console as opposed to
> the
> > mt entity in the device.
> >
> > Same thing, this creates a req to the PCE to install a track. Do we want
> to
> > merge those 2 flows? – I think so.
> >
> >
> >
> > Cheers,
> >
> >
> >
> > Pascal
> >
> >
> >
> > From: Maria Rita PALATTELLA [mailto:maria-rita.palattella@uni.lu]
> > Sent: jeudi 5 septembre 2013 08:47
> > To: Pascal Thubert (pthubert); Qin Wang
> > Cc: Thomas Watteyne; 6tsch@ietf.org
> > Subject: RE: [6tsch] About the special type of event to ask PCE to
> create a
> > track
> >
> >
> >
> > I agree too. If we want to cut the name shorter, maybe we can just call
> it “
> > Schedule Flow” (removing the update).
> >
> > In the end, we know that this flow will happen when a node asks the PCE
> to
> > update its schedule, and add/remove cells/tracks. What do you think?
> >
> > Maria Rita
> >
> >
> >
> > From: 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] On Behalf
> Of
> > Pascal Thubert (pthubert)
> > Sent: Thursday, September 05, 2013 7:29 AM
> > To: Qin Wang
> > Cc: Thomas Watteyne; 6tsch@ietf.org
> > Subject: Re: [6tsch] About the special type of event to ask PCE to
> create a
> > track
> >
> >
> >
> > +1
> >
> > Pascal
> >
> >
> > Le 5 sept. 2013 à 00:10, "Qin Wang" <qinwang@berkeley.edu> a écrit :
> >
> > Thomas,
> >
> >
> >
> > I think "Flow" is a process to exchange messages for a given objective.
> For
> > example, action flow consists of a Action Request from ME to 6top, and a
> > Execution Confirm (Succ/Fail) from 6top to ME. But, "Schedule update
> > request" looks like one step of a process. I would like to suggest that
> the
> > 5th flow is called "Schedule update flow", consists of a "Schedule update
> > request" from node to PCE, and something like "Track/cell installation"
> from
> > PCE to node.
> >
> >
> >
> > Make sense?
> >
> > Qin
> >
> >
> >
> > On Thu, Sep 5, 2013 at 5:29 AM, Thomas Watteyne <
> watteyne@eecs.berkeley.edu>
> > wrote:
> >
> > 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
> >
> >
> > _______________________________________________
> > 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
> >
> >
> > _______________________________________________
> > 6tsch mailing list
> > 6tsch@ietf.org
> > https://www.ietf.org/mailman/listinfo/6tsch
> >
>
>
>
> --
> DIEGO DUJOVNE
> Académico Escuela de Ingeniería en Informática y Telecomunicaciones
> Facultad de Ingeniería UDP
> www.ingenieria.udp.cl
> (56 2) 676 8125
>