rfc1349.txt

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

         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