Subject: [6tsch] on end to end reservation and 6TSCH role

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 08 Feb 2013 10:28:04 -0800

Hi all,

after the phone meeting I want to share my point on the end to end 
reservation as pointed out by Pascal.

I think that the information that is carried on a message to establish 
end to end reservation has to feed 6tsch who as a black box will setup 
the links at L2.

So if the application or RSVP mechanism wants to set an end-to-end 
bandwidth (of X packets/s),  that reservation message has to flow 
through the desired route (path) and ask to 6TSCH to meet that 
bandwidth. This has not to be bound to a specific scheduling protocol as 
we want to support both centralized and decentralized approaches, 
meaning that if centralized the reservation request will include some IE 
indicating to 6TSCH exactly what to schedule, contrarily, if 
decentralized, 6TSCH will receive the requirement and reserve the slots 
according to some internal mechanism such as pair-wise negotiation with 
neighbors.

I point out that because I don't know if this is aligned with what 
Pascal said and I want to know what is your opinion here.

thanks.
Xavi

---

From: Pascal Thubert <[email-masked]>
Date: Fri, 8 Feb 2013 21:40:15 +0100

Hi Xavier

We are in line. I think the reservation could also carry a budget in latency so that the sub layer determines and returns how much is consumed between incoming and outgoing time slots with the associated in and out labels,

What do you think?

Cheers

Pascal

Le 8 févr. 2013 à 19:28, Xavier Vilajosana <[email-masked]> a écrit :

> Hi all,
> 
> after the phone meeting I want to share my point on the end to end reservation as pointed out by Pascal.
> 
> I think that the information that is carried on a message to establish end to end reservation has to feed 6tsch who as a black box will setup the links at L2.
> 
> So if the application or RSVP mechanism wants to set an end-to-end bandwidth (of X packets/s),  that reservation message has to flow through the desired route (path) and ask to 6TSCH to meet that bandwidth. This has not to be bound to a specific scheduling protocol as we want to support both centralized and decentralized approaches, meaning that if centralized the reservation request will include some IE indicating to 6TSCH exactly what to schedule, contrarily, if decentralized, 6TSCH will receive the requirement and reserve the slots according to some internal mechanism such as pair-wise negotiation with neighbors.
> 
> I point out that because I don't know if this is aligned with what Pascal said and I want to know what is your opinion here.
> 
> thanks.
> Xavi
> _______________________________________________
> 6tsch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tsch

---

From: Xavier Vilajosana <[email-masked]>
Date: Fri, 08 Feb 2013 13:48:51 -0800

Totally agree.

One more question then:

Is task of 6TSCH to define or at least point out what metrics (latency, 
bandwidth,fairness*,etc..) should the reservation carry on?

My guess is that yes, but I am not sure on what kind of detail, should 
we define the message type? should it be a TLV element or an option?

RSVP for examples is pretty open on that, as long as you keep their 
object header, you can embed objects into the packet (TLV style).

*fairness means that all nodes in the network for example have the same 
opportunities to transmit at the same rate or that the delay is more or 
less uniform across the network.

regards,
Xavi

---

From: Tom Phinney <[email-masked]>
Date: Sat, 09 Feb 2013 01:19:25 -0700

I'd like to point out that, at least in practical
industrial automation networks, metrics such as fairness* need to
be assessed relative to a subset of the nodes. In general it makes
sense to assess fairness* relative to other devices that are
conveying information floes of the same industrial automation
usage class#, perhaps restricted to the subset of flows that have
approximately the same repetition rate. In other words, fairness
may make sense when comparing information flows used for 250 ms (4
Hz) closed loop control, but it hardly seems relevant when
comparing messaging supporting such 4 Hz control with an hourly
class 5 status report about a valve that replaces a manual
walk-around observation of that valve which previously (before
wireless) occured once every 24 hours.

For those unfamiliar with the usage classes for industrial
automation, the following (excerpted from an Annex to the IEC
62734 version of the ISA100.11a standard) may serve to introduce
the concept.

A.1.1  General

While there are many techniques that may be
used to
categorize the communications needs of industrial applications,
this standard
uses classes based upon usage. Analysis of the patterns of
intended use of
inter-device industrial wireless communications resulted in a
partitioning of
such communications into six classes. These classes are summarized
in Table C.1.

