Subject: Re: [6tisch] 6tisch architecture and time-critical events

From: "S.V.R. Anand" <[email-masked]>
Date: Wed, 01 Jul 2015 22:19:37 +0530

Hi Yvonne-Anne,

Thanks for re-initiating this topic and for stressing the need for 
6tisch to address emergency/alarm conditions that occur in industry 
environments. In some sense your inputs have reinforced what I expressed 
in my earlier mail.

 From your mail it appears that there could arise situations where the 
network is expected to respond to application's reaction to exceptions 
by way of allocating network resources in a timely manner, and the 
amount of bandwidth required may be substantially more than the normal 
conditions. Finally, there is a need to satisfy deterministic 
expectations by 6tisch mechanism.

To meet all the above requirements simultaneously, perhaps there is a 
need for combining OTF with RSVP to create emergency flows on-the-fly 
that ensure end-to-end bandwidth guarantees till such a condition 
subsides. In this far fetching ? Hopefully not.

Anand

On 29/06/2015 15:00, Yvonne-Anne Pignolet wrote:
> Dear all
>
> Taking up some remarks by Anand and Pascal, has there been any recent activity w ith respect to the topic of handling resources in emergency scenarios?
> In case there hasn't, it would like to stress that from an industrial perspective such scenarios are very important.
>
> In particular, this concerns resources such as flows that follow certain routes, and bandwidth allocation. Depending on the traffic demands during alarm/emergency conditions, applications may decide to pre-empt or stall some of the ongoing traffic flows to accommodate new flows or to assign appropriate resources to existing flows. Is there a concept of priorities of flows envisioned in the architecture?
>
> Note that if there are cascading errors this often leads to an increase in traffic (messages to trigger logging of abnormal conditions, alarms for operators, &). Certain protocols (e.g. GOOOSE) send bursts of messages in such situations (e.g., three messages with a very short time interval in between, while normally one message every few seconds is sent) One could also envision applications having tighter control over network resources. For instance, an application might want to (i) increase the sensing rate (ii) activate additional sensors (iii) create special routing paths, ... In current implementations the applications are not designed to trigger such actions. However, the examples your point out can clearly be beneficial. As an easy and crucial part I see priorities and bandwidths.
>
> I'm very interested in any feedback to these points!
>
> Best Regards
> Yvonne-Anne
>    
> Yvonne-Anne Pignolet
> Dr. Sc. ETH Zürich
> ABB Corporate Research
> Segelhofstrasse 1K
> 5400 Baden-Dättwil, Switzerland
> Phone: +41 58 586 86 56
> Mobile: +41 79 766 10 54
> email: [email-masked]
>
>
> On Mon, Feb 16, 2015 at 6:39 PM, Pascal Thubert (pthubert) <pthubert at cisco.com> wrote:
>> A great thought, Anand,
>>   
>>
>> which has to do external control of 6top, establishing on demand path
>> (tracks) etc.
>>
>> I think that the next round to charter will have some deterministic/PCE in it, that should address this scenario.
>>
>> What's interesting in your suggestion is that it is midway between OTF and classical tracks for control loops, being urgent and dynamic.
>>
>> Do you have a documented use case?
>>
>>   
>> Pascal
>>
>>   
>>
>> From: 6tisch [mailto:6tisch-bounces at ietf.org] On Behalf Of
>> S.V.R.Anand
>> Sent: lundi 16 février 2015 15:00
>> To: 6tisch at ietf.org
>> Subject: Re: [6tisch] Last call for draft-ietf-6tisch-architecture-05
>>
>>   
>>
>> Dear All,
>>
>> I found that the architecture draft captured most of the general requirements.
>>
>> There is just one observation which I could not resist mentioning. It
>> has to do with the coupling of real-time application demands with the
>> rest of the architecture. There could be application specific "time critical and sudden" events that might call for on-demand resource allocation.
>> While we can delegate such an event handling to NME and PCE, perhaps,
>> bringing in an application awareness to the overall architecture might be useful so that we are not leaving out this possible scenario.
>>
>> Just a thought.
>>
>> Regards
>> Anand
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: "Senju Panicker" <[email-masked]>
Date: Tue, 7 Jul 2015 18:43:30 +0530

Hi,

I am glad that time critical events during emergency/alarm conditions is
being
discussed in the mailing list as it is extremely important for my work.
Thanks
to Yvonne-Anne for bringing up this important topic.

We are working towards deploying a complete 6tisch based network for
monitoring
and control for an industrial application. This industry currently uses
combination of wired and wireless infrastructure. The wireless part is used
for
not-so-critical and routing monitoring activities, whereas wired
infrastructure
is used to perform time critical parameter monitoring and control loop
operations. One of the main requirements when we completely migrate to
6tisch
network is timely handling of emergency conditions so that system trip and
shutdown are avoided.

