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 protected]>:
> 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
>
--
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
_______________________________________________
6tisch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6tisch
