rfc1349.txt

RFC 的详细文档！

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]