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

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 5 Sep 2013 07:25:16 +0000

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:[email-masked]]
Sent: jeudi 5 septembre 2013 09:16
To: Pascal Thubert (pthubert); Qin Wang
Cc: Thomas Watteyne; [email-masked]
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:[email-masked]]
Sent: Thursday, September 05, 2013 9:02 AM
To: Maria Rita PALATTELLA; Qin Wang
Cc: Thomas Watteyne; [email-masked]<mailto:[email-masked]>
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:[email-masked]]
Sent: jeudi 5 septembre 2013 08:47
To: Pascal Thubert (pthubert); Qin Wang
Cc: Thomas Watteyne; [email-masked]<mailto:[email-masked]>
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: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, September 05, 2013 7:29 AM
To: Qin Wang
Cc: Thomas Watteyne; [email-masked]<mailto:[email-masked]>
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" <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> 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) <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

_______________________________________________
6tsch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tsch

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 5 Sep 2013 08:40:17 -0400

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) <[email-masked]>:
> Yes…
> 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
>
>
>
> 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
>
>
>
> 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
>
>
>
> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
> Pascal Thubert (pthubert)
> Le 5 sept. 2013 à 00:10, "Qin Wang" <[email-masked]> 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 <[email-masked]>
> 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?).
>
>
>
> On Wed, Sep 4, 2013 at 2:12 PM, Qin Wang <[email-masked]> 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
> <[email-masked]> 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 <[email-masked]> 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)
> <[email-masked]> 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.
> - Probably yields different data format. The demand carries and points, end
> to end latency and bandwidth. That's quite specific.
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]
> [email-masked]

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

---

From: Qin Wang <[email-masked]>
Date: Fri, 6 Sep 2013 01:44:46 +0800

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 <
[email-masked]> wrote:

> > Subject: RE: [6tsch] About the special type of event to ask PCE to
> create a
> > track
> >
> >
> >
> > Subject: RE: [6tsch] About the special type of event to ask PCE to
> create a
> > track
> >
> >
> >
> > Fine with me Maria Rita,
> >
> >
> >
> > Subject: RE: [6tsch] About the special type of event to ask PCE to
> create a
> > track
> >
> >
> >
> > Subject: Re: [6tsch] About the special type of event to ask PCE to
> create a
> > track
> >
> >
> >
> > +1
> >
> > Pascal
> >
> >
> > At the call, I suggested that it could be a new, 5th flow. My arguments
> are
> > that this flow:

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 5 Sep 2013 10:46:53 -0700

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) <
[email-masked]> wrote:

>  Yes…****
>
> ** **
>
> And the aim should be to make sure that the PCE has queued the request to
> build a track.****
>
> 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:[email-masked]]
> *Sent:* jeudi 5 septembre 2013 09:16
>
> *To:* Pascal Thubert (pthubert); Qin Wang
> *Cc:* Thomas Watteyne; [email-masked]
> *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:[email-masked]<[email-masked]>]
>
> *Sent:* Thursday, September 05, 2013 9:02 AM
> *To:* Maria Rita PALATTELLA; Qin Wang
> *Cc:* Thomas Watteyne; [email-masked]
> *Subject:* RE: [6tsch] About the special type of event to ask PCE to
> create a track****
>
>  ****
>
> Fine with me Maria Rita,****
>
>  ****
>
> 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:[email-masked]<[email-masked]>]
>
> *Sent:* jeudi 5 septembre 2013 08:47
> *To:* Pascal Thubert (pthubert); Qin Wang
> *Cc:* Thomas Watteyne; [email-masked]
> *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).****
>
> update its schedule, and add/remove cells/tracks. What do you think?****
>
> Maria Rita****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Pascal Thubert (pthubert)
> *Sent:* Thursday, September 05, 2013 7:29 AM
> *To:* Qin Wang
> *Cc:* Thomas Watteyne; [email-masked]
> *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" <[email-masked]> 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" 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 <
> [email-masked]> wrote:****
>
> new flows (CoAP now? maybe PCEP later?). ****
>
>  ****
>
> ****
>  ****
> Thomas****
>  ****
> On Wed, Sep 4, 2013 at 2:12 PM, Qin Wang <[email-masked]> 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 <
> [email-masked]> wrote:****
>
> Qin, ****
>
>  ****
>
> 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.****
>
>  ****
>
> 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 <[email-masked]> wrote:**
> **
>
> Hi Pascal, ****
>
>  ****
>
> 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) <
> [email-masked]> wrote:****
>
> Dear all,
>
> are that this flow:
> - Probably yields different data format. The demand carries and points,
> end to end latency and bandwidth. That's quite specific.
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ****
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ****
>
>  ****
>
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>  ****
>
> https://www.ietf.org/mailman/listinfo/6tsch****
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 5 Sep 2013 11:29:39 -0700

