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:
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 protected]] On Behalf Of Senju Panicker
> Sent: Dienstag, 7. Juli 2015 15:14
> To: [email protected]
> 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.
>
> 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 protected]] On Behalf Of
Yvonne-Anne Pignolet
> Sent: 29 June 2015 15:00
> To: [email protected]
> 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.
>
> 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 protected]
>
>
> 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 protected]
> 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.
>
-------------------------------------------------------------------------------------------------------------------------------
>
> _______________________________________________
> 6tisch mailing list
> [email protected]
> 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.
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