Table C.1 – Usage classes

Safety

Class 0: Emergency action

Always critical

Control

Class 1: Closed loop regulatory
control

Often critical

Class 2: Closed loop supervisory
control

Usually non-critical

Class 3: Open loop control

Human in the loop

Monitoring

Class 4: Alerting

Short-term operational consequence
(e.g., event-based maintenance)

Class 5: Logging and downloading /
uploading

No immediate operational consequence
(e.g., history collection, sequence-of-events,
preventive maintenance)

NOTE Batch levels[1]
3 and 4 could be class 2, class 1 or even class 0,
depending on function.

A.1.2  Class
examples

·
Class 0: Emergency action
(always critical)

Examples include:

–
safety interlock;

–
emergency shutdown;

–
automatic fire control.

·
Class 1: Closed loop regulatory control      (often critical)

Examples
include:

–      direct
control
of primary actuators (e.g., field device to host connection
availability on demand of at least 99,99%, with link outages >
500 ms
intolerable, with demand rates of 0,2 Hz or greater);

–      high-frequency
cascade
loops.

·
Class 2: Closed loop supervisory control     (usually non-critical)

Examples
include:

–      low-frequency
cascade
loops;

–      multivariable
controls;

–      optimizers.

·
Class 3: Open loop control
(human in the loop)

Examples
include:

–      operator
manually
initiates a flare and watches the flare;

–      guard
remotely
opens a security gate;

–      operator
performs
manual pump/valve adjustment.

·
Class 4: Alerting – Short-term
operational
consequence

Examples
include:

–      event-based
maintenance;

–      marginal
bearing
temp results in technician sent to field;

–      battery
low
indicator for a device results in technician sent to change
battery;

–      asset
tracking.

·
Class 5: Logging – data/messages with no
immediate operational consequence

Examples
include:

–      history
collection;

–      preventive
maintenance
rounds;

–      sequence
of
events (SOE) uploading.

NOTE SOE uses lossless communication, such as file
transfer,
rather than timely communication such as used by control
messaging.

Alarm examples include:

·
Class 0: leak detector for radiation or
fatally
toxic gas, automated response (e.g., automated containment
response).

·
Class 1: high-impact process condition,
automated response (e.g., automated shutdown of reaction).

·
Class 2: automated response to process
condition
(e.g., automated flow diversion).

·
Class 3: process condition with
manually-initiated operational response (e.g., decide whether to
divert flow to
a parallel reactor).

·
Class 4: equipment condition with
short-time-scale maintenance response (e.g., send technician to
field).

·
Class 5: equipment condition with
long-time-scale maintenance action (e.g., order spare parts).

[1]
Batch levels are defined in IEC 61512-1, where L3 = unit and
L4 = process cell

-Tom

===

On 2013.02.08 14:48, Xavier Vilajosana wrote:

Totally agree.

One more question then:

Is task of 6TSCH to define or at least point out what metrics
(latency, bandwidth,fairness*,etc..) should the reservation carry
on?

My guess is that yes, but I am not sure on what kind of detail,
should we define the message type? should it be a TLV element or
an option?

RSVP for examples is pretty open on that, as long as you keep
their object header, you can embed objects into the packet (TLV
style).

*fairness means that all nodes in the network for example have the
same opportunities to transmit at the same rate or that the delay
is more or less uniform across the network.

regards,

Xavi

Hi Xavier

We are in line. I think the reservation could also carry a
budget in latency so that the sub layer determines and returns
how much is consumed between incoming and outgoing time slots
with the associated in and out labels,

What do you think?

Cheers

Pascal

Le 8 févr. 2013 à 19:28, Xavier Vilajosana
<[email-masked]> a écrit :

Hi all,

after the phone meeting I want to share my point on the end to
end reservation as pointed out by Pascal.

I think that the information that is carried on a message to
establish end to end reservation has to feed 6tsch who as a
black box will setup the links at L2.

So if the application or RSVP mechanism wants to set an
end-to-end bandwidth (of X packets/s),  that reservation
message has to flow through the desired route (path) and ask
to 6TSCH to meet that bandwidth. This has not to be bound to a
specific scheduling protocol as we want to support both
centralized and decentralized approaches, meaning that if
centralized the reservation request will include some IE
indicating to 6TSCH exactly what to schedule, contrarily, if
decentralized, 6TSCH will receive the requirement and reserve
the slots according to some internal mechanism such as
pair-wise negotiation with neighbors.

