Subject: RE: LINK update

From: Vernon Schryver <[email-masked]>
Date: Thu, 5 Jul 2001 18:17:44 -0600 (MDT)

> From: Phillip Neumiller <[email-masked]>

> ...
> The MAC/LLC(link) should "respect" the TOS field in the IP header.
> To do this, the MAC/LLC(link) SHOULD be passed the IP packet and
> the TOS value (parsed out by the IP layer and handed to the MAC
> directly) upon a message send. ...

Why require that sort of thing instead of expecting what many link
layer drivers have done for 15 years, which is to look at the IP TOS
bits at the same time they look at other parts of the IP header to
encapsulate and otherwise contort IP datagrams to the idiosyncracies
of their wires?  Reasonable PPP and SLIP drivers have long paid
attention to interesting parts of the IP header, and sometimes even
parts of UDP adh TCP headers.

Layering is a useful and valuable tool, but a poor master or religion.

> ...
> In the opposite direction, when receiving IP packets from the link,
> the TOS field is part of the MAC frame so that inbound packet can
> be handled appropriately (for example if there is MAC layer
> forwarding, or different IP input queues for different TOSs).

What's wrong with peeking at the IP TOS (or DiffServ) field if you
need to do such things?  Why duplicate the IP TOS field somewhere in
the MAC bits outside the IP datagram?  Duplicating information is only
a certain method for generating confusion and bugs.

Besides, if you do care about layering, having a link-layer driver
fiddle with IP queues sounds like a layering violation.

Vernon Schryver    [email-masked]

---

From: Lloyd Wood <[email-masked]>
Date: Fri, 6 Jul 2001 18:48:26 +0100 (BST)

On Thu, 5 Jul 2001, Vernon Schryver wrote:

> the MAC bits outside the IP datagram? 

because the IP datagram is carried in more than one MAC frame, so you
don't have a choice? because the local meaning of the bits must be
translated into an approximate match that the MAC can
understand and support?

Doing 8-bit TOS/6-bit Diffserv depends on knowledge of local context
by the link, and that crawls all the way up the layers to wherever
that nebulous 'policy' jabberwocky sits..

L.

<[email-masked]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>