Hello Thomas: 100% with you. And great, visionary paper by the way.
There was a confusion at the call about applying OTF to tracks in the one hand, which includes the discussion below, and employing some central computation to help OTF do its work in the other. I was advocating that there are agile steps even in application of OTF designs to best effort IP flows. In that endeavor: Step 1) (and your suggestion in this thread) is the capability to negotiate at L2 between adjacent peers to add or remove a unicast cell in one of their pair of L3 bundles, the up and the down ones, aka track0. This would come with some intelligence local to the node that finds when there is a need for this to happen. An example of the result could have been a combination of the CoAP IE and the OTF drafts as they stand now, though the call indicated that we are probably not pursuing the CoAP-IE path any longer. Discovery of empty cells would not be considered if the CDU matrix is expected to be largely unused. Step 2) is the capability to appropriate cells and add some management to the CDU matrix. That would include LBT and chunk management. Step 3) (my point at the call) is that the local intelligence with constrained memory does not allow to manage a more global optimization that avoids greedy RPL parents from starving some other routers (e.g. around the root), and would enable a better adaptations to observables rhythms in the network operation. At that point, there could be some intelligence at the PCE that would hint the parents about timely boundaries in the way they appropriate cells, blocking them from being too greedy some times, and allowing them to actually prepare for upcoming (periodic) increases of traffic in some areas of the network. Certainly I’m suggesting that the WG concentrates on one step at a time in order to deliver usable specifications that can be tested for interop one at a time. I’m also happy to start some parallel work on the next item long as the conversation does not disrupt the main task at hand. Take care, Pascal From: 6tisch [mailto:[email protected]] On Behalf Of Thomas Watteyne Sent: vendredi 25 septembre 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
