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

From: Yvonne-Anne Pignolet <[email-masked]>
Date: Mon, 29 Jun 2015 09:30:19 +0000

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 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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 30 Jun 2015 11:55:16 +0000

Hello Yvonne-Anne

Please see below

> 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?

2 things here
1) the schedule can be configured with some amount of Tracks designed for asynchronous control and alerting. The time slots will be opportunistically reused by best effort traffic to the same next hop if the flow is not present.
2) TSCH has the concept of priority. You can define a slotframe with a higher priority that you normally do not use, but if you do in emergency, it will have precedence.

> 
> 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.
> 

Well, if the usage is not deterministic and not programmed in advance, 6TiSCH adds RPL to the picture. I think that this boils down to an interaction with OTF whereby slots would be granted in emergency and opposed to waiting for a statistical impact. Adding Diego here...

Cheers

Pascal

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Tue, 30 Jun 2015 11:19:27 -0300

Yvonne-Anne:
                      As pointed out by Pascal on the former e-mail,
the On-The-Fly scheduling current draft dynamically allocates
bandwidth in a neighbour-to-neighbour basis, following a user-defined
and parametrizable embedded algorithm. I think this kind of solution
fits the requirements you initially mentioned.
You can check version 5 of the draft here:

https://datatracker.ietf.org/doc/draft-dujovne-6tisch-on-the-fly/

Comments are welcome.

Regards,

                                        Diego Dujovne

2015-06-30 8:55 GMT-03:00 Pascal Thubert (pthubert) <[email-masked]>:

> 1) the schedule can be configured with some amount of Tracks designed for
> asynchronous control and alerting. The time slots will be opportunistically
> reused by best effort traffic to the same next hop if the flow is not
> present.
> 2) TSCH has the concept of priority. You can define a slotframe with a
> higher priority that you normally do not use, but if you do in emergency,
> it will have precedence.
>
> >
> Well, if the usage is not deterministic and not programmed in advance,
> 6TiSCH adds RPL to the picture. I think that this boils down to an
> interaction with OTF whereby slots would be granted in emergency and
> opposed to waiting for a statistical impact. Adding Diego here...
>
>
> Cheers
>
> Pascal
>

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125