Subject: [6tsch] Interaction between RPL and PCE

From: Thomas Watteyne <[email-masked]>
Date: Mon, 18 Mar 2013 09:26:31 -0700

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

---

From: Thomas Watteyne <[email-masked]>
Date: Mon, 18 Mar 2013 12:13:21 -0700

Alfredo,
I agree that this would be a very nice feature to have. Would you have an
idea of how to do this? I believe it's pretty hard to maintain a schedule
which guarantees hard constraints for motes jumping around inside the
topology. Are you thinking of some super-fast handover, or something elsa?
Thomas

On Mon, Mar 18, 2013 at 9:53 AM, Alfredo Grieco <[email-masked]>wrote:

> Hi all,****
>
> ** **
>
> Is it possible to handle mobile nodes having hard constraints for their
> packets ? This is not so rare in industrial scenarios where there are many
> machines that moves and at the same time need to transmit their data.****
>
> ** **
>
> In this case, the topology cannot be known in advance because the position
> of the machines depends on the events that happen within the system.****
>
> ** **
>
> Is it still possible to build a reasonable schedule for this scenario ?
> Can 6tus account also for mobile nodes ?****
>
> ** **
>
> Cheers****
>
> ** **
>
> Alfredo****
>
> ** **
>
> ** **
>
> *Da**:* [email-masked] [mailto:[email-masked]] *Per conto
> di *Thomas Watteyne
> *Inviato**:* Monday, March 18, 2013 5:27 PM
> *A:* IETF 6TSCH
> *Oggetto**:* [6tsch] Interaction between RPL and PCE****
>
> ** **
>
> [subject was: Scope: 6LoWPAN + 1]****
>
> ** **
>
> Maria Rita,****
>
> ** **
>
> 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
> believe is best fit.****
> ** **
> ****
> problem persists."****
> ** **
> This shot-circuits RPL.****
>
> ** **
>
> The two use cases I can see are:****
>
> background for emergency repair actions only.****
>
> That is, the PCE only performs L2 resource allocation.****
>
> ** **
>
> information about RPL routes (especially in storing mode)?****
>
> ** **
>
> Thomas****
>
> ** **
>
> [email-masked]> wrote:****
>
> Hi Qin, and all,
> ****
> https://www.ietf.org/mailman/listinfo/6tsch****
>
> ** **
>