I would like to emphasise that there is a need for urgent and additional
network
resource provisioning due to several inter-related sensors getting actuated
and
the increased monitoring rate during emergency situations. If it were to be
monitored at the normal sampling rate, the parameter could very well exceed
its
safe level in few updates and could very well lead to a system trip.

Below is one such condition that occurs in a thermal power plant where we
had

worked earlier.

When pulverized coal outlet temperature limit crosses certain limit for safe
operation of the coal mill, it could be due to several reasons such as
deviation in primary air temperature, primary air flow, mill inlet
temperature
or cold air inflow. The deviation in primary air temperature itself could be
due to problems associated with pre-heating and the deviation in cold air
inflow could be due to malfunctioning of hot air damper valve. 

It will be very helpful if we have mechanisms built into 6tisch which
enables
end application/controller, and nodes in the network to set up emergency
flows through
network bandwidth reservations in a timely manner that guarantees end-to-end
QoS till the emergency condition lasts.

Thanks & Regards

Senju Thomas Panicker

Senior Engineer

Control & Instrumentation Group

 

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Yvonne-Anne
Pignolet
Sent: 29 June 2015 15:00
To: [email-masked]
Subject: Re: [6tisch] 6tisch architecture and time-critical events

Dear all

Taking up some remarks by Anand and Pascal, has there been any recent
activity with respect to the topic of handling resources in emergency
scenarios?

In case there hasn't, it would like to stress that from an industrial
perspective such scenarios are very important.

In particular, this concerns resources such as flows that follow certain
routes, and bandwidth allocation. Depending on the traffic demands during
alarm/emergency conditions, applications may decide to pre-empt or stall
some of the ongoing traffic flows to accommodate new flows or to assign
appropriate resources to existing flows. Is there a concept of priorities of
flows envisioned in the architecture?

Note that if there are cascading errors this often leads to an increase in
traffic (messages to trigger logging of abnormal conditions, alarms for
operators, &). Certain protocols (e.g. GOOOSE) send bursts of messages in
such situations (e.g., three messages with a very short time interval in
between, while normally one message every few seconds is sent) One could
also envision applications having tighter control over network resources.
For instance, an application might want to (i) increase the sensing rate
(ii) activate additional sensors (iii) create special routing paths, ... In
current implementations the applications are not designed to trigger such
actions. However, the examples your point out can clearly be beneficial. As
an easy and crucial part I see priorities and bandwidths.

Best Regards

Yvonne-Anne

Yvonne-Anne Pignolet

Dr. Sc. ETH Zürich

ABB Corporate Research

Segelhofstrasse 1K

Phone: +41 58 586 86 56

Mobile: +41 79 766 10 54

email:  <mailto:[email-masked]>
[email-masked]

On Mon, Feb 16, 2015 at 6:39 PM, Pascal Thubert (pthubert) <pthubert at
cisco.com> wrote:

> What's interesting in your suggestion is that it is midway between OTF and
classical tracks for control loops, being urgent and dynamic.

> rest of the architecture. There could be application specific "time
critical and sudden" events that might call for on-demand resource
allocation.

> bringing in an application awareness to the overall architecture might be
useful so that we are not leaving out this possible scenario.

6tisch mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/6tisch>
https://www.ietf.org/mailman/listinfo/6tisch

-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------

---

From: Yvonne-Anne Pignolet <[email-masked]>
Date: Thu, 9 Jul 2015 07:53:05 +0000

Dear Senju

Thanks for describing this use case. It matches exactly the kind of scenarios I had in mind.

In his email on the 1st of July Anand mentioned that "combining OTF with RSVP to create emergency flows on-the-fly" might be a way to handle these situations. Anand, can you elaborate a bit more on that? Or can someone else give feedback if this or another mechanism could help to achieve this goal?

Regards
Yvonne-Anne
____________________
From: 6tisch [mailto:[email-masked]] On Behalf Of Senju Panicker
Sent: Dienstag, 7. Juli 2015 15:14
To: [email-masked]
Subject: Re: [6tisch] 6tisch architecture and time-critical events

Hi,

I am glad that time critical events during emergency/alarm conditions is being
discussed in the mailing list as it is extremely important for my work. Thanks
to Yvonne-Anne for bringing up this important topic.

We are working towards deploying a complete 6tisch based network for monitoring
and control for an industrial application. This industry currently uses
combination of wired and wireless infrastructure. The wireless part is used for
not-so-critical and routing monitoring activities, whereas wired infrastructure
is used to perform time critical parameter monitoring and control loop
operations. One of the main requirements when we completely migrate to 6tisch
network is timely handling of emergency conditions so that system trip and
shutdown are avoided.

