Re: [Hist Trivia] IP Protocol Layers

End-to-End Transparent Transport of the IPv4 TOS field would seem to be
a fundamental given for IPv4. It is an 8-bit field and what goes in should
come
out on the other end, unchanged. In my opinion, people and companies should
check with the carriers that they connect to, in order to make sure that the
TOS
field is transported unchanged. Assuming it is, then splitting that 8-bit
field into
two symmetric 4-bit fields allows the entire IPv4 Internet Address Space to
be
increased by a factor of x16. All of the major carriers seem to be willing
to go
on record as saying that they DO NOT CHANGE the TOS field. That seems to
be a start, at ending what some would consider to be "layer violations".

http://www1.ietf.org/mail-archive/ietf/Current/msg12713.html
RFC-2001-07-11-000 IPv4+ and Testing of TOS Routing on New.Net Transport

Jim Fleming
http://www.unir.com/images/architech.gif
http://www.unir.com/images/address.gif
http://www.unir.com/images/headers.gif
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt
http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp
http://www.ietf.org/mail-archive/ietf/Current/msg12213.html
http://www.ietf.org/mail-archive/ietf/Current/msg12223.html

----- Original Message -----
From: "Brian E Carpenter" <brian(_at_)hursley(_dot_)ibm(_dot_)com>
To: "Mahadevan Iyer" <miyer(_at_)ece(_dot_)uci(_dot_)edu>
Cc: "ietf" <ietf(_at_)ietf(_dot_)org>
Sent: Thursday, July 19, 2001 2:26 PM
Subject: Re: [Hist Trivia] IP Protocol Layers


> Interestingly enough, when we wrote RFC 1958 "Architectural principles
> of the Internet", nobody suggested "layer violation is evil" as a
> principle. The arguments against layer violation tend to be pragmatic -
> certain types of layer violation (such as "content based routing")
> could lead to complex failure modes - others (such as diffserv peeking)
> are probably safe. It certainly shouldn't be a religious principle.
>
>    Brian
>
> Mahadevan Iyer wrote:
> > Jon Crowcroft wrote:
> >
> > > In message <v04220802b77bde136984(_at_)[10(_dot_)83(_dot_)97(_dot_)216]>, 
> > > Steve Deering
typed:
> > >  >>We used to use "gateway" instead of "router" (and a few still do),
and
> > > i lik the fact that if you type getaway by mistake you get what people
> > > are trying to do when they are routed ...
> > >
> > > i also like the fact that MOST fancy things we do in traffic treatment
> > > (firewall, diff/int serv, header compression, checksum) ignore this
> > > layering rubbish idea and look at the whole packet and the whole state
> > > of the systems where you need to......
> > I always thought peeking into other layer headers to make better
decisions
> > doesn't always destroy layering. It's when the implementation gets tied
to a
> > specific other-layer technology,  or it *writes* into other layer
headers, or
> > performs 'designated' other-layer functions, that layering is destroyed.
> >
> > Say, a diff serv implementation that tries to figure out what kind of
lower
> > layer protocol is present and if it succeeds in doing so, uses the lower
layer
> > information to make forwarding decisions, is not really destroying
layering,
> > is it.
> > I can still deploy this diff serv implementation readily over all kinds
of
> > lower layer 'technologies' or standards, because it is not tied to any
> > specific such technology. If it can recognise the lower layer
technology, it
> > uses that extra lower layer information to try improve performance,
otherwise
> > it just performs default operations. So for example, I can still easily
> > transfer such an implementation from a wired-ethernet to some wireless
> > standard without any rework. Now, isn't *that* kind of layering good? Or
am I
> > missing something.