Diego, all,

Let's not get confused. IMHO, the goal is to mainly identify the
interactions between the PCE, and the mesh and the Internet, to guide us in
the choice of the different packets. I created the figure below so we have
something clear to argue over. Comments/edits more than welcome.

About your question, Diego, I believe that the request flow should contain
a mechanism for the requester to query the state of its request, and for
the PCE to notify the requester about the outcome. It the PCE cannot
satisfy the request, that is an administrative issue rather than a
networking issue. I believe that this is out of scope.

Thomas

On Thu, Sep 5, 2013 at 5:40 AM, Prof. Diego Dujovne <
[email-masked]> wrote:

> > build a track.
> through
> entities,
> to
> For
> from
> [email-masked]>
> > wrote:
> >
> is
> instead
> transported
> layer
> end

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 5 Sep 2013 18:36:50 +0000

+1

If the PCE cannot solve the problem I can hardly see how the mote could fix it...

Pascal

Le 5 sept. 2013 à 20:30, "Thomas Watteyne" <[email-masked]> a écrit :

> Diego, all,
> 
> Let's not get confused. IMHO, the goal is to mainly identify the interactions between the PCE, and the mesh and the Internet, to guide us in the choice of the different packets. I created the figure below so we have something clear to argue over. Comments/edits more than welcome.
> 
> 
> About your question, Diego, I believe that the request flow should contain a mechanism for the requester to query the state of its request, and for the PCE to notify the requester about the outcome. It the PCE cannot satisfy the request, that is an administrative issue rather than a networking issue. I believe that this is out of scope.
> 
> Thomas
> 
> 
> On Thu, Sep 5, 2013 at 5:40 AM, Prof. Diego Dujovne <[email-masked]<mailto:[email-masked]>> wrote:
> Dear All,
> 2013/9/5 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
>> Yes…
>> 
>> 
>> 
>> From: Maria Rita PALATTELLA [mailto:[email-masked]<mailto:[email-masked]>]
>> From: Pascal Thubert (pthubert) [mailto:[email-masked]<mailto:[email-masked]>]
>> From: Maria Rita PALATTELLA [mailto:[email-masked]<mailto:[email-masked]>]
>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
>> <[email-masked]<mailto:[email-masked]>> wrote:
>> 
>> Qin,
>> 
>> 
>> 
>> <[email-masked]<mailto:[email-masked]>> wrote:
>> 
>> Dear all,
>> 
> www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
> (56 2) 676 8125<tel:%2856%202%29%20676%208125>
> 
> <6tisch_flows.ppt>

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 5 Sep 2013 15:14:25 -0400

Pascal,
           I was not looking for the node to fix it, just looking
to understand how smart 6top should be, or which entity should
provide an answer instead.
Thanks,

                           Diego

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 6 Sep 2013 06:22:36 +0000

That's another interesting discussion Diego,

To be very clear, there should not be more intelligence in 6Top than what's needed to act on a schedule, hard or soft.
If there is any management brain at all, it should be in the ME, and then the ME talks to 6Top or the external entities.
6Top does not really care which flows cause the call to the APIs, either through the ME Service Access Point or the data SAP.

