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