Bit
Click on the red underlined text to get to the source
... instead delivers it the same way it would have been delivered had
none of the TOS bits been set.
Even though the TOS ...
... zero (unless participating in an Internet protocol experiment which
makes use of that bit). Routers and recipients of datagrams ignore
...
... TOS
field. RFC-791std5 defined it as a three bit field, including bits 3-5
in the figure above. It included bit ...
... field. RFC-791std5 defined it as a three bit field, including bits 3-5
in the figure above. It included bit 6 in the MBZ field. RFC-1122std3 ...
... bit field, including bits 3-5
in the figure above. It included bit 6 in the MBZ field. RFC-1122std3
added bits ...
... bit 6 in the MBZ field. RFC-1122std3
added bits 6 and 7 to the TOS field, eliminating the MBZ field. This
memo redefines the TOS ...
... 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 ...
... 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.
...
... As was stated just above, this memo redefines the TOS field as a four
bit field. Also contrary to RFC-791std5, this memo defines the TOS field
...
... 791std5, 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 ...
... 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 ...
... Because this specification redefines TOS values to be integers rather
than sets of bits, computing the logical OR of two TOS values is no
...
... 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(-> 1340(-> 1700hist(-> 3232))) ...
... (1) The TOS field is four bits wide rather than five bits wide.
The requirements that refer to the TOS ...
... requirements that refer to the TOS field should refer
only to the four bits that make up the TOS field.
...
... 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
...
... OSPF, the extension of the TOS field
to four bits requires minor modifications to the section that
describes the encoding of TOS ...
... 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 ...
...
There were four goals that guided the decision to have a four bit
TOS field and the specification of that field's values:
...
... 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 ...
... bits, so
at most three new type of service bits could be defined without
resorting to the impractical step of changing the IP header
...
...
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 ...
... 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
...
...
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 ...
... 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 ...
... 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
...
... 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 ...
... Although one could perhaps assign reasonable semantics to most
pairs of bits, it is unclear that the range of network service
...
... 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
...
... 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 ...
... 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 ...
... bits.
The integers were chosen to be compatible with the bit definitions
found in RFC-791std5. Thus, for example, setting the TOS ...
... 791std5. Thus, for example, setting the TOS field to
1000 (minimize delay) sets bit 3 of the Type of Service octet; bit
...
... 1000 (minimize delay) sets bit 3 of the Type of Service octet; bit
3 is defined as the Low Delay bit in RFC-791std5 ...
... Type of Service octet; bit
3 is defined as the Low Delay bit in RFC-791std5. This memo only
defines values which correspond to setting a single one of the
...
... defines values which correspond to setting a single one of the
RFC-791std5 bits, since setting multiple TOS bits does not seem to be
...
... 791std5 bits, since setting multiple TOS bits does not seem to be
a common practice. According to [15], none of the common TCP/IP ...
... TCP/IP
applications currently set multiple TOS bits. However, TOS values
corresponding to particular combinations of the RFC-791std5 ...
... TOS values
corresponding to particular combinations of the RFC-791std5 bits could
be defined if and when they are determined to be useful.
...
... implementations. This seemed to imply that the value should be
one which left all of the RFC-791std5 bits clear. That would require
expanding the TOS field, but would allow old implementations to
...
... 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 ...
... 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.
...
... 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
...
... Host Requirements, but would reduce to one the
number of reserved bits in the IP header. Expanding the TOS field
...
... 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 ...
... Requirements Working Group concluded that
a four bits wide TOS field allow enough values for future use and
that consistency ...