rfc1349.txt

中、英文RFC文档大全打包下载完全版 .

      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)