Subject: Re: [6tisch] 6tisch architecture and time-critical events

From: Thomas Watteyne <[email-masked]>
Date: Fri, 25 Sep 2015 12:25:23 +0200

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-masked]>
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-masked] <[email-masked]>]
> On Behalf Of Senju Panicker
> > Sent: Dienstag, 7. Juli 2015 15:14
> > To: [email-masked]
> > 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-masked] <[email-masked]>]
> On Behalf Of Yvonne-Anne Pignolet
> > Sent: 29 June 2015 15:00
> > To: [email-masked]
> > 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-masked]
> >
> >
> > 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-masked]
> > 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-masked]
> > 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-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Yvonne-Anne Pignolet <[email-masked]>
Date: Fri, 25 Sep 2015 13:04:24 +0000

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-masked]] On Behalf Of Thomas Watteyne
Sent: Freitag, 25. September 2015 12:25
To: [email-masked]
Subject: Re: [6tisch] 6tisch architecture and time-critical events

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-masked]<mailto:[email-masked]>> 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.

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-masked]] On Behalf Of Senju Panicker
> To: [email-masked]<mailto:[email-masked]>
> 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
> We are working towards deploying a complete 6tisch based network for monitoring
> combination of wired and wireless infrastructure. The wireless part is used for
> not-so-critical and routing monitoring activities, whereas wired infrastructure
> 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
> 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
> deviation in primary air temperature, primary air flow, mill inlet temperature
> or cold air inflow. The deviation in primary air temperature itself could be
> 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
> From: 6tisch [mailto:[email-masked]] On Behalf Of Yvonne-Anne Pignolet
> Sent: 29 June 2015 15:00
> To: [email-masked]<mailto:[email-masked]>
> 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.
>
> 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-masked]<mailto:[email-masked]>
>
>
> On Mon, Feb 16, 2015 at 6:39 PM, Pascal Thubert (pthubert) <pthubert at cisco.com<http://cisco.com>> wrote:
>>
>> A great thought, Anand,
>>
>>
>> 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.
>>
>> From: 6tisch [mailto:6tisch-bounces at ietf.org<http://ietf.org>] On Behalf Of
>> S.V.R.Anand
>> To: 6tisch at ietf.org<http://ietf.org>
>> I found that the architecture draft captured most of the general requirements.
>>
>> rest of the architecture. There could be application specific "time critical and sudden" events that might call for on-demand resource allocation.
>> 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
>
> [email-masked]<mailto:[email-masked]>
> intended recipient, please contact the sender by reply e-mail and destroy
> [email-masked]<mailto:[email-masked]>

--
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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: "S.V.R.Anand" <[email-masked]>
Date: Fri, 25 Sep 2015 21:16:14 +0530

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

>> > Dr. Sc. ETH ZÃ¼rich
>> > 5400 Baden-DÃ¤ttwil, Switzerland
>> > Phone: +41 58 586 86 56
>> > Mobile: +41 79 766 10 54
>> >> Sent: lundi 16 fÃ©vrier 2015 15:00
>> >> To: 6tisch at ietf.org
> dangerous content by MailScanner, and is
> believed to be clean.
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 28 Sep 2015 09:20:05 +0000

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-masked]] On Behalf Of Thomas Watteyne
Sent: vendredi 25 septembre 2015 12:25
To: [email-masked]
Subject: Re: [6tisch] 6tisch architecture and time-critical events

Thomas

Anand

---

From: Xavier Vilajosana <[email-masked]>
Date: Thu, 1 Oct 2015 08:32:50 +0200

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-masked]>:

> 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-masked]] *On Behalf Of *Thomas
> Watteyne
> *Sent:* vendredi 25 septembre 2015 12:25
>
> *To:* [email-masked]
> *Subject:* Re: [6tisch] 6tisch architecture and time-critical events
>
>
>
> 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:
>
> 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
>
>
>