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

Pascal,
Just trying to make sure I'm on the same page. The second "schedule update
request" flow would come from a different entity than the mote, right? I'm
thinking for example about a controller on the Internet wanting to send
data to a mote, and which contacts the PCE to update the schedule
accordingly. What's your example? That being said, I believe we are in line
here, and I agree taht it's a good idea to merge the two "schedule update
request" flow flavors.
Thomas

On Thu, Sep 5, 2013 at 12:25 AM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

>  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<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<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<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****
>
>