I would like to emphasise that there is a need for urgent and additional network
resource provisioning due to several inter-related sensors getting actuated and
the increased monitoring rate during emergency situations. If it were to be
monitored at the normal sampling rate, the parameter could very well exceed its
safe level in few updates and could very well lead to a system trip.

Below is one such condition that occurs in a thermal power plant where we had
worked earlier.

deviation in primary air temperature, primary air flow, mill inlet temperature

It will be very helpful if we have mechanisms built into 6tisch which enables
end application/controller, and nodes in the network to set up emergency flows through
network bandwidth reservations in a timely manner that guarantees end-to-end
QoS till the emergency condition lasts.

Thanks & Regards

Senju Thomas Panicker
Senior Engineer

-----Original Message-----
From: 6tisch [mailto:[email-masked]] On Behalf Of Yvonne-Anne Pignolet
Sent: 29 June 2015 15:00
To: [email-masked]
Subject: Re: [6tisch] 6tisch architecture and time-critical events

Dear all

Taking up some remarks by Anand and Pascal, has there been any recent activity with respect to the topic of handling resources in emergency scenarios?
In case there hasn't, it would like to stress that from an industrial perspective such scenarios are very important.

Best Regards
Yvonne-Anne
  
Yvonne-Anne Pignolet
Dr. Sc. ETH Zürich
ABB Corporate Research
Segelhofstrasse 1K

---

From: "S.V.R.Anand" <[email-masked]>
Date: Fri, 10 Jul 2015 15:56:52 +0530

Hi Yvonne-Anne,

Let me first say that the problem is actually very complex than what I 
anticipated. My
suggestion of extending OTF to create RSVP flows is to treated as a starting
point that can be used to address at least part of the problem, and it 
is far
from a complete solution.

As per yours and Senju's mails, it is evident that one requires rapid 
creation
of flows that satisfy bandwidth and delay constraints of the 
application. Since
these flows also need to persist till the emergency condition goes away, 
RSVP
can be used to create, maintain, tear down these flows. Let me add to what I
hinted in my previous mail.

If the nodes in the network happen to initiate such flows before application
comes into the picture with its own resource provisioning, then RSVP 
operation
can be triggered by using OTF scheduling approach, but giving it an 
additional
functionality of propagating the reservation request all the way to the
destination, which could be the host running the end application. In this
process, the intermediate nodes that have already provisioned cells to carry
normal traffic may have to be re-allocated/deleted to support this 
request. Let
me add that the use of OTF to support flows of this kind serves the 
purpose of
sending sudden traffic surge in a deterministic manner end-to-end, perhaps,
as an immediate reaction before application takes over.

The questions of scalability, control message overheads, call admission 
control
need to be addressed too.

How the application takes over by interacting with PCE is another story. 
If the
emergency condition also brings in new sensor nodes into the network, 
the join
process and the related delays can only add to the complication! There 
are layers
of complexity as one can see.

I will be very happy to hear from others on this challenging problem.

Anand

On Thursday 09 July 2015 01:23 PM, Yvonne-Anne Pignolet wrote:
 > In his email on the 1st of July Anand mentioned that "combining OTF 
with RSVP to create emergency flows on-the-fly" might be a way to handle 
these situations. Anand, can you elaborate a bit more on that? Or can 
someone else give feedback if this or another mechanism could help to 
achieve this goal?
monitoring
infrastructure
temperature
enables
 >
 > In particular, this concerns resources such as flows that follow 
certain routes, and bandwidth allocation. Depending on the traffic 
demands during alarm/emergency conditions, applications may decide to 
pre-empt or stall some of the ongoing traffic flows to accommodate new 
flows or to assign appropriate resources to existing flows. Is there a 
concept of priorities of flows envisioned in the architecture?
 >
 > Note that if there are cascading errors this often leads to an 
increase in traffic (messages to trigger logging of abnormal conditions, 
alarms for operators, &). Certain protocols (e.g. GOOOSE) send bursts of 
messages in such situations (e.g., three messages with a very short time 
interval in between, while normally one message every few seconds is 
sent) One could also envision applications having tighter control over 
network resources. For instance, an application might want to (i) 
increase the sensing rate (ii) activate additional sensors (iii) create 
special routing paths, ... In current implementations the applications 
are not designed to trigger such actions. However, the examples your 
point out can clearly be beneficial. As an easy and crucial part I see 
priorities and bandwidths.
 >> I think that the next round to charter will have some 
deterministic/PCE in it, that should address this scenario.
 >>
 >> What's interesting in your suggestion is that it is midway between 
OTF and classical tracks for control loops, being urgent and dynamic.
 >> bringing in an application awareness to the overall architecture 
might be useful so that we are not leaving out this possible scenario.