RFCs in HTML Format

RFC 1349

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

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]
RFC 1349 Type of Service July 1992 except as described in Section 8 should not) make any distinction between TOS values whose semantics are defined by this memo and those that are not. It is important to note the use of the words "minimize" and "maximize" in the definitions of values for the TOS field. For example, setting the TOS field to 1000 (minimize delay) does not guarantee that the path taken by the datagram will have a delay that the user considers "low". The network will attempt to choose the lowest delay path available, based on its (often imperfect) information about path delay. The network will not discard the datagram simply because it believes that the delay of the available paths is "too high" (actually, the network manager can override this behavior through creative use of routing metrics, but this is strongly discouraged: setting the TOS field is intended to give better service when it is available, rather than to deny service when it is not). 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 discusses how protocols above IP choose appropriate values. 5.1 Internet Control Message Protocol (ICMP) ICMP [8,9,12] defines a number of messages for performing error reporting and diagnostic functions for the Internet Layer. This section describes how a host or router chooses appropriate TOS values for ICMP messages it originates. The TOS facility also affects the origination and processing of ICMP Redirects and ICMP Destination Unreachables, but that is the topic of Section 6. For purposes of this discussion, it is useful to divide ICMP messages into three classes: o ICMP error messages include ICMP message types 3 (Destination Unreachable), 4 (Source Quench), 5 (Redirect), 11 (Time Exceeded), and 12 (Parameter Problem). o ICMP request messages include ICMP message types 8 (Echo), 10 (Router Solicitation), 13 (Timestamp), 15 (Information Request -- now obsolete), and 17 (Address Mask Request). o 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). Almquist [Page 6]
RFC 1349 Type of Service July 1992 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 to allow the user to specify the TOS value to be used would be a useful feature in many applications that generate ICMP request messages. An ICMP reply message is sent with the same value in the TOS field as was used in the corresponding ICMP request message. 5.2 Transport Protocols When sending a datagram, a transport protocol uses the TOS requested by the application. There is 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 that it is primarily sending small acknowledgement packets). It may be useful for a transport protocol to provide applications with a mechanism for learning the value of the TOS field that accompanied 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 being generated changes. An example of this would be SMTP, which spends part of its time doing bulk data transfer and part of its time exchanging short command messages and responses. TCP [13] should use the same TOS for datagrams containing only TCP control information as it does for datagrams which contain user data. Although it might seem intuitively correct to always request that the network minimize delay for segments containing acknowledgements but no data, 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 is the responsibility of the application's designer or programmer to make a suitable choice, based on the nature of the traffic to be originated by the application. It is essential for many sorts of network diagnostic applications, and desirable for other applications, that the user of the Almquist [Page 7]
RFC 1349 Type of Service July 1992 application be able to override the TOS value(s) which the application would otherwise choose. The Assigned Numbers document is revised and reissued periodically. Until RFC 1060, the edition current as this is being written, has been superceded, 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 the ICMP protocol. 6.1 Destination Unreachable The ICMP Destination Unreachable message contains a code which describes the reason that the destination is unreachable. There are four codes [1,12] which are particularly relevant to the topic of this memo: 0 -- network unreachable 1 -- host unreachable 11 -- network unreachable for type of service 12 -- host unreachable for type of service A 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 rationale for having these codes and the limited cases in which they are expected to be used are described in Appendix B.5. Almquist [Page 8]
RFC 1349 Type of Service July 1992 6.2 Redirect The ICMP Redirect message also includes a code, which specifies the class of datagrams to which the Redirect applies. 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 host A router generates a code 3 Redirect when the Redirect applies only to IP packets which request a particular TOS value. A router generates a code 1 Redirect instead when the the optimal next hop on the path to the destination would be the same for any TOS value. In order 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 Both hosts and routers should consider the value of the TOS field of a datagram when choosing an appropriate path to get the datagram to its destination. The mechanisms for doing so are discussed in this section. Whether a packet's TOS value actually affects the path it takes inside of a particular routing domain is a choice made by the routing domain's network manager. In many routing domains the paths are sufficiently homogeneous in nature that there is no reason for routers to choose different paths based up the TOS field in a datagram. Inside such a routing domain, the network manager may choose to limit the size of the routing database and of routing protocol updates by only defining routes for the default (0000) TOS. Neither hosts nor routers should need to have any explicit knowledge of whether TOS affects routing in the local routing domain. Almquist [Page 9]
RFC 1349 Type of Service July 1992 7.1 Host Routing When a host (which is not also a router) wishes to send an IP packet to a destination on another network or subnet, it needs to choose an appropriate router to send the packet to. According to the IP Architecture, it does so by maintaining a route cache and a list of default routers. Each entry in the route cache lists a destination (IP address) and the appropriate router to use to reach that destination. The host learns the information stored in its route cache through the ICMP Redirect mechanism. The host learns the list of default routers either from static configuration information or by using the ICMP Router Discovery mechanism [8]. When the host wishes to send an IP packet, it searches its route cache for a route matching the destination address in the packet. If one is found it is used; if not, the packet is sent to one of the default routers. All of this is described in greater detail in section 3.3.1 of RFC 1122 [1]. Adding support for the TOS facility changes the host routing procedure only slightly. In the following, it is assumed that (in accordance with 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, it is assumed that 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. Readers considering violating these assumptions should be aware that long and careful consideration of the way in which Redirects are treated is necessary to avoid situations where every packet sent to some destination provokes a Redirect. Because these assumptions match the recommendations of Internet Host specification, that careful consideration is beyond the scope of this memo. As was described in Section 6.2, some ICMP Redirects apply only to IP packets which request a particular TOS. Thus, a host (at least conceptually) needs to store two types of entries in its route cache: type 1: { destination, TOS, router } type 2: { destination, *, router } where type 1 entries result from the receipt of code 3 (or code 1) Redirects and type 2 entries result from the receipt of code 2 (or code 0) Redirects. Almquist [Page 10]
RFC 1349 Type of Service July 1992 When a host wants to send a packet, it first searches the route cache for a type 1 entry whose destination matches the destination address of the packet and whose TOS matches the requested TOS in the packet. If it doesn't find one, the host searches its route cache again, this time looking for a type 2 entry whose destination matches the destination address of the packet. If either of these searches finds a matching entry, the packet is sent to the router listed in the matching entry. Otherwise, the packet is sent 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 which have the same destination. This is necessary for correctness, since the type 1 entry may be obsolete but would continue to be 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 some TOS values other than the one specified in the type 1 entry, saving the type 2 entry will likely cut down on the number of Redirects which the host would otherwise receive. This savings can potentially be substantial if one of the Redirects which was avoided would have created a new type 2 entry (thereby causing the new type 1 entry to be flushed). 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 alternative allows the host to have only type 1 route cache entries, thereby simplifying route lookup and eliminating the need for the rules in the previous two paragraphs. The disadvantage of this approach 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's to a destination for which the host should use the same router regardless of the requested TOS. There is not yet sufficient experience with the TOS facility to know whether that disadvantage would be serious enough in practice to outweigh the simplicity of this approach. Despite RFC 1122, some hosts acquire their routing information by "wiretapping" a routing protocol instead of by using the Almquist [Page 11]
RFC 1349 Type of Service July 1992
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 much to expand it. Expanding it to five bits would allow considerable future expansion (27 new TOS values) and would be consistent with Host Requirements, but would reduce to one the number of reserved bits in the 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 bit free. The IETF's Router Requirements Working Group concluded that a four bits wide TOS field allow 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: (1) 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. (2) 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. (3) 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 was quickly rejected. Because it requires that each router a packet traverses have a route with the requested TOS, packets which requested non-zero TOS values would have (at least until the TOS facility becomes widely used) a high probability of being discarded as undeliverable. This 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 not as straightforward. Weak TOS was chosen because it is slightly Almquist [Page 21]
RFC 1349 Type of Service July 1992 simpler to implement and because it is consistent with the OSPF and Integrated IS-IS specifications. In addition, many 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 cannot be justified by intuition (there is no reason to believe that having a numerically smaller TOS makes a route better). Since a router would need to understand the semantics of all of the TOS values to make a more intelligent choice, there seems to be no reasonable way to fix this particular deficiency of Very Weak TOS. In practice it is expected that the choice between Weak TOS and Very Weak TOS will make little practical 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 for which there is 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: (1) 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. (2) 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 that 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 easily (accidently) configure things in such a way that packets which request a certain TOS and should be delivered locally will instead follow a default route for that TOS and be dumped into the Internet. Thus, the first option would seem to have a slight edge with regard to robustness in the face of errors by the network manager. Almquist [Page 22]
RFC 1349 Type of Service July 1992 It has been also been suggested that the first option provides the additional benefit of allowing loop-free routing in routing domains which contain both routers that consider TOS in their routing decisions and routers that do not. Whether that is true in all cases is unknown. It is certainly the case, however, that under the second option it would not work to mix routers that consider TOS and routers which do not in the same routing domain. All in all, there were no truly compelling arguments for choosing one way or the other, but it was nontheless necessary to make a choice: if different routers were to make 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 but requesting a different TOS would have been deliverable. This would seem to fall 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: (1) 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. (2) 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. None of them have the default TOS. It is commonly accepted that a router which has a default route should nonetheless discard a packet if the router has a more specific route to the destination in its forwarding table but that route has an infinite metric. The first two cases seem to be analogous to that rule. Almquist [Page 23]
RFC 1349 Type of Service July 1992 In addition, it is worth noting that, except perhaps during brief transients resulting from topology changes, routes with infinite metrics occur only as the result of deliberate action (or serious error) on the part of the network manager. Thus, packets are unlikely to be discarded unless the network manager has taken deliberate action to cause them to be. Some people believe that this is an important feature of the specification, allowing the network to (for example) keep packets which have requested that cost be minimized off of a link that is so expensive that the network manager feels confident that the users would want their packets to be dropped. Others (including the author of this memo) believe that this "feature" will prove not to be useful, and that other mechanisms may be required for access controls on links, but couldn't justify changing this specification in the ways necessary to eliminate the "feature". Case (3) above is more problematic. It could have been avoided by using Very Weak TOS, but that idea was rejected for the reasons discussed in Appendix B.3. Some suggested that case (3) could be fixed by relaxing longest match routing (described in Appendix B.4), but that idea was rejected because it would add complexity to routers without necessarily making their routing choices particularly more intuitive. It is also worth noting that this is another case that a network manager has to try rather hard to create: since OSPF and Integrated IS-IS both enforce the constraint that there must be a route with the default TOS to any destination for which there is a route with a non-zero TOS, a network manager would have to await the development of a new routing protocol or create the problem with static routes. The eventual conclusion was that any fix to case (3) was worse than the problem. APPENDIX C. Limitations of the TOS Mechanism It is important to note that the TOS facility has some limitations. Some are consequences of engineering choices made in this specification. Others, referred to as "inherent limitations" below, could probably not have been avoided without either replacing the TOS facility defined in RFC 791 or accepting that things wouldn't work right until all routers in the Internet supported the TOS facility. C.1 Inherent Limitations The most important of the inherent limitations is that the TOS facility is strictly an advisory mechanism. It is not an appropriate mechanism for requesting service guarantees. There are two reasons why this is so: Almquist [Page 24]
RFC 1349 Type of Service July 1992 (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: there will be a (probably lengthy) period when some networks will use equipment that predates this specification. Even long term, however, many networks will not be able to provide better service by considering the value of the TOS field. For example, the best path through a network composed of a homogeneous collection of interconnected LANs is probably the same for any possible TOS value. Inside such a network, it would make little sense to require routers and routing protocols to do the extra work needed to consider the value of the TOS field when forwarding packets. (2) The TOS mechanism is not powerful enough to allow an application to quantify the level of service it desires. For example, an application may use the TOS field to request that the network choose a path which maximizes throughput, but cannot use that mechanism to say that it needs or wants a particular number of kilobytes or megabytes per second. Because the network cannot know what the application requires, it would be inappropriate for the network to decide to discard a packet which requested maximal throughput because no "high throughput" path was available. The inability to provide resource guarantees is a serious drawback for certain kinds of network applications. For example, a system using packetized voice simply creates network congestion when the available bandwidth is inadequate to deliver intelligible speech. Likewise, the network oughtn't even bother to deliver a voice packet that has suffered more delay in the network than the application can tolerate. Unfortunately, resource guarantees are problematic in connectionless networks. Internet researchers are actively studying this problem, and are optimistic that they will be able to invent ways in which the Internet Architecture can evolve to support resource guarantees while preserving the advantages of connectionless networking. C.2 Limitations of this Specification There are a couple of additional limitations of the TOS facility which are not inherent limitations but instead are consequences of engineering choices made in this specification: (1) Routing is not really optimal for some TOS values. This is because optimal routing for those TOS values would require that routing protocols be cognizant of the semantics of the TOS values and use special algorithms to compute routes for Almquist [Page 25]
RFC 1349 Type of Service July 1992 them. For example, routing protocols traditionally compute the metric for a path by summing the costs of the individual links that make up the path. However, to maximize reliability, a routing protocol would instead have to compute a metric which was the product of the probabilities of successful delivery over each of the individual links in the path. While this limitation is in some sense a limitation of current routing protocols rather than of this specification, this specification contributes to the problem by specifying that there are a number of legal TOS values that have no currently defined semantics. (2) This specification assumes that network managers will do "the right thing". If a routing domain uses TOS, the network manager must configure the routers in such a way that a reasonable path is chosen for each TOS. While this ought not to be terribly difficult, 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. Almquist [Page 26]
RFC 1349 Type of Service July 1992 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. Almquist [Page 27]
RFC 1349 Type of Service July 1992 Acknowledgements Some of the ideas presented in this memo are based on discussions held by the IETF's Router Requirements Working Group. Much of the specification of the treatment of Type of Service by hosts is merely 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 assistance and cooperation in achieving consistency among the OSPF specification, the Integrated IS-IS specification, and this memo. This memo has been substantially improved as the result of thoughtful comments from a number 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 on this memo was done while its author was an employee of BARRNet. Their support is gratefully acknowledged.

Back to RFC index




Register domain name and transfer | Cheap webhosting service | Domain name registration