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
