[6tsch] R: priority and priority

["Alfredo Grieco" <[e-mail]>]

Dear Thomas and all,
 
I think that the adoption of label switching approaches is totally
appropriate in this context and can help solving several issues, including
priority.
 
As a matter of fact, the label (as in MPLS) can encode many different
properties: priority, destination node, kind of application, and whatever we
want.
 
The point is we should adopt some lightweight label dissemination mechanism
for the LLN context, but I am sure that approaches based on RSVP (one among
others) could surely fit well.
 
Cheers
 
Alfredo
 
Da: [e-mail] [mailto:[e-mail]] Per conto di
Thomas Watteyne
Inviato: Friday, March 08, 2013 8:35 AM
A: IETF 6TSCH
Oggetto: [6tsch] priority and priority
 
All,
 
I believe that we have been discussing two different notions of priority:
- Packet Priority: Assuming an existing data flow in a network, some packets
are marked as "high priority", the rest as "low priority". All packets are
part of the same flow, but high priority packets are treated with more
urgency that low priority packets. This translates into a set of queuing
rules. This is the notion illustrated by Pascal in his "traffic lights in a
city" analogy (where high priority packets are police cars passing other
vehicles) and used in Qin's mux/i-mux.
- Flow Priority, which is slightly different. In a network, multiple classes
of traffic co-exist. This results in multiple data flows. Different data
flows have a different combination of destination, priority, bandwidth and
latency. A network-wide policy defines whether data flows are entirely
independent, or if some over-flowing is allowed. In TSCH, a flow translated
into a slotframe. In case of contention (e.g. at a given slot a mote can
send a packet from each flow), flow priority arbitrates which packet goes
first. Note that this is entirely within the TSCH spec.
 
These two definitions are complementary: different flows can exist in a
network, but inside a flow, some high priority packets can "pass" other
packets. The network policy defines how those two interact; e.g. a
highest-priority packet can be allowed to "jump" into another flow, if
needed.
 
We need to define how this materializes in a network. Here is a proposal:
 
Each data flow turns into a TSCH slotframe. The scheduling entity populates
the slots in the slotframe in such as way that the slots "point to" some
destination. In a typical case, slots in a slotframe are equivalent: to end
up at mote A, take any slot in slotframe 1. This allows us to use
label-switching approach, which I'm sure will pop up in some future draft.
We can end up with different slotframes for different destinations, or for
different types of traffic to the same destination.
 
Optionally, packets can contain some priority field (probably DSCP, as per
http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-recommendations-0
0?) which serves as the "high priority" marker. A policy then regulates how
this translates to queuing and flow equivalence rules.
 
DSCP can also be used by the higher layer to indicate to which flow this
packet pertains, and with what (optional) priority. Upon receiving a packet
from a higher layer, the 6tsch layer could inspect the DSCP and some set of
rules would tell him which flow to send it on. Once it is in a flow, the
full DSCP is not needed, and there is lots of opportunity to elide some
information while the packet is on the LLN. I'm hoping that Shitanshu a.o.
can help decide on the applicability of this.
 
Thomas