Subject: Re: [6tsch] Interaction between RPL and PCE

From: "Qin Wang" <[email-masked]>
Date: Mon, 18 Mar 2013 10:25:18 -0700

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?

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?

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

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Mon, 18 Mar 2013 18:01:08 +0000

Thomas, I think we should consider both cases (1) and (2), and not focused on only 1.

As Qin said, in case (2), the PCE takes care of the cells/bundle allocation, while RPL sets up the multi-hop path. Actually this is the approach used by TASA.
But we still need an interaction between PCE and RPL. And this gap should be filled by 6tsch.
For instance, based on the topology built by RPL, every child node may have more than 1 parent node.  Then, one issue could be how the PCE selects the next-hop wihile allocating the cells?
This may be done, according to the bandwitdth and QoS specification, e.g., the congestion level of the nodes.  
In any case the PCE will have to schedule the cells in order to provide the required QoS (i.e., latency, duty cycle, etc.)
Foe instace, in TASA, the PCE builts the schedule based on the traffic offered by the nodes, minimizing the network duty cycle.

Maria Rita

________________________________________
From: [email-masked] [[email-masked]] on behalf of Qin Wang [[email-masked]]
Sent: Monday, March 18, 2013 6:25 PM
To: Thomas Watteyne
Cc: IETF 6TSCH
Subject: Re: [6tsch] Interaction between RPL and PCE

Thomas,

Qin

---

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

Qin,

Please see inline.

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

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

---

From: "Qin Wang" <[email-masked]>
Date: Mon, 18 Mar 2013 12:41:33 -0700

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

> but it seems to be the approach
> draft-ietf-roll-rpl-industrial-applicability
> takes.
>
>
>> > I fully agree with Pascal's suggestion to have the PCE only talk to
>> one
>> of

---

From: Tom Phinney <[email-masked]>
Date: Mon, 18 Mar 2013 13:06:31 -0700

Re: it seems to be the approach draft-ietf-roll-rpl-industrial-applicability
takes.

The reason why centralized (i.e., PCE) computation was favored is
that compute-intensive consideration of schedules, based on physical
knowledge of the placement of all scheduled devices from the plant
piping and instrumentation diagram (P&ID) database, when coupled
with knowledge of the required periodic publication messaging (it's
frequency, criticality and even PDU size), and potentially augmented
by collected history of communications failure rates on specific
routes, can lead to minimizing potential RF conflicts for the most
critical messaging. Supercomputers were applied to optimizing such
industrial processes as early as the 1980s, and to optimizing
airline equipment use and routing as early as the late 1960s. There
is nothing novel about large industrial users doing such centralized
optimization to increase their profitability.

Those of us who work in this industry have always thought that
RF-equipped devices such as those using 802.15.4 might be able to
use their radios for some form of localized site survey. This would
be particularly the case for devices that are externally powered
(such as those coupled to powered actuators) or environmentally
recharged (e.g., from solar, or thermal potential differences, or
vibration energy harvesting), where battery life is not an
overriding concern. Use of the distributed network of field devices
to assess RF problems and provide information that can assist in
localizing the emission source causing the problems is a
high-payback additional capability.

In summary, a centralized high-compute-power PCE, driven from a
large database that includes physical siting information as well as
historical performance observations, should be able to statistically
deconflict many tracks by construction. That's a capability that
would be applied first to the most critical tracks, then the most
frequently used tracks, then down the priority chain.

There is less of an opportunity to improve aperiodically-used tracks
via PCE precomputation, but that still seems worth doing to some
extent.

Relative to mobile, the only mobile equipment in large outdoor
plants that would be involved in class 0 or class 1 traffic might be
overhead traveling cranes. That's a case where it might make sense
for a PCE to set up tracks to all but the last hop, with multiple
field routers able to receive from the crane and forward one hop to
merge into the precomputed track.

All food for thought.

-Tom

====

On 2013.03.18 12:18, Thomas Watteyne wrote:

Qin,

Please see inline.

