doc: Add RFC documents

1 files changed, 1624 insertions, 0 deletions

diff --git a/doc/rfc/rfc1349.txt b/doc/rfc/rfc1349.txt
new file mode 100644
index 0000000..cfbacb6
--- /dev/null
+++ b/doc/rfc/rfc1349.txt
@@ -0,0 +1,1624 @@
+
+
+
+
+
+Network Working Group                                        P. Almquist
+Request for Comments: 1349                                    Consultant
+Updates: RFCs 1248, 1247, 1195,                                July 1992
+         1123, 1122, 1060, 791
+
+
+
+
+             Type of Service in the Internet Protocol Suite
+
+Status of This Memo
+
+   This document specifies an IAB standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "IAB
+   Official Protocol Standards" for the standardization state and status
+   of this protocol.  Distribution of this memo is unlimited.
+
+Summary
+
+   This memo changes and clarifies some aspects of the semantics of the
+   Type of Service octet in the Internet Protocol (IP) header.  The
+   handling of IP Type of Service by both hosts and routers is specified
+   in some detail.
+
+   This memo defines a new TOS value for requesting that the network
+   minimize the monetary cost of transmitting a datagram.  A number of
+   additional new TOS values are reserved for future experimentation and
+   standardization.  The ability to request that transmission be
+   optimized along multiple axes (previously accomplished by setting
+   multiple TOS bits simultaneously) is removed.  Thus, for example, a
+   single datagram can no longer request that the network simultaneously
+   minimize delay and maximize throughput.
+
+   In addition, there is a minor conflict between the Host Requirements
+   (RFC-1122 and RFC-1123) and a number of other standards concerning
+   the sizes of the fields in the Type of Service octet.  This memo
+   resolves that conflict.
+
+Table of Contents
+
+   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.  Introduction
+
+   Paths through the Internet vary widely in the quality of service they
+   provide.  Some paths are more reliable than others.  Some impose high
+   call setup or per-packet charges, while others do not do usage-based
+   charging.  Throughput and delay also vary widely.  Often there are
+   tradeoffs: the path that provides the highest throughput may well not
+   be the one that provides the lowest delay or the lowest monetary
+   cost.  Therefore, the "optimal" path for a packet to follow through
+   the Internet may depend on the needs of the application and its user.
+
+   Because the Internet itself has no direct knowledge of how to
+   optimize the path for a particular application or user, the IP
+   protocol [11] provides a (rather limited) facility for upper layer
+   protocols to convey hints to the Internet Layer about how the
+   tradeoffs should be made for the particular packet.  This facility is
+   the "Type of Service" facility, abbreviated as the "TOS facility" in
+   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,
+   the Internet host specification [1,2] now mandates that hosts use the
+   TOS facility.  Additionally, routing protocols (including OSPF [10]
+   and Integrated IS-IS [7]) have been developed which can compute
+   routes separately for each type of service.  These new routing
+   protocols make it practical for routers to consider the requested
+   type of service when making routing decisions.
+
+   This specification defines in detail how 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 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) chooses appropriate values to insert into the
+   TOS fields of the IP datagrams it originates.  Sections 6 and 7
+   describe the ICMP Destination Unreachable and Redirect messages and
+   how TOS affects path choice by both hosts and routers.  Section 8
+   describes some additional ways in which TOS may optionally affect
+   packet processing.  Appendix A describes how this specification
+   updates a number of existing specifications.  Appendices B and C
+   expand on the discussion in Section 2.
+
+2.  Goals and Philosophy
+
+   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 facility, its network service should
+   be at least as good as (and hopefully better than) it would have been
+
+
+
+Almquist                                                        [Page 3]
+
+
+
+RFC 1349                    Type of Service                    July 1992
+
+
+   if the host had not used the facility.  This goal was considered
+   particularly important because it is unlikely that any specification
+   which did not meet this goal, no matter how good it might be in other
+   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
+   instead delivers it the same way it would have been delivered had
+   none of the TOS 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 implementations
+   should not interact badly with 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
+   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 should be able to handle a
+   new type of service correctly without having to understand its
+   semantics.
+
+   Appendix B of this memo provides a more detailed explanation of the
+   rationale behind particular aspects of this specification.
+
+3.  Specification of the Type of Service Octet
+
+   The TOS facility is one of the features of the Type of Service octet
+   in the IP datagram header.  The Type of Service octet consists of
+   three fields:
+
+                0     1     2     3     4     5     6     7
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+             |                 |                       |     |
+             |   PRECEDENCE    |          TOS          | MBZ |
+             |                 |                       |     |
+             +-----+-----+-----+-----+-----+-----+-----+-----+
+
+   The first field, labeled "PRECEDENCE" above, is intended to denote
+   the importance or priority of the datagram.  This field is not
+   discussed in detail in this memo.
+
+   The second field, labeled "TOS" above, denotes how the network should
+
+
+
+Almquist                                                        [Page 4]
+
+
+
+RFC 1349                    Type of Service                    July 1992
+
+
+   make tradeoffs between 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
+   currently unused.  The originator of a datagram sets this field to
+   zero (unless participating in an Internet protocol experiment which
+   makes use of that bit).  Routers and recipients of datagrams ignore
+   the value of this field.  This field is copied on fragmentation.
+
+   In the past there has been some confusion about the size of the TOS
+   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.  This
+   memo redefines the 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.
+
+4.  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-791, 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
+                    0100   --   maximize throughput
+                    0010   --   maximize reliability
+                    0001   --   minimize monetary cost
+                    0000   --   normal service
+
+   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 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."
+
+   Because this specification redefines TOS values to be integers rather
+   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 to choose a low delay path for a packet whose requested TOS
+   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 are
+   not defined by this memo, they are perfectly legal TOS values, and
+   hosts and routers must not preclude their use in any way.  As will
+   become clear after reading the remainder of this memo, only the
+   default TOS is in any way special.  A host or router need not (and
+
+
+
+Almquist                                                        [Page 5]
+
+
+
+RFC 1349                    Type of Service                    July 1992
+
+
+   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
+   guarantee that the path taken by the datagram will have a delay that
+   the user considers "low".  The network will attempt to choose the
+   lowest delay path available, based on its (often imperfect)
+   information about path delay.  The network will not discard the
+   datagram simply because it believes that the delay of the available
+   paths is "too high" (actually, the network manager can override this
+   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 when
+   it is not).
+
+5.  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
+   protocols above IP choose appropriate values.
+
+   5.1  Internet Control Message Protocol (ICMP)
+
+      ICMP [8,9,12] defines a number of messages for performing error
+      reporting and diagnostic functions for the Internet Layer.  This
+      section describes how a host or router chooses appropriate TOS
+      values for ICMP messages it originates.  The TOS facility also
+      affects the origination and processing of ICMP Redirects and ICMP
+      Destination Unreachables, but that is the topic of Section 6.
+
+      For purposes of this discussion, it is useful to divide ICMP
+      messages into three classes:
+
+       o   ICMP error messages include ICMP message types 3 (Destination
+           Unreachable), 4 (Source Quench), 5 (Redirect), 11 (Time
+           Exceeded), and 12 (Parameter Problem).
+
+       o   ICMP request messages include ICMP message types 8 (Echo), 10
+           (Router Solicitation), 13 (Timestamp), 15 (Information
+           Request -- now obsolete), and 17 (Address Mask Request).
+
+       o   ICMP reply messages include ICMP message types 0 (Echo
+           Reply), 9 (Router Advertisement), 14 (Timestamp Reply), 16
+           (Information Reply -- also obsolete), and 18 (Address Mask
+           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 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 request messages.
+
+      An ICMP reply message is sent with the same value in the TOS field
+      as was used in the corresponding ICMP request message.
+
+   5.2  Transport Protocols
+
+      When sending a datagram, a transport protocol uses the TOS
+      requested by the application.  There is no 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
+      that throughput be maximized, whereas the receiving side might
+      request that delay be minimized (assuming that it is primarily
+      sending small acknowledgement packets).  It may be useful for a
+      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 being generated
+      changes.  An example of this would be SMTP, which spends part of
+      its time doing bulk data transfer and part of its time exchanging
+      short command messages and responses.
+
+      TCP [13] should use the same TOS for datagrams containing only TCP
+      control information as it does for datagrams which contain user
+      data.  Although it might seem intuitively correct to always
+      request that the network minimize delay for segments containing
+      acknowledgements but no data, doing so could corrupt TCP's round
+      trip time estimates.
+
+   5.3  Application Protocols
+
+      Applications are responsible for choosing appropriate TOS values
+      for any 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
+      the application's designer or programmer to make a suitable
+      choice, based on the nature of the traffic to be originated by the
+      application.
+
+      It is essential for many sorts of network diagnostic applications,
+      and desirable for other applications, that the user of the
+
+
+
+Almquist                                                        [Page 7]
+
+
+
+RFC 1349                    Type of Service                    July 1992
+
+
+      application be able to override the TOS value(s) which the
+      application would otherwise choose.
+
+      The Assigned Numbers document is revised and reissued
+      periodically.  Until RFC-1060, the edition current as this is
+      being written, has been superceded, readers should consult
+      Appendix A.2 of this memo.
+
+6.  ICMP and the TOS Facility
+
+   Routers communicate routing information to hosts using the ICMP
+   protocol [12].  This section describes how support for the TOS
+   facility affects the origination and interpretation of ICMP Redirect
+   messages and certain types of ICMP Destination Unreachable messages.
+   This memo does not define any new extensions to the ICMP protocol.
+
+   6.1  Destination Unreachable
+
+      The ICMP Destination Unreachable message contains a code which
+      describes the reason that the destination is unreachable.  There
+      are four codes [1,12] which are particularly relevant to the topic
+      of this memo:
+
+         0 -- network unreachable
+         1 -- host unreachable
+        11 -- network unreachable for type of service
+        12 -- host unreachable for type of service
+
+      A router generates a code 11 or code 12 Destination Unreachable
+      when an unreachable destination (network or host) would have been
+      reachable had a different TOS value been specified.  A router
+      generates a code 0 or code 1 Destination Unreachable in other
+      cases.
+
+      A host receiving a Destination Unreachable message containing any
+      of these codes should recognize that it may result from a routing
+      transient.  The host should therefore interpret the message as
+      only a hint, not proof, that the specified destination is
+      unreachable.
+
+      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.
+
+
+
+
+
+
+Almquist                                                        [Page 8]
+
+
+
+RFC 1349                    Type of Service                    July 1992
+
+
+   6.2  Redirect
+
+      The ICMP Redirect message also includes a code, which specifies
+      the class of datagrams to which the Redirect applies.  There are
+      currently four codes defined:
+
+         0 -- redirect datagrams for the network
+         1 -- redirect datagrams for the host
+         2 -- redirect datagrams for the type of service and network
+         3 -- redirect datagrams for the type of service and host
+
+      A 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
+      on the path to the destination would be the same for any TOS
+      value.  In order to minimize the potential for host confusion,
+      routers should refrain from using codes 0 and 2 in Redirects
+      [3,6].
+
+      Although the current Internet Host specification [1] only requires
+      hosts to correctly handle code 0 and code 1 Redirects, a host
+      should also correctly handle code 2 and code 3 Redirects, as
+      described in Section 7.1 of this memo.  If a host does not, it is
+      better for the host to treat code 2 as equivalent to code 0 and
+      code 3 as equivalent to code 1 than for the host to simply ignore
+      code 2 and code 3 Redirects.
+
+7.  Use of the TOS Field in Routing
+
+   Both hosts and routers should consider the value of the TOS field of
+   a datagram when choosing an appropriate path to get the datagram to
+   its destination.  The mechanisms for doing so are discussed in this
+   section.
+
+   Whether a packet's TOS value actually affects the path it takes
+   inside of a particular routing domain is a choice made by the routing
+   domain's network manager.  In many routing domains the paths are
+   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 domain, the network manager may
+   choose to limit the size of the routing database and of routing
+   protocol updates by only defining routes for the default (0000) TOS.
+   Neither hosts nor routers should need to have any explicit knowledge
+   of whether TOS affects routing in the local routing domain.
+
+
+
+
+
+
+
+Almquist                                                        [Page 9]
+
+
+
+RFC 1349                    Type of Service                    July 1992
+
+
+   7.1  Host Routing
+
+      When a host (which is not also a router) wishes to send an IP
+      packet to a destination on another network or subnet, it needs to
+      choose an appropriate router to send the packet to.  According to
+      the IP Architecture, it does so by maintaining a route cache and a
+      list of default routers.  Each entry in the route cache lists a
+      destination (IP address) and the appropriate router to use to
+      reach that destination.  The host learns the information stored in
+      its route cache through the ICMP Redirect mechanism.  The host
+      learns the list of default routers either from static
+      configuration information or by using the ICMP Router Discovery
+      mechanism [8].  When the host wishes to send an IP packet, it
+      searches its route cache for a route matching the destination
+      address in the packet.  If one is found it is used; if not, the
+      packet is sent to one of the default routers.  All of this is
+      described in greater detail in section 3.3.1 of RFC-1122 [1].
+
+      Adding support for the TOS facility changes the host routing
+      procedure only slightly.  In the following, it is assumed that (in
+      accordance with the current Internet Host specification [1]) the
+      host treats code 0 (redirect datagrams for the network) Redirects
+      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) Redirects
+      as if they were code 3 (redirect datagrams for the host and type
+      of service) Redirects.  Readers considering violating these
+      assumptions should be aware that long and careful consideration of
+      the way in which Redirects are treated is necessary to avoid
+      situations where every packet sent to some destination provokes a
+      Redirect.  Because these assumptions match the recommendations of
+      Internet Host specification, that careful consideration is beyond
+      the scope of this memo.
+
+      As was described in Section 6.2, some 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:
+
+       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 (or
+      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 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 searches its route
+      cache again, this time looking for a type 2 entry whose
+      destination matches the destination address of the packet.  If
+      either of these searches finds a matching entry, the packet is
+      sent to the router listed in the matching entry.  Otherwise, the
+      packet is sent to one of the routers on the list of default
+      routers.
+
+      When a host creates (or updates) a type 2 entry, it must flush
+      from its route cache any type 1 entries which have the same
+      destination.  This is necessary for correctness, since the type 1
+      entry may be obsolete but would continue to be used if it weren't
+      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 same
+      destination.  In this case, the type 1 entry will properly
+      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 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
+      host would otherwise receive.  This savings can potentially be
+      substantial if one of the Redirects which was avoided would have
+      created a new type 2 entry (thereby causing the new type 1 entry
+      to be flushed).  That can happen, for example, if only some of the
+      routers on the local net are part of a routing domain that
+      computes separate routes for each TOS.
+
+      As an alternative, a host may treat all Redirects as if they were
+      code 3 (redirect datagrams for hosts and type of service)
+      Redirects.  This alternative allows the host to have only type 1
+      route cache entries, thereby simplifying route lookup and
+      eliminating the need for the rules in the previous two paragraphs.
+      The disadvantage of this approach is that it increases the size of
+      the route cache and the amount of Redirect traffic if the host
+      sends packets with a variety of requested TOS's to a destination
+      for which the 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
+      enough in practice to outweigh the simplicity of this approach.
+
+      Despite RFC-1122, some hosts acquire their routing information by
+      "wiretapping" a routing protocol instead of by using the
+
+
+
+Almquist                                                       [Page 11]
+
+
+
+RFC 1349                    Type of Service                    July 1992
+
+
+      mechanisms described above.  Such hosts will need to follow the
+      procedures described in Section 7.2 (except of course that hosts
+      will not send ICMP Destination Unreachables or ICMP Redirects).
+
+   7.2  Forwarding
+
+      A 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 does this is a part of the
+      more general issue of how a router picks appropriate paths.  This
+      larger issue can be extremely complex [4], and is beyond the scope
+      of this memo.  This discussion should therefore be considered only
+      an overview.  Implementors should consult the Router Requirements
+      specification [3] and the the specifications of the routing
+      protocols they implement for details.
+
+      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
+      field in an IP datagram (including those values whose 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
+      always assigned the default TOS value (0000).  Static routes have
+      their TOS values assigned by the network manager.
+
+      When a router wants to forward a packet, it first looks up the
+      destination address in its forwarding table.  This yields a set of
+      candidate routes.  The set may be empty (if the destination is
+      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
+      TOS exactly matches the TOS field of the packet being forwarded
+      then that route is chosen.  If not but the set contains a route
+      with the default TOS then that route is chosen.
+
+      If no route is found, or if the the chosen route has an infinite
+      metric, the destination is considered to be unreachable.  The
+      packet is discarded and an ICMP Destination Unreachable is
+      returned to the source.  Normally, the Unreachable uses code 0
+      (Network unreachable) or 1 (Host unreachable).  If, however, a
+      route to the destination exists which has a different TOS value
+      and a non-infinite metric then code 11 (Network unreachable for
+      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 TOS
+
+   The TOS field in a datagram primarily affects the path chosen through
+   the network, but an implementor may choose to have TOS also affect
+   other aspects of how the datagram is handled.  For example, a host or
+   router might choose to give preferential queuing on network output
+   queues to datagrams which have requested that delay be minimized.
+   Similarly, a router forced by overload to discard packets might
+   attempt to avoid discarding packets that have requested that
+   reliability be maximized.  At least one paper [14] has explored these
+   ideas in some detail, but little is known about how well such special
+   handling would work in practice.
+
+   Additionally, some Link Layer protocols have their own quality of
+   service mechanisms.  When a router or host transmits an IP packet, it
+   might request from the Link Layer 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) was made to codify how this might be
+   done, but that document describes Link Layer protocols which have
+   since become obsolete and no more recent document on the subject has
+   been written.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Almquist                                                       [Page 13]
+
+
+
+RFC 1349                    Type of Service                    July 1992
+
+
+APPENDIX A.  Updates to Other Specifications
+
+   While this memo is primarily an update to the IP protocol
+   specification [11], it also peripherally affects a number of other
+   specifications.  This appendix describes those peripheral effects.
+   This information is included in an appendix rather than in the main
+   body of the document because most if not all of these other
+   specifications will be updated in the future.  As that happens, the
+   information included in this appendix will become obsolete.
+
+   A.1  RFC-792 (ICMP)
+
+      RFC-792 [12] defines a set of codes indicating reasons why a
+      destination is unreachable.  This memo describes the use of two
+      additional codes:
+
+        11 -- network unreachable for type of service
+        12 -- host unreachable for type of service
+
+      These codes were defined in RFC-1122 [1] but were not included in
+      RFC-792.
+
+   A.2  RFC-1060 (Assigned Numbers)
+
+      RFC-1060 [15] describes the old interpretation of the TOS field
+      (as three independent bits, with no way to specify that monetary
+      cost should be minimized).  Although it is likely obvious how the
+      values in RFC-1060 ought to be interpreted in light of this memo,
+      the information from that RFC is reproduced here.  The only actual
+      changes are for ICMP (to conform to Section 5.1 of this memo) and
+      NNTP:
+
+                        ----- Type-of-Service Value -----
+
+         Protocol           TOS Value
+
+         TELNET (1)         1000                 (minimize delay)
+
+         FTP
+           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 Value
+
+         Domain Name Service
+           UDP Query        1000                 (minimize delay)
+           TCP Query        0000
+           Zone Transfer    0100                 (maximize throughput)
+
+         NNTP               0001                 (minimize monetary cost)
+
+         ICMP
+           Errors           0000
+           Requests         0000 (4)
+           Responses        <same as request> (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 TOS
+              during the lifetime of the connection, then the
+              recommended TOS on opening the connection is the default
+              TOS (0000).
+
+          (4) Although 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 response
+              always uses the same TOS value as was used in the
+              corresponding ICMP request message.  See Section 5.1 of
+              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 revision
+         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 in
+      RFC-1122 [1] and RFC-1123 [2].  The information provided there is
+      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 refer
+           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-zero
+           value (but still must not set bit 7 to a non-zero value).
+
+      These details will presumably be corrected in the next revision of
+      the Host Requirements specification, at which time this appendix
+      can be considered obsolete.
+
+   A.4  RFC-1195 (Integrated IS-IS)
+
+      Integrated IS-IS (sometimes known as Dual IS-IS) has multiple
+      metrics for each route.  Which of the metrics is used to 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-1195 [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.
+      Although the specification in this memo is intended to be
+      substantially compatible with Integrated IS-IS, the extension of
+      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:
+
+         The IP TOS octet is mapped onto the four available metrics as
+         follows:
+
+         Bits 0-2 (Precedence): (unchanged from RFC-1195)
+
+         Bits 3-6 (TOS):
+
+            0000    (all normal)               Use default metric
+            1000    (minimize delay)           Use delay metric
+            0100    (maximize throughput)      Use default metric
+            0010    (maximize reliability)     Use reliability metric
+            0001    (minimize monetary cost)   Use cost metric
+            other                              Use default metric
+
+         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-IS
+      specification will include this corrected table, at which time
+      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 be
+      substantially compatible with OSPF, the extension of the TOS field
+      to four 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 [10].  The encoding is
+      summarized in Table 17 of that memo; what follows is an updated
+      version of table 17.  The numbers in the first column are decimal
+      integers, and the numbers in the second column are binary TOS
+      values:
+
+                OSPF encoding   TOS
+                _____________________________________________
+
+                0               0000   normal service
+                2               0001   minimize monetary cost
+                4               0010   maximize reliability
+                6               0011
+                8               0100   maximize throughput
+                10              0101
+                12              0110
+                14              0111
+                16              1000   minimize delay
+                18              1001
+                20              1010
+                22              1011
+                24              1100
+                26              1101
+                28              1110
+                30              1111
+
+      The OSPF MIB, described in RFC-1248 [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 of TOS values as 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).
+
+      If RFC-1247 and RFC-1248 are revised in the future, it is expected
+      that this information will be incorporated into the revised
+      versions.  At that time, this appendix may be considered obsolete.
+
+
+
+
+Almquist                                                       [Page 17]
+
+
+
+RFC 1349                    Type of Service                    July 1992
+
+
+APPENDIX B.  Rationale
+
+   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.  While this memo
+   does amend the facility in some small and carefully considered ways
+   discussed below, the desirability of compatibility with existing
+   specifications and uses of the TOS facility [1,2,7,10,11] was never
+   in doubt.  This goal of backwards compatibility determined the broad
+   outlines and many of the details of this specification.
+
+   Much of the rest of this specification was determined by two
+   additional goals, which were described more fully in Section 2.  The
+   first was that hosts should never be penalized for using the TOS
+   facility, since that would likely ensure that it would never be
+   widely deployed.  The second was that the specification should make
+   it easy, or at least possible, to define and deploy new types of
+   service in the future.
+
+   The three goals above did not eliminate all need for engineering
+   choices, however, and in a few cases the goals proved to be in
+   conflict with each other.  The remainder of this appendix discusses
+   the rationale behind some of these engineering choices.
+
+   B.1  The Minimize Monetary Cost TOS Value
+
+      Because the Internet is becoming increasingly commercialized, a
+      number of participants in the IETF's 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 (cost = 0)
+      rather than merely requesting that some 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.  Also, it would not be helpful to users who
+      want their packets to travel via the least-cost path but can
+      accept some level of cost when necessary.  Finally, since whether
+      any particular routing domain considers the TOS field when routing
+
+
+
+Almquist                                                       [Page 18]
+
+
+
+RFC 1349                    Type of Service                    July 1992
+
+
+      is a choice made by the network manager, a user requiring a free
+      path might not get one if the packet has to pass through a routing
+      domain that does not consider TOS in its 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
+      and turns out to have an additional interesting quirk: because of
+      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.  Thus, such a TOS value would almost be
+      equivalent to a "maximize monetary cost" value!
+
+      It seems likely that in the future users may need some mechanism
+      to express the maximum amount they are willing to pay to have a
+      packet delivered.  However, an IP option would be a more
+      appropriate mechanism, since there are precedents for having IP
+      options that all routers are required to honor, and an 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 requesting that the network
+           "minimize monetary cost"
+
+       (2) To remain as compatible as possible with existing
+           specifications and uses of the TOS facility
+
+       (3) To allow for the definition and deployment of new 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
+      for routing to work correctly when new types of service are
+      deployed.  If routers have different ideas about the size of the
+      TOS field they make inconsistent decisions that may lead to
+      routing loops.
+
+      At first glance goals (3) and (4) seem to be pretty much mutually
+      exclusive.  The IP header currently has only three unused bits, so
+      at most three new type of service bits could be defined without
+      resorting to the impractical step of changing the IP header
+
+
+
+Almquist                                                       [Page 19]
+
+
+
+RFC 1349                    Type of Service                    July 1992
+
+
+      format.  Since one of them would need to be allocated to meet goal
+      (1), at most two bits could be reserved for new or experimental
+      types of service.  Not only is it questionable whether two would
+      be enough, but it is improbable that the IETF and IAB would allow
+      all of the currently unused bits to be permanently reserved for
+      types of service which might or might or might not ever be
+      defined.
+
+      However, some (if not most of) the possible combinations of the
+      individual bits would not be useful.  Clearly, setting all of the
+      bits would be equivalent to setting none of the bits, since
+      setting all of the bits would indicate that none of the types of
+      optimization was any more important than any of the others.
+      Although one could perhaps assign reasonable semantics to most
+      pairs of bits, it is unclear that the range of network service
+      provided by various paths could usefully be subdivided in so fine
+      a manner.  If some of these non-useful combinations of bits could
+      be assigned to new types of service then it would be possible to
+      meet goal (3) and goal (4) without having to use up all of the
+      remaining 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.
+
+      The integers were chosen to be compatible with the bit definitions
+      found in RFC-791.  Thus, for example, setting the TOS field to
+      1000 (minimize delay) sets bit 3 of the Type of Service octet; bit
+      3 is defined as the Low Delay bit in RFC-791.  This memo only
+      defines values which correspond to setting a single one of the
+      RFC-791 bits, since setting multiple TOS bits does not seem to be
+      a common practice.  According to [15], none of the common TCP/IP
+      applications currently set multiple TOS bits.  However, TOS values
+      corresponding to particular combinations of the RFC-791 bits could
+      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
+      one which left all of the RFC-791 bits clear.  That would require
+      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
+      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 three bit TOS field and others 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 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.
+
+
+
+Almquist                                                       [Page 20]
+
+
+
+RFC 1349                    Type of Service                    July 1992
+
+
+      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
+      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, but would reduce to one the
+      number of reserved bits in the IP header.  Expanding the TOS field
+      to four bits would restrict future expansion to more modest levels
+      (11 new TOS values), but would leave an additional IP header bit
+      free.  The IETF's Router Requirements Working Group concluded that
+      a four bits wide TOS field allow enough values for future use and
+      that consistency with Host Requirements was inadequate
+      justification for unnecessarily increasing the size of the TOS
+      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
+
+
+
+Almquist                                                       [Page 21]
+
+
+
+RFC 1349                    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.
+
+
+
+
+Almquist                                                       [Page 22]
+
+
+
+RFC 1349                    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.
+
+
+
+
+Almquist                                                       [Page 23]
+
+
+
+RFC 1349                    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:
+
+
+
+
+Almquist                                                       [Page 24]
+
+
+
+RFC 1349                    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
+
+
+
+Almquist                                                       [Page 25]
+
+
+
+RFC 1349                    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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Almquist                                                       [Page 26]
+
+
+
+RFC 1349                    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",
+        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 Information
+        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 Dual
+        Environments", RFC 1195, Digital Equipment Corporation, December
+        1990.
+
+  [8]   Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
+        PARC, September 1991.
+
+  [9]   Mogul, J. and J. Postel, "Internet Standard Subnetting
+        Procedure", RFC 950, USC/Information Sciences Institute, August
+        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 Sciences
+        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
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Almquist                                                       [Page 28]
+