Hi Yvonne-Anne,
Thanks for re-initiating this topic and for stressing the need for
6tisch to address emergency/alarm conditions that occur in industry
environments. In some sense your inputs have reinforced what I expressed
in my earlier mail.
From your mail it appears that there could arise situations where the
network is expected to respond to application's reaction to exceptions
by way of allocating network resources in a timely manner, and the
amount of bandwidth required may be substantially more than the normal
conditions. Finally, there is a need to satisfy deterministic
expectations by 6tisch mechanism.
To meet all the above requirements simultaneously, perhaps there is a
need for combining OTF with RSVP to create emergency flows on-the-fly
that ensure end-to-end bandwidth guarantees till such a condition
subsides. In this far fetching ? Hopefully not.
Anand
On 29/06/2015 15:00, Yvonne-Anne Pignolet wrote:
Dear all
Taking up some remarks by Anand and Pascal, has there been any recent activity
w ith 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 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
--
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
