Home > Resources > Networking Glossary > TCP/IP Protocols >

print

IP Type Of Service

The 'Type Of Service' Byte In The IP Header

RFC 791, (Internet Protocol - DARPA Internet Program Protocol Specification, September 1981), defined a field within the IP header called the Type Of Service (TOS) byte. This Byte is used to specify the quality of service desired for the datagram and is an amalgamation of several factors. These factors include several fields such as Precedence, Speed, Throughput and Reliability as identified below. In normal conversations you would not use any special alternatives, so the Type of Service byte typically would be set to zero. However, with the advent of Internet multimedia transmission and the emergence of protocols such as Session Initiation Protocol (SIP), this field is coming into use.

(A general note regarding the use of the IP TOS Byte is that in the course of normal network operations, not including Internet Multimedia, if you ever see the Type Of Service byte set to anything other than zero you should find out who's doing it, and why.)

The IP Type of Service Byte:

Bits 0-2: Precedence.
Bit 3: Delay (0 = Normal Delay, 1 = Low Delay)
Bit 4: Throughput (0 = Normal Throughput, 1 = High Throughput)
Bit 5: Reliability (0 = Normal Reliability, 1 = High Reliability)
Bits 6-7: Reserved for Future Use.

The three bit Precedence field is further defined as follows:

111 - Network Control
110 - Internetwork Control
101 - CRITIC/ECP
100 - Flash Override
011 - Flash
010 - Immediate
001 - Priority
000 - Routine

So what exactly is the Precedence field, and what is the difference between these various classifications such as Priority and Immediate? Recall that ARPAnet originated under the authority of the DOD, and that a number of the early performance parameters were patterned after existing DOD communications models. It is from these already established models of communications that the concept of the Precedence Field emerged. The answer for the priorities (Routine - CRITIC/ECP) is defined in Department of Defense (DOD) communications message handling directives and in RFC 791. The remaining two classifications (Internetwork Control and Network Control) are defined in RFC 791.

The following is a synopsis of these classifications as specified by DOD Communications Directives and RFC 791:

A. DOD DD173 Precedence/Priority Filed Explanations (Lowest-Highest):

1. Routine: (R) "…is used for all messages that justify transmission by electrical means unless the message delivery is of sufficient urgency to require higher precedence."
2. Priority: (P) "…is used for all messages that require expeditious action by the addressee(s) and/or furnish essential information for the conduct of ongoing operations."
3. Immediate (O) "…is reserved for messages relating to situations that gravely affect the security of National/Allied forces or populace."
4. Flash (Z) "…is reserved for initial enemy contact messages or operational combat messages of extreme urgency."
5. Flash Override (X) "… is reserved for messages relating to the outbreak of hostilities and/or detonation of nuclear devices."
6. CRITIC/ECP "…stands for "Critical and Emergency Call Processing" and should only be used for authorized emergency communications, for example in the United States Government Emergency Telecommunications Service (GETS), the United Kingdom Government Telephone Preference Scheme (GTPS) and similar government emergency preparedness or reactionary implementations elsewhere."

B. RFC 971 Specific Classifications:

According to RFC 791, the functions of the classifications: Network Control and Internetwork Control are defined as follows:

1. Network Control "…is intended to be used within a network only. The actual use and control of that designation is up to each network."

2. Internetwork Control "…is intended for use by gateway control originators only."

RFC 791 further addresses the use of these two classifications by noting that if used, "… it is the responsibility of that network to control the access to, and use of, those precedence designations."

It should now be apparent why the Precedence field is no longer used in traditional networking applications. Therefore, if you ever see these bits in use, you should find out who's doing it, and why. The implication of using the priority bits is completely vendor dependent. Consider the following example of IP TOS in a contemporary network environment:

Let's assume that you have a router that shows three different routes between Honolulu (on the island of Oahu) and Hilo (on the big island of Hawaii). You have a leased copper T1 line (which runs in an undersea cable), a fiber optic link (also in the cable), and a T1 satellite link. You decide that there is the least data loss in the fiber optic cable and you select it to be your link of greatest reliability. You know that most traffic is going across this link (because you have load-balancing routers) and that the satellite link and the leased T1 are almost unused. You decide that the leased T1 will be your link of least delay and that the satellite link will be your link of maximum throughput. These decisions are totally arbitrary; let's hope you made good decisions.

Let's further assume that your routers support the speed, throughput, and reliability types of service. You configure the Router and identify the links according to your decisions. Let's now assume that your workstation has the need, ability, and application software that will try to utilize different types of service for different activities. Perhaps your file transfer utility will select the link of greatest bandwidth while your accounting application selects the link of greatest reliability. Meanwhile, your terminal access software selects the link of highest speed.

Now consider the following criteria: Does your router support alternative types of service? Do your workstations support these options? A failure of any device in the datagram path will result in the traffic not being properly routed to its destination. This is why you need to determine who is responsible if you ever see the Type Of Service byte set to anything other than zero.

If a misconfiguration exists or an error occurs that relates to the IP Type Of Service, a protocol called ICMP (Internet Control Message Protocol) will report the error back to the station sending the failed frame. RFC 1349 discusses the relationship between IP Type Of Service and ICMP messages. For more information on ICMP or to read the text of RFC 1349, please refer to the ICMP Section.

Future Employment of the TOS/Precedence Byte:

Until fairly recently, it was a safe assumption that the IP TOS Byte was essentially obsolete and would be ignored in day-to-day networking situations. However, with the emergence of Internet multimedia transmission and the emergence of protocols such as Session Initiation Protocol (SIP), this field is returning to use.

RFC 2543 (SIP: Session Initiation Protocol, March 1999) specifies a protocol known as Session Initiation Protocol (SIP). This protocol is an application-layer control protocol used for creating, modifying and terminating sessions with one or more participants. Some examples of such activities include Internet multimedia conferences, Internet telephone calls and multimedia distribution. SIP is intended to support communications using Multicast, a mesh of Unicast relations, or a combination of both.

Contained within this protocol specification is the reliance upon the traditional RFC 791 Precedence classifications as identified by "Priority" in the following extract:

"…The resource value is formatted as "namespace"".""Priority value". The namespace and priority value are assigned by IANA (see IANA Considerations). An initial namespace, "dsn" (Defense Switched Network), contains the priority values, "critic-ecp", "flash-override", "flash", "immediate", "priority", "routine", where "flash-override" is the highest priority and "routine" is the lowest.

As a response header, the value indicates the actual priority selected by the recipient. This priority value may be lower or higher than the request header value. If the header field is missing, the SIP request is treated as if it had the Resource-Priority value of "routine"..." For further information regarding the specifications of SIP, consult RFC 2543 (SIP: Session Initiation Protocol, March 1999)