Re: [6tsch] work item 2: centralized route and track computation with PCE

Hi Pascal,

What I read from the new paragraph is that the task will result in two sets
of operations, i.e. (1) and (2) in the paragraph, one should be implemented
in routing layer, and another should be implemented in 6top sublayer. I
think the operations needed are almost there. But, the problem is 6TSCH
only focus on 6top sublayer, and can not require specific function in
routing layer, correct?

So, can we just describe what operations will be investigated, and don't
specify which layer will be responsible for the operations. In fact, I
think , at end of result, 6top has to take care the operations needed,
otherwise, I'm afraid we will leave another gap in the protocol stack.

How do you think?

Qin

On Tue, Jul 23, 2013 at 6:34 PM, Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

>  Hello Raghu and all:****
>
> ** **
>
> About item 2 6TSCH Centralized Management:****
>
> ** **
>
> Since we wrote the charter a few months ago we have been digging and it
> appears that we are probably not ready for going standard track right away
> with a 6TSCH document.****
>
> - In one hand, we understand better that the PCE is the component we need
> for both centralized route AND track computation.****
>
> - OTOH, we realized that PCEP only covers a limited portion of the
> required standard work and we realize that we need to dig deeper in what
> needs to be done, in particular to locate the PCE(s), export topology and
> metrics to the PCE, and then install routes and tracks from the PCE.  We
> also understand that some of that work belongs to the PCE working group
> though it is unclear exactly how much that is.****
>
> ** **
>
> Right now the charter has this:****
>
> ** **
>
> 2. Produce "6TSCH centralized management" to define the mechanism by which
> an****
>
> external Path Computation Element can communicate with the 6top protocol
> layer****
>
> of the different nodes in the network (1) to modify their TSCH schedule and
> ****
>
> (2) to gather link quality statistics and data flow requirements.  The WG
> will****
>
> initially look at PCEP and CoAP.****
>
> Depending on the applicability of PCEP, this document will be targeted to*
> ***
>
> proposed standard.****
>
> ** **
>
> In the light of our studies, I’d suggest this:****
>
> 2. Produce requirements and an overall architecture for  "6TSCH
> centralized routes and tracks management" ****
>
> describing the mechanism by which an external Path Computation Element
> (PCE) can communicate with ****
>
> devices in a 6TSCH network in order to maintain routing and forwarding
> states. In detail, the WG will ****
>
> consider operations (1) by the device routing layer for (i) sending
> topological information and routing ****
>
> metrics to the PCE, and (ii) getting on-demand routing information; and
> (2) by the device 6top sublayer ****
>
> for exporting neighboring and link quality statistics to the PCE and (2)
> requesting to (re)compute and ****
>
> install a track that meets explicit flow requirements.****
>
> ** **
>
> What do you guys think?****
>
> ** **
>
> ** **
>
> Pascal****
>
> ** **
>
> *From:* 6tsch-bounces@ietf.org [mailto:6tsch-bounces@ietf.org] *On Behalf
> Of *Raghuram Sudhaakar (rsudhaak)
> *Sent:* lundi 22 juillet 2013 07:25
> *To:* 6tsch@ietf.org
> *Subject:* [6tsch] slides for work items****
>
> ** **
>
> All,****
>
> Attached are the slides for the work items. Please provide your comments.*
> ***
>
> ** **
>
> Specifically, please provide feedback on whether we must have the security
> framework as a work item.****
>
> ** **
>
> -raghuram****
>
> _______________________________________________
> 6tsch mailing list
> 6tsch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tsch
>
>