[coman] Interaction between NME and PCE

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Qin;

There is potentially some duplication between what a 6TSCH node would exchange with a network management entity  (NME) and with a path computation entity (PCE). Basically, the information we want to report about peering, neighbors, cell and track utilization can be useful on both sides.

And we may even have a use case where the track is entered manually à la MPLS TP as opposed to TE, thus coming from NME though, fingers crossed, I've not seen that one yet. In that case, the track information could be imposed on the 6TSCH node by either NME and PCE, and there could potentially be a conflict between those tracks. 

If we pick the direct path way of enhancing existing standards: 
1)  Network Management will have its own mechanisms, based on the work at the COMAN ML.
2)  Path Computation will have its own mechanisms, probably a PCEP enhancement.
Yet:
3)  We do not want to report a lot of information twice from the 6TSCH nodes, once for NME and once for PCE.
4)  We want the conflicts between manual (NME) and automatic (PCE) routes to be sorted between those two before the device sees any of it. 

So certainly, PCEP seems to be a most promising venue for centralized route computation. For all I know, PCEP in a classical PCE allocates lambdas in DWDM, so why wouldn't we enhance it to allocate cells and tracks in 6TSCH? 

But if we pick PCEP between the node and the PCE for all the PCE related exchanges, then we probably want the NME to interact with the PCE to dig the related information, and we have to document how that happens. At the same time, we have to document how things work when there is no PCE. Looks like the PCE would act as a proxy or something.

It makes sense to me that the network management information may be digged from a gateway anyway for all sorts on non-IP world compatibility. Cc'ing COMAP 

Pascal


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Qin Wang
Sent: lundi 18 mars 2013 20:42
To: Thomas Watteyne
Cc: IETF 6TSCH
Subject: Re: [6tsch] Interaction between RPL and PCE

Thomas,

I'm not very familiar with PCE protocol. According to my knowledge, there are extensions of PCE protocol corresponding to different protocols like GMPLS. So, maybe a extension of PCE for 6tus is needed, which computes the track for given multihop path and bandwidth requirement, or the track for given topology and end-to-end bandwidth requirement.

How do you think?

Qin



