justification for unnecessarily increasing the size of the TOS
field.
B.3 The Choice of Weak TOS Routing
"Ruminations on the Next Hop" [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 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
TOS. If there is no route with either the requested TOS or
the default TOS, the packet is discarded.
(3) Very Weak TOS --
like Weak TOS, except that a route with the numerically
smallest TOS is used if there is no route that has either the
requested TOS or the default TOS.
This specification has adopted Weak TOS.
Strong TOS was quickly rejected. Because it requires that each
router a packet traverses have a route with the requested TOS,
packets which requested 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 should not be penalized for
choosing non-zero TOS values.
The choice between Weak TOS and Very Weak TOS was not as
straightforward. Weak TOS was chosen because it is slightly
RFC1349 Type of Service July 1992
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
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
better). Since a 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.
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
otherwise) there will be a route with the default TOS to any
destination for which there is a route with any other TOS.
B.4 The Retention of Longest Match Routing
An interesting issue is how early in the route choice process TOS
should be considered. There seem to be two obvious possibilities:
(1) Find the set of routes that best match the 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.
From among those, choose the route which best matches the
destination address of the packet.
The two approaches are believed to support an identical set of
routing policies. Which of the two allows the simpler
configuration and minimizes the amount of routing information that
needs to be passed around seems to depend on the topology, though
some believe that the second option has a slight edge in this
regard.
Under the first option, if 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
option, however, a 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 and be dumped into the Internet. Thus,
the first option would seem to have a slight edge with regard to
robustness in the face of errors by the network manager.
RFC1349 Type of Service July 1992
It has been also been suggested that the first option provides the
additional benefit of allowing loop-free routing in routing
domains which contain both routers that consider TOS in their
routing decisions and routers that do not. Whether that is true
in all cases is unknown. It is certainly the case, however, that
under the second option it would not work to mix routers that
consider TOS and routers which do not in the same routing domain.
All in all, there were no truly compelling arguments for choosing
one way or the other, but it was nontheless necessary to make a
choice: if different routers were to make the choice differently,
chaos (in the form of routing loops) would result. The mechanisms
specified in this memo reflect the first option because that will
probably be more intuitive to most network managers. Internet
routing has traditionally chosen the route which best matches the
destination address, with other mechanisms serving merely as tie-
breakers. The first option is consistent with that tradition.
B.5 The Use of Destination Unreachable
Perhaps the most contentious and least defensible part of this
specification is that a packet can be discarded because the
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 should never be penalized for
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 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, but it has an infinite metric.
(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.
It is commonly accepted that a router which has a default route
should nonetheless discard a packet if the router has a more
specific route to the destination in its forwarding table but that
route has an infinite metric. The first two cases seem to be
analogous to that rule.
RFC1349 Type of Service July 1992
In addition, it is worth noting that, except perhaps during brief
transients resulting from topology changes, routes with infinite
metrics occur only as the result of deliberate action (or serious
error) on the part of the network manager. Thus, packets are
unlikely to be discarded unless the network manager has taken
deliberate action to cause them to be. Some people believe that
this is an important feature of the specification, allowing the
network to (for example) keep packets which have requested that
cost be minimized off of a link that is so expensive that the
network manager feels confident that the users would want their
packets to be dropped. Others (including the author of this memo)
believe that this "feature" will prove not to be useful, and that
other mechanisms may be required for access controls on links, but
couldn't justify changing this specification in the ways necessary
to eliminate the "feature".
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 (described in Appendix
B.4), but that idea was rejected because it would add complexity
to routers without necessarily making their routing choices
particularly more intuitive. It is also worth noting that this is
another case that a network manager has to try rather hard to
create: since OSPF and Integrated IS-IS both enforce the
constraint that there must be a route with the default TOS to any
destination for which there is a route with a non-zero TOS, a
network manager would have to await the development of a new
routing protocol or create the problem with static routes. The
eventual conclusion was that any fix to case (3) was worse than
the problem.
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,
could probably not have been avoided without either replacing the TOS
facility defined in RFC-791 or accepting that things wouldn't work
right until all routers in the Internet supported the TOS facility.
C.1 Inherent Limitations
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 guarantees. There
are two reasons why this is so:
RFC1349 Type of Service July 1992
(1) Not all networks will consider the value of the TOS field
when deciding how to handle and route packets. Partly this
is a transition issue: there will be a (probably lengthy)
period when some networks will use equipment that predates
this specification. Even long term, however, many networks
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
interconnected LANs is probably the same for any possible TOS
value. Inside such a network, it would make little sense to
require routers and routing protocols to do the extra work
needed to consider the value of the TOS field when forwarding
packets.
(2) The TOS mechanism is not powerful enough to allow an
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, but
cannot use that mechanism to say that it needs or wants a
particular number of kilobytes or megabytes per second.
Because the network cannot know what the application
requires, it would be inappropriate for the network to decide
to discard a packet which requested maximal throughput
because no "high throughput" path was available.
The inability to provide resource guarantees is a serious drawback
for certain kinds of network applications. For example, a system
using packetized voice simply creates network congestion when the
available bandwidth is inadequate to deliver intelligible speech.
Likewise, the network oughtn't even bother to deliver a voice
packet that has suffered more delay in the network than the
application can tolerate. Unfortunately, resource guarantees are
problematic in connectionless networks. Internet researchers are
actively studying this problem, and are optimistic that they will
be able to invent ways in which the Internet Architecture can
evolve to support resource guarantees while preserving the
advantages of connectionless networking.
C.2 Limitations of this Specification
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 values would require
that routing protocols be cognizant of the semantics of the
TOS values and use special algorithms to compute routes for
RFC1349 Type of Service July 1992
them. For example, routing protocols traditionally compute
the metric for a path by summing the costs of the individual
links that make up the path. However, to maximize
reliability, a routing protocol would instead have to compute
a metric which was the product of the probabilities of
successful delivery over each of the individual links in the
path. While this limitation is in some sense a limitation of
current 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.
(2) This specification assumes that network managers will do "the
right thing". If a routing domain uses TOS, the 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
or intentionally violate our rule that using the TOS facility
should provide service at least as good as not using it.
RFC1349 Type of Service July 1992
References
[1] Internet Engineering Task Force (R. Braden, Editor),
"Requirements for Internet Hosts -- Communication Layers", RFC
1122, USC/Information Sciences Institute, October 1989.
[2] Internet Engineering Task Force (R. Braden, Editor),
"Requirements for Internet Hosts -- Application and Support",
RFC1123, 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 Information
Base", RFC1248, ACC, Computer Science Center, August 1991.
[6] Braden, R. and J. Postel, "Requirements for Internet Gateways",
RFC1009, USC/Information Sciences Institute, June 1987.
[7] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual
Environments", RFC1195, Digital Equipment Corporation, December
1990.
[8] Deering, S., "ICMP Router Discovery Messages", RFC1256, Xerox
PARC, September 1991.
[9] Mogul, J. and J. Postel, "Internet Standard Subnetting
Procedure", RFC950, USC/Information Sciences Institute, August
1985.
[10] Moy, J., "OSPF Version 2", RFC1247, Proteon, Inc., July 1991.
[11] Postel, J., "Internet Protocol", RFC791, DARPA, September 1981.
[12] Postel, J., "Internet Control Message Protocol", RFC792, DARPA,
September 1981.
[13] Postel, J., "Transmission Control Protocol", RFC793, DARPA,
September 1981.
[14] Prue, W. and J. Postel, "A Queuing Algorithm to Provide Type-
of-Service for IP Links", RFC1046, USC/Information Sciences
Institute, February 1988.
[15] Reynolds, J. and J. Postel, "Assigned Numbers", RFC1060,
USC/Information Sciences Institute, March 1990.
RFC1349 Type of Service July 1992
Acknowledgements
Some of the ideas presented in this memo are based on discussions
held by the IETF's Router Requirements 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 Requirements
Working Group, as captured in RFC-1122 and RFC-1123. The author is
indebted to John Moy and Ross Callon for their assistance and
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 thoughtful
comments from a number of reviewers, including Dave Borman, Bob
Braden, Ross Callon, Vint Cerf, Noel Chiappa, Deborah Estrin, Phill
Gross, Bob Hinden, Steve Huston, Jon Postel, Greg Vaudreuil, John
Wobus, and the Router Requirements Working Group.
The initial work on this memo was done while its author was an
employee of BARRNet. Their support is gratefully acknowledged.
Security Considerations
This memo does not explicitly discuss security issues. The author
does not believe that the specifications in this memo either weaken
or enhance the security of the IP Protocol or of the other protocols
mentioned herein.
Author's Address
Philip Almquist
214 Cole Street, Suite 2
San Francisco, CA 94117-1916
Phone: 415-752-2427
Email: almquist@Jessica.Stanford.EDU