Re: [coman] Interaction between NME and PCE

["Qin Wang" <[e-mail]>]

Hi Pascal,

Thank you for your comments.

Just a quick question. By NME, do you refer to Common Network Management
(CNM) in the draft-thubert-6tsch-architecture-00? If yes, my understanding
is that only one of them should be enabled in a network setting. In
another word, it should not be the case that both of them compute TSCH
schedule (i.e. tracks) at one time. Correct? I wonder why we need to
consider both of them functioning at same time in terms of track
computation. Maybe I missed something.

Qin


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