> Qin,
>
> Please see inline.
>
> On Mon, Mar 18, 2013 at 10:25 AM, Qin Wang <[e-mail]> wrote:
>
>> Thomas,
>>
>> I think for a data flow, there are three elements needed to be 
>> defined or scheduled explicitly or implicitly:
>> (1) multihop path, i.e. who is the next hop neighbor
>> (2) bandwidth and Qos requirement
>> (3) cell set (i.e. bundle) to implement the bandwidth
>>
>> In case-1, all of the three elements are determined by PCE, and RPL 
>> is just a backup and works on slot-aloha cells. Correct?
>>
>
> I believe that's correct. BTW, I'm not per se advocating for this 
> solution, but it seems to be the approach 
> draft-ietf-roll-rpl-industrial-applicability
> takes.
>
>
>> In case2, element(1) is determined by RPL based on Rank, and 
>> element(3) is determined by PCE. But, who will determine element(2)? 
>> by PCE or by some entity like RSVP/NSIS or DSCP?
>>
>>
> Agreed. It relatively straightforward for a PCE to compute a schedule 
> and distribute that into the network, but how does it figure out what 
> the requirements are from the nodes in the network. Could we reuse a 
> "PCE requirements" protocol out there?
>
>
>> Qin
>>
>> > [subject was: Scope: 6LoWPAN + 1]
>> >
>> > Maria Rita,
>> >
>> > I fully agree with Pascal's suggestion to have the PCE only talk to
>> one
>> of
>> > the two sides on a on-hop link, and have 6tus be in charge to 
>> > telling
>> the
>> > other side to reserve the same cell. I believe Qin has also
>> acknowledged
>> > this, and has agreed to put this mechanism into 6tus. This would
>> probably
>> > mean adding some option in the 6tus message format saying "this is 
>> > not
>> a
>> > negociation for a soft cell, but an order for you to add this hard
>> cell".
>> >
>> > All,
>> >
>> > I believe Maria Rita is touching a very important point we haven't 
>> > had time to discuss last week in Orlando, but which I believe is 
>> > essential: how
>> do
>> > RPL and the PCE interact? The PCE can have complete knowledge of 
>> > the network topology and the network traffic, so besides L2 
>> > resource allocation, it could also make routing decision, i.e. 
>> > build the track
>> it
>> > believe is best fit.
>> >
>> > draft-ietf-roll-rpl-industrial-applicability-00 also states similar
>> ideas:
>> > "The domain of applicability for the RPL protocol may include all
>> phases
>> > but the Normal Operation phase, where the bandwidth allocation and 
>> > the *routes are usually optimized by an external Path Computing 
>> > Engine (PCE)*.
>> [...]
>> > Additionally, it could be envisioned to include RPL in the normal 
>> > operation provided that a new Objective Function is defined that 
>> > actually
>> interacts
>> > with the PCE is order to establish the reference topology, in which
>> case
>> > *RPL
>> > operations would only apply to emergency repair actions*. when the 
>> > reference topology becomes unusable for some failure, and as long 
>> > as
>> the
>> > problem persists."
>> >
>> > This shot-circuits RPL.
>> >
>> > The two use cases I can see are:
>> > 1. the PCE makes decisions without RPL's intervention. RPL runs in 
>> > the background for emergency repair actions only.
>> > 2. RPL sets up multi-hop routes which the PCE uses for building
>> tracks.
>> > That is, the PCE only performs L2 resource allocation.
>> >
>> > Do we agree to use only use case 1? If we go for 2, how does the 
>> > PCE
>> get
>> > information about RPL routes (especially in storing mode)?
>> >
>> > Thomas
>> >
>> > On Mon, Mar 18, 2013 at 2:06 AM, Maria Rita PALATTELLA < 
>> > [e-mail]> wrote:
>> >
>> >> Hi Qin, and all,
>> >> Sorry for coming back to this discussion after some time, but I
>> wanted
>> >> to
>> >> raise and clarify a point.
>> >>
>> >> Qin>>>(2) If there is PCE, there may be different setting. For
>> example,
>> >> PCE is in charge for reserving both multiple hop path (i.e. every
>> next
>> >> hop
>> >> Qin>>>neighbor) and cells; or PCE is just in charge for reserving 
>> >> Qin>>>the
>> >> multiple hop path and leaving cell reservation to local, and the 
>> >> distributed cell reservation will meet the bandwidth requirement 
>> >> from multiple hop path reservation. In the first case, hard Qin>>> 
>> >> cell  reservation will be used.
>> >>
>> >> Qin >>>(3)If there is no PCE, both multi-hop path and cells are
>> reserved
>> >> in local.
>> >> Qin>>For example, RPL + soft cell reservation in 6tus.
>> >>
>> >> From my point of view (and thinking about TASA implementation), 
>> >> the
>> PCE
>> >> shouldn't be in charge for reserving the multiple hop path. But 
>> >> the routing protocol (i.e., RPL in our case) should take care of 
>> >> the next hop neighbor selection.
>> >> When a centralized approach is adopted, the PCE will schedule the
>> cells
>> >>  (i.e., hard cells according to 6tus terminology).
>> >> While, when a distributed solution is used, 6tus will allocate the
>> soft
>> >> cells.
>> >>
>> >> In the centralized scenario with the PCE, to avoid the exchange of
>> many
>> >> signaling messages, for setting up the schedule, we may think (as
>> Pascal
>> >> was suggesting during one of the last call) to use some hybrid 
>> >> solutions.
>> >> In other words, if PCE allocates (timeoffset1, channeloffset3, 
>> >> slotframe1,
>> >> TX) to node A for transmitting to node B, then, node B could know 
>> >> locally from node A, (and not from the PCE), that the cell 
>> >> (timeoffset1, channeloffset3, slotframe1, RX) has been reserved to 
>> >> it, for
>> receiving
>> >> from
>> >> node A.
>> >> We may try to include some functionality in 6tus layer in order to 
>> >> manage such situation.
>> >> What do you think?
>> >>
>> >> Maria Rita
>> >>
>> >>
>> >>
>> ---------------------------------------------------------------------
>> -------------------------------------------
>> >> > On 3/14/13 9:02 PM, Paul Chilton wrote:
>> >> >>>- optionally a PCE sits on the backbone and drives the LLNs' 
>> >> >>>TSCH schedules.
>> >> >
>> >> > Ah, maybe understood.  It doesn't say that existence of PCE is
>> >> optional.
>> >> > It says that it's optional to put PCE in the backbone.  It 
>> >> > doesn't preclude to put it on BBR.  Correct ?
>> >> >
>> >> > Shoichi
>> >> > _______________________________________________
>> >> > 6tsch mailing list
>> >> > [e-mail]
>> >> > https://www.ietf.org/mailman/listinfo/6tsch
>> >> >
>> >>
>> >> _______________________________________________
>> >> 6tsch mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/6tsch
>> >> _______________________________________________
>> >> 6tsch mailing list
>> >> [e-mail]
>> >> https://www.ietf.org/mailman/listinfo/6tsch
>> >>
>> > _______________________________________________
>> > 6tsch mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/6tsch
>> >
>>
>>
>>
> _______________________________________________
> 6tsch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tsch
>


_______________________________________________
6tsch mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6tsch