Type of service
 | This article may be confusing or unclear to readers. (October 2010) |
The Type of Service (TOS) field in the IPv4 header has had various purposes over the years, and has been defined in different ways by five RFCs[note 1] The modern redefinition of the TOS field is a six-bit Differentiated Services Code Point (DSCP) field and a two-bit Explicit Congestion Notification field.
Type of Service
The original intention of the TOS field was for a sending host to specify a preference for how the datagram would be handled as it made its way through an internet. For instance, one host could set its IPv4 datagrams' TOS field value to prefer low delay, while another might prefer high reliability. In practice, the TOS field was not widely implemented. However, a great deal of experimental, research and deployment work has focused on how to make use of these eight bits, resulting in the current DSCP field definition.
As defined in RFC 791, the following eight bits were allocated to a TOS field in the IP header. They can be divided into 5 subfields:
| 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
|---|---|---|---|---|---|---|---|
| Precedence | D | T | R | Unused | |||
0 = Most Significant Bit; 7 = Least Significant Bit.
The 3 Precedence bits have a from 0 to 7 and are used to indicate the importance of a datagram (default is 000, higher is better).
| Precedence | Hexadecimal | Decimal | Description |
|---|---|---|---|
| 111 | 0xE0 | 224 | Network Control |
| 110 | 0xC0 | 192 | Internetwork Control |
| 101 | 0xA0 | 160 | CRITIC/ECP |
| 100 | 0x80 | 128 | Flash Override |
| 011 | 0x60 | 96 | Flash |
| 010 | 0x40 | 64 | Immediate |
| 001 | 0x20 | 32 | Priority |
| 000 | 0x00 | 0 | Routine |
The decimal and hexadecimal values above, assumes bits 3 to 7 are set to 0.
Bits 3 4 5 represent the following:
- D: requests low delay
- T: requests high throughput
- R: requests high reliability
Bit 6 was later defined by RFC 1349 as "Minimize Monetary Cost".
A router maintains a TOS value for each route in its routing table. Routes learned through a protocol that does not support TOS are assigned a TOS of zero. Routers use the TOS to choose a destination for the packet.
- The router locates in its routing table all available routes to the destination.
- If one or more of those routes have a TOS that exactly matches the TOS specified in the packet, the router chooses the route with the best metric.
- Otherwise, the router repeats the above step, except looking at routes whose TOS is zero.
- If no route was chosen above, the router drops the packet because the destination is unreachable. The router returns an ICMP Destination Unreachable error specifying the appropriate code: either Network Unreachable with Type of Service (code 11) or Host Unreachable with Type of Service (code 12).
The TOS model of the "IP precedence" model as defined in RFC 791 and RFC 1349 are outdated. The replacing model as described in RFC 2474 uses the DSCP field in the IPv4 Header and IPv6 Header.[1] Some backwards compatibility is maintained.
See also
Notes
- ^ RFC 791, RFC 1122, RFC 1349, RFC 2474, and RFC 3168. For a full history of the TOS field, see section 22 of RFC 3168.
References
- ^ asterisk's docs -- doc/ip-tos.txt
Further reading
- "Deploying IP and MPLS QoS for Multiservice Networks: Theory and Practice" by John Evans, Clarence Filsfils (Morgan Kaufmann, 2007, ISBN 0-370561-370548-5)
External links
- Linux Advanced Routing & Traffic Control. How to set TOS byte via IPChains
- RFC 1349, Type of Service in the Internet Protocol Suite