Hi Pascal, w.r.t your step 3) I think we are still far from that. However I like the idea. Not sure about the centralized approach though. As RPL is fully distributed, could not this information be obtained in a distributed/hybrid(parent-child) manner?
My thought is to focus in step 1) . As said I am also in favor on a Sub-IE like approach instead of the complex CoAP IE management. my 2 cents, X 2015-09-28 11:20 GMT+02:00 Pascal Thubert (pthubert) <[email protected]>: > 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]> > 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 > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
