Subject: [babel] A babel service code

From: Dave Taht <[email-masked]>
Date: Fri, 14 Apr 2017 17:57:57 -0700

As I've tried to demonstrate in the earlier thread, I think a simple
direct map of a babel "TOS" to the DSCP tos is hopeless, as far more than
one dscp field is in common use, and different ones are used at the same
time for signalling and for data.

So.... as for AEs 7, 8, which include the "Tos" field:

Here's a semi-concrete counter proposal:

A) Map those 8 extra bits into something more abstract and useful than TOS,
call it a "BST" - babel service tag, which has bits defined for voice,
video, and whatnot, which then get mapped down to the appropriate set of
dscp-enabled services.

or:

B) Drop the notion of specific AE numbers including a "TOS" or "BST",
and add a TLV with the notion of a "tag" or "label" describing the desired
and/or available service characteristics on that route.

Of the two, I prefer B. 

And I'd imagine that generally it would only be used on a very few
gateways advertising specific services, and thus propagated minimally 
through the protocol.

Either way, one code would then map to as many actual tos values in
the routing table as needed.

(... or make suitable modifications to how a given metric is calculated
which is a bit fuzzier to me at the moment than I'd like )

Either way that "tag" seems to be a bunch of bits more expressive
than just tos.

...

In either case, there is a problem in defining the "fallback" characteristics
against a given "tag". Where you distinguish between "use this route for 
voice", and "this for data", and the data route is down, you can't get enough
dns/webrtc/whathaveyou to initiate the connection, in the first place.

So I think a soft preference, rather than hard, for the best route, is needed.

However there may be circumstances where "All lines are busy now", is an
appropriate response, that rather than provide bad service over a busy link.

And thus I do not define the format of that new sub-tlv "tag" today.

...

PS https://tools.ietf.org/html/draft-ietf-tsvwg-ieee-802-11-01 may also
be of interest.  the vlan priority field is arguably more often used
than dscp values and can be considered part of a packet as much, or -
actually - far more, than the dscp field, these days. Most switches, for
example, respect the vlan priority field, out of the box, and have to be
configured specially to respect dscp. Presently, within modern networks,
you will see often see voice configured on it's own high priority vlan.

/me dons flame retardant clothing