ToS
Click on the red underlined text to get to the source
... tradeoffs should be made for the particular packet. This facility is
the "Type of Service" facility, abbreviated as the "TOS facility" in
this memo.
...
... this memo.
Although the TOS facility has been a part of the IP specification
since the beginning, it has been little used in the past. However,
...
... 2] now mandates that hosts use the
TOS facility. Additionally, routing protocols (including OSPF [10 ...
... hosts and routers use the
TOS facility. Section 2 introduces the primary considerations that
motivated the design choices in this specification. Sections 3 and 4
describe the Type of Service ...
... Type of Service octet in the IP header and the values
which the TOS field of that octet may contain. Section 5 describes
how a host (or router ...
... host (or router) chooses appropriate values to insert into the
TOS fields of the IP datagrams it originates. Sections 6 and 7
describe the ICMP Destination ...
... ICMP Destination Unreachable and Redirect messages and
how TOS affects path choice by both hosts and routers. Section 8
...
... hosts and routers. Section 8
describes some additional ways in which TOS may optionally affect
packet processing. Appendix A describes how this specification
...
... The fundamental rule that guided this specification is that a host
should never be penalized for using the TOS facility. If a host
makes appropriate use of the TOS ...
... TOS facility. If a host
makes appropriate use of the TOS facility, its network service should
be at least as good as (and hopefully better than) it would have been
...
... respects, would ever become widely deployed and used. A particular
consequence of this goal is that if a network cannot provide the TOS
requested in a packet, the network does not discard the packet but
...
... network does not discard the packet but
instead delivers it the same way it would have been delivered had
none of the TOS bits been set.
...
... bits been set.
Even though the 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 ...
... hosts and routers which implement the
specifications of this memo, since TOS support is almost non-existent
in routers which predate this specification. However, this memo does
...
... routers which predate this specification. However, this memo does
attempt to be compatible with the treatment of IP TOS in OSPF and
Integrated IS-IS ...
... Because the Internet community does not have much experience with
TOS, it is important that this specification allow easy definition
and deployment of new and experimental ...
... types of service. This goal
has had a significant impact on this specification. In particular,
it led to the decision to fix permanently the size of the TOS field
and to the decision that hosts and routers ...
... +-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| PRECEDENCE | TOS | MBZ |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
...
... discussed in detail in this memo.
The second field, labeled "TOS" above, denotes how the network should
...
... throughput, delay, reliability, and cost. The
TOS field is the primary topic of this memo.
The last field, labeled "MBZ" (for "must be zero") above, is
...
... fragmentation.
In the past there has been some confusion about the size of the TOS
field. RFC-791std5 defined it as a three bit ...
... 1122std3
added bits 6 and 7 to the TOS field, eliminating the MBZ field. This
memo redefines the TOS field to be the four bits ...
... bits 6 and 7 to the TOS field, eliminating the MBZ field. This
memo redefines the TOS field to be the four bits shown in the figure
above. The reasons for choosing to make the TOS ...
... TOS field to be the four bits shown in the figure
above. The reasons for choosing to make the TOS field four bits wide
can be found in Appendix B.2.
...
... Specification of the TOS Field ...
...
As was stated just above, this memo redefines the TOS field as a four
bit field. Also contrary to RFC-791std5 ...
... bit field. Also contrary to RFC-791std5, this memo defines the TOS field
as a single enumerated value rather than as a set of bits (where each
...
... bit has its own meaning). This memo defines the semantics of the
following TOS field values (expressed as binary numbers):
1000 -- minimize delay
...
... service
The values used in the TOS field are referred to in this memo as "TOS
values", and the value of the TOS ...
...
The values used in the TOS field are referred to in this memo as "TOS
values", and the value of the TOS field of an IP packet ...
... TOS field are referred to in this memo as "TOS
values", and the value of the TOS field of an IP packet is referred
to in this memo as the "requested TOS ...
... TOS field of an IP packet is referred
to in this memo as the "requested TOS". The TOS field value 0000 is
referred to in this memo as the "default TOS ...
... IP packet is referred
to in this memo as the "requested TOS". The TOS field value 0000 is
referred to in this memo as the "default TOS."
...
... TOS". The TOS field value 0000 is
referred to in this memo as the "default TOS."
Because this specification redefines TOS ...
... TOS."
Because this specification redefines TOS values to be integers rather
than sets of bits, computing the logical OR ...
... than sets of bits, computing the logical OR of two TOS values is no
longer meaningful. For example, it would be a serious error for a
router ...
... longer meaningful. For example, it would be a serious error for a
router to choose a low delay path for a packet whose requested TOS
was 1110 simply because the router noted that the former "delay bit ...
... Although the semantics of values other than the five listed above are
not defined by this memo, they are perfectly legal TOS values, and
hosts and routers ...
... routers must not preclude their use in any way. As will
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
...
... router need not (and
except as described in Section 8 should not) make any distinction
between TOS values whose semantics are defined by this memo and those
that are not.
...
...
It is important to note the use of the words "minimize" and
"maximize" in the definitions of values for the TOS field. For
example, setting the TOS field to 1000 (minimize delay) does not
...
... "maximize" in the definitions of values for the TOS field. For
example, setting the TOS field to 1000 (minimize delay) does not
guarantee that the path taken by the datagram will have a delay that
...
... behavior through creative use of routing metrics, but this is
strongly discouraged: setting the TOS field is intended to give
better service when it is available, rather than to deny service ...
... Use of the TOS Field in the Internet Protocols ...
...
For the TOS facility to be useful, the TOS fields in IP packets must
be filled in with reasonable values. This section discusses how
...
... section describes how a host or router chooses appropriate TOS
values for ICMP messages it originates. The TOS ...
... TOS
values for ICMP messages it originates. The TOS facility also
affects the origination and processing of ICMP Redirects and ICMP
Destination ...
... An ICMP request message may be sent with any value in the TOS
field. A mechanism to allow the user to specify the TOS value to
...
... request message may be sent with any value in the TOS
field. A mechanism to allow the user to specify the TOS value to
be used would be a useful feature in many applications that
generate ICMP ...
... An ICMP reply message is sent with the same value in the TOS field
as was used in the corresponding ICMP request message ...
... When sending a datagram, a transport protocol uses the TOS
requested by the application. There is no requirement that both
...
... requirement that both
ends of a transport connection use the same TOS. For example, the
sending side of a bulk data transfer application should request
...
... transport protocol to provide applications with a mechanism for
learning the value of the TOS field that accompanied the most
recently received data.
...
...
It is quite permissible to switch to a different TOS in the middle
of a connection if the nature of the traffic ...
...
Applications are responsible for choosing appropriate TOS values
for any traffic they originate. The Assigned Numbers document
...
... traffic they originate. The Assigned Numbers document
[15] lists the TOS values to be used by a number of common network
applications. For other applications, it is the responsibility of
...
... and desirable for other applications, that the user of the
application be able to override the TOS value(s) which the
application would otherwise choose.
...
... ICMP
protocol [12]. This section describes how support for the TOS
facility affects the origination and interpretation of ICMP Redirect
messages ...
... network or host) would have been
reachable had a different TOS value been specified. A router
generates a code 0 or code 1 Destination ...
... The use of codes 11 and 12 may seem contrary to the statement in
Section 2 that packets should not be discarded simply because the
requested TOS cannot be provided. The rationale for having these
codes and the limited cases in which they are expected to be used
are described in Appendix B.5.
...
... router generates a code 3 Redirect when the Redirect applies
only to IP packets which request a particular TOS value. A router
generates a code 1 Redirect instead when the the optimal next hop ...
... next hop
on the path to the destination would be the same for any TOS
value. In order to minimize the potential for host confusion,
...
... Both hosts and routers should consider the value of the TOS field of
a datagram when choosing an appropriate path to get the datagram ...
... section.
Whether a packet's TOS value actually affects the path it takes
inside of a particular routing domain ...
... sufficiently homogeneous in nature that there is no reason for
routers to choose different paths based up the TOS field in a
datagram. Inside such a routing ...
... routing database and of routing
protocol updates by only defining routes for the default (0000) TOS.
Neither hosts nor routers ...
... hosts nor routers should need to have any explicit knowledge
of whether TOS affects routing in the local routing domain ...
... ICMP Redirects apply only to
IP packets which request a particular TOS. Thus, a host (at least
conceptually) needs to store two types of entries in its route
cache ...
... route
cache for a type 1 entry whose destination matches the destination
address of the packet and whose TOS matches the requested TOS in
the packet. If it doesn't find one, the host ...
... destination matches the destination
address of the packet and whose TOS matches the requested TOS in
the packet. If it doesn't find one, the host searches its route
cache ...
... override the type 2 entry for packets whose destination address
and requested TOS match the type 1 entry. Because the type 2
entry may well specify the correct router for some TOS ...
... TOS match the type 1 entry. Because the type 2
entry may well specify the correct router for some TOS values
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
...
... traffic if the host
sends packets with a variety of requested TOS's to a destination
for which the host ...
... host should use the same router regardless of the
requested TOS. There is not yet sufficient experience with the
TOS facility to know whether that disadvantage would be serious
...
... requested TOS. There is not yet sufficient experience with the
TOS facility to know whether that disadvantage would be serious
enough in practice to outweigh the simplicity of this approach.
...
... router in the Internet should be able to consider the value of
the TOS field when choosing an appropriate path over which to
forward an IP packet. How a router ...
...
A router associates a TOS value with each route in its forwarding
table. The value can be any of the possible values of the TOS ...
... TOS value with each route in its forwarding
table. The value can be any of the possible values of the TOS
field in an IP datagram (including those values whose semantics ...
... semantics
are yet to be defined). Any routes learned using routing
protocols which support TOS are assigned appropriate TOS value by
those protocols. Routes learned using other routing protocols ...
... are yet to be defined). Any routes learned using routing
protocols which support TOS are assigned appropriate TOS value by
those protocols. Routes learned using other routing protocols are
...
... those protocols. Routes learned using other routing protocols are
always assigned the default TOS value (0000). Static routes have
their TOS values assigned by the network manager ...
... always assigned the default TOS value (0000). Static routes have
their TOS values assigned by the network manager.
...
... unreachable), or it may contain one or more routes to the
destination. If the set is not empty, the TOS values of the
routes in the set are examined. If the set contains a route whose
...
... routes in the set are examined. If the set contains a route whose
TOS exactly matches the TOS field of the packet being forwarded
then that route ...
... route whose
TOS exactly matches the TOS field of the packet being forwarded
then that route is chosen. If not but the set contains a route ...
... route is chosen. If not but the set contains a route
with the default TOS then that route is chosen.
...
... route to the destination exists which has a different TOS value
and a non-infinite metric then code 11 (Network unreachable for
...
... Other consequences of TOS ...
... the network, but an implementor may choose to have TOS also affect
other aspects of how the datagram is handled. For example, a host ...
... Link Layer a quality of service as close as
possible to the one requested in the TOS field in the IP header.
Long ago an attempt (RFC-795 ...
... RFC-1060(-> 1340(-> 1700hist(-> 3232))) [15] describes the old interpretation of the TOS field
(as three independent bits, with no way to specify that monetary
...
... data transfer protocols (e.g., rcp).
(3) If the implementation does not support changing the TOS
during the lifetime of the connection ...
... lifetime of the connection, then the
recommended TOS on opening the connection is the default
TOS ...
... ICMP request messages are normally sent with the
default TOS, there are sometimes good reasons why they
would be sent with some other TOS value. An ICMP ...
... default TOS, there are sometimes good reasons why they
would be sent with some other TOS value. An ICMP response
always uses the same TOS ...
... TOS value. An ICMP response
always uses the same TOS value as was used in the
corresponding ICMP request message ...
... bits wide.
The requirements that refer to the TOS field should refer
only to the four bits that make up the TOS ...
... TOS field should refer
only to the four bits that make up the TOS field.
(2) An application may set bit ...
...
(2) An application may set bit 6 of the TOS octet to a non-zero
value (but still must not set bit ...
... route a
particular IP packet is determined by the TOS field in the packet.
This is described in detail in section 3.5 of RFC-1195prop [7 ...
... 7].
The mapping from the value of the TOS field to an appropriate
Integrated IS-IS metric is described by a table in that section.
...
... substantially compatible with Integrated IS-IS, the extension of
the TOS field to four bits and the addition of a TOS value
...
... the TOS field to four bits and the addition of a TOS value
requesting "minimize monetary cost" require minor modifications to
that table, as shown here:
...
... Although the specification in this memo is intended to be
substantially compatible with OSPF, the extension of the TOS field
to four bits requires minor modifications to the section that
...
... bits requires minor modifications to the section that
describes the encoding of TOS values in Link State Advertisements,
described in section 12.3 of RFC-1247(-> 1583(-> 2178(-> 2328std54))) ...
... version of table 17. The numbers in the first column are decimal
integers, and the numbers in the second column are binary TOS
values:
...
... 5], is entirely consistent
with this memo except for the textual comment which describes the
mapping of the old TOS flag bits into TOSType values. TOSType
values use the same encoding ...
... flag bits into TOSType values. TOSType
values use the same encoding of TOS values as OSPF's Link State
Advertisements do, so the above table also describes the mapping
...
... OSPF's Link State
Advertisements do, so the above table also describes the mapping
between TOSType values (the first column) and TOS field values
(the second column).
...
...
The main body of this memo has described the details of how TOS
facility works. This appendix is for those who wonder why it works
that way.
...
... Much of what is in this document can be explained by the simple fact
that the goal of this document is to provide a clear and complete
specification of the existing TOS facility rather than to design from
scratch a new quality of service mechanism for IP ...
... discussed below, the desirability of compatibility with existing
specifications and uses of the TOS facility [1,2,7 ...
... 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
widely deployed. The second was that the specification should make
...
... B.1 The Minimize Monetary Cost TOS Value ...
... Router Requirements Working
Group felt it would be important to have a TOS value which would
allow a user to declare that monetary cost was more important than
other qualities of the service ...
...
There was considerable debate over what exactly this value should
mean. Some felt, for example, that the TOS value should mean
"must not cost money". This was rejected for several reasons.
Because it would request a particular level of service ...
... service attribute be
minimized or maximized, it would not only philosophically at odds
with the other TOS values but would require special code in both
hosts and routers ...
... routing decisions.
Some proposed a slight variant: a TOS value which would mean "I am
willing to pay money to have this packet delivered". This
proposal suffers most of the same shortcomings as the previous one
...
... the algorithms specified in Section 7.2, any packet which used
this TOS value would prefer links that cost money over equally
good free links ...
... links that cost money over equally
good free links. Thus, such a TOS value would almost be
equivalent to a "maximize monetary cost" value!
...
... IP option
could include parameters such as the maximum amount the user was
willing to pay. Thus, the TOS value defined in this memo merely
requests that the network "minimize monetary cost".
...
... B.2 The Specification of the TOS Field ...
... There were four goals that guided the decision to have a four bit
TOS field and the specification of that field's values:
(1) To define a new type of service ...
...
(2) To remain as compatible as possible with existing
specifications and uses of the TOS facility
(3) To allow for the definition and deployment ...
... types of
service in the future
(4) To permanently fix the size of the TOS field
The last goal may seem surprising, but turns out to be necessary
...
... deployed. If routers have different ideas about the size of the
TOS field they make inconsistent decisions that may lead to
routing loops.
...
... reserved bits in the IP header. The obvious way to do
that was to change the interpretation of TOS values so that they
were integers rather than independently settable bits.
...
... bit definitions
found in RFC-791std5. Thus, for example, setting the TOS field to
1000 (minimize delay) sets bit 3 of the Type of Service ...
... RFC-791std5 bits, since setting multiple TOS bits does not seem to be
a common practice. According to [15 ...
... 15], none of the common TCP/IP
applications currently set multiple TOS bits. However, TOS values
...
... applications currently set multiple TOS bits. However, TOS values
corresponding to particular combinations of the RFC-791std5 bits ...
... be defined if and when they are determined to be useful.
The new TOS value for "minimize monetary cost" needed to be one
which would not be too terribly misconstrued by preexisting
implementations. This seemed to imply that the value should be
...
... 791std5 bits clear. That would require
expanding the TOS field, but would allow old implementations to
treat packets which request minimization of monetary cost (TOS
...
... expanding the TOS field, but would allow old implementations to
treat packets which request minimization of monetary cost (TOS
0001) as if they had requested the default TOS. This is not a
...
... treat packets which request minimization of monetary cost (TOS
0001) as if they had requested the default TOS. This is not a
perfect solution since (as described above) changing the size of
the TOS ...
... TOS. This is not a
perfect solution since (as described above) changing the size of
the TOS field could cause routing loops if some routers were to
...
... route
based on a four bit TOS field. Fortunately, this should not be
much of a problem in practice because routers which route ...
... route based on
a three bit TOS field are very rare as this is being written and
will only become more so once this specification is published.
...
...
Because of those considerations, and also in order to allow a
reasonable number of TOS values for future definition, it seemed
desirable to expand the TOS field. That left the question of how
...
... reasonable number of TOS values for future definition, it seemed
desirable to expand the TOS field. That left the question of how
much to expand it. Expanding it to five bits would allow
...
... much to expand it. Expanding it to five bits would allow
considerable future expansion (27 new TOS values) and would be
consistent with Host Requirements ...
... number of reserved bits in the IP header. Expanding the TOS field
to four bits would restrict future expansion to more modest levels
...
... to four bits would restrict future expansion to more modest levels
(11 new TOS values), but would leave an additional IP header bit
...
... Working Group concluded that
a four bits wide TOS field allow enough values for future use and
that consistency with Host ...
... Host Requirements was inadequate
justification for unnecessarily increasing the size of the TOS
field.
...
... 4] describes three alternative ways
of routing based on the TOS field. Briefly, they are:
(1) Strong TOS ...
... a route may be used only if its TOS exactly matches the TOS
in the datagram being routed. If there is no route ...
... datagram being routed. If there is no route with the
requested TOS, the packet is discarded.
(2) Weak TOS ...
... like Strong TOS, except that a route with the default TOS
(0000) is used if there is no route that has the requested
...
... (0000) is used if there is no route that has the requested
TOS. If there is no route with either the requested TOS or
...
... TOS. If there is no route with either the requested TOS or
the default TOS, the packet is discarded.
...
... route with either the requested TOS or
the default TOS, the packet is discarded.
(3) Very Weak TOS ...
... TOS, except that a route with the numerically
smallest TOS is used if there is no route that has either the
requested TOS ...
... route that has either the
requested TOS or the default TOS.
This specification has adopted Weak TOS ...
... TOS.
Strong TOS was quickly rejected. Because it requires that each
router a packet traverses have a route ...
... router a packet traverses have a route with the requested TOS,
packets which requested non-zero TOS ...
... TOS,
packets which requested non-zero TOS values would have (at least
until the TOS facility becomes widely used) a high probability of
...
... non-zero TOS values would have (at least
until the TOS facility becomes widely used) a high probability of
being discarded as undeliverable. This violates the principle
(described in Section 2) that hosts ...
... TOS values.
The choice between Weak TOS and Very Weak TOS was not as
straightforward. Weak TOS ...
...
The choice between Weak TOS and Very Weak TOS was not as
straightforward. Weak TOS was chosen because it is slightly
...
... TOS and Very Weak TOS was not as
straightforward. Weak TOS was chosen because it is slightly
simpler to implement and because it is consistent with the OSPF ...
... and Integrated IS-IS specifications. In addition, many dislike
Very Weak TOS because its algorithm for choosing a route when none
...
... route when none
of the available routes have either the requested or the default
TOS cannot be justified by intuition (there is no reason to
believe that having a numerically smaller TOS makes a route ...
... TOS cannot be justified by intuition (there is no reason to
believe that having a numerically smaller TOS makes a route
better). Since a router ...
... router would need to understand the semantics of
all of the TOS values to make a more intelligent choice, there
seems to be no reasonable way to fix this particular deficiency of
Very Weak TOS ...
... TOS values to make a more intelligent choice, there
seems to be no reasonable way to fix this particular deficiency of
Very Weak TOS.
In practice it is expected that the choice between Weak TOS ...
... TOS.
In practice it is expected that the choice between Weak TOS and
Very Weak TOS will make little practical difference, since (except
...
... In practice it is expected that the choice between Weak TOS and
Very Weak TOS will make little practical difference, since (except
where the network manager has intentionally set things up
...
... network manager has intentionally set things up
otherwise) there will be a route with the default TOS to any
destination for which there is a route ...
...
An interesting issue is how early in the route choice process TOS
should be considered. There seem to be two obvious possibilities:
...
... destination
address of the packet. From among those, choose the route
which best matches the requested TOS.
(2) Find the set of routes that best match the requested TOS ...
... TOS.
(2) Find the set of routes that best match the requested TOS.
From among those, choose the route which best matches the
...
... network manager neglects some
pieces of the configuration the likely consequence is that some
packets which would benefit from TOS-specific routes will be
routed as if they had requested the default TOS. Under the second
...
... packets which would benefit from TOS-specific routes will be
routed as if they had requested the default TOS. Under the second
option, however, a network manager can easily (accidently)
...
... network manager can easily (accidently)
configure things in such a way that packets which request a
certain TOS and should be delivered locally will instead follow a
default route for that TOS ...
... TOS and should be delivered locally will instead follow a
default route for that TOS and be dumped into the Internet. Thus,
the first option would seem to have a slight edge ...
... under the second option it would not work to mix routers that
consider TOS and routers which do not in the same routing domain ...
... destination is considered to be unreachable even though a packet
to the same destination but requesting a different TOS would have
been deliverable. This would seem to fall perilously close to
violating the principle that hosts ...
... violating the principle that hosts should never be penalized for
requesting non-default TOS values in packets they originate.
This can happen in only three, somewhat unusual, cases:
...
... route to the packet's destination which has the
TOS value requested in the packet, but the route has an
infinite metric.
...
...
(2) The only routes to the packet's destination have TOS values
other than the one requested in the packet. One of them has
the default TOS ...
... TOS values
other than the one requested in the packet. One of them has
the default TOS, but it has an infinite metric.
(3) The only routes to the packet's destination ...
...
(3) The only routes to the packet's destination have TOS values
other than the one requested in the packet. None of them
have the default TOS ...
... TOS values
other than the one requested in the packet. None of them
have the default TOS.
It is commonly accepted that a router ...
...
Case (3) above is more problematic. It could have been avoided by
using Very Weak TOS, but that idea was rejected for the reasons
discussed in Appendix B.3. Some suggested that case (3) could be
fixed by relaxing longest match routing ...
... constraint that there must be a route with the default TOS to any
destination for which there is a route ...
... destination for which there is a route with a non-zero TOS, a
network manager would have to await the development of a new
...
... APPENDIX C. Limitations of the TOS Mechanism ...
...
It is important to note that the TOS facility has some limitations.
Some are consequences of engineering choices made in this
specification. Others, referred to as "inherent limitations" below,
...
... Some are consequences of engineering choices made in this
specification. Others, referred to as "inherent limitations" below,
could probably not have been avoided without either replacing the TOS
facility defined in RFC-791std5 or accepting that things wouldn't work
...
...
The most important of the inherent limitations is that the TOS
facility is strictly an advisory mechanism. It is not an
appropriate mechanism for requesting service ...
...
(1) Not all networks will consider the value of the TOS field
when deciding how to handle and route packets. Partly this
...
... will not be able to provide better service by considering the
value of the TOS field. For example, the best path through a
network composed of a homogeneous collection of
...
... network composed of a homogeneous collection of
interconnected LANs is probably the same for any possible TOS
value. Inside such a network, it would make little sense to
...
... routers and routing protocols to do the extra work
needed to consider the value of the TOS field when forwarding
packets.
...
... forwarding
packets.
(2) The TOS mechanism is not powerful enough to allow an
application to quantify the level of service it desires. For
...
... application to quantify the level of service it desires. For
example, an application may use the TOS field to request that
the network choose a path which maximizes throughput ...
...
There are a couple of additional limitations of the TOS facility
which are not inherent limitations but instead are consequences of
engineering choices made in this specification:
...
...
(1) Routing is not really optimal for some TOS values. This is
because optimal routing for those TOS ...
... TOS values. This is
because optimal routing for those TOS values would require
that routing protocols be cognizant of the semantics ...
... routing protocols be cognizant of the semantics of the
TOS values and use special algorithms to compute routes for
...
... routing protocols rather than of this specification,
this specification contributes to the problem by specifying
that there are a number of legal TOS values that have no
currently defined semantics.
...
... right thing". If a routing domain uses TOS, the network
manager must configure the routers in such a way that a
...
... network
manager must configure the routers in such a way that a
reasonable path is chosen for each TOS. While this ought not
to be terribly difficult, a network manager could accidently
...
... to be terribly difficult, a network manager could accidently
or intentionally violate our rule that using the TOS facility
should provide service at least as good as not using it.
...