I've attached a cheat-sheet (view/print with monospace font).
There is a little bit of historical context that's useful to understand
ToS, though. For example, Michael shows that some flows have ToS 2. That
could either be an antique "min-montetary-cost" host or, more likely,
a modern ECN-compliant host.
ECN (RFC 3168) is an emerging issue for traditional netflow collection
and processing. The jist of ECN is that an intermediary router can,
after sensing congestion, change the lower two bits of ToS to indicate
congestion so that the hosts can slow themselves down. It's a L3
implementation of frame-relay FECN, essentially. Unfortunately, since
the ToS field changes packet-to-packet and hop-to-hop, it also disrupts
the traditional netflow 7-tuplet key (protocol, src/dst IP, src/dst port,
ToS, input interface).
If you can, exclude ToS as a flow key on your netflow sources. Recent
cisco IOS versions let you do this with flexible netflow while still
exporting netflow v5.
-Craig
On Sat, 5 Dec 2009, [email protected] wrote:
> > Various flow-stat and flow-report output include Type of Service
> > reports. I'm finally on a network where we use ToS, and I need to
> > make sense of the results.
> >
> > Can anyone point me to any documentation on the ToS values flow-tools
> > reports? How can I map these results to, say, DSCP? Here's a snippet
> > of flow-stat output for reference:
>
> There's no magic here. ToS is the whole 8 bit ToS field. Divide by 4
> (or right shift 2) to get DSCP, since DSCP is the 6 most significant
> bits of the ToS field.
>
> Steinar Haug, Nethelp consulting, [email protected]
> _______________________________________________
> Flow-tools mailing list
> [email protected]
> http://mailman.splintered.net/mailman/listinfo/flow-tools
>
**** Pre-1998
The IPv4 ToS byte was part of the original 1981 definition of Internet Protocol
in RFC 791, which specified a 3-bit precedence value and 3-bits of ToS
attributes. In the tables below, "tos" values refer to the entire byte. In
1992, RFC 1349 added a fourth ToS attribute.
0x80 0x40 0x20 0x10 0x08 0x04 0x02 0x01
+-----+-----+-----+-----+-----+-----+-----+-----+
| PRECEDENCE | TOS attributes | - |
+-----+-----+-----+-----+-----+-----+-----+-----+
PRECEDENCE TOS attributes
name dec tos bin name dec tos bin
network 7 224 111 min-delay 8 16 1000
internet 6 192 110 max-throughput 4 8 0100
critical 5 160 101 max-reliability 2 4 0010
flash-override 4 128 100 min-monetary-cost 1 2 0001
flash 3 96 011 normal 0 0 0000
immediate 2 64 010
priority 1 32 001
routine 0 0 000
**** Post-1998
RFC 2474 reworked the ToS as a 6-bit Differentiated Services Code Point (DSCP)
and, soon after, RFC 3168 allocated the lowest two bits for Error Congestion
Notification (ECN, an IP analogy of frame-relay FECN and ATM EFCI).
0x80 0x40 0x20 0x10 0x08 0x04 0x02 0x01
+-----+-----+-----+-----+-----+-----+-----+-----+
| DSCP | ECN |
+-----+-----+-----+-----+-----+-----+-----+-----+
DSCP
name dec tos binary name dec tos binary
AF11 10 40 001010 CS1 8 32 001000
AF12 12 48 001100 CS2 16 64 010000
AF13 14 56 001110 CS3 24 96 011000
AF21 18 72 010010 CS4 32 128 100000
AF22 20 80 010100 CS5 40 160 101000
AF23 22 88 010110 CS6 48 192 110000
AF31 26 104 011010 CS7 56 224 111000
AF32 28 112 011100 EF 46 184 101110
AF33 30 120 011110 default 0 0 000000
AF41 34 136 100010
AF42 36 144 100100 AF = assured forwarding
AF43 38 152 100110 EF = expedited forwarding
CS = class selector
ECN (unrelated to QoS)
00 Not-ECT Not ECN-Capable Transport
01 ECT(0) ECN-Capable Transport
10 ECT(1) ECN-Capable Transport
11 CE Congestion Experienced
**** Notes on interpreting the ToS byte
The two definitions are complimentary for the upper 3-bits. This is good, since
those three bits are often copied to/from the 3-bit class-of-service (CoS)
field of layer-2 802.1p frames and the 3-bit experimental (EXP) field of MPLS
frames. Bits 3-5, however, are fairly incompatible..
Thus, it's important not to oversimplify precedence/DSCP as a simple pecking
order. In reality, each unique precedence/DSCP value conveys a packet's
requirements for throughput, latency, and packet loss, three traits that are
somewhat at odds with each other. And, any value can be assigned to any
organizationally-unique purposes. For example,
* Packets with precedence 5 and/or DSCP EF are often serviced by priority
queues, so they may delay packets with higher precedence/DSCP values.
* Within each AF level (e.g., AF2x includes AF21, AF22, and AF23), the
higher values indicate a higher tolerance to packet loss. I.e., a congested
interface should drop AF22 packets earlier than AF21 packets. In Cisco IOS,
this behavior is implemented with DiffServ-complaint WRED ('random-detect dscp'
on a class-map).
* Any DSCP value under CS6 can be assigned for any organizationally-unique
use. For example, Precedence 1/DSCP CS1 is often assigned for use as a
less-than-best-effort class called scavenger. To successfully implement the
scavenger class, all network devices must agree to treat CS1 traffic worse than
Precedence 0/DSCP default.
_______________________________________________
Flow-tools mailing list
[email protected]
http://mailman.splintered.net/mailman/listinfo/flow-tools
