QoS Type of Service Field Evolution

RFC791 introduced the Type of Service (ToS) field using the most significant fields of the octet (as explained in the last blog). RFC795 defined the service mappings of the delay, throughput, and reliability bits. RFC1349 “Type of Service in the Internet Protocol Suite” re-defined the ToS byte as the following: Precedence – first three bits TOS – following four bits MBZ (must be zero) – last bit As of RF1349, the TOS field had four bits in the following order: Delay, Throughput, Reliability, and Monetary. The monetary bit was to be used in routing protocols to indicate the monetary cost of links. The monetary bit was rarely used in practical application. The “show ospf” command output of a Cisco router illustrates the lack of ToS based routing support. RFC1812 “Requirements for IP Version 4 Routers” obsolete the delay, throughput, reliability, and monetary bits. These bits were not used in practical application so the ToS byte was re-mapped to include the three IP Precedence bits and nothing else. RFC2474 “Definition of the Differentiated Services Field” outlined the new, current architecture and usage of the Type of Service byte. Instead of using only 3 bits to indicate IP Precedence (priority), the ToS byte would now use the 6 most significant bits of the ToS byte to indicate priority levels. Using 6 bits for priority levels would theoretically allow for 64 markings (2 to the 6th power). These values are in the range of 0 to 63 and the bit values of the field are as follows (highest to lowest): 32 | 16 | 8 | 4 | 2 | 1 32 + 16 + 8 + 4 + 2 + 1 = 63 (0 through 63 equals 64 different values) The new 6 bit marking was named the Differentiated Services Code Point (DSCP). The three most significant bits of this field were previously used in the IP Precedence paradigm. The designers of this new paradigm were very careful to design a scheme in which the new DSCP markings would be backward compatible to the previously used IP Precedence field. The Assured Forwarding (AF) model was designed to meet the IP Precedence backward compatibility objective. The assured forwarding model is outlined in RFC2597. The next blog will begin our exploration into the details of the assured forwarding model. REFERENCES: Internet Engineering Task Force (RFC downloads): www.ietf.org RFC Editor (Full RFC download): www.rfc-editor.org