I point out that because I don't know if this is aligned with
what Pascal said and I want to know what is your opinion here.

thanks.

Xavi

6tsch mailing list

[email-masked]

6tsch mailing list

[email-masked]

---

From: Thomas Watteyne <[email-masked]>
Date: Sun, 10 Feb 2013 13:35:59 -0800

Tom,

Thank you for this information. Could you confirm that these are the
classes you introduced in http://tools.ietf.org/html/rfc5673#section-3.1?

Thanks,
Thomas

On Sat, Feb 9, 2013 at 12:19 AM, Tom Phinney <[email-masked]> wrote:

> **
> I'd like to point out that, at least in practical industrial automation
> networks, metrics such as fairness* need to be assessed relative to a
> subset of the nodes. In general it makes sense to assess fairness* relative
> to other devices that are conveying information floes of the same
> industrial automation usage class#, perhaps restricted to the subset of
> flows that have approximately the same repetition rate. In other words,
> fairness may make sense when comparing information flows used for 250 ms (4
> Hz) closed loop control, but it hardly seems relevant when comparing
> messaging supporting such 4 Hz control with an hourly class 5 status report
> about a valve that replaces a manual walk-around observation of that valve
> which previously (before wireless) occured once every 24 hours.
>
> For those unfamiliar with the usage classes for industrial automation, the
> following (excerpted from an Annex to the IEC 62734 version of the
> ISA100.11a standard) may serve to introduce the concept.
>
> A.1.1  General
>
> While there are many techniques that may be used to categorize the
> communications needs of industrial applications, this standard uses classes
> based upon usage. Analysis of the patterns of intended use of inter-device
> industrial wireless communications resulted in a partitioning of such
> communications into six classes. These classes are summarized in Table C.1
> .
>
> Class 1: Closed loop regulatory control
>
> Often critical
>
> Class 2: Closed loop supervisory control
>
> Usually non-critical
>
> Short-term operational consequence (e.g., event-based maintenance)
>
> Class 5: Logging and downloading / uploading
>
> No immediate operational consequence (e.g., history collection,
> sequence-of-events, preventive maintenance)
>
> NOTE Batch levels[1] 3 and 4 could be class 2, class 1 or even class 0,
> depending on function.
>
>
>
>
>
> A.1.2  Class examples
>
> ·      Class 0: Emergency action            (always critical)
>
> Examples include:
>
> –      safety interlock;**
>
> –      emergency shutdown;**
>
> –      automatic fire control.**
>
> ·      Class 1: Closed loop regulatory control      (often critical)
>
> Examples include:
>
> –      direct control of primary actuators (e.g., field device to host
> connection availability on demand of at least 99,99%, with link outages >
> 500 ms intolerable, with demand rates of 0,2 Hz or greater);
>
> –      high-frequency cascade loops.
>
> ·      Class 2: Closed loop supervisory control     (usually non-critical)
>
> Examples include:
>
> –      low-frequency cascade loops;
>
> –      multivariable controls;
>
> –      optimizers.
>
> ·      Class 3: Open loop control (human in the loop)
>
> Examples include:
>
> –      operator manually initiates a flare and watches the flare;
>
> –      guard remotely opens a security gate;
>
> –      operator performs manual pump/valve adjustment.
>
> ·      Class 4: Alerting – Short-term operational consequence
>
> Examples include:
>
> –      event-based maintenance;
>
> –      marginal bearing temp results in technician sent to field;
>
> –      battery low indicator for a device results in technician sent to
> change battery;
>
> –      asset tracking.
>
> ·      Class 5: Logging – data/messages with no immediate operational
> consequence
>
> Examples include:
>
> –      history collection;
>
> –      preventive maintenance rounds;
>
> –      sequence of events (SOE) uploading.
>
> NOTE SOE uses lossless communication, such as file transfer, rather than
> timely communication such as used by control messaging.
>
>  Alarm examples include:
>
> ·      Class 0: leak detector for radiation or fatally toxic gas,
> automated response (e.g., automated containment response).
>
> ·      Class 1: high-impact process condition, automated response (e.g.,
> automated shutdown of reaction).
>
> ·      Class 2: automated response to process condition (e.g., automated
> flow diversion).
>
> ·      Class 3: process condition with manually-initiated operational
> response (e.g., decide whether to divert flow to a parallel reactor).
>
> ·      Class 4: equipment condition with short-time-scale maintenance
> response (e.g., send technician to field).
>
> ·      Class 5: equipment condition with long-time-scale maintenance
> action (e.g., order spare parts).
>
> ------------------------------
>
> [1] Batch levels are defined in IEC 61512-1, where L3 = unit and L4 =
> process cell
>   ------------------------------
>
>
>
> -Tom
> ===
>
> My guess is that yes, but I am not sure on what kind of detail, should we
> define the message type? should it be a TLV element or an option?
>
> RSVP for examples is pretty open on that, as long as you keep their object
> header, you can embed objects into the packet (TLV style).
>
>
> We are in line. I think the reservation could also carry a budget in
> latency so that the sub layer determines and returns how much is consumed
> between incoming and outgoing time slots with the associated in and out
> labels,
>
> What do you think?
>
> Cheers
>
> Pascal
>
> Le 8 févr. 2013 à 19:28, Xavier Vilajosana <[email-masked]><[email-masked]>a écrit :
>
> Hi all,
>
> I think that the information that is carried on a message to establish end
> to end reservation has to feed 6tsch who as a black box will setup the
> links at L2.
>
> bandwidth (of X packets/s),  that reservation message has to flow through
> the desired route (path) and ask to 6TSCH to meet that bandwidth. This has
> not to be bound to a specific scheduling protocol as we want to support
> both centralized and decentralized approaches, meaning that if centralized
> the reservation request will include some IE indicating to 6TSCH exactly
> what to schedule, contrarily, if decentralized, 6TSCH will receive the
> requirement and reserve the slots according to some internal mechanism such
> as pair-wise negotiation with neighbors.
>
> I point out that because I don't know if this is aligned with what Pascal
> said and I want to know what is your opinion here.
>
> thanks.
> Xavi

