Re: [coman] Interaction between NME and PCE

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

Hello Qin:

I use NME as the common name for the Network Management Entity. CNM is more specific, it is a particular group, WG20 at ISA100 (thus ISA100.20).
ISA100.20 CNM will define an abstract manager of managers. A CNM Entity should be able to talk in a unified fashion to NMEs from different origins, like ISA100.11a, WIAPA or wiHART (or COMAN). The idea being that the admin can do things once at the CNM level and then get the execution distributed through the more specific NMEs for the particular networks that they can handle. 

My goal with CNM would be that the CNM formats translate easily of not natively into the COMAN formats.

Now, as I said, we do not have a use case right now for a manual track enforcement (à la MPLS-TP) from the network management console.
Hopefully this will never come. But if it does, I'm saying that the collisions should be sorted out by direct communication between NMA and PCE.

Cheers,

Pascal


-----Original Message-----
From: Qin Wang [mailto:[e-mail]] 
Sent: vendredi 22 mars 2013 14:50
To: Pascal Thubert (pthubert)
Cc: Qin Wang; Thomas Watteyne; IETF 6TSCH; [e-mail]
Subject: Re: Interaction between NME and PCE

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
>