The type of service field in the IPv4 header has had various purposes over the years, and has been defined in different ways by five RFC

Request for Comments

In computer network engineering, a Request for Comments is a memorandum published by the Internet Engineering Task Force describing methods, behaviors, research, or innovations applicable to the working of the Internet and Internet-connected systems.Through the Internet Society, engineers and...

s. The modern redefinition of the TOS field is a six-bit differentiated services code point

Differentiated services

Differentiated Services or DiffServ is a computer networking architecture that specifies a simple, scalable and coarse-grained mechanism for classifying and managing network traffic and providing Quality of Service on modern IP networks...

 (DSCP) field and a two-bit Explicit Congestion Notification

Explicit Congestion Notification

Explicit Congestion Notification is an extension to the Internet Protocol and to the Transmission Control Protocol and is defined in RFC 3168 . ECN allows end-to-end notification of network congestion without dropping packets. ECN is an optional feature that is only used when both endpoints...

 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 three 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	Decimal of 6 left bits	Description
111	0xE0	224	56	Network control
110	0xC0	192	48	Internetwork control
101	0xA0	160	40	CRITIC/ECP
100	0x80	128	32	Flash override
011	0x60	96	24	Flash
010	0x40	64	16	Immediate
001	0x20	32	8	Priority
000	0x00	0	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.

1. The router locates in its routing table all available routes to the destination.
2. 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.
3. Otherwise, the router repeats the above step, except looking at routes whose TOS is zero.
4. 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. Some backwards compatibility is maintained.

External links

• Linux Advanced Routing & Traffic Control. How to set TOS byte via IPChains