RFC 1349
Type of Service in the Internet Protocol Suite
RFC 1349: Type of Service in the Internet Protocol Suite 🎀
Okay bestie, the vibes first 🧚. This one comes from the Network Working Group and was written by P. Almquist, a Consultant, in July 1992 📅. It's an IAB standards track protocol, and it updates a whole list of older RFCs: RFCs 1248, 1247, 1195, 1123, 1122, 1060, and 791. The header doesn't list any RFCs it obsoletes 🫶.
Status of This Memo 💅
Here's the official vibe check: this doc specifies an IAB standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements. For the standardization state and status of this protocol, go check the current edition of the "IAB Official Protocol Standards." Distribution of this memo is unlimited 🦋.
Summary 💜
Okay so this memo changes and clarifies some of the semantics of the Type of Service octet in the Internet Protocol (IP) header. It goes into a lot of detail about how both hosts and routers handle IP Type of Service 🔥.
It defines a brand-new TOS value that asks the network to minimize the monetary cost of transmitting a datagram 💸. A bunch of other new TOS values are reserved for future experimentation and standardization 🧪. The ability to ask for transmission to be optimized along multiple axes (which used to happen by setting multiple TOS bits at once) is gone 💀. So for example, one datagram can no longer ask the network to minimize delay and maximize throughput at the same time. Not it 🙈.
Also, there's a minor conflict between the Host Requirements (RFC-1122 and RFC-1123) and a bunch of other standards about 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
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 ............................................... 281. Introduction ✨
Okay, paths through the Internet are wildly different in quality of service 🌈. Some are more reliable than others. Some impose high call setup or per-packet charges, while others don't do usage-based charging 💸. Throughput and delay vary a lot too. There are tradeoffs: the path with the highest throughput might not be the one with the lowest delay or the lowest monetary cost. So the "optimal" path for a packet can depend on what the application and its user actually need 🤔.
The Internet itself has no direct knowledge of how to optimize the path for a particular application or user. So the IP protocol [11] gives upper layer protocols a (rather limited 😬) facility for dropping hints to the Internet Layer about how the tradeoffs should be made for a particular packet. This is the "Type of Service" facility, which this memo abbreviates as the "TOS facility" 🫶.
The TOS facility has been part of the IP spec since the very beginning, but it's been barely used 😭. That's changing. The Internet host specification [1,2] now mandates that hosts use the TOS facility. Plus, routing protocols (including OSPF [10] and Integrated IS-IS [7]) have been developed that 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 spec defines in detail how hosts and routers use the TOS facility. Section 2 introduces the main considerations behind the design choices. Sections 3 and 4 describe the Type of Service octet in the IP header and the values the TOS field of that octet may contain. Section 5 describes how a host (or router) picks appropriate values to put in 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 TOS may optionally affect packet processing. Appendix A describes how this spec updates a bunch of existing specifications. Appendices B and C expand on the discussion in Section 2 🗺️.
2. Goals and Philosophy 🌸
The fundamental rule behind this whole spec 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) what it would have been without using the facility ✨. This goal was seen as super important, because any spec that didn't meet it, no matter how good it was otherwise, was unlikely to ever get widely deployed and used 😤. A particular consequence is that if a network can't provide the TOS requested in a packet, the network does not discard the packet 🙅♀️. Instead, it delivers the packet the same way it would have been delivered had none of the TOS bits been set.
Even though the TOS facility hasn't been widely used in the past, this memo aims to be as compatible as possible with existing practice 🧩. Mainly that means existing host implementations should not interact badly with hosts and routers that implement the specifications of this memo, since TOS support is almost non-existent in routers that predate this spec 🙈. However, this memo does try to stay compatible with how IP TOS is treated in OSPF and Integrated IS-IS.
Because the Internet community doesn't have much experience with TOS, this spec needs to allow easy definition and deployment of new and experimental types of service 🧪. This goal had a big impact. It led to the decision to permanently fix 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 gives a more detailed explanation of the rationale behind particular aspects of this spec 📚.
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, shown here:
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 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's 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, and 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 ✨
okay so, like we said up above, this memo makes the TOS field a four bit field 🫶. And unlike RFC-791 (which treated it as a bunch of bits, each with its own meaning), this memo treats the TOS field as ONE enumerated value 💅. These are the five values this memo gives meaning to, written in binary:
1000 -- minimize delay
0100 -- maximize throughput
0010 -- maximize reliability
0001 -- minimize monetary cost
0000 -- normal serviceThe values in the TOS field are called "TOS values" in this memo, and whatever is in the TOS field of an IP packet is the "requested TOS" 📦. The TOS field value 0000 is the "default TOS." 🌸
Here's the thing: since this spec makes TOS values integers instead of sets of bits, computing the logical OR of two TOS values is no longer meaningful 🙅♀️. Like, it would be a serious error for a router to pick a low delay path for a packet whose requested TOS was 1110 just because it noticed the old "delay bit" was set 💀.
Values other than those five aren't defined by this memo, but they're still perfectly legal TOS values, and hosts and routers MUST NOT preclude their use in any way 🙌. As you'll see, only the default TOS is special. A host or router need not (and except as described in Section 8, SHOULD NOT) make any distinction between TOS values this memo defines and the ones it doesn't 🫠.
Now, pay attention to the words "minimize" and "maximize" in the value definitions, because they're important 👀. Setting the TOS field to 1000 (minimize delay) does NOT guarantee that the path will have a delay the user considers "low" 😭. The network will try to choose the lowest delay path it knows about, based on its (often imperfect) info about path delay. The network won't drop the datagram just because it thinks the available paths have "too high" delay. (The network manager can override this through creative use of routing metrics, but that's strongly discouraged: setting the TOS field is meant to give better service when it's available, not to deny service when it isn't) 🙈
5. Use of the TOS Field in the Internet Protocols 🌈
For the TOS facility to be useful, the TOS fields in IP packets MUST be filled in with reasonable values 🎀. This section is about how the protocols above IP pick good ones.
5.1. Internet Control Message Protocol (ICMP) 🧚
ICMP [8,9,12] defines a bunch of messages for error reporting and diagnostic functions at the Internet Layer 🔍. This section explains how a host or router picks TOS values for the ICMP messages it originates. TOS also affects the origination and processing of ICMP Redirects and ICMP Destination Unreachables, but that's the tea in Section 6 ☕.
To make this easier to talk about, we split ICMP messages into three classes:
- ICMP error messages include ICMP message types 3 (Destination Unreachable), 4 (Source Quench), 5 (Redirect), 11 (Time Exceeded), and 12 (Parameter Problem).
- ICMP request messages include ICMP message types 8 (Echo), 10 (Router Solicitation), 13 (Timestamp), 15 (Information Request -- now obsolete), and 17 (Address Mask Request).
- ICMP reply messages include ICMP message types 0 (Echo Reply), 9 (Router Advertisement), 14 (Timestamp Reply), 16 (Information Reply -- also obsolete), and 18 (Address Mask Reply).
An ICMP error message is always sent with the default TOS (0000) 💖.
An ICMP request message MAY be sent with any value in the TOS field ✨. A mechanism that lets the user specify the TOS value to be used would be a useful feature in lots of applications that generate ICMP request messages 💡.
An ICMP reply message is sent with the same TOS value that was used in the corresponding ICMP request message 🔁.
5.2. Transport Protocols 🚚
When sending a datagram, a transport protocol uses the TOS the application requested 💌. There's no requirement that both ends of a transport connection use the same TOS 🙃. For example, the sending side of a bulk data transfer application SHOULD request that throughput be maximized, whereas the receiving side might request that delay be minimized (assuming it's mostly sending small acknowledgement packets) 📦. It may be useful for a transport protocol to give applications a way to learn the TOS value that came with the most recently received data 👀.
It is quite permissible to switch to a different TOS in the middle of a connection if the nature of the traffic changes 🔀. SMTP is the classic example: it spends part of its time doing bulk data transfer and part of its time swapping short command messages and responses 📬.
TCP [13] SHOULD use the same TOS for datagrams containing only TCP control information as it does for datagrams containing user data 🧠. I know it might seem intuitively correct to always ask the network to minimize delay for segments that contain acknowledgements but no data, but doing so could corrupt TCP's round trip time estimates 😵.
5.3. Application Protocols 📱
Applications are responsible for choosing appropriate TOS values for any traffic they originate 👩💻. The Assigned Numbers document [15] lists the TOS values to be used by a number of common network applications 📖. For other applications, it's the responsibility of the application's designer or programmer to make a suitable choice, based on the nature of the traffic the application originates 🧑💻.
It is essential for many sorts of network diagnostic applications, and desirable for other applications, that the user of the application be able to override the TOS value(s) the application would otherwise choose 🛠️.
The Assigned Numbers document gets revised and reissued periodically 🗓️. Until RFC-1060, the edition current as this is being written, has been superseded, so readers SHOULD consult Appendix A.2 of this memo 📚.
6. ICMP and the TOS Facility 🎭
Routers communicate routing information to hosts using the ICMP protocol [12] 🗺️. This section describes how support for the TOS facility affects the origination and interpretation of ICMP Redirect messages and certain types of ICMP Destination Unreachable messages 🧭. This memo does not define any new extensions to ICMP 🙅♀️.
6.1. Destination Unreachable 🚫
The ICMP Destination Unreachable message contains a code that describes why the destination is unreachable. There are four codes [1,12] that are especially relevant to this memo:
0 -- network unreachable
1 -- host unreachable
11 -- network unreachable for type of service
12 -- host unreachable for type of serviceA router generates a code 11 or code 12 Destination Unreachable when an unreachable destination (network or host) would have been reachable had a different TOS value been specified 🤯. A router generates a code 0 or code 1 Destination Unreachable in other cases.
A host receiving a Destination Unreachable message containing any of these codes SHOULD recognize that it may result from a routing transient 🌊. The host SHOULD therefore interpret the message as only a hint, not proof, that the specified destination is unreachable 🤏.
The use of codes 11 and 12 may seem contrary to the statement in Section 2 that packets SHOULD NOT be discarded simply because the requested TOS cannot be provided 🤔. The reasoning behind these codes, and the limited cases in which they're expected to be used, are described in Appendix B.5 📎.
6.2. Redirect 🔀
The ICMP Redirect message also includes a code, which specifies the class of datagrams the Redirect applies to. There are currently four codes defined:
0 -- redirect datagrams for the network
1 -- redirect datagrams for the host
2 -- redirect datagrams for the type of service and network
3 -- redirect datagrams for the type of service and hostA router generates a code 3 Redirect when the Redirect applies only to IP packets that request a particular TOS value 🎯. A router generates a code 1 Redirect instead when the optimal next hop on the path to the destination would be the same for any TOS value 🛤️. To minimize the potential for host confusion, routers SHOULD refrain from using codes 0 and 2 in Redirects [3,6] 🙏.
Although the current Internet Host specification [1] only requires hosts to correctly handle code 0 and code 1 Redirects, a host SHOULD also correctly handle code 2 and code 3 Redirects, as described in Section 7.1 of this memo 💅. If a host does not, it is better for the host to treat code 2 as equivalent to code 0 and code 3 as equivalent to code 1 than for the host to simply ignore code 2 and code 3 Redirects 🫶.
7. Use of the TOS Field in Routing ✨
okay bestie, hosts AND routers SHOULD both look at the TOS field of a datagram when they pick a path to get it to its destination 🧚 this section is all about the mechanisms for doing that 💅
whether a packet's TOS value actually changes the path it takes inside a routing domain is totally up to that domain's network manager 👑 in lots of routing domains the paths are pretty much the same everywhere, so there's no real reason for routers to pick different paths based on TOS 🌸 inside a domain like that, the manager MAY choose to keep the routing database and routing protocol updates small by only defining routes for the default (0000) TOS. and honestly, neither hosts nor routers SHOULD need any explicit knowledge of whether TOS affects routing in the local routing domain 🫶
7.1. Host Routing
okay so picture a host (a machine that is NOT also a router) that wants to send an IP packet to a destination on another network or subnet 🦋 it has to pick a good router to hand the packet to. the IP Architecture says it does this by keeping a route cache and a list of default routers. each route cache entry lists a destination (IP address) and the right router to use to reach it. the host learns what goes in its route cache through the ICMP Redirect mechanism, and it learns its default routers either from static configuration or through ICMP Router Discovery [8]. when it has a packet to send, it searches the route cache for a route matching the packet's destination address. if it finds one, it uses it; if not, the packet goes to one of the default routers. all of this is explained in more detail in section 3.3.1 of RFC-1122 [1] 📚
adding TOS support only changes the host routing procedure a tiny bit ✨ here we assume that (following the current Internet Host specification [1]) the host treats code 0 (redirect datagrams for the network) Redirects as if they were code 1 (redirect datagrams for the host) Redirects. similarly, we assume the host treats code 2 (redirect datagrams for the network and type of service) Redirects as if they were code 3 (redirect datagrams for the host and type of service) Redirects.
😭 if you're thinking about breaking these assumptions, you SHOULD be aware that long and careful consideration of how Redirects are treated is necessary, so you don't end up in a situation where every packet sent to some destination provokes a Redirect.
because these assumptions match the recommendations of the Internet Host specification, that careful consideration is beyond the scope of this memo 💀
as we covered in Section 6.2, some ICMP Redirects only apply to IP packets that request a particular TOS. so a host (at least in theory) needs to store two types of entries in its route cache:
type 1: { destination, TOS, router }
type 2: { destination, *, router }where type 1 entries come from receiving code 3 (or code 1) Redirects, and type 2 entries come from receiving code 2 (or code 0) Redirects.
when a host wants to send a packet, it first searches the route cache for a type 1 entry whose destination matches the packet's destination address AND whose TOS matches the requested TOS in the packet 🎀 if it doesn't find one, it searches the route cache again, this time looking for a type 2 entry whose destination matches the packet's destination address. if either search finds a matching entry, the packet goes to the router listed in that entry. otherwise, the packet goes to one of the routers on the list of default routers.
when a host creates (or updates) a type 2 entry, it MUST flush from its route cache any type 1 entries that have the same destination. this is necessary for correctness, since the type 1 entry MAY be obsolete but would keep getting used if it weren't flushed, because type 1 entries are always preferred over type 2 entries 🔥
however, the converse is not true: when a host creates a type 1 entry, it SHOULD NOT flush a type 2 entry that has the same destination 🍓 in this case the type 1 entry will properly override the type 2 entry for packets whose destination address and requested TOS match the type 1 entry. because the type 2 entry MAY well specify the correct router for TOS values other than the one in the type 1 entry, keeping it will likely cut down on the number of Redirects the host would otherwise get. that savings can be substantial if one of the avoided Redirects would have created a new type 2 entry (which would then flush the new type 1 entry). that can happen, for example, if only some of the routers on the local net are part of a routing domain that computes separate routes for each TOS.
as an alternative, a host MAY treat all Redirects as if they were code 3 (redirect datagrams for hosts and type of service) Redirects 🦋 this lets the host keep only type 1 route cache entries, which simplifies route lookup and gets rid of the need for the rules in the previous two paragraphs. the downside is that it increases the size of the route cache and the amount of Redirect traffic if the host sends packets with a variety of requested TOS values to a destination where the host SHOULD use the same router regardless of the requested TOS. there isn't yet enough experience with the TOS facility to know whether that downside would be serious enough in practice to outweigh the simplicity of this approach.
despite RFC-1122, some hosts get their routing information by "wiretapping" a routing protocol instead of using the mechanisms described above. such hosts will need to follow the procedures in Section 7.2 (except, of course, that hosts will not send ICMP Destination Unreachables or ICMP Redirects) 🙈
7.2. Forwarding
a router in the Internet SHOULD be able to consider the TOS field when choosing the path it forwards an IP packet over 💖 how a router does this is part of the bigger question of how a router picks appropriate paths. that bigger question can be extremely complex [4], and it's beyond the scope of this memo, so this discussion SHOULD therefore be treated as just an overview. implementors SHOULD consult the Router Requirements specification [3] and the specifications of the routing protocols they implement for details.
a router associates a TOS value with each route in its forwarding table ✨ the value can be any of the possible values of the TOS field in an IP datagram (including values whose semantics are yet to be defined). any routes learned using routing protocols that support TOS get an appropriate TOS value from those protocols. routes learned using other routing protocols always get the default TOS value (0000). static routes get their TOS values from the network manager.
when a router wants to forward a packet, it first looks up the destination address in its forwarding table 🧚 this gives a set of candidate routes. the set MAY be empty (if the destination is unreachable), or it MAY contain one or more routes to the destination. if the set is not empty, the TOS values of the routes in it get examined. if the set contains a route whose TOS exactly matches the TOS field of the packet being forwarded, that route is chosen. if not, but the set contains a route with the default TOS, that route is chosen.
if no route is found, or if the chosen route has an infinite metric, the destination is considered to be unreachable 💀 the packet is discarded and an ICMP Destination Unreachable is returned to the source. normally the Unreachable uses code 0 (Network unreachable) or 1 (Host unreachable). however, if a route to the destination exists that has a different TOS value and a non-infinite metric, then code 11 (Network unreachable for type of service) or code 12 (Host unreachable for type of service) MUST be used instead 🔥
8. Other consequences of TOS ✨
the TOS field in a datagram mainly affects the path chosen through the network, but an implementor MAY choose to have TOS also affect other aspects of how the datagram is handled 👑 for example, a host or router might choose to give preferential queuing on network output queues to datagrams that have requested that delay be minimized. similarly, a router forced by overload to discard packets might attempt to avoid discarding packets that have requested that reliability be maximized. at least one paper [14] has explored these ideas in some detail, but little is known about how well such special handling would work in practice 🌈
also, some Link Layer protocols have their own quality of service mechanisms 🌸 when a router or host transmits an IP packet, it might request a quality of service from the Link Layer that is as close as possible to the one requested in the TOS field of the IP header. long ago an attempt (RFC-795) was made to codify how this might be done, but that document describes Link Layer protocols that have since become obsolete, and no more recent document on the subject has been written 🥺
APPENDIX A. Updates to Other Specifications ✨
okay so this memo is mainly an update to the IP spec [11], but it also has little side effects on a bunch of other specs 🦋 this appendix lists those side effects. it's in an appendix instead of the main body because most (if not all) of those other specs are gonna get updated later. once that happens, everything in here becomes obsolete 💅
A.1 RFC-792 (ICMP) 🌸
RFC-792 [12] defines a set of codes that say why a destination is unreachable. this memo adds two more codes, bestie:
11 -- network unreachable for type of service
12 -- host unreachable for type of servicethese codes were defined in RFC-1122 [1] but never made it into RFC-792 😭
A.2 RFC-1060 (Assigned Numbers) 🎀
RFC-1060 [15] describes the old way of reading the TOS field, where it's three independent bits and there's no way to say "minimize monetary cost" 💀 it's probably pretty obvious how RFC-1060's values should be read now that this memo exists, but we're copying that info here anyway. the only real changes are for ICMP (to match Section 5.1 of this memo) and NNTP 💜
----- Type-of-Service Value -----
Protocol TOS Value
TELNET (1) 1000 (minimize delay)
FTP
Control 1000 (minimize delay)
Data (2) 0100 (maximize throughput)
TFTP 1000 (minimize delay)
SMTP (3)
Command phase 1000 (minimize delay)
DATA phase 0100 (maximize throughput) ----- Type-of-Service Value -----
Protocol TOS Value
Domain Name Service
UDP Query 1000 (minimize delay)
TCP Query 0000
Zone Transfer 0100 (maximize throughput)
NNTP 0001 (minimize monetary cost)
ICMP
Errors 0000
Requests 0000 (4)
Responses <same as request> (4)
Any IGP 0010 (maximize reliability)
EGP 0000
SNMP 0010 (maximize reliability)
BOOTP 0000here's what the notes say 🧐
- (1) this covers all the interactive user protocols (e.g., rlogin) 🖥️
- (2) this covers all the bulk data transfer protocols (e.g., rcp) 📦
- (3) if the implementation can't change the TOS during the life of the connection, then the recommended TOS when you open the connection is the default TOS (0000) 🙈
- (4) ICMP request messages are normally sent with the default TOS, but sometimes there are good reasons to send them with a different TOS value. an ICMP response always uses the same TOS value as the request it's answering. see Section 5.1 of this memo 🫶
an application may (at the request of the user) swap in 0001 (minimize monetary cost) for any of the values above ✨
this appendix is expected to be obsoleted by the next revision of the Assigned Numbers document 🥀
A.3 RFC-1122 and RFC-1123 (Host Requirements) 🍓
hosts use the TOS field in a lot of detail, and that's covered in RFC-1122 [1] and RFC-1123 [2]. the info there is still correct, except for these two things:
- the TOS field is four bits wide, not five bits wide. any requirements that mention the TOS field should only mean the four bits that make up the TOS field 🔥
- an application may set bit 6 of the TOS octet to a non-zero value, but it still must not set bit 7 to a non-zero value 💅
these details will probably get fixed in the next revision of the Host Requirements spec, and then this appendix can be considered obsolete 🌈
A.4 RFC-1195 (Integrated IS-IS) 🧚
Integrated IS-IS (sometimes called Dual IS-IS) has multiple metrics for each route 👑 which metric gets used to route a particular IP packet is decided by the TOS field in that packet. this is described in detail in section 3.5 of RFC-1195 [7] 💖
the mapping from the TOS field value to the right Integrated IS-IS metric is a table in that section. this memo is supposed to be pretty compatible with Integrated IS-IS, but making the TOS field four bits and adding a TOS value for "minimize monetary cost" means that table needs small tweaks, 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.the next revision of the Integrated IS-IS spec is expected to include this corrected table, and then this appendix can be considered obsolete 🫶
A.5 RFC-1247 (OSPF) and RFC-1248 (OSPF MIB) 🌷
this memo is supposed to be pretty compatible with OSPF too, but making the TOS field four bits means the section about encoding TOS values in Link State Advertisements needs small changes 🦋 that section is described in section 12.3 of RFC-1247 [10]. the encoding is summed up in Table 17 of that memo, and what comes next 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 1111the OSPF MIB, described in RFC-1248 [5], is totally consistent with this memo except for one text comment about how the old TOS flag bits map into TOSType values 🙈 TOSType values use the same encoding of TOS values as OSPF's Link State Advertisements, so the table above also shows the mapping between TOSType values (the first column) and TOS field values (the second column) 💜
if RFC-1247 and RFC-1248 get revised in the future, this info is expected to be folded into those revised versions. at that point, this appendix may be considered obsolete 🌸
APPENDIX B. Rationale 🧠
the main body of this memo explained how the TOS facility works. this appendix is for anyone who's wondering why it works that way 🤔
a lot of what's in this document can be explained by one simple fact: the goal here is to give a clear and complete spec of the TOS facility that already exists, not to design a brand-new quality of service mechanism for IP from scratch 💅 this memo does tweak the facility in a few small, carefully thought-out ways (we'll get to those below), but keeping compatibility with the existing specs and uses of the TOS facility [1,2,7,10,11] was never up for debate 🫶 that goal of backwards compatibility set the broad outlines and a lot of the details of this spec ✨
a lot of the rest of this spec came down to two more goals, which are explained more in Section 2 🌈 the first one: hosts should never be penalized for using the TOS facility, because that would probably make sure it never gets widely deployed 😭 the second one: the spec should make it easy, or at least possible, to define and deploy new types of service later on 🚀
the three goals above didn't remove every need for engineering choices, though 🙃 in a few cases, the goals actually clashed with each other. the rest of this appendix talks through the reasoning behind some of those engineering choices 🎀
B.1 The Minimize Monetary Cost TOS Value 💸
the Internet is getting more and more commercialized, so a bunch of people in the IETF's Router Requirements Working Group thought it would be important to have a TOS value that lets a user say monetary cost matters more than other qualities of the service 🥹
there was a LOT of debate about what exactly that value should mean 😭 some people thought the TOS value should mean "must not cost money." this got rejected for a few reasons. first, it would request one specific level of service (cost = 0) instead of just asking for some service attribute to be minimized or maximized, so it would be philosophically at odds with the other TOS values and would need special code in both hosts and routers 🙄 second, it wouldn't help users who want their packets to take the least-cost path but can accept some cost when they have to 💅 and third, whether a routing domain considers the TOS field when routing is the network manager's call. so a user who needs a free path might not get one if their packet has to pass through a routing domain that doesn't look at TOS in its routing decisions 💀
some people proposed a slight variant: a TOS value meaning "I am willing to pay money to have this packet delivered." this proposal has most of the same problems as the previous one, and it has one extra interesting quirk 👀 because of the algorithms in Section 7.2, any packet that uses this TOS value would prefer links that cost money over equally good free links. so this TOS value would almost be the same as a "maximize monetary cost" value! 🤯🔥
Okay so, the future probably has users who'll want a way to say the most they're willing to pay for a packet to get delivered 💸🫶. But ngl, an IP option would be the more proper move 💅. Routers already have IP options they're required to honor, and an option could carry parameters like the maximum amount the user is willing to pay ✨. So the TOS value in this memo just politely asks the network to "minimize monetary cost" 🎀.
B.2 The Specification of the TOS Field 🎀
There were four goals guiding the decision to make a four bit TOS field and to specify its values 🧚:
- Define a brand-new type of service that asks the network to "minimize monetary cost" 💸
- Stay as compatible as possible with existing specifications and uses of the TOS facility 🫶
- Leave room to define and deploy new types of service in the future 🦋
- Permanently fix the size of the TOS field 🔒
The last goal sounds surprising, but it's actually necessary for routing to work correctly when new types of service get deployed 🙈. If routers disagree about how big the TOS field is, they make inconsistent decisions, and that can lead to routing loops 🌀 (scary!!).
At first glance, goals (3) and (4) seem 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 the impractical step of changing the IP header format 💀. One of those has to go to goal (1), so at most two bits could be reserved for new or experimental types of service. It's questionable whether two would be enough, and it's improbable that the IETF and IAB would let all the currently unused bits sit permanently reserved for types of service that might or might or might not ever be defined 😭.
However, some (if not most) of the possible combinations of individual bits wouldn't be useful 🥱. Setting all of the bits is basically the same as setting none of them, since that would say none of the types of optimization is any more important than the others. Sure, you could assign reasonable meaning to most pairs of bits, but it's unclear whether the range of network service on different paths could really be split up that finely 🤷♀️. If some of those useless combinations could be given to new types of service, goals (3) and (4) could both be met without using up every remaining reserved bit in the IP header 🧠✨. The obvious way to pull that off was to change the TOS values so they're integers instead of independently settable bits 🔢.
The integers were chosen to be compatible with the bit definitions in RFC-791 💜. So, for example, setting the TOS field to 1000 (minimize delay) sets bit 3 of the Type of Service octet, and bit 3 is the Low Delay bit in RFC-791 ⚡. This memo only defines values that correspond to setting a single one of the RFC-791 bits, since setting multiple TOS bits doesn't seem to be common practice 🙅. According to [15], none of the common TCP/IP applications currently set multiple TOS bits 📚. Values for particular combinations of RFC-791 bits could still be defined if and when they're determined to be useful 🌈.
The new TOS value for "minimize monetary cost" needed to be one that preexisting implementations wouldn't totally misread 👀. That seemed to mean the value should leave all of the RFC-791 bits clear 🫧. That would require expanding the TOS field, but it would let old implementations treat packets requesting minimized monetary cost (TOS 0001) as if they'd asked for the default TOS 💅. It's not a perfect solution, though. As described above, changing the size of the TOS field could cause routing loops if some routers route based on a three bit TOS field and others route based on a four bit one 😬. Thankfully, this shouldn't be much of a problem in practice, because routers that route based on a three bit TOS field are very rare as this is being written, and they'll only become more so once this specification is published 📉.
So for all of those reasons, and also to leave 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. Going to five bits would allow considerable future expansion (27 new TOS values) and would be consistent with Host Requirements, but it would reduce the number of reserved bits in the IP header to one 😳. Going to four bits would restrict future expansion to more modest levels (11 new TOS values), but it would leave an additional IP header bit free 🦋. The IETF's Router Requirements Working Group concluded that a four bit wide TOS field allows 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:
- 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 💀.
- 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. - 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 got rejected pretty quickly 🚫. Because it requires that every router a packet traverses have a route with the requested TOS, packets requesting non-zero TOS values would (at least until the TOS facility becomes widely used) have a high probability of being discarded as undeliverable 😭. That 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 less straightforward 🤔. Weak TOS won because it's slightly simpler to implement and because it's consistent with the OSPF and Integrated IS-IS specifications ✨. Plus, many people dislike Very Weak TOS, because its algorithm for choosing a route when none of the available routes have either the requested or the default TOS can't be justified by intuition. There's no reason to believe a numerically smaller TOS makes a route better 🤷♀️. Since a router would need to understand the semantics of all the TOS values to make a smarter choice, there doesn't seem to be a reasonable way to fix this particular deficiency of Very Weak TOS 😵💫.
In practice, the choice between Weak TOS and Very Weak TOS is expected to make little difference 🌤️, since (except where the network manager has intentionally set things up otherwise) there will be a route with the default TOS to any destination that has a route with any other TOS 💖.
B.4 The Retention of Longest Match Routing 📏
An interesting issue is how early in the route choice process TOS should be considered 🤓. There seem to be two obvious possibilities:
- Find the set of routes that best match the destination address of the packet. From among those, choose the route which best matches the requested TOS.
- Find the set of routes that best match the requested TOS. From among those, choose the route which best matches the destination address of the packet.
The two approaches are believed to support an identical set of routing policies 🪞. Which of the two allows the simpler configuration and minimizes the amount of routing information that needs to be passed around seems to depend on the topology, though some believe the second option has a slight edge in this regard 🗺️.
Under the first option, if the network manager neglects some pieces of the configuration, the likely consequence is that some packets which would benefit from TOS-specific routes will be routed as if they had requested the default TOS 🥲. Under the second option, however, a network manager can very easily (accidentally) configure things so that packets which request a certain TOS and should be delivered locally will instead follow a default route for that TOS and get dumped into the Internet 🙀. So the first option has a slight edge when it comes to robustness in the face of network manager errors 🛡️.
It has also been suggested that the first option provides the additional benefit of allowing loop-free routing in routing domains that contain both routers that consider TOS in their routing decisions and routers that don't 🔁. Whether that's true in all cases is unknown 🤔. It is certainly the case, though, that under the second option it would not work to mix routers that consider TOS and routers that don't in the same routing domain 🚫.
All in all, there were no truly compelling arguments for choosing one way or the other 🙃, but a choice still had to be made. If different routers made the choice differently, chaos (in the form of routing loops) would result 🌪️. The mechanisms specified in this memo reflect the first option, because that will probably be more intuitive to most network managers 🧠. Internet routing has traditionally chosen the route which best matches the destination address, with other mechanisms serving merely as tie-breakers 👑. The first option is consistent with that tradition 💜.
B.5 The Use of Destination Unreachable 🚧
Perhaps the most contentious and least defensible part of this specification is that a packet can be discarded because the destination is considered to be unreachable, even though a packet to the same destination requesting a different TOS would have been deliverable 😬. This falls perilously close to violating the principle that hosts should never be penalized for requesting non-default TOS values in packets they originate 🥺.
This can happen in only three, somewhat unusual, cases 🧩:
- There is a route to the packet's destination which has the TOS value requested in the packet, but the route has an infinite metric ♾️.
- The only routes to the packet's destination have TOS values other than the one requested in the packet. One of them has the default TOS, but it has an infinite metric.
(3) the only routes to the packet's destination have TOS values other than the one requested in the packet, and none of them have the default TOS 💅
okay so it's kinda commonly accepted that a router with a default route should still drop a packet if it has a more specific route to the destination in its forwarding table but that route has an infinite metric 🙈 cases one and two feel super analogous to that rule, bestie ✨
also, lowkey iconic: except maybe during brief transients from topology changes, routes with infinite metrics only show up because the network manager did something on purpose (or made a serious error) 🚫 so packets are unlikely to get discarded unless the manager deliberately made it happen. some people think this is a major feature of the spec 🌸 it lets the network keep packets that asked for cost to be minimized off of a link that's so expensive the manager is sure users would want those packets dropped. others (including the author of this memo) think this "feature" won't actually be useful, and that other mechanisms may be needed for access controls on links. but they didn't feel justified changing the spec in the ways needed to remove the "feature" 🦋
case (3) is the messier one 😭 it could have been avoided by using Very Weak TOS, but that idea got rejected for the reasons in Appendix B.3. some folks suggested fixing case (3) by relaxing longest match routing (see Appendix B.4), but that got rejected too, since it would add complexity to routers without necessarily making their routing choices any more intuitive. it's also another case a network manager has to try really hard to create 💀 OSPF and Integrated IS-IS both enforce that there must be a route with the default TOS to any destination that has a route with a non-zero TOS, so a manager would have to wait for a brand new routing protocol or make the problem with static routes. the final vibe check was that any fix for case (3) was worse than the problem itself 💅
APPENDIX C. Limitations of the TOS Mechanism ✨
It is important to note that the TOS facility has some limitations, bestie 🎀 some are consequences of engineering choices made in this specification. Others, called "inherent limitations" below, probably couldn't have been avoided without either replacing the TOS facility defined in RFC-791 or accepting that things wouldn't work right until every router on the Internet supported the TOS facility 🌈
C.1. Inherent Limitations 💜
The biggest inherent limitation is that the TOS facility is strictly an advisory mechanism 🫶 it is not an appropriate tool for requesting service guarantees. There are two reasons why:
(1) Not all networks will consider the value of the TOS field when deciding how to handle and route packets 🙈 partly this is a transition issue, since there will be a (probably lengthy) period when some networks run equipment that predates this specification. but even long term, many networks won't be able to provide better service by looking at the TOS field. for example, the best path through a network made of a homogeneous collection of interconnected LANs is probably the same for every possible TOS value. inside a network like that, it would make little sense to make routers and routing protocols do the extra work of considering the TOS field when forwarding packets 💅
(2) The TOS mechanism isn't powerful enough to let an application quantify the level of service it wants 😭 for example, an application can use the TOS field to ask the network to choose a path that maximizes throughput, but it can't use that mechanism to say it needs a particular number of kilobytes or megabytes per second. because the network can't know what the application actually requires, it would be inappropriate for the network to discard a packet that asked for maximal throughput just because no "high throughput" path was available 🍓
the inability to provide resource guarantees is a serious drawback for certain kinds of network applications 🥺 a system using packetized voice, for example, just creates network congestion when the available bandwidth is too low to deliver intelligible speech. and the network really oughtn't even bother delivering a voice packet that has been delayed in the network longer than the application can tolerate. unfortunately, resource guarantees are problematic in connectionless networks. Internet researchers are actively studying this problem, and they're optimistic they'll find ways for the Internet Architecture to evolve to support resource guarantees while keeping the perks of connectionless networking ✨👑
C.2. Limitations of this Specification 🧚
there are a couple more limitations of the TOS facility that aren't inherent. instead, they're consequences of engineering choices made in this specification:
(1) Routing isn't really optimal for some TOS values 🙈 that's because optimal routing for those values would require routing protocols to understand the semantics of the TOS values and use special algorithms to compute routes for them. for example, routing protocols usually compute a path's metric by summing the costs of the individual links in that path. but to maximize reliability, a routing protocol would instead have to compute a metric that's the product of the probabilities of successful delivery over each link in the path. this is kinda a limitation of current routing protocols rather than of this specification, but the spec still contributes by saying there are a number of legal TOS values with no currently defined semantics 💀
(2) This specification assumes network managers will do "the right thing" 🥹 if a routing domain uses TOS, the network manager must configure the routers so that a reasonable path is chosen for each TOS. that ought not to be terribly difficult, but a network manager could accidently or intentionally violate our rule that using the TOS facility should provide service at least as good as not using it 😤
References 📚
[1] Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts -- Communication Layers", RFC 1122, USC/Information Sciences Institute, October 1989.
[2] Internet Engineering Task Force (R. Braden, Editor), "Requirements for Internet Hosts -- Application and Support", RFC 1123, USC/Information Sciences Institute, October 1989.
[3] Almquist, P., "Requirements for IP Routers", Work in progress.
[4] Almquist, P., "Ruminations on the Next Hop", Work in progress.
[5] Baker, F. and R. Coltun, "OSPF Version 2 Management Information Base", RFC 1248, ACC, Computer Science Center, August 1991.
[6] Braden, R. and J. Postel, "Requirements for Internet Gateways", RFC 1009, USC/Information Sciences Institute, June 1987.
[7] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Dual Environments", RFC 1195, Digital Equipment Corporation, December 1990.
[8] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox PARC, September 1991.
[9] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", RFC 950, USC/Information Sciences Institute, August 1985.
[10] Moy, J., "OSPF Version 2", RFC 1247, Proteon, Inc., July 1991.
[11] Postel, J., "Internet Protocol", RFC 791, DARPA, September 1981.
[12] Postel, J., "Internet Control Message Protocol", RFC 792, DARPA, September 1981.
[13] Postel, J., "Transmission Control Protocol", RFC 793, DARPA, September 1981.
[14] Prue, W. and J. Postel, "A Queuing Algorithm to Provide Type-of-Service for IP Links", RFC 1046, USC/Information Sciences Institute, February 1988.
[15] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1060, USC/Information Sciences Institute, March 1990.
Acknowledgements 🫶
Some of the ideas in this memo are based on discussions held by the IETF's Router Requirements Working Group 💖 much of the specification of how hosts treat Type of Service is basically a restatement of the ideas of the IETF's former Host Requirements Working Group, as captured in RFC-1122 and RFC-1123 ✨ the author is indebted to John Moy and Ross Callon for their help and cooperation in getting the OSPF specification, the Integrated IS-IS specification, and this memo to agree with each other 👑
This memo got substantially better thanks to thoughtful comments from a bunch of reviewers, including Dave Borman, Bob Braden, Ross Callon, Vint Cerf, Noel Chiappa, Deborah Estrin, Phill Gross, Bob Hinden, Steve Huston, Jon Postel, Greg Vaudreuil, John Wobus, and the Router Requirements Working Group 🌸 the initial work was done while the author was an employee of BARRNet, and their support is gratefully acknowledged 🙌
Security Considerations 🔐
Okay, babe, no explicit security talk here 🙈 this memo does not explicitly discuss security issues. The author does not believe that the specifications in this memo either weaken or enhance the security of the IP Protocol or of the other protocols mentioned herein 🦋
Author's Address 🖊️
Philip Almquist
214 Cole Street, Suite 2
San Francisco, CA 94117-1916
Phone: 415-752-2427
Email: almquist@Jessica.Stanford.EDU📦 where this page comes from
- ietf: rfc1349 1992-07
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms