rfc1349.txt

RFC 的详细文档！

      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