---

From: Tom Phinney <[email-masked]>
Date: Sun, 10 Feb 2013 19:58:37 -0700

Thomas,

They are. I happened to be working on the IEC version of the
ISA100.11a spec at the time, so copied that version, which was
also the source of the rfc5673 material.

If you received it all garbled, which it was when it came back to
me (and seems to be an occasional consequence of my using Mozilla
Thunderbird as an e-mail client), I'll send out a different
version.

These classes were developed years ago, early in the ISA100
standardization effort, to characterize the types of
machine-to-machine communication that occurs in the process
automation industry. I don't recall that the original contained
the "intolerable" statement, but that does summarize the way that
end users (e.g., multi-billion dollar corporations) feel about any
loss of communication that causes mode-shedding in the controlled
process. As Herman Storey, formerly of Shell Oil (and now a member
of this list), put it at the start of ISA100, "once a year for
such an incident is too much", i.e., too often for the plant
manager, and that's with thousands of such control loops in
operation around the clock.

-Tom

=====

On 2013.02.10 14:35, Thomas Watteyne wrote:

Tom,

Thank
you for this information. Could you confirm that these are the
classes you introduced in http://tools.ietf.org/html/rfc5673#section-3.1?

Thanks,

Thomas

I'd
like to point out that, at least in practical industrial
automation networks, metrics such as fairness* need to be
assessed relative to a subset of the nodes. In general it
makes sense to assess fairness* relative to other devices
that are conveying information floes of the same industrial
automation usage class#, perhaps restricted to the subset of
flows that have approximately the same repetition rate. In
other words, fairness may make sense when comparing
information flows used for 250 ms (4 Hz) closed loop
control, but it hardly seems relevant when comparing
messaging supporting such 4 Hz control with an hourly class
5 status report about a valve that replaces a manual
walk-around observation of that valve which previously
(before wireless) occured once every 24 hours.

For those unfamiliar with the usage classes for industrial
automation, the following (excerpted from an Annex to the
IEC 62734 version of the ISA100.11a standard) may serve to
introduce the concept.

A.1.1  General

While there are many techniques that may
be used to categorize the communications needs of industrial
applications, this standard uses classes based upon usage.
Analysis of the patterns of intended use of inter-device
industrial wireless communications resulted in a
partitioning of such communications into six classes. These
classes are summarized in Table C.1.

