Dear Thomas Thanks for getting back to us. I agree that having standards out fast is for everyone’s benefit and that functionality for time-critical events can augment them in a second step.
I’m looking forward to reading your paper and to any further discussions on this topic. Unfortunately, I cannot participate in today’s meeting. Best Regards Yvonne-Anne From: 6tisch [mailto:[email protected]] On Behalf Of Thomas Watteyne Sent: Freitag, 25. September 2015 12:25 To: [email protected] Subject: Re: [6tisch] 6tisch architecture and time-critical events Anand, Yvonne-Anne, Senju, I'm reopening an old thread here to acknowledge that your requirements are heard loud and clear. TSCH has the great feature that link-layer resource are clearly identified and can be cleanly allocated. It's hence logical to introduce priorities between flows, which is exactly what is done with the concept of tracks and associated priority. About the idea of augmenting OTF with RSVP-like behavior, I'd like to point you to a publication in which we played with just that idea in the OpenWSN project: Label Switching over IEEE802.15.4e Networks. Antoni Morell, Xavier Vilajosana, Jose Lopez Vicario, Thomas Watteyne. Wiley Transactions on Emerging Telecommunications Technologies. DOI: 10.1002/ett.2650. May 2013. As you can read in this paper, the concept is powerful and would allow seamless co-existence between different flows in a distributed manner. Now with my co-chair hat on, I believe we need to proceed step-by-step. My (strong) opinion is that we should deliver standards fast, and augment them with further functionality as a second step. We have concluded the work on draft-minimal with the July 6TiSCH plugtest. IMO, our next step is to conclude the work on OTF (the aim being to test interoperability in February 2016). After that, we can consider coupling OTF with RSVP-like reservation. I expect much discussion/work to be needed for that last point, but will be exciting. We are meeting this in 3.5h to discuss the precise scope of our next steps. Your input would be very much appreciated during this discussion. Thomas On Fri, Jul 10, 2015 at 12:26 PM, S.V.R.Anand <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[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<tel:%2B41%2058%20586%2086%2056> > Mobile: +41 79 766 10 54<tel:%2B41%2079%20766%2010%2054> > email: [email protected]<mailto:[email protected]> > > > On Mon, Feb 16, 2015 at 6:39 PM, Pascal Thubert (pthubert) <pthubert at > cisco.com<http://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<http://ietf.org>] On Behalf >> Of >> S.V.R.Anand >> Sent: lundi 16 février 2015 15:00 >> To: 6tisch at ietf.org<http://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]<mailto:[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]<mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/6tisch > -- This message has been scanned for viruses and dangerous content by MailScanner<http://www.mailscanner.info/>, and is believed to be clean. _______________________________________________ 6tisch mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
