Requesting clarification on IPTOS_* values w/regard to RFC-1349

Requesting clarification on IPTOS_* values w/regard to RFC-1349

[Ben Greear]

I have a hard time believing that the kernel is wrong
on something so basic, but I cannot reconcile RFC-1349
with include/linux/ip.h

Here is the snippet from RFC-1349, found here:
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1349.html

****************************************************************************
3 Specification of the Type of Service Octet

    The TOS facility is one of the features of the Type of Service
    octet in the IP datagram header. The Type of Service
    octet consists of three fields: 

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

    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 memo. 
****************************************************************************


However, include/linux/ip.h defines the values as if RFC-1349 numbered
the bits backwards.  (It appears to me, for example, that the TOS_MASK
should be, in binary: 0111 1000, not 0001 1110 as ip.h shows.)

*************************************************
/* SOL_IP socket options */

#define IPTOS_TOS_MASK		0x1E
#define IPTOS_TOS(tos)		((tos)&IPTOS_TOS_MASK)
#define	IPTOS_LOWDELAY		0x10
#define	IPTOS_THROUGHPUT	0x08
#define	IPTOS_RELIABILITY	0x04
#define	IPTOS_MINCOST		0x02
*************************************************


Am I even more confused than normal, or is this really a problem?


Thanks,
Ben


-- 
Ben Greear <greearb@candelatech.com>          <Ben_Greear@excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: Requesting clarification on IPTOS_* values w/regard to RFC-1349

[Roland Dreier]

>>>>> "Ben" == Ben Greear <greearb@candelatech.com> writes:

    Ben> I have a hard time believing that the kernel is wrong on
    Ben> something so basic, but I cannot reconcile RFC-1349 with
    Ben> include/linux/ip.h

    Ben> Here is the snippet from RFC-1349, found here:
    Ben> http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc1349.html

****************************************************************************
3 Specification of the Type of Service Octet

    The TOS facility is one of the features of the Type of Service
    octet in the IP datagram header. The Type of Service
    octet consists of three fields: 

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

****************************************************************************


    Ben> However, include/linux/ip.h defines the values as if RFC-1349
    Ben> numbered the bits backwards.  (It appears to me, for example,
    Ben> that the TOS_MASK should be, in binary: 0111 1000, not 0001
    Ben> 1110 as ip.h shows.)

#define IPTOS_TOS_MASK		0x1E

Actually, this is correct.  The RFC shows bits inside an octect in
"network order".  In other words the high-order bit of an octect
appears at the left, just as the high-order octet of a word appears at
the left.  The way I always remember it is that network order writes
bits the way you would write a binary number by hand.

For further confirmation, you can see RFC 1122, which says:

  The "Type-of-Service" byte in the IP header is divided into two
  sections: the Precedence field (high-order 3 bits), and a field that
  is customarily called "Type-of-Service" or "TOS" (low-order 5 bits).
  In this document, all references to "TOS" or the "TOS field" refer
  to the low-order 5 bits only.

Roland