📄 rfc1349.txt
字号:
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)
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
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -