rfc1349.txt

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

   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