Subject: [Ieprep] Use of ToS bits for "emergency" preferential treatment

From: [email-masked]
Date: Tue, 26 Nov 2002 20:04:58 EST

In a message dated 11/26/2002 4:50:34 PM Eastern Standard Time, 
[email-masked] writes:

> Note well that IP ToS bits are likely to be zero'd whilst transiting a 
> commercial
> backbone, so marking packets' ToS bits is unlikely to be a widely deployable
> approach.
> 

Perhaps you could comment on the applicability/correctness of the following 
requirement out of the DoD Joint Technical Architecture document:

"In addition, all implementations of IP must pass the 8-bit Type-of-Service
(TOS) byte transparently up and down through the transport layer
as defined in IETF Standard 3, Host Requirements."

Mike Pierce
Artel

---

From: Bill Woodcock <[email-masked]>
Date: Tue, 26 Nov 2002 17:40:33 -0800 (PST)

> as defined in IETF Standard 3, Host Requirements."

That's a host requirement, not a service provider requirement.

                                -Bill

_______________________________________________
Ieprep mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ieprep

---

From: Scott Bradner <[email-masked]>
Date: Tue, 26 Nov 2002 21:12:04 -0500 (EST)

> as defined in IETF Standard 3, Host Requirements."

OBE
	the 8-bit TOS field is no more
	6 bits are the differv DSCP (see RFC 2474)
	2 bits are ECN (see RFC 3168)

Scott

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 26 Nov 2002 21:22:56 -0500

On Tuesday, Nov 26, 2002, at 20:04 America/Montreal, [email-masked] 
wrote:
> Perhaps you could comment on the applicability/correctness of the 
> following requirement out of the DoD Joint Technical Architecture 
> document:
>

Standard 3 == {RFC-1122, RFC-1123} with some updates.

Parts of STD3 are in fact badly out of date.  Several parts of it are 
defunct,
but there has never been enough energy in IETF to revisit the documents.

I gather the quoted text is from the DoD JTA document, because I'm 
unable
to locate that text in either RFC-1122 or RFC-1123.  RFC-1122 Section 
3.2.1.6
might be related.  That part of RFC-1122 is definitely updated/modified 
by
the latest DiffServ specifications, since the DiffServ RFCs changed the 
semantics
of the bit values from the original (DoD-centric) values specified in 
RFC-791.

The quoted text (from JTA ?) appears (to me) to require that an 
implementation of
IPv4 inside a host must be able to receive a ToS byte value from 
TCP/UDP/SCTP/OSPF
for outbound packets and must be able to send a ToS byte value from IPv4
upwards to the applicable transport layer protocol (e.g. TCP, UDP, SCTP,
or OSPF[1]).

The quoted text does not appear to make any requirements on a router
or a network operator, as near as I can tell, since STD 3 is the
Host Requirements RFC (pair of RFCs really).

In practice, many host stacks don't have much support for 
application-layer
selection of IP ToS on outbound sessions/packets or for informing 
applications
about the IP ToS that is in use on received packets for those incoming
sessions.  Since the most common API in use is the BSD-style Sockets API
(which has numerous slightly different implementations), if this 
capability
is a matter of concern then the first place to check on host support
for IP ToS values likely would be the sockets(3) page in the 
programming manual
for the computer system in use.

I happen to use an Apple running MacOS X, which is a kind of UNIX (more 
precisely
a Mach 3.0 kernel + BSD-compatibility subsystem + 4.4 BSD network 
stack).
I checked the man page for setsockopt(2), which is used to set Socket 
options.
I'm unable to locate any way to either retrieve or set the IP ToS byte 
using
getsockopt()/setsockopt().  I also looked into 
/usr/include/sys/socket.h and
~/socketvar.h -- could not immediately find any way to set/retrieve the 
IP ToS
byte there either.  A quick check of a Solaris system seems to indicate 
that
they at least support setting IP ToS if one uses the XTI API.  Unclear 
to me
at quick glance whether their Sockets API support such.

Ran
[email-masked]

[1] OSPF is a routing protocol, but it sits directly on top of IP,
rather than on top of UDP, for historical reasons.  So it would need
to have the same capability to send an IP ToS byte down on packets
being sent out from the node.

---

From: RJ Atkinson <[email-masked]>
Date: Tue, 26 Nov 2002 22:02:12 -0500

On Tuesday, Nov 26, 2002, at 21:12 America/Montreal, Scott Bradner 
> 	2 bits are ECN (see RFC 3168)

Scott's comments are all true, where OBE == "Overtaken By Events".

Separately, at least some existing commercial IP routers can still be 
configured
to use the RFC-791 precedence bit settings.  And at least one router is 
still
available that supports the full RFC-791 IP ToS bit settings, including 
with IGP
support for ToS-based IP routing -- this last still has significantly 
deployment
by one US uniformed service for its WAN  tactical links, though I assume
that it is gradually fading away from the installed base of routers.

Many IP routers/L3 switches can be configured to set/clear/reset the IP 
ToS
or DiffServ byte, generally based on ACLs configured by the router 
administrator.
Of course, the details of the configuration method vary from vendor to 
vendor
and there are performance/other differences among various 
implementations.
The better L3 switches/routers can generally also map QoS values in 
either
direction between IP ToS bits and IEEE 802.1p precedence bits, 
honouring either
set of bits or the ACL for class based queuing inside the L3 
switch/router.

Ran