mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Roland Dreier <roland@topspincom.com>
To: Ben Greear <greearb@candelatech.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Requesting clarification on IPTOS_* values w/regard to RFC-1349
Date: 13 Aug 2001 16:50:47 -0700	[thread overview]
Message-ID: <523d6vldt4.fsf@love-boat.topspincom.com> (raw)
In-Reply-To: <3B7862FD.BBDF0C51@candelatech.com>
In-Reply-To: Ben Greear's message of "Mon, 13 Aug 2001 16:30:05 -0700"

>>>>> "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



      reply	other threads:[~2001-08-13 23:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-08-13 23:30 Ben Greear
2001-08-13 23:50 ` Roland Dreier [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=523d6vldt4.fsf@love-boat.topspincom.com \
    --to=roland@topspincom.com \
    --cc=greearb@candelatech.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®