On Mon, Mar 18, 2013 at 10:25 AM, Qin
Wang <[email-masked]>
wrote:

Thomas,

I think for a data flow, there are three elements needed to
be defined or

In case-1, all of the three elements are determined by PCE,
and RPL is

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

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

---

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

Tom,

Thanks for your insights, this is extremely useful.

I have a specific question:
"when coupled with knowledge of the required periodic publication messaging
(it's frequency, criticality and even PDU size)"
What do you think is the most traditional way for the PCE to gather this
info?

Thomas

On Mon, Mar 18, 2013 at 1:06 PM, Tom Phinney <[email-masked]> wrote:

> **
> The reason why centralized (i.e., PCE) computation was favored is that
> compute-intensive consideration of schedules, based on physical knowledge
> of the placement of all scheduled devices from the plant piping and
> instrumentation diagram (P&ID) database, when coupled with knowledge of the
> required periodic publication messaging (it's frequency, criticality and
> even PDU size), and potentially augmented by collected history of
> communications failure rates on specific routes, can lead to minimizing
> potential RF conflicts for the most critical messaging. Supercomputers were
> applied to optimizing such industrial processes as early as the 1980s, and
> to optimizing airline equipment use and routing as early as the late 1960s.
> There is nothing novel about large industrial users doing such centralized
> Those of us who work in this industry have always thought that RF-equipped
> devices such as those using 802.15.4 might be able to use their radios for
> some form of localized site survey. This would be particularly the case for
> devices that are externally powered (such as those coupled to powered
> actuators) or environmentally recharged (e.g., from solar, or thermal
> potential differences, or vibration energy harvesting), where battery life
> is not an overriding concern. Use of the distributed network of field
> devices to assess RF problems and provide information that can assist in
> localizing the emission source causing the problems is a high-payback
> additional capability.
>
> In summary, a centralized high-compute-power PCE, driven from a large
> database that includes physical siting information as well as historical
> performance observations, should be able to statistically deconflict many
> tracks by construction. That's a capability that would be applied first to
> the most critical tracks, then the most frequently used tracks, then down
> the priority chain.
>
> There is less of an opportunity to improve aperiodically-used tracks via
> PCE precomputation, but that still seems worth doing to some extent.
>
> Relative to mobile, the only mobile equipment in large outdoor plants that
> would be involved in class 0 or class 1 traffic might be overhead traveling
> cranes. That's a case where it might make sense for a PCE to set up tracks
> to all but the last hop, with multiple field routers able to receive from
> the crane and forward one hop to merge into the precomputed track.
>
> All food for thought.
>
> -Tom
> ====
>
>  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.
>
>
>  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
> 6tsch mailing [email-masked]://www.ietf.org/mailman/listinfo/6tsch
>
>

---

From: Tom Phinney <[email-masked]>
Date: Mon, 18 Mar 2013 15:22:51 -0700

In process automation plants, the information on each control loop,
including its criticality, loop rate (e.g., 4 Hz, 1 Hz) or period
(e.g., 5 s, 15 s, 30 s, 60 s, 5 m), phasing relative to other
interacting control loops where such is relevant, and much more is
part of a site database. The primary users of that database are the
engineering workstations that control the process, most of which are
typically found in control rooms inside blast-resistant buildings.

The primary key to that database is the device's "tag name", which
is the alphanumeric name assigned to the particular process sensor
or actuator device (e.g., T3E01, MF102, VA241, MC205 for temperature
sensor 301, mass flow sensor 102, valve 241, motor controller 205).
The P&ID (piping and instrumentation diagram) database is also
accessible by tag name; it shows not only physical geolocation of
devices but also their interconnections. Most of the P&ID
database is irrelevant to communications; it contains information on
things such as the materials of construction of the
process-contacting parts of the equipment, diameters of connecting
pipes (e.g., 60 cm), anticipated maximum pressures, site cameras
that have a view of that equipment and coordinates to aim and zoom
the cameras, diagrams and perhaps photos of the construction, etc.

So, to answer your question about "the most traditional way to
gather this info", there are traditional databases on a site where
this information resides, and there are existing standard protocols
such as OPC that can provide access to that information. However,
OPC normally does not need access to the device geolocation, so that
probably would need to be included in the engineering database
(obtained from the P&ID database).

There is existing practice for doing RF surveys of specific site
areas, usually with manual optimization of RF relays, but there is
no real history of automating the process at the scale under
discussion. Since site optimization of wireless via a PCE is not
(yet) industry standard practice, there is no comparable experience
to draw on here, so there will necessarily be innovation.

-Tom

===

On 2013.03.18 13:18, Thomas Watteyne wrote:

Tom,

"when coupled with knowledge of the required periodic
publication messaging (it's frequency, criticality and even PDU
size)"

What do you think is the most traditional way for the PCE to
gather this info?

Thomas

On Mon, Mar 18, 2013 at 1:06 PM, Tom
Phinney <[email-masked]>
wrote:

Re: it seems to be
the approach draft-ietf-roll-rpl-industrial-applicability
takes.

The reason why centralized (i.e., PCE) computation was
favored is that compute-intensive consideration of
schedules, based on physical knowledge of the placement of
all scheduled devices from the plant piping and
instrumentation diagram (P&ID) database, when coupled
with knowledge of the required periodic publication
messaging (it's frequency, criticality and even PDU size),
and potentially augmented by collected history of
communications failure rates on specific routes, can lead
to minimizing potential RF conflicts for the most critical
messaging. Supercomputers were applied to optimizing such
industrial processes as early as the 1980s, and to
optimizing airline equipment use and routing as early as
the late 1960s. There is nothing novel about large
industrial users doing such centralized optimization to
increase their profitability.

Those of us who work in this industry have always thought
that RF-equipped devices such as those using 802.15.4
might be able to use their radios for some form of
localized site survey. This would be particularly the case
for devices that are externally powered (such as those
coupled to powered actuators) or environmentally recharged
(e.g., from solar, or thermal potential differences, or
vibration energy harvesting), where battery life is not an
overriding concern. Use of the distributed network of
field devices to assess RF problems and provide
information that can assist in localizing the emission
source causing the problems is a high-payback additional
capability.

In summary, a centralized high-compute-power PCE, driven
from a large database that includes physical siting
information as well as historical performance
observations, should be able to statistically deconflict
many tracks by construction. That's a capability that
would be applied first to the most critical tracks, then
the most frequently used tracks, then down the priority
chain.

There is less of an opportunity to improve
aperiodically-used tracks via PCE precomputation, but that
still seems worth doing to some extent.

Relative to mobile, the only mobile equipment in large
outdoor plants that would be involved in class 0 or class
1 traffic might be overhead traveling cranes. That's a
case where it might make sense for a PCE to set up tracks
to all but the last hop, with multiple field routers able
to receive from the crane and forward one hop to merge
into the precomputed track.

All food for thought.

-Tom

====

On 2013.03.18 12:18, Thomas
Watteyne wrote:

Qin,

Please see inline.

On Mon, Mar 18, 2013 at
10:25 AM, Qin Wang <[email-masked]>
wrote:

Thomas,

I think for a data flow, there are three
elements needed to be defined or

(1) multihop path, i.e. who is the next hop
neighbor

(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

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

draft-ietf-roll-rpl-industrial-applicability-00

> reference topology becomes
unusable for some failure, and as long as
the

> [email-masked]>

wrote:

>> Qin>>>(2) If there is
PCE, there may be different setting. For
example,

>> Qin>>>neighbor) and
cells; or PCE is just in charge for
reserving the

>> Qin >>>(3)If there is no
PCE, both multi-hop path and cells are
reserved

>> From my point of view (and
thinking about TASA implementation), the
PCE

>> While, when a distributed
solution is used, 6tus will allocate the
soft

>> >>>- optionally a PCE
sits on the backbone and drives the LLNs'
TSCH

6tsch mailing list

[email-masked]