Safety

Always critical

Control

Class 1: Closed loop
regulatory control

Often critical

Class 2: Closed loop
supervisory control

Usually non-critical

Human in the loop

Monitoring

Class 4: Alerting

Short-term operational
consequence (e.g., event-based maintenance)

Class 5: Logging and
downloading / uploading

No immediate operational
consequence (e.g., history collection,
sequence-of-events, preventive maintenance)

NOTE Batch levels[1]

A.1.2  Class examples

·      Class
0: Emergency action            (always
critical)

Examples
include:

–      safety
interlock;

–      emergency
shutdown;

–      automatic
fire control.

·      Class
1: Closed loop regulatory control      (often
critical)

Examples

include:

–      direct
control

of primary actuators (e.g., field device to host connection
availability on demand of at least 99,99%, with link outages

–      high-frequency
cascade

loops.

·      Class
2: Closed loop supervisory control     (usually
non-critical)

Examples

include:

–      low-frequency
cascade

loops;

–      multivariable

controls;

–      optimizers.

·      Class
3: Open loop control (human in the
loop)

Examples

include:

–      operator
manually

–      guard
remotely

opens a security gate;

–      operator
performs

·      Class
4: Alerting – Short-term operational consequence

Examples

include:

–      event-based

maintenance;

–      marginal
bearing

–      battery
low

–      asset

tracking.

·      Class
5: Logging – data/messages with no immediate operational
consequence

Examples

include:

–      history

collection;

–      preventive
maintenance

rounds;

–      sequence
of

events (SOE) uploading.

NOTE SOE uses lossless communication, such as
file transfer, rather than timely communication such as used
by control messaging.

Alarm examples include:

·      Class
0: leak detector for radiation or fatally toxic gas,
automated response (e.g., automated containment response).

·      Class
1: high-impact process condition, automated response (e.g.,
automated shutdown of reaction).

·      Class
2: automated response to process condition (e.g., automated
flow diversion).

·      Class
3: process condition with manually-initiated operational
response (e.g., decide whether to divert flow to a parallel
reactor).

·      Class
4: equipment condition with short-time-scale maintenance
response (e.g., send technician to field).

·      Class
5: equipment condition with long-time-scale maintenance
action (e.g., order spare parts).

[1]
Batch levels are defined in IEC 61512-1, where L3 = unit
and L4 = process cell

-Tom

===

Totally agree.

One more question then:

Is task of 6TSCH to define or at least point out what
metrics (latency, bandwidth,fairness*,etc..) should the
reservation carry on?

My guess is that yes, but I am not sure on what kind of
detail, should we define the message type? should it be a
TLV element or an option?

RSVP for examples is pretty open on that, as long as you
keep their object header, you can embed objects into the
packet (TLV style).

*fairness means that all nodes in the network for example
have the same opportunities to transmit at the same rate or
that the delay is more or less uniform across the network.

regards,

Xavi

Hi Xavier

We are in line. I think the reservation could also carry a
budget in latency so that the sub layer determines and
returns how much is consumed between incoming and outgoing
time slots with the associated in and out labels,

What do you think?

Cheers

Pascal

Le 8 févr. 2013 à 19:28, Xavier Vilajosana <[email-masked]>
a écrit :

Hi all,

after the phone meeting I want to share my point on the
end to end reservation as pointed out by Pascal.

I think that the information that is carried on a
message to establish end to end reservation has to feed
6tsch who as a black box will setup the links at L2.

So if the application or RSVP mechanism wants to set an
end-to-end bandwidth (of X packets/s),  that reservation
message has to flow through the desired route (path) and
ask to 6TSCH to meet that bandwidth. This has not to be
bound to a specific scheduling protocol as we want to
support both centralized and decentralized approaches,
meaning that if centralized the reservation request will
include some IE indicating to 6TSCH exactly what to
schedule, contrarily, if decentralized, 6TSCH will
receive the requirement and reserve the slots according
to some internal mechanism such as pair-wise negotiation
with neighbors.

I point out that because I don't know if this is aligned
with what Pascal said and I want to know what is your
opinion here.

thanks.

Xavi

6tsch mailing list

[email-masked]

6tsch mailing list

[email-masked]