The control flows that we are talking about are really between PCE, NME (admin console, mobile handheld) and ME in the device, with maybe some proxy or pub sub in the middle.
This is where the binary that we are chartering to define will be transmitted. So picking Xavi's list I'd map pour work as follows:

ME-6TOP - Query Flow			(NME or PCE) -> ME
ME-6TOP - Action Flow			(NME or PCE) -> ME		

6TOP - ME - Report Flow		ME -> (NME or PCE)
6TOP - ME - Event Flow			ME -> (NME  or PCE)
6TOP - ME - Request BW Flow		(ME or NME) -> PCE

And I would apply Maria-Rita's suggestion to rename Request BW Flow into "schedule flow".

The sequence we are talking about would become like:

6Top			ME 			NME			PCE	
	
      			---------------------- schedule (instance) ---------------->		
      				OR                           -- schedule (instance)->	
						<ACK>
      			<--------------------- Action (instance) --------------------

	      		-- event (instance) --->        -- event (instance) --->

It would be clearer that we define a 6th flow like this

(NME or PCE) -> ME 	- Query Flow	
(NME or PCE) -> ME 	- Action Flow	
PCE  -> NME		- Schedule info Flow		

ME -> NME -> PCE	- Report Flow		
ME -> NME -> PCE	- Event Flow			
(ME or NME) -> PCE	- Schedule Flow

The sequence we are talking about would become 

6Top			ME 			NME			PCE	
	
      			---------------------- schedule (instance) ---------------->		
      				OR                           -- schedule (instance)->	
						<ACK>
      			<--------------------- Action (instance) --------------------

	      		-------------------- event (instance) ---------------------->	
      				                        <- schedule info (instance)--	

We cannot expect the ME to do more than a few retries of schedule (instance), using CoAP.
In all cases all we really need is that the message is received, and if the PCE is stateful as we expect, we can save the ack for the action. 
The PCE will wait for the report or retry on time out.

What do you think?

Pascal

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: jeudi 5 septembre 2013 21:14
To: Pascal Thubert (pthubert)
Cc: Thomas Watteyne; [email-masked]; JP Vasseur (jvasseur)
Subject: Re: [6tsch] About the special type of event to ask PCE to create a track

Pascal,
           I was not looking for the node to fix it, just looking to understand how smart 6top should be, or which entity should provide an answer instead.
Thanks,

                           Diego

2013/9/5 Pascal Thubert (pthubert) <[email-masked]>:
>> - 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
>>
>>
>>
>>> Yes.
>>> sometimes needs to defragment / reoptimize multiple flows, and it 
>>> may stack some requests for a short while.
>>>
>>> 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:[email-masked]<mailto:maria-rita.palattella@un
>>> i.lu>]
>>> create a track
>>> entities, they are both addressed to the PCE, and they have the same final aim.
>>>
>>> Maria Rita
>>>
>>>
>>>
>>> From: Pascal Thubert (pthubert) 
>>> [mailto:[email-masked]<mailto:[email-masked]>]
>>> create a track
>>> 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:[email-masked]<mailto:maria-rita.palattella@un
>>> i.lu>]
>>> 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: [email-masked]<mailto:[email-masked]> 
>>> [mailto:[email-masked]<mailto:[email-masked]>] On 
>>> Behalf Of Pascal Thubert (pthubert)
>>> create a track
>>> 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 
>>> 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?).
>>>
>>>
>>>
>>> Thanks for your explanation. You are saying the request packet from 
>>> node is generated by the upper layer of 6top, correct?
>>>
>>>
>>>
>>> instead of 6top internal events like alarm, I think it is reasonable 
>>> to add the 5th control flow.
>>>
>>>
>>>
>>> What do you think?
>>>
>>>
>>>
>>> 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 
>>> 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
>>>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>> - Probably yields different data format. The demand carries and 
>>> points, end to end latency and bandwidth. That's quite specific.

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