As per Relevance of the word specific, we have this rfc below:
Network Working Group P.
Request for Comments: 1349
Updates: RFCs 1248, 1247, 1195, July 1992
1123, 1122, 1060, 791
Type of Service in the Internet Protocol
Status of This
This document specifies an IAB standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" for the standardization state and
of this protocol. Distribution of this memo is unlimited
This memo changes and clarifies some aspects of the semantics of
Type of Service octet in the Internet Protocol (IP) header.
handling of IP Type of Service by both hosts and routers is
in some detail
This memo defines a new TOS value for requesting that the
minimize the monetary cost of transmitting a datagram. A number
additional new TOS values are reserved for future experimentation
standardization. The ability to request that transmission
optimized along multiple axes (previously accomplished by
multiple TOS bits simultaneously) is removed. Thus, for example,
single datagram can no longer request that the network
minimize delay and maximize throughput
In addition, there is a minor conflict between the Host
(RFC-1122 and RFC-1123) and a number of other standards
the sizes of the fields in the Type of Service octet. This
resolves that conflict
Table of
1. Introduction ............................................... 3
2. Goals and Philosophy ....................................... 3
3. Specification of the Type of Service Octet ................. 4
4. Specification of the TOS Field ............................. 5
Almquist [Page 1]
RFC 1349 Type of Service July 1992
5. Use of the TOS Field in the Internet Protocols ............. 6
5.1 Internet Control Message Protocol (ICMP) ............... 6
5.2 Transport Protocols .................................... 7
5.3 Application Protocols .................................. 7
6. ICMP and the TOS Facility .................................. 8
6.1 Destination Unreachable ................................ 8
6.2 Redirect ............................................... 9
7. Use of the TOS Field in Routing ............................ 9
7.1 Host Routing ........................................... 10
7.2 Forwarding ............................................. 12
8. Other consequences of TOS .................................. 13
APPENDIX A. Updates to Other Specifications ................... 14
A.1 RFC-792 (ICMP) ......................................... 14
A.2 RFC-1060 (Assigned Numbers) ............................ 14
A.3 RFC-1122 and RFC-1123 (Host Requirements) .............. 16
A.4 RFC-1195 (Integrated IS-IS) ............................ 16
A.5 RFC-1247 (OSPF) and RFC-1248 (OSPF MIB) ................ 17
APPENDIX B. Rationale ......................................... 18
B.1 The Minimize Monetary Cost TOS Value ................... 18
B.2 The Specification of the TOS Field ..................... 19
B.3 The Choice of Weak TOS Routing ......................... 21
B.4 The Retention of Longest Match Routing ................. 22
B.5 The Use of Destination Unreachable ..................... 23
APPENDIX C. Limitations of the TOS Mechanism .................. 24
C.1 Inherent Limitations ................................... 24
C.2 Limitations of this Specification ...................... 25
References ..................................................... 27
Acknowledgements ............................................... 28
Security Considerations ........................................ 28
Author's Address ............................................... 28
Almquist [Page 2]
RFC 1349 Type of Service July 1992
1.
Paths through the Internet vary widely in the quality of service
provide. Some paths are more reliable than others. Some impose
call setup or per-packet charges, while others do not do usage-
charging. Throughput and delay also vary widely. Often there
tradeoffs: the path that provides the highest throughput may well
be the one that provides the lowest delay or the lowest
cost. Therefore, the "optimal" path for a packet to follow
the Internet may depend on the needs of the application and its user
Because the Internet itself has no direct knowledge of how
optimize the path for a particular application or user, the
protocol [11] provides a (rather limited) facility for upper
protocols to convey hints to the Internet Layer about how
tradeoffs should be made for the particular packet. This facility
the "Type of Service" facility, abbreviated as the "TOS facility"
this memo
Although the TOS facility has been a part of the IP
since the beginning, it has been little used in the past. However
the Internet host specification [1,2] now mandates that hosts use
TOS facility. Additionally, routing protocols (including OSPF [10]
and Integrated IS-IS [7]) have been developed which can
routes separately for each type of service. These new
protocols make it practical for routers to consider the
type of service when making routing decisions
This specification defines in detail how hosts and routers use
TOS facility. Section 2 introduces the primary considerations
motivated the design choices in this specification. Sections 3 and 4
describe the Type of Service octet in the IP header and the
which the TOS field of that octet may contain. Section 5
how a host (or router) chooses appropriate values to insert into
TOS fields of the IP datagrams it originates. Sections 6 and 7
describe the ICMP Destination Unreachable and Redirect messages
how TOS affects path choice by both hosts and routers. Section 8
describes some additional ways in which TOS may optionally
packet processing. Appendix A describes how this
updates a number of existing specifications. Appendices B and
expand on the discussion in Section 2.
2. Goals and
The fundamental rule that guided this specification is that a
should never be penalized for using the TOS facility. If a
makes appropriate use of the TOS facility, its network service
be at least as good as (and hopefully better than) it would have
Almquist [Page 3]
RFC 1349 Type of Service July 1992
if the host had not used the facility. This goal was
particularly important because it is unlikely that any
which did not meet this goal, no matter how good it might be in
respects, would ever become widely deployed and used. A
consequence of this goal is that if a network cannot provide the
requested in a packet, the network does not discard the packet
instead delivers it the same way it would have been delivered
none of the TOS bits been set
Even though the TOS facility has not been widely used in the past,
is a goal of this memo to be as compatible as possible with
practice. Primarily this means that existing host
should not interact badly with hosts and routers which implement
specifications of this memo, since TOS support is almost non-
in routers which predate this specification. However, this memo
attempt to be compatible with the treatment of IP TOS in OSPF
Integrated IS-IS
Because the Internet community does not have much experience
TOS, it is important that this specification allow easy
and deployment of new and experimental types of service. This
has had a significant impact on this specification. In particular
it led to the decision to fix permanently the size of the TOS
and to the decision that hosts and routers should be able to handle
new type of service correctly without having to understand
semantics
Appendix B of this memo provides a more detailed explanation of
rationale behind particular aspects of this specification
3. Specification of the Type of Service
The TOS facility is one of the features of the Type of Service
in the IP datagram header. The Type of Service octet consists
three fields
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| | | |
| PRECEDENCE | TOS | MBZ |
| | | |
+-----+-----+-----+-----+-----+-----+-----+-----+
The first field, labeled "PRECEDENCE" above, is intended to
the importance or priority of the datagram. This field is
discussed in detail in this memo
The second field, labeled "TOS" above, denotes how the network
Almquist [Page 4]
RFC 1349 Type of Service July 1992
make tradeoffs between throughput, delay, reliability, and cost.
TOS field is the primary topic of this memo
The last field, labeled "MBZ" (for "must be zero") above,
currently unused. The originator of a datagram sets this field
zero (unless participating in an Internet protocol experiment
makes use of that bit). Routers and recipients of datagrams
the value of this field. This field is copied on fragmentation
In the past there has been some confusion about the size of the
field. RFC-791 defined it as a three bit field, including bits 3-5
in the figure above. It included bit 6 in the MBZ field. RFC-1122
added bits 6 and 7 to the TOS field, eliminating the MBZ field.
memo redefines the TOS field to be the four bits shown in the
above. The reasons for choosing to make the TOS field four bits
can be found in Appendix B.2.
4. Specification of the TOS
As was stated just above, this memo redefines the TOS field as a
bit field. Also contrary to RFC-791, this memo defines the TOS
as a single enumerated value rather than as a set of bits (where
bit has its own meaning). This memo defines the semantics of
following TOS field values (expressed as binary numbers):
1000 -- minimize
0100 -- maximize
0010 -- maximize
0001 -- minimize monetary
0000 -- normal
The values used in the TOS field are referred to in this memo as "
values", and the value of the TOS field of an IP packet is
to in this memo as the "requested TOS". The TOS field value 0000
referred to in this memo as the "default TOS."
Because this specification redefines TOS values to be integers
than sets of bits, computing the logical OR of two TOS values is
longer meaningful. For example, it would be a serious error for
router to choose a low delay path for a packet whose requested
was 1110 simply because the router noted that the former "delay bit
was set
Although the semantics of values other than the five listed above
not defined by this memo, they are perfectly legal TOS values,
hosts and routers must not preclude their use in any way. As
become clear after reading the remainder of this memo, only
default TOS is in any way special. A host or router need not (
Almquist [Page 5]
RFC 1349 Type of Service July 1992
except as described in Section 8 should not) make any
between TOS values whose semantics are defined by this memo and
that are not
It is important to note the use of the words "minimize"
"maximize" in the definitions of values for the TOS field.
example, setting the TOS field to 1000 (minimize delay) does
guarantee that the path taken by the datagram will have a delay
the user considers "low". The network will attempt to choose
lowest delay path available, based on its (often imperfect
information about path delay. The network will not discard
datagram simply because it believes that the delay of the
paths is "too high" (actually, the network manager can override
behavior through creative use of routing metrics, but this
strongly discouraged: setting the TOS field is intended to
better service when it is available, rather than to deny service
it is not).
5. Use of the TOS Field in the Internet
For the TOS facility to be useful, the TOS fields in IP packets
be filled in with reasonable values. This section discusses
protocols above IP choose appropriate values
5.1 Internet Control Message Protocol (ICMP
ICMP [8,9,12] defines a number of messages for performing
reporting and diagnostic functions for the Internet Layer.
section describes how a host or router chooses appropriate
values for ICMP messages it originates. The TOS facility
affects the origination and processing of ICMP Redirects and
Destination Unreachables, but that is the topic of Section 6.
For purposes of this discussion, it is useful to divide
messages into three classes
o ICMP error messages include ICMP message types 3 (
Unreachable), 4 (Source Quench), 5 (Redirect), 11 (
Exceeded), and 12 (Parameter Problem).
o ICMP request messages include ICMP message types 8 (Echo), 10
(Router Solicitation), 13 (Timestamp), 15 (
Request -- now obsolete), and 17 (Address Mask Request).
o ICMP reply messages include ICMP message types 0 (
Reply), 9 (Router Advertisement), 14 (Timestamp Reply), 16
(Information Reply -- also obsolete), and 18 (Address
Reply).
Almquist [Page 6]
RFC 1349 Type of Service July 1992
An ICMP error message is always sent with the default TOS (0000).
An ICMP request message may be sent with any value in the
field. A mechanism to allow the user to specify the TOS value
be used would be a useful feature in many applications
generate ICMP request messages
An ICMP reply message is sent with the same value in the TOS
as was used in the corresponding ICMP request message
5.2 Transport
When sending a datagram, a transport protocol uses the
requested by the application. There is no requirement that
ends of a transport connection use the same TOS. For example,
sending side of a bulk data transfer application should
that throughput be maximized, whereas the receiving side
request that delay be minimized (assuming that it is
sending small acknowledgement packets). It may be useful for
transport protocol to provide applications with a mechanism
learning the value of the TOS field that accompanied the
recently received data
It is quite permissible to switch to a different TOS in the
of a connection if the nature of the traffic being
changes. An example of this would be SMTP, which spends part
its time doing bulk data transfer and part of its time
short command messages and responses
TCP [13] should use the same TOS for datagrams containing only
control information as it does for datagrams which contain
data. Although it might seem intuitively correct to
request that the network minimize delay for segments
acknowledgements but no data, doing so could corrupt TCP's
trip time estimates
5.3 Application
Applications are responsible for choosing appropriate TOS
for any traffic they originate. The Assigned Numbers
[15] lists the TOS values to be used by a number of common
applications. For other applications, it is the responsibility
the application's designer or programmer to make a
choice, based on the nature of the traffic to be originated by
application
It is essential for many sorts of network diagnostic applications
and desirable for other applications, that the user of
Almquist [Page 7]
RFC 1349 Type of Service July 1992
application be able to override the TOS value(s) which
application would otherwise choose
The Assigned Numbers document is revised and
periodically. Until RFC-1060, the edition current as this
being written, has been superceded, readers should
Appendix A.2 of this memo
6. ICMP and the TOS
Routers communicate routing information to hosts using the
protocol [12]. This section describes how support for the
facility affects the origination and interpretation of ICMP
messages and certain types of ICMP Destination Unreachable messages
This memo does not define any new extensions to the ICMP protocol
6.1 Destination
The ICMP Destination Unreachable message contains a code
describes the reason that the destination is unreachable.
are four codes [1,12] which are particularly relevant to the
of this memo
0 -- network
1 -- host
11 -- network unreachable for type of
12 -- host unreachable for type of
A router generates a code 11 or code 12 Destination
when an unreachable destination (network or host) would have
reachable had a different TOS value been specified. A
generates a code 0 or code 1 Destination Unreachable in
cases
A host receiving a Destination Unreachable message containing
of these codes should recognize that it may result from a
transient. The host should therefore interpret the message
only a hint, not proof, that the specified destination
unreachable
The use of codes 11 and 12 may seem contrary to the statement
Section 2 that packets should not be discarded simply because
requested TOS cannot be provided. The rationale for having
codes and the limited cases in which they are expected to be
are described in Appendix B.5.
Almquist [Page 8]
RFC 1349 Type of Service July 1992
6.2
The ICMP Redirect message also includes a code, which
the class of datagrams to which the Redirect applies. There
currently four codes defined
0 -- redirect datagrams for the
1 -- redirect datagrams for the
2 -- redirect datagrams for the type of service and
3 -- redirect datagrams for the type of service and
A router generates a code 3 Redirect when the Redirect
only to IP packets which request a particular TOS value. A
generates a code 1 Redirect instead when the the optimal next
on the path to the destination would be the same for any
value. In order to minimize the potential for host confusion
routers should refrain from using codes 0 and 2 in
[3,6].
Although the current Internet Host specification [1] only
hosts to correctly handle code 0 and code 1 Redirects, a
should also correctly handle code 2 and code 3 Redirects,
described in Section 7.1 of this memo. If a host does not, it
better for the host to treat code 2 as equivalent to code 0
code 3 as equivalent to code 1 than for the host to simply
code 2 and code 3 Redirects
7. Use of the TOS Field in
Both hosts and routers should consider the value of the TOS field
a datagram when choosing an appropriate path to get the datagram
its destination. The mechanisms for doing so are discussed in
section
Whether a packet's TOS value actually affects the path it
inside of a particular routing domain is a choice made by the
domain's network manager. In many routing domains the paths
sufficiently homogeneous in nature that there is no reason
routers to choose different paths based up the TOS field in
datagram. Inside such a routing domain, the network manager
choose to limit the size of the routing database and of
protocol updates by only defining routes for the default (0000) TOS
Neither hosts nor routers should need to have any explicit
of whether TOS affects routing in the local routing domain
Almquist [Page 9]
RFC 1349 Type of Service July 1992
7.1 Host
When a host (which is not also a router) wishes to send an
packet to a destination on another network or subnet, it needs
choose an appropriate router to send the packet to. According
the IP Architecture, it does so by maintaining a route cache and
list of default routers. Each entry in the route cache lists
destination (IP address) and the appropriate router to use
reach that destination. The host learns the information stored
its route cache through the ICMP Redirect mechanism. The
learns the list of default routers either from
configuration information or by using the ICMP Router
mechanism [8]. When the host wishes to send an IP packet,
searches its route cache for a route matching the
address in the packet. If one is found it is used; if not,
packet is sent to one of the default routers. All of this
described in greater detail in section 3.3.1 of RFC-1122 [1].
Adding support for the TOS facility changes the host
procedure only slightly. In the following, it is assumed that (
accordance with the current Internet Host specification [1])
host treats code 0 (redirect datagrams for the network)
as if they were code 1 (redirect datagrams for the host
Redirects. Similarly, it is assumed that the host treats code 2
(redirect datagrams for the network and type of service)
as if they were code 3 (redirect datagrams for the host and
of service) Redirects. Readers considering violating
assumptions should be aware that long and careful consideration
the way in which Redirects are treated is necessary to
situations where every packet sent to some destination provokes
Redirect. Because these assumptions match the recommendations
Internet Host specification, that careful consideration is
the scope of this memo
As was described in Section 6.2, some ICMP Redirects apply only
IP packets which request a particular TOS. Thus, a host (at
conceptually) needs to store two types of entries in its
cache
type 1: { destination, TOS, router }
type 2: { destination, *, router }
where type 1 entries result from the receipt of code 3 (or code 1)
Redirects and type 2 entries result from the receipt of code 2 (
code 0) Redirects
Almquist [Page 10]
RFC 1349 Type of Service July 1992
When a host wants to send a packet, it first searches the
cache for a type 1 entry whose destination matches the
address of the packet and whose TOS matches the requested TOS
the packet. If it doesn't find one, the host searches its
cache again, this time looking for a type 2 entry
destination matches the destination address of the packet.
either of these searches finds a matching entry, the packet
sent to the router listed in the matching entry. Otherwise,
packet is sent to one of the routers on the list of
routers
When a host creates (or updates) a type 2 entry, it must
from its route cache any type 1 entries which have the
destination. This is necessary for correctness, since the type 1
entry may be obsolete but would continue to be used if it weren'
flushed because type 1 entries are always preferred over type 2
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
destination. In this case, the type 1 entry will
override the type 2 entry for packets whose destination
and requested TOS match the type 1 entry. Because the type 2
entry may well specify the correct router for some TOS
other than the one specified in the type 1 entry, saving the
2 entry will likely cut down on the number of Redirects which
host would otherwise receive. This savings can potentially
substantial if one of the Redirects which was avoided would
created a new type 2 entry (thereby causing the new type 1
to be flushed). That can happen, for example, if only some of
routers on the local net are part of a routing domain
computes separate routes for each TOS
As an alternative, a host may treat all Redirects as if they
code 3 (redirect datagrams for hosts and type of service
Redirects. This alternative allows the host to have only type 1
route cache entries, thereby simplifying route lookup
eliminating the need for the rules in the previous two paragraphs
The disadvantage of this approach is that it increases the size
the route cache and the amount of Redirect traffic if the
sends packets with a variety of requested TOS's to a
for which the host should use the same router regardless of
requested TOS. There is not yet sufficient experience with
TOS facility to know whether that disadvantage would be
enough in practice to outweigh the simplicity of this approach
Despite RFC-1122, some hosts acquire their routing information
"wiretapping" a routing protocol instead of by using
Almquist [Page 11]
RFC 1349 Type of Service July 1992
mechanisms described above. Such hosts will need to follow
procedures described in Section 7.2 (except of course that
will not send ICMP Destination Unreachables or ICMP Redirects).
7.2
A router in the Internet should be able to consider the value
the TOS field when choosing an appropriate path over which
forward an IP packet. How a router does this is a part of
more general issue of how a router picks appropriate paths.
larger issue can be extremely complex [4], and is beyond the
of this memo. This discussion should therefore be considered
an overview. Implementors should consult the Router
specification [3] and the the specifications of the
protocols they implement for details
A router associates a TOS value with each route in its
table. The value can be any of the possible values of the
field in an IP datagram (including those values whose
are yet to be defined). Any routes learned using
protocols which support TOS are assigned appropriate TOS value
those protocols. Routes learned using other routing protocols
always assigned the default TOS value (0000). Static routes
their TOS values assigned by the network manager
When a router wants to forward a packet, it first looks up
destination address in its forwarding table. This yields a set
candidate routes. The set may be empty (if the destination
unreachable), or it may contain one or more routes to
destination. If the set is not empty, the TOS values of
routes in the set are examined. If the set contains a route
TOS exactly matches the TOS field of the packet being
then that route is chosen. If not but the set contains a
with the default TOS then that route is chosen
If no route is found, or if the the chosen route has an
metric, the destination is considered to be unreachable.
packet is discarded and an ICMP Destination Unreachable
returned to the source. Normally, the Unreachable uses code 0
(Network unreachable) or 1 (Host unreachable). If, however,
route to the destination exists which has a different TOS
and a non-infinite metric then code 11 (Network unreachable
type of service) or code 12 (Host unreachable for type of service
must be used instead
Almquist [Page 12]
RFC 1349 Type of Service July 1992
8. Other consequences of
The TOS field in a datagram primarily affects the path chosen
the network, but an implementor may choose to have TOS also
other aspects of how the datagram is handled. For example, a host
router might choose to give preferential queuing on network
queues to datagrams which have requested that delay be minimized
Similarly, a router forced by overload to discard packets
attempt to avoid discarding packets that have requested
reliability be maximized. At least one paper [14] has explored
ideas in some detail, but little is known about how well such
handling would work in practice
Additionally, some Link Layer protocols have their own quality
service mechanisms. When a router or host transmits an IP packet,
might request from the Link Layer a quality of service as close
possible to the one requested in the TOS field in the IP header
Long ago an attempt (RFC-795) was made to codify how this might
done, but that document describes Link Layer protocols which
since become obsolete and no more recent document on the subject
been written
Almquist [Page 13]
RFC 1349 Type of Service July 1992
APPENDIX A. Updates to Other
While this memo is primarily an update to the IP
specification [11], it also peripherally affects a number of
specifications. This appendix describes those peripheral effects
This information is included in an appendix rather than in the
body of the document because most if not all of these
specifications will be updated in the future. As that happens,
information included in this appendix will become obsolete
A.1 RFC-792 (ICMP
RFC-792 [12] defines a set of codes indicating reasons why
destination is unreachable. This memo describes the use of
additional codes
11 -- network unreachable for type of
12 -- host unreachable for type of
These codes were defined in RFC-1122 [1] but were not included
RFC-792.
A.2 RFC-1060 (Assigned Numbers
RFC-1060 [15] describes the old interpretation of the TOS
(as three independent bits, with no way to specify that
cost should be minimized). Although it is likely obvious how
values in RFC-1060 ought to be interpreted in light of this memo
the information from that RFC is reproduced here. The only
changes are for ICMP (to conform to Section 5.1 of this memo)
NNTP
----- Type-of-Service Value -----
Protocol TOS
TELNET (1) 1000 (minimize delay
Control 1000 (minimize delay
Data (2) 0100 (maximize throughput
TFTP 1000 (minimize delay
SMTP (3)
Command phase 1000 (minimize delay
DATA phase 0100 (maximize throughput
Almquist [Page 14]
RFC 1349 Type of Service July 1992
----- Type-of-Service Value -----
Protocol TOS
Domain Name
UDP Query 1000 (minimize delay
TCP Query 0000
Zone Transfer 0100 (maximize throughput
NNTP 0001 (minimize monetary cost
Errors 0000
Requests 0000 (4)
Responses (4)
Any IGP 0010 (maximize reliability
EGP 0000
SNMP 0010 (maximize reliability
BOOTP 0000
Notes
(1) Includes all interactive user protocols (e.g., rlogin).
(2) Includes all bulk data transfer protocols (e.g., rcp).
(3) If the implementation does not support changing the
during the lifetime of the connection, then
recommended TOS on opening the connection is the
TOS (0000).
(4) Although ICMP request messages are normally sent with
default TOS, there are sometimes good reasons why
would be sent with some other TOS value. An ICMP
always uses the same TOS value as was used in
corresponding ICMP request message. See Section 5.1
this memo
An application may (at the request of the user) substitute 0001
(minimize monetary cost) for any of the above values
This appendix is expected to be obsoleted by the next
of the Assigned Numbers document
Almquist [Page 15]
RFC 1349 Type of Service July 1992
A.3 RFC-1122 and RFC-1123 (Host Requirements
The use of the TOS field by hosts is described in detail
RFC-1122 [1] and RFC-1123 [2]. The information provided there
still correct, except that
(1) The TOS field is four bits wide rather than five bits wide
The requirements that refer to the TOS field should
only to the four bits that make up the TOS field
(2) An application may set bit 6 of the TOS octet to a non-
value (but still must not set bit 7 to a non-zero value).
These details will presumably be corrected in the next revision
the Host Requirements specification, at which time this
can be considered obsolete
A.4 RFC-1195 (Integrated IS-IS
Integrated IS-IS (sometimes known as Dual IS-IS) has
metrics for each route. Which of the metrics is used to route
particular IP packet is determined by the TOS field in the packet
This is described in detail in section 3.5 of RFC-1195 [7].
The mapping from the value of the TOS field to an
Integrated IS-IS metric is described by a table in that section
Although the specification in this memo is intended to
substantially compatible with Integrated IS-IS, the extension
the TOS field to four bits and the addition of a TOS
requesting "minimize monetary cost" require minor modifications
that table, as shown here
The IP TOS octet is mapped onto the four available metrics
follows
Bits 0-2 (Precedence): (unchanged from RFC-1195)
Bits 3-6 (TOS):
0000 (all normal) Use default
1000 (minimize delay) Use delay
0100 (maximize throughput) Use default
0010 (maximize reliability) Use reliability
0001 (minimize monetary cost) Use cost
other Use default
Bit 7 (MBZ): This bit is ignored by Integrated IS-IS
Almquist [Page 16]
RFC 1349 Type of Service July 1992
It is expected that the next revision of the Integrated IS-
specification will include this corrected table, at which
this appendix can be considered obsolete
A.5 RFC-1247 (OSPF) and RFC-1248 (OSPF MIB
Although the specification in this memo is intended to
substantially compatible with OSPF, the extension of the TOS
to four bits requires minor modifications to the section
describes the encoding of TOS values in Link State Advertisements
described in section 12.3 of RFC-1247 [10]. The encoding
summarized in Table 17 of that memo; what follows is an
version of table 17. The numbers in the first column are
integers, and the numbers in the second column are binary
values
OSPF encoding
_____________________________________________
0 0000 normal
2 0001 minimize monetary
4 0010 maximize
6 0011
8 0100 maximize
10 0101
12 0110
14 0111
16 1000 minimize
18 1001
20 1010
22 1011
24 1100
26 1101
28 1110
30 1111
The OSPF MIB, described in RFC-1248 [5], is entirely
with this memo except for the textual comment which describes
mapping of the old TOS flag bits into TOSType values.
values use the same encoding of TOS values as OSPF's Link
Advertisements do, so the above table also describes the
between TOSType values (the first column) and TOS field
(the second column).
If RFC-1247 and RFC-1248 are revised in the future, it is
that this information will be incorporated into the
versions. At that time, this appendix may be considered obsolete
Almquist [Page 17]
RFC 1349 Type of Service July 1992
APPENDIX B.
The main body of this memo has described the details of how
facility works. This appendix is for those who wonder why it
that way
Much of what is in this document can be explained by the simple
that the goal of this document is to provide a clear and
specification of the existing TOS facility rather than to design
scratch a new quality of service mechanism for IP. While this
does amend the facility in some small and carefully considered
discussed below, the desirability of compatibility with
specifications and uses of the TOS facility [1,2,7,10,11] was
in doubt. This goal of backwards compatibility determined the
outlines and many of the details of this specification
Much of the rest of this specification was determined by
additional goals, which were described more fully in Section 2.
first was that hosts should never be penalized for using the
facility, since that would likely ensure that it would never
widely deployed. The second was that the specification should
it easy, or at least possible, to define and deploy new types
service in the future
The three goals above did not eliminate all need for
choices, however, and in a few cases the goals proved to be
conflict with each other. The remainder of this appendix
the rationale behind some of these engineering choices
B.1 The Minimize Monetary Cost TOS
Because the Internet is becoming increasingly commercialized,
number of participants in the IETF's Router Requirements
Group felt it would be important to have a TOS value which
allow a user to declare that monetary cost was more important
other qualities of the service
There was considerable debate over what exactly this value
mean. Some felt, for example, that the TOS value should
"must not cost money". This was rejected for several reasons
Because it would request a particular level of service (cost = 0)
rather than merely requesting that some service attribute
minimized or maximized, it would not only philosophically at
with the other TOS values but would require special code in
hosts and routers. Also, it would not be helpful to users
want their packets to travel via the least-cost path but
accept some level of cost when necessary. Finally, since
any particular routing domain considers the TOS field when
Almquist [Page 18]
RFC 1349 Type of Service July 1992
is a choice made by the network manager, a user requiring a
path might not get one if the packet has to pass through a
domain that does not consider TOS in its routing decisions
Some proposed a slight variant: a TOS value which would mean "I
willing to pay money to have this packet delivered".
proposal suffers most of the same shortcomings as the previous
and turns out to have an additional interesting quirk: because
the algorithms specified in Section 7.2, any packet which
this TOS value would prefer links that cost money over
good free links. Thus, such a TOS value would almost
equivalent to a "maximize monetary cost" value
It seems likely that in the future users may need some
to express the maximum amount they are willing to pay to have
packet delivered. However, an IP option would be a
appropriate mechanism, since there are precedents for having
options that all routers are required to honor, and an IP
could include parameters such as the maximum amount the user
willing to pay. Thus, the TOS value defined in this memo
requests that the network "minimize monetary cost".
B.2 The Specification of the TOS
There were four goals that guided the decision to have a four
TOS field and the specification of that field's values
(1) To define a new type of service requesting that the
"minimize monetary cost
(2) To remain as compatible as possible with
specifications and uses of the TOS
(3) To allow for the definition and deployment of new types
service in the
(4) To permanently fix the size of the TOS
The last goal may seem surprising, but turns out to be
for routing to work correctly when new types of service
deployed. If routers have different ideas about the size of
TOS field they make inconsistent decisions that may lead
routing loops
At first glance goals (3) and (4) seem to be pretty much
exclusive. The IP header currently has only three unused bits,
at most three new type of service bits could be defined
resorting to the impractical step of changing the IP
Almquist [Page 19]
RFC 1349 Type of Service July 1992
format. Since one of them would need to be allocated to meet
(1), at most two bits could be reserved for new or
types of service. Not only is it questionable whether two
be enough, but it is improbable that the IETF and IAB would
all of the currently unused bits to be permanently reserved
types of service which might or might or might not ever
defined
However, some (if not most of) the possible combinations of
individual bits would not be useful. Clearly, setting all of
bits would be equivalent to setting none of the bits,
setting all of the bits would indicate that none of the types
optimization was any more important than any of the others
Although one could perhaps assign reasonable semantics to
pairs of bits, it is unclear that the range of network
provided by various paths could usefully be subdivided in so
a manner. If some of these non-useful combinations of bits
be assigned to new types of service then it would be possible
meet goal (3) and goal (4) without having to use up all of
remaining reserved bits in the IP header. The obvious way to
that was to change the interpretation of TOS values so that
were integers rather than independently settable bits
The integers were chosen to be compatible with the bit
found in RFC-791. Thus, for example, setting the TOS field
1000 (minimize delay) sets bit 3 of the Type of Service octet;
3 is defined as the Low Delay bit in RFC-791. This memo
defines values which correspond to setting a single one of
RFC-791 bits, since setting multiple TOS bits does not seem to
a common practice. According to [15], none of the common TCP/
applications currently set multiple TOS bits. However, TOS
corresponding to particular combinations of the RFC-791 bits
be defined if and when they are determined to be useful
The new TOS value for "minimize monetary cost" needed to be
which would not be too terribly misconstrued by
implementations. This seemed to imply that the value should
one which left all of the RFC-791 bits clear. That would
expanding the TOS field, but would allow old implementations
treat packets which request minimization of monetary cost (
0001) as if they had requested the default TOS. This is not
perfect solution since (as described above) changing the size
the TOS field could cause routing loops if some routers were
route based on a three bit TOS field and others were to
based on a four bit TOS field. Fortunately, this should not
much of a problem in practice because routers which route based
a three bit TOS field are very rare as this is being written
will only become more so once this specification is published
Almquist [Page 20]
RFC 1349 Type of Service July 1992
Because of those considerations, and also in order to allow
reasonable number of TOS values for future definition, it
desirable to expand the TOS field. That left the question of
much to expand it. Expanding it to five bits would
considerable future expansion (27 new TOS values) and would
consistent with Host Requirements, but would reduce to one
number of reserved bits in the IP header. Expanding the TOS
to four bits would restrict future expansion to more modest
(11 new TOS values), but would leave an additional IP header
free. The IETF's Router Requirements Working Group concluded
a four bits wide TOS field allow enough values for future use
that consistency with Host Requirements was
justification for unnecessarily increasing the size of the
field
B.3 The Choice of Weak TOS
"Ruminations on the Next Hop" [4] describes three alternative
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
in the datagram being routed. If there is no route with
requested TOS, the packet is discarded
(2) Weak TOS --
like Strong TOS, except that a route with the default
(0000) is used if there is no route that has the
TOS. If there is no route with either the requested TOS
the default TOS, the packet is discarded
(3) Very Weak TOS --
like Weak TOS, except that a route with the
smallest TOS is used if there is no route that has either
requested TOS or the default TOS
This specification has adopted Weak TOS
Strong TOS was quickly rejected. Because it requires that
router a packet traverses have a route with the requested TOS
packets which requested non-zero TOS values would have (at
until the TOS facility becomes widely used) a high probability
being discarded as undeliverable. This violates the
(described in Section 2) that hosts should not be penalized
choosing non-zero TOS values
The choice between Weak TOS and Very Weak TOS was not
straightforward. Weak TOS was chosen because it is
Almquist [Page 21]
RFC 1349 Type of Service July 1992
simpler to implement and because it is consistent with the
and Integrated IS-IS specifications. In addition, many
Very Weak TOS because its algorithm for choosing a route when
of the available routes have either the requested or the
TOS cannot be justified by intuition (there is no reason
believe that having a numerically smaller TOS makes a
better). Since a router would need to understand the semantics
all of the TOS values to make a more intelligent choice,
seems to be no reasonable way to fix this particular deficiency
Very Weak TOS
In practice it is expected that the choice between Weak TOS
Very Weak TOS will make little practical difference, since (
where the network manager has intentionally set things
otherwise) there will be a route with the default TOS to
destination for which there is a route with any other TOS
B.4 The Retention of Longest Match
An interesting issue is how early in the route choice process
should be considered. There seem to be two obvious possibilities
(1) Find the set of routes that best match the
address of the packet. From among those, choose the
which best matches the requested TOS
(2) Find the set of routes that best match the requested TOS
From among those, choose the route which best matches
destination address of the packet
The two approaches are believed to support an identical set
routing policies. Which of the two allows the
configuration and minimizes the amount of routing information
needs to be passed around seems to depend on the topology,
some believe that the second option has a slight edge in
regard
Under the first option, if the network manager neglects
pieces of the configuration the likely consequence is that
packets which would benefit from TOS-specific routes will
routed as if they had requested the default TOS. Under the
option, however, a network manager can easily (accidently
configure things in such a way that packets which request
certain TOS and should be delivered locally will instead follow
default route for that TOS and be dumped into the Internet. Thus
the first option would seem to have a slight edge with regard
robustness in the face of errors by the network manager
Almquist [Page 22]
RFC 1349 Type of Service July 1992
It has been also been suggested that the first option provides
additional benefit of allowing loop-free routing in
domains which contain both routers that consider TOS in
routing decisions and routers that do not. Whether that is
in all cases is unknown. It is certainly the case, however,
under the second option it would not work to mix routers
consider TOS and routers which do not in the same routing domain
All in all, there were no truly compelling arguments for
one way or the other, but it was nontheless necessary to make
choice: if different routers were to make the choice differently
chaos (in the form of routing loops) would result. The
specified in this memo reflect the first option because that
probably be more intuitive to most network managers.
routing has traditionally chosen the route which best matches
destination address, with other mechanisms serving merely as tie
breakers. The first option is consistent with that tradition
B.5 The Use of Destination
Perhaps the most contentious and least defensible part of
specification is that a packet can be discarded because
destination is considered to be unreachable even though a
to the same destination but requesting a different TOS would
been deliverable. This would seem to fall perilously close
violating the principle that hosts should never be penalized
requesting non-default TOS values in packets they originate
This can happen in only three, somewhat unusual, cases
(1) There is a route to the packet's destination which has
TOS value requested in the packet, but the route has
infinite metric
(2) The only routes to the packet's destination have TOS
other than the one requested in the packet. One of them
the default TOS, but it has an infinite metric
(3) The only routes to the packet's destination have TOS
other than the one requested in the packet. None of
have the default TOS
It is commonly accepted that a router which has a default
should nonetheless discard a packet if the router has a
specific route to the destination in its forwarding table but
route has an infinite metric. The first two cases seem to
analogous to that rule
Almquist [Page 23]
RFC 1349 Type of Service July 1992
In addition, it is worth noting that, except perhaps during
transients resulting from topology changes, routes with
metrics occur only as the result of deliberate action (or
error) on the part of the network manager. Thus, packets
unlikely to be discarded unless the network manager has
deliberate action to cause them to be. Some people believe
this is an important feature of the specification, allowing
network to (for example) keep packets which have requested
cost be minimized off of a link that is so expensive that
network manager feels confident that the users would want
packets to be dropped. Others (including the author of this memo
believe that this "feature" will prove not to be useful, and
other mechanisms may be required for access controls on links,
couldn't justify changing this specification in the ways
to eliminate the "feature".
Case (3) above is more problematic. It could have been avoided
using Very Weak TOS, but that idea was rejected for the
discussed in Appendix B.3. Some suggested that case (3) could
fixed by relaxing longest match routing (described in
B.4), but that idea was rejected because it would add
to routers without necessarily making their routing
particularly more intuitive. It is also worth noting that this
another case that a network manager has to try rather hard
create: since OSPF and Integrated IS-IS both enforce
constraint that there must be a route with the default TOS to
destination for which there is a route with a non-zero TOS,
network manager would have to await the development of a
routing protocol or create the problem with static routes.
eventual conclusion was that any fix to case (3) was worse
the problem
APPENDIX C. Limitations of the TOS
It is important to note that the TOS facility has some limitations
Some are consequences of engineering choices made in
specification. Others, referred to as "inherent limitations" below
could probably not have been avoided without either replacing the
facility defined in RFC-791 or accepting that things wouldn't
right until all routers in the Internet supported the TOS facility
C.1 Inherent
The most important of the inherent limitations is that the
facility is strictly an advisory mechanism. It is not
appropriate mechanism for requesting service guarantees.
are two reasons why this is so
Almquist [Page 24]
RFC 1349 Type of Service July 1992
(1) Not all networks will consider the value of the TOS
when deciding how to handle and route packets. Partly
is a transition issue: there will be a (probably lengthy
period when some networks will use equipment that
this specification. Even long term, however, many
will not be able to provide better service by considering
value of the TOS field. For example, the best path through
network composed of a homogeneous collection
interconnected LANs is probably the same for any possible
value. Inside such a network, it would make little sense
require routers and routing protocols to do the extra
needed to consider the value of the TOS field when
packets
(2) The TOS mechanism is not powerful enough to allow
application to quantify the level of service it desires.
example, an application may use the TOS field to request
the network choose a path which maximizes throughput,
cannot use that mechanism to say that it needs or wants
particular number of kilobytes or megabytes per second
Because the network cannot know what the
requires, it would be inappropriate for the network to
to discard a packet which requested maximal
because no "high throughput" path was available
The inability to provide resource guarantees is a serious
for certain kinds of network applications. For example, a
using packetized voice simply creates network congestion when
available bandwidth is inadequate to deliver intelligible speech
Likewise, the network oughtn't even bother to deliver a
packet that has suffered more delay in the network than
application can tolerate. Unfortunately, resource guarantees
problematic in connectionless networks. Internet researchers
actively studying this problem, and are optimistic that they
be able to invent ways in which the Internet Architecture
evolve to support resource guarantees while preserving
advantages of connectionless networking
C.2 Limitations of this
There are a couple of additional limitations of the TOS
which are not inherent limitations but instead are consequences
engineering choices made in this specification
(1) Routing is not really optimal for some TOS values. This
because optimal routing for those TOS values would
that routing protocols be cognizant of the semantics of
TOS values and use special algorithms to compute routes
Almquist [Page 25]
RFC 1349 Type of Service July 1992
them. For example, routing protocols traditionally
the metric for a path by summing the costs of the
links that make up the path. However, to
reliability, a routing protocol would instead have to
a metric which was the product of the probabilities
successful delivery over each of the individual links in
path. While this limitation is in some sense a limitation
current routing protocols rather than of this specification
this specification contributes to the problem by
that there are a number of legal TOS values that have
currently defined semantics
(2) This specification assumes that network managers will do "
right thing". If a routing domain uses TOS, the
manager must configure the routers in such a way that
reasonable path is chosen for each TOS. While this ought
to be terribly difficult, a network manager could
or intentionally violate our rule that using the TOS
should provide service at least as good as not using it
Almquist [Page 26]
RFC 1349 Type of Service July 1992
[1] Internet Engineering Task Force (R. Braden, Editor),
"Requirements for Internet Hosts -- Communication Layers",
1122, USC/Information Sciences Institute, October 1989.
[2] Internet Engineering Task Force (R. Braden, Editor),
"Requirements for Internet Hosts -- Application and Support",
RFC 1123, USC/Information Sciences Institute, October 1989.
[3] Almquist, P., "Requirements for IP Routers", Work in progress
[4] Almquist, P., "Ruminations on the Next Hop", Work in progress
[5] Baker, F. and R. Coltun, "OSPF Version 2 Management
Base", RFC 1248, ACC, Computer Science Center, August 1991.
[6] Braden, R. and J. Postel, "Requirements for Internet Gateways",
RFC 1009, USC/Information Sciences Institute, June 1987.
[7] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and
Environments", RFC 1195, Digital Equipment Corporation,
1990.
[8] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
PARC, September 1991.
[9] Mogul, J. and J. Postel, "Internet Standard
Procedure", RFC 950, USC/Information Sciences Institute,
1985.
[10] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991.
[11] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981.
[12] Postel, J., "Internet Control Message Protocol", RFC 792, DARPA
September 1981.
[13] Postel, J., "Transmission Control Protocol", RFC 793, DARPA
September 1981.
[14] Prue, W. and J. Postel, "A Queuing Algorithm to Provide Type
of-Service for IP Links", RFC 1046, USC/Information
Institute, February 1988.
[15] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1060,
USC/Information Sciences Institute, March 1990.
Almquist [Page 27]
RFC 1349 Type of Service July 1992
Some of the ideas presented in this memo are based on
held by the IETF's Router Requirements Working Group. Much of
specification of the treatment of Type of Service by hosts is
a restatement of the ideas of the IETF's former Host
Working Group, as captured in RFC-1122 and RFC-1123. The author
indebted to John Moy and Ross Callon for their assistance
cooperation in achieving consistency among the OSPF specification
the Integrated IS-IS specification, and this memo
This memo has been substantially improved as the result of
comments from a number of reviewers, including Dave Borman,
Braden, Ross Callon, Vint Cerf, Noel Chiappa, Deborah Estrin,
Gross, Bob Hinden, Steve Huston, Jon Postel, Greg Vaudreuil,
Wobus, and the Router Requirements Working Group
The initial work on this memo was done while its author was
employee of BARRNet. Their support is gratefully acknowledged
Security
This memo does not explicitly discuss security issues. The
does not believe that the specifications in this memo either
or enhance the security of the IP Protocol or of the other
mentioned herein
Author's
Philip
214 Cole Street, Suite 2
San Francisco, CA 94117-1916
Phone: 415-752-2427
Email: almquist@Jessica.Stanford.
Almquist [Page 28]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
