Thomas, Thanks a ton for re-opening the thread, and for the paper. Will certainly read it!
I agree with your proposition regarding the sequence of activities that has been planned by the group. As was discussed in the virtual meeting today, I also concur with the view that we should first focus on pure distributed scheduling as of now. As we go along, I will be extremely happy to discuss more on the RSVP-OTF, OTF-PCE interaction, and other topics that will be of interest to the group. Anand > 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]> > 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] >> <[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] >> <[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 <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* <http://www.mailscanner.info/>, and >> is >> believed to be clean. >> >> _______________________________________________ >> 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 > -- 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
