host
Click on the red underlined text to get to the source
... since the beginning, it has been little used in the past. However,
the Internet host specification [1, 2] now mandates that hosts ...
... host specification [1, 2] now mandates that hosts use the
TOS facility. Additionally, routing protocols ...
... which the TOS field of that octet may contain. Section 5 describes
how a host (or router) chooses appropriate values to insert into the
TOS ...
... Redirect messages and
how TOS affects path choice by both hosts and routers. Section 8
describes some additional ways in which TOS ...
...
The fundamental rule that guided this specification is that a host
should never be penalized for using the TOS facility. If a host ...
... host
should never be penalized for using the TOS facility. If a host
makes appropriate use of the TOS facility, its network service ...
... be at least as good as (and hopefully better than) it would have been
if the host had not used the facility. This goal was considered
particularly important because it is unlikely that any specification
which did not meet this goal, no matter how good it might be in other
...
... TOS facility has not been widely used in the past, it
is a goal of this memo to be as compatible as possible with existing
practice. Primarily this means that existing host implementations
should not interact badly with hosts and routers ...
... practice. Primarily this means that existing host implementations
should not interact badly with hosts and routers which implement the
specifications of this memo, since TOS ...
... it led to the decision to fix permanently the size of the TOS field
and to the decision that hosts and routers should be able to handle a
new type of service ...
... not defined by this memo, they are perfectly legal TOS values, and
hosts and routers must not preclude their use in any way. As will
become clear after reading the remainder of this memo, only the
...
... become clear after reading the remainder of this memo, only the
default TOS is in any way special. A host or router need not (and
except as described in Section 8 should not) make any distinction
...
... 0 -- network unreachable
1 -- host unreachable
11 -- network unreachable for type of service ...
... when an unreachable destination (network or host) would have been
reachable had a different TOS value been specified. A router ...
... of these codes should recognize that it may result from a routing
transient. The host should therefore interpret the message as
only a hint, not proof, that the specified destination ...
... network
1 -- redirect datagrams for the host
2 -- redirect datagrams for the type of service ...
... destination would be the same for any TOS
value. In order to minimize the potential for host confusion,
routers should refrain from using codes 0 and 2 in Redirects
...
... Host specification [1] only requires
hosts to correctly handle code 0 and code 1 Redirects, a host
should also correctly handle code 2 and code 3 Redirects, as
...
... 1] only requires
hosts to correctly handle code 0 and code 1 Redirects, a host
should also correctly handle code 2 and code 3 Redirects, as
described in Section 7.1 of this memo. If a host ...
... host
should also correctly handle code 2 and code 3 Redirects, as
described in Section 7.1 of this memo. If a host does not, it is
better for the host to treat code 2 as equivalent to code 0 and
...
... described in Section 7.1 of this memo. If a host does not, it is
better for the host to treat code 2 as equivalent to code 0 and
code 3 as equivalent to code 1 than for the host to simply ignore
...
... better for the host to treat code 2 as equivalent to code 0 and
code 3 as equivalent to code 1 than for the host to simply ignore
code 2 and code 3 Redirects.
...
... routing
protocol updates by only defining routes for the default (0000) TOS.
Neither hosts nor routers should need to have any explicit knowledge
of whether TOS ...
... router to use to
reach that destination. The host learns the information stored in
its route cache through the ICMP ...
... its route cache through the ICMP Redirect mechanism. The host
learns the list of default routers either from static
...
... ICMP Router Discovery
mechanism [8]. When the host wishes to send an IP packet, it
searches its route cache ...
...
Adding support for the TOS facility changes the host routing
procedure only slightly. In the following, it is assumed that (in
...
... procedure only slightly. In the following, it is assumed that (in
accordance with the current Internet Host specification [1]) the
host ...
... Host specification [1]) the
host treats code 0 (redirect datagrams for the network) Redirects
...
... network) Redirects
as if they were code 1 (redirect datagrams for the host)
Redirects. Similarly, it is assumed that the host treats code 2
...
... datagrams for the host)
Redirects. Similarly, it is assumed that the host treats code 2
(redirect datagrams for the network ...
... type of service) Redirects
as if they were code 3 (redirect datagrams for the host and type
of service) Redirects. Readers considering violating these
assumptions should be aware that long and careful consideration of
...
... Redirect. Because these assumptions match the recommendations of
Internet Host specification, that careful consideration is beyond
the scope of this memo.
...
... IP packets which request a particular TOS. Thus, a host (at least
conceptually) needs to store two types of entries in its route
cache:
...
... code 0) Redirects.
When a host wants to send a packet, it first searches the route
cache for a type 1 entry whose destination matches the destination
address ...
... TOS matches the requested TOS in
the packet. If it doesn't find one, the host searches its route
cache again, this time looking for a type 2 entry whose
destination ...
... routers.
When a host creates (or updates) a type 2 entry, it must flush
from its route cache ...
... entries.
However, the converse is not true: when a host creates a type 1
entry, it should not flush a type 2 entry that has the same
...
... other than the one specified in the type 1 entry, saving the type
2 entry will likely cut down on the number of Redirects which the
host would otherwise receive. This savings can potentially be
substantial if one of the Redirects which was avoided would have
created ...
... TOS.
As an alternative, a host may treat all Redirects as if they were
code 3 (redirect datagrams for hosts ...
... host may treat all Redirects as if they were
code 3 (redirect datagrams for hosts and type of service)
Redirects. This alternative allows the host ...
... hosts and type of service)
Redirects. This alternative allows the host to have only type 1
route cache entries, thereby simplifying route ...
... the route cache and the amount of Redirect traffic if the host
sends packets with a variety of requested TOS's to a destination ...
... TOS's to a destination
for which the host should use the same router regardless of the
requested TOS ...
... routing protocol instead of by using the
mechanisms described above. Such hosts will need to follow the
procedures described in Section 7.2 (except of course that hosts
...
... mechanisms described above. Such hosts will need to follow the
procedures described in Section 7.2 (except of course that hosts
will not send ICMP Destination Unreachables or ICMP ...
... returned to the source. Normally, the Unreachable uses code 0
(Network unreachable) or 1 (Host unreachable). If, however, a
route to the destination ...
... Network unreachable for
type of service) or code 12 (Host unreachable for type of service)
must be used instead.
...
... TOS also affect
other aspects of how the datagram is handled. For example, a host or
router might choose to give preferential queuing on network ...
... Link Layer protocols have their own quality of
service mechanisms. When a router or host transmits an IP packet, it
might request from the Link Layer ...
...
These details will presumably be corrected in the next revision of
the Host Requirements specification, at which time this appendix
can be considered obsolete.
...
... Much of the rest of this specification was determined by two
additional goals, which were described more fully in Section 2. The
first was that hosts should never be penalized for using the TOS
facility, since that would likely ensure that it would never be
...
... with the other TOS values but would require special code in both
hosts and routers. Also, it would not be helpful to users who
want their packets to travel via the least-cost path but can
...
... considerable future expansion (27 new TOS values) and would be
consistent with Host Requirements, but would reduce to one the
number of reserved bits ...
... TOS field allow enough values for future use and
that consistency with Host Requirements was inadequate
justification for unnecessarily increasing the size of the TOS ...
... TOS facility becomes widely used) a high probability of
being discarded as undeliverable. This violates the principle
(described in Section 2) that hosts should not be penalized for
choosing non-zero TOS ...
... TOS would have
been deliverable. This would seem to fall perilously close to
violating the principle that hosts should never be penalized for
requesting non-default TOS values in packets they originate.
...
... Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts -- Communication Layers", RFC 1122std3, USC/Information Sciences Institute, October 1989. ...
... Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts -- Application and Support", RFC 1123std3, USC/Information Sciences Institute, October 1989. ...
... Working Group. Much of the
specification of the treatment of Type of Service by hosts is merely
a restatement of the ideas of the IETF's former Host ...
... hosts is merely
a restatement of the ideas of the IETF's former Host Requirements
Working Group ...