This is part 2 of a series on the ToS field of IP frames. Eventually I’ll get around to how it relates to NetFlow and sFlow.  🙂 Oh, and Part 1 is here.

ToS part 2
I’ve read some interesting posts on QoS from other companies in reference to NetFlow. The authors of those should read this blog post because calling DSCP or ToS the ‘QoS’ field in my opinion isn’t really a correct use of the acronym.  Silly, silly, silly…..   Anyway, in this blog I will take text largely from the RFC as I review RFC 1349 which covers how the Type of Service octet consists of three fields:

         0     1     2     3     4     5     6     7
      +-----+-----+-----+-----+-----+-----+-----+-----+
      |                 |                       |     |
      |   PRECEDENCE    |          TOS          | MBZ |
      |                 |                       |     |
      +-----+-----+-----+-----+-----+-----+-----+-----+

You’ll notice that the ToS field is now 4 bits and in the first blog it was 3 bits.  This RFC redefines the TOS facility field to be the four bits shown in the figure above.   I know this is confusing because this RFC talks about the 8 bit ToS octet and then on page 4 it talks about a 4 bit ToS field. Rrrrrrrr.  Hang in there!

ToS, T0S, TOS, I’m confused
REMEMBER: don’t commit this stuff to memory because it changes in the future and please don’t think of ToS as DSCP as this isn’t right either.  Today (i.e. 2009) ToS = 8 bits and DSCP = 6 bits (i.e. not the same) more on this in future blogs.   It doesn’t really matter right now because we are still talking about the history of this field and believe me, things change a few years later from what is displayed above.  Wikipedia uses ‘ToS’ RFC 1349 uses TOS.  Again, don’t get caught up in these darn acronyms.   We are working our way through 30 years of the evolution on this field.

PRECEDENCE
OK, back to topic: The first field, labeled “PRECEDENCE” above, is intended to denote the importance or priority of the datagram.  This field is not discussed in detail in this RFC.

TOS
The second field, labeled ‘TOS’ above, is a 4 bit facility that denotes how the network should make tradeoffs between throughput, delay, reliability, and cost.  Notice the last one ‘cost’ wasn’t part of the 1981 RFC 791.  Anyway, the TOS ‘facility’ field is the primary topic of this RFC.

MBZ
The last field, labeled “MBZ” (for “must be zero”) above, as of this RFC dated July of 1992 was unused.  The originator of a datagram sets this field to zero (unless participating in an Internet protocol experiment which makes use of that bit).  Routers and recipients of datagrams ignore the value of this field (remember: as of 1992).

The following TOS field values (expressed as binary numbers):

1000   —   minimize delay
0100   —   maximize throughput
0010   —   maximize reliability
0001   —   minimize monetary cost
0000   —   normal service

The binary “TOS values” above are considered the “requested TOS”.  Heh heh, ‘requested’ means it may not happen!  🙂  The TOS field value 0000 is referred to in this RFC as the “default TOS”.

Host setting ToS
When sending a datagram, a transport protocol uses the TOS requested by the application.  There is no requirement that both ends of a transport connection use the same TOS.  For example, the sending side of a bulk data transfer application should request that throughput be maximized, whereas the receiving side might request that delay be minimized (assuming that it is primarily sending small acknowledgment packets).

Router looking at ToS
A router in the Internet should be able to consider the value of the TOS field when choosing an appropriate path over which to forward an IP packet.  How a router does this is a part of the more general issue of how a router picks appropriate paths.

Routing logic in 1992 using ToS
When a router wants to forward a packet, it first looks up the destination address in its forwarding table.  This yields a set of candidate routes.  The set may be empty (if the destination is unreachable), or it may contain one or more routes to the destination.  If the set is not empty, the TOS values of the routes in the set are examined.  If the set contains a route whose TOS exactly matches the TOS field of the packet being forwarded then that route is chosen.  If not, but the set contains a route with the default TOS, then that route is chosen.

Summary
Are you bored to tears yet?  Well, hang in there and don’t fall in love with the format of the ToS field as it changes again in 1998!  It gets better in part 3 where I digress on Differentiated Services (aka DiffServ).

Mike Patterson author pic

Michael

Michael is one of the Co-founders and the former product manager for Scrutinizer. He enjoys many outdoor winter sports and often takes videos when he is snowmobiling, ice fishing or sledding with his kids. Cold weather and lots of snow make the best winters as far as he is concerned. Prior to starting Somix and Plixer, Mike worked in technical support at Cabletron Systems, acquired his Novell CNE and then moved to the training department for a few years. While in training he finished his Masters in Computer Information Systems from Southern New Hampshire University and then left technical training to pursue a new skill set in Professional Services. In 1998 he left the 'Tron' to start Somix which later became Plixer.

Related

Leave a Reply