Skip to contentSkip to conversation

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

DISCUSSION Ben Greear 2 participants 2 messages Aug 13, 2001

lore
Share & tools
lore

Ben Greear

author
#0 lore raw

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

Signature · 3 lines
Ben Greear <[email protected]>          <[email protected]>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear
#1 lore raw
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

"Ben" == Ben Greear <[email protected]> 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