Today's networked applications—such as enterprise resource planning (ERP), data mining, e-commerce, and multimedia—are bandwidth hungry, time sensitive, and mission critical. These applications need networks to accommodate today's business priorities. Traditional networks can't recognize priority data because they handle network traffic in old-fashioned ways, such as best-effort or first-come first-served. For example, when application data enters a traditional network, the network allocates as much bandwidth as the application needs—until the network runs out of bandwidth. Mission-critical applications, such as SAP R/3, and time-sensitive applications, such as NetMeeting videoconferencing, can drown in a flood of less important network traffic—such as a PointCast Web newscast. Systems administrators end up facing network congestion, slow response, and packet-dropping problems.
Simply throwing more bandwidth at your network is not the ultimate solution to these problems, because you can't foresee what new bandwidth-hungry applications will be in use in several months. An ill-behaved application can easily bring your network down—and potentially shut down your business operation.
What Is QoS?
To gain more effective control of your network, you need to incorporate Quality of Service (QoS). In a QoS-enabled network, you can prioritize network traffic flow, allocate network bandwidth and resources to different applications and users, enforce security to applications and users entering your network, and link business needs with desired network behavior. For example, you can guarantee that an SAP R/3 application has the highest network priority and reserve a specific bandwidth for the finance department, and assign PointCast the lowest network priority and a limit on allowable bandwidth.
QoS has been in use for several years. IP supports QoS in the IP header. Asynchronous transfer mode (ATM) natively provides QoS in its virtual circuits and various bit-rate controls. Recently, the Internet Engineering Task Force (IETF) developed Resource Reservation Setup Protocol (RSVP) as a QoS standard for TCP/IP networks and the Internet. The Institute of Electrical and Electronics Engineers (IEEE) defined the 802.1p standard for QoS in all IEEE 802-type networks, such as Ethernet-standard networks.
Major network vendors, including 3Com, Bay Networks, and Cisco, have developed road maps to QoS implementation and started to deliver QoS-enabled network equipment and management tools. Microsoft is building QoS into Windows NT 5.0 and has released QoS APIs for developers to use in writing QoS-enabled applications. Designing and building QoS-enabled NT networks and applications might soon be at the top of your task list. In this article, I'll help you jump onto the QoS bandwagon by giving you an overview of QoS signaling techniques and queuing mechanisms. I'll describe QoS policy management and implementation methods. Finally, I'll explain Microsoft's implementation of QoS in NT 5.0.
QoS Signaling Techniques
QoS includes four reservation techniques—IP Precedence, 802.1p, RSVP, and Subnet Bandwidth Manager (SBM)—which are also called QoS signaling. QoS signaling lets routers and switches better control network traffic.
IP Precedence and 802.1p. When IETF designed IPv4, the current Internet network protocol, the task force defined a Type of Service (ToS) field in the IP header of IP packets. IP uses 3 bits of the 8-bit ToS field to designate IP Precedence. Using IP Precedence, systems administrators can partition their IP traffic into up to eight classes of service, numbered from 0 to 7. The higher the number, the higher the priority. For example, you might assign SAP R/3 priority number 7, SQL Server priority number 6, and NetMeeting priority number 5. Networks deliver higher-priority packets before they deliver lower-priority packets. QoS-enabled applications, computers, routers, and Layer 3 switches can set the IP Precedence designation for each IP packet when they generate or transmit the packet. By examining IP Precedence, routers and Layer 3 switches can easily prioritize arriving packets in different queue classes and deliver the packets based on their priority. IETF is researching how to use other bits in the IP header's ToS field for QoS. IETF has included the 8-bit Class and 20-bit Flow Label fields in the IP header of IPv6, the next generation IP, so that IPv6 will be ready to support more comprehensive QoS in the future. (To learn more about IPv6, see "The Next Generation IP in Action," June 1998.)
In contrast to IP Precedence, which lets administrators prioritize IP-only packets at Layer 3, IEEE defined the 802.1p standard for its 802-type (e.g., Ethernet and Token Ring) network at Layer 2. When IEEE developed the 802.1Q standard for virtual LANs (VLANs), it specified a VLAN tag that the standard appends to media access control (MAC) frames to carry VLAN information. This tag includes two types of information: 12 bits for the VLAN ID, and 3 bits for the priority designation. Although 802.1Q defines the tag format, the standard doesn't specify how to use the 3-bit priority field. The 802.1p standard, however, specifies how to use the 3-bit priority field. The 802.1p standard establishes eight levels of priority—0 to 7—similar to IP Precedence. NICs and switches supporting 802.1p can use the priority levels to route different types of network traffic. The 802.1p prioritization working at Layer 2 can support any upper-layer protocols, which means you can use 802.1p to define priorities for IPX, SNA, and AppleTalk applications, as well as IP applications. Layer 3 switches can also easily map 802.1p's eight priority levels to the corresponding eight priority levels in IP Precedence before the switches forward packets to routers.
RSVP. RSVP is a resource reservation setup protocol that IETF defined in Request for Comments (RFC) 2205. You can use RSVP to enhance support for QoS in IP and Internet networks through resource reservation. With RSVP, you can request that the network provide specific QoS for a particular application. RSVP ensures that each node along the path reserves the requested resource—from source to destination—and that routers deliver the request to all nodes in the path and maintain the reservation information.
Let's use the example Figure 1 illustrates to look at how RSVP works. Computer A wants to reserve 1 megabit per second (Mbps) bandwidth for a video stream, or flow, from itself to Computer B. The process starts when Computer A sends a PATH message to Computer B. The PATH message includes a flow ID, which contains the reservation information and source and destination addresses. In Figure 1, the PATH message contains the reservation request of 1Mbps bandwidth and Computer A's and Computer B's IP addresses. The message can contain other information, such as a reservation for a video stream that user John sends with a maximum 100-millisecond (ms) delay. When Router 1 receives the PATH message, it remembers the flow ID and the incoming link that the PATH message is from. The router maps the data-flow path and is prepared to reserve the requested resource. Then the router forwards the PATH message to the next router. This process repeats until Computer B receives the PATH message. If Computer B wants to receive John's video, it sends a RESV message using the same flow ID to Computer A and following the reverse path of the PATH message. The RESV message tells the routers in its path what QoS level Computer B allows (1Mbps in this example). When Router 2 receives the RESV message, it commits the reservation and enters the reservation in its flow table, which identifies the associated incoming packets and RSVP sessions. Router 2 then forwards the RESV message to Router 1. This process repeats until Computer A gets the RESV message. In this way, RSVP reserves a 1Mbps data flow between Computer A and Computer B. When the conversation between communicating computers ends, one of the computers sends a PATHTEAR message to tear down the data flow and free the reserved resources.
Using RSVP, a QoS-enabled application or computer can request more bandwidth than it needs. For example, suppose user Joe tries to reserve 100Mbps bandwidth for a newscast application between his workstation and a news server. When each node on the data path receives Joe's reservation request, each node must answer two questions: Do I have enough local resources available to meet the request? Is this user or application authorized to make such a request? If the answer to either question is no, RSVP will return an error to the request source, rejecting the request. RSVP terminology refers to the first verification as admission control and to the second verification as policy control. Administrators can specify QoS policy for a particular application or user. In this example, RSVP will probably deny Joe's request for 100Mbps as exceeding local resources.
SBM. RSVP can reserve resources between two end systems connected by RSVP-aware routers and switches. However, a network may contain legacy shared or switched LAN segments, (e.g., Ethernet) that don't support QoS. Multiple computers on a shared switch that request resource reservation can overflow the switch. For example, suppose four computers share a switch that's capable of only 10Mbps bandwidth. Computer A reserves 10Mbps bandwidth data flow between itself and Computer C, and Computer B reserves 10Mbps bandwidth data flow between itself and Computer D. The combined reservations will oversubscribe the shared switch. To overcome this problem, IETF defined the SBM protocol to provide RSVP-type admission control in legacy LAN segments. Although SBM is still an Internet draft (draft-ietf-issll-is802-sbm-06.txt), it has gained support from vendors. (Microsoft will offer an SBM server in NT 5.0 and an SBM client in NT 5.0 and Windows 98.) You can implement SBM in switches and routers as well as in network operating systems (OSs). SBM is also referred to as RSVP proxy.
Let's look at how SBM resolves the switch-overflow problem. In Figure 2, the SBM server contains admission control information, such as the limits of available resources that computers can reserve on its managed segment. Computer A and Computer C are both SBM clients. When Computer A needs to reserve a 10Mbps bandwidth flow between itself and Computer B, it sends an RSVP PATH message to the SBM server instead of to Computer B. If the SBM server passes the admission control verification (i.e., it has adequate resources available for reservation on the managed segment), it forwards the PATH message to the message's destination—Computer B—via the router, as in the standard RSVP process. The SBM server remembers the PATH information and the machine that issued the PATH message. When the SBM server receives the RESV message that Computer B originated, it reserves 10Mbps bandwidth for Computer A and maintains the reservation information. When Computer C needs to reserve 10Mbps bandwidth flow between itself and Computer D, it also sends a PATH message to the SBM server. However, in this case, the SBM server, using its admission control function, finds that the managed segment doesn't have enough available bandwidth for reservation. The SBM server therefore rejects the request.
QoS Queuing
QoS implements queuing techniques to efficiently route packets in priority order. Network vendors often implement three common QoS queuing mechanisms in their routers and switches. These mechanisms are priority, weighted round-robin, and weighted fair queuing.
Priority. Priority queuing, as its name implies, places arriving packets into a queue based on the criteria of a packet's priority and information such as 802.1p, IP Precedence, RSVP reservation, network protocol, source and destination addresses, and TCP/ UDP ports. Queues can exist in various classes, such as high, medium, normal, and low. Priority queuing prefers to transmit the packets in higher-priority queues, and transfers packets in low-priority queues only when no high-priority queues are waiting for transfer. With priority queuing, you can ensure that mission-critical traffic, such as order entry, gets to its server ahead of less important traffic. However, priority queuing can increase delay and failure on lower-priority traffic and applications.
Weighted round robin. To make sure that no application will dominate the overall capacity of a router or switch, the weighted round-robin queuing technique transmits entire queues in round-robin order. You can assign a priority to a queue by defining the queue's length: The longer the length, the higher the queue's priority. For example, imagine three queues with respective lengths of 1, 2, and 3. Packets with the highest priority enter the length-3 queue, and packets with the lowest priority enter the length-1 queue. By giving highest transmission priority to length-3 queues, weighted round robin can process more high-priority traffic and also treat low-priority traffic fairly.
Weighted fair. Compared with weighted round-robin queuing, weighted fair queuing provides a more comprehensive mechanism to fairly handle both heavy and light traffic. Weighted fair queuing uses flow-based queuing to dynamically allocate to each flow a proportion of link bandwidth. For example, if a router interface has one flow at each IP precedence level, there will be eight flows. If each of the eight flows has a weight equal to its precedence level plus one (i.e., precedence level 0 has a weight of 0 + 1), the total link bandwidth weight will be 36 (1 + 2 + 3 + 4 + 5 + 6 + 7 + 8 = 36). Dividing a flow's weight by this total weight yields the flow's link bandwidth allocation factor. For example, precedence 7's flow will get 8/36 of the link bandwidth, precedence 6's flow will get 7/36 of the link bandwidth, and so on. If the router interface has 20 precedence 2 flows and 1 of all other precedence-level flows, each of the 20 precedence 2 flows will get 3/93 (1 + 2 + 20 * 3 + 4 + 5 + 6 + 7 + 8 = 93) of the link bandwidth.
QoS Policy Management
The QoS signaling and queuing techniques are tools you can use to maintain the QoS levels you want to implement in your network. You define your chosen techniques in QoS policies. Managing QoS policies is a three-layered process consisting of setting up the policies, storing the policies, and delivering the policies to network equipment.
To set up efficient QoS policies for your network, you need to analyze your business needs and translate these requirements into QoS policies. For instance, you might convert the business requirement the quarterly company financial report must be finished on time into the QoS policy accept SAP R/3 traffic at TCP port 1234 with priority 7 and 500Kbps bandwidth in the last week of March, June, September, and December for the financial department. This policy might seem complicated; fortunately, network vendors provide easy-to-use GUI-based QoS administrative tools, such as Cisco's QoS Policy Manager and 3Com's Transcend Policy Manager, to create such QoS policies.
You can store QoS policies either in a policy server or a directory. Vendors believe that the directory is a better place to store policies, because centrally managing policies in the hierarchical directory is easier. You can organize and replicate policies according to your organizational structure and link policies to applications, users, groups, organizations, and computers in the directory. The Directory Enabled Networks (DEN) initiative led by Microsoft and Cisco is defining a directory schema standard for network devices and services, including QoS services and policies, that will be a part of NT 5.0's Active Directory (AD). Vendors, including 3Com and Cisco, will deliver AD-based QoS policy management as part of their policy-based networking strategies.
In addition to the directory, the policy server plays a crucial role in QoS management. The policy server can accept QoS definitions from an administrative tool, translate them into QoS policies, and store and retrieve the policies in the directory. The server can also answer policy queries from a network device requesting a policy decision. For example, if a network device doesn't have local information, the device can query the policy server to determine whether user John can reserve 1Mbps bandwidth. The policy server can distribute policies to all QoS-enabled devices (i.e., policy clients) in its managed domain through a push or pull method. In the push method, the policy server will send policies to the policy client when a certain condition is triggered: for example, when an administrator creates or modifies a policy. In the pull method, the policy client will retrieve policies at defined intervals, such as once a day. You might have one or more policy servers in your network, based on how you partition your network into policy domains; one policy server manages each policy domain.
Figure 3 illustrates the directory-server-client relationship, in which the policy server stores and retrieves policy data in the directory using Lightweight Directory Access Protocol (LDAP), and the policy server and client communicate using either Common Open Policy Service Protocol (COP) or the DIAMETER protocol. LDAP is the Internet standard for directory access. Your directory must be LDAP-compliant (e.g., AD, Netscape Directory Server, Novell Directory Service—NDS). COP and DIAMETER are two policy transaction protocols that IETF is currently developing. Both protocols are Internet drafts and candidates to become policy transaction standards over the Internet.
QoS Implementation Methods
If you've decided to add QoS to your network, you can choose among three methods to implement your QoS-enabled network. The methods are networkcentric, network-based end-to-end, and application-based end-to-end.
Networkcentric. In the networkcentric method, you deploy QoS only in internetwork devices, such as switches and routers. You don't need to upgrade your legacy applications, servers, and workstations to support QoS. By using predefined QoS policies, the switches and routers can prioritize incoming traffic, reserve necessary bandwidth for the traffic, place packets into appropriate queues, and forward the packets. For example, a Layer 3 switch determines that SAP R/3 is originating incoming application data when the switch detects the data's TCP port in the packet. The switch can then apply a QoS policy to this traffic: for example, by setting IP Precedence to 7 and reserving 1Mbps bandwidth. The networkcentric method is the simplest QoS-enabling method, because it doesn't require changes in the user community. However, the networkcentric approach doesn't provide QoS on receiving computers. Bay Networks, Cisco, and Cabletron support the networkcentric method.
Network-based end-to-end. In the network-based end-to-end QoS-enabling method, you implement QoS not only in internetwork devices but also in computer NICs. A QoS-enabled NIC can classify application data passing through the NIC by setting its 802.1p and IP Precedence priorities based on predefined policies. You can thereby provide end-to-end QoS without modifying your existing applications. Currently, 3Com supports the network-based end-to-end method.
Application-based end-to-end. The application-based end-to-end QoS-enabling method requires implementation of QoS-enabled applications in workstations and servers. Using this method, you can fully exploit comprehensive QoS techniques, such as RSVP and SBM, from computer to computer in your network. Microsoft supports this approach in NT 5.0.
Microsoft QoS
Microsoft QoS consists of Generic QoS API, QoS Service Provider (SP), Traffic Control Interface, and Admission Control Service (ACS). Using Microsoft's Generic QoS API (part of Winsock 2), you can write a QoS-enabled application and specify the QoS requirement for the application. Then, QoS SP in the computer running the application can generate the RSVP message for the application. QoS SP then invokes Traffic Control Interface in the computer, which can classify the application traffic by defining its 802.1p and IP Precedence priorities, and schedule delivery time.
ACS provides QoS policy management, policy control, and SBM. ACS runs as a service on an NT 5.0 server and requires one ACS server per subnet in the network. Microsoft lets network vendors implement ACS in their routers and switches. ACS stores QoS policies in AD and uses LDAP to retrieve policy information from AD. You can link a QoS policy to a user, group, organizational unit, organization, or subnet in AD. When a client requests resource reservation, ACS checks the client's request against the QoS policies in the directory to verify the request.
Figure 4 shows how Microsoft ACS works with AD to implement QoS policy control. User John, who has logged on to the NT 5.0 domain from his computer, starts a QoS-enabled application, which requests a 56Kbps bandwidth reservation. QoS SP in the computer gets John a Kerberos ticket for ACS from the Kerberos server. The Kerberos ticket contains the user account information (e.g., domain\john) and session key. QoS SP forms a PATH message that includes the Kerberos ticket, and sends the message to the ACS server on the same subnet. The ACS server verifies the Kerberos ticket and checks domain\ john's permission to use 56Kbps through an LDAP lookup of John's user policy in AD. If the ACS server verifies the request, it sends the PATH message to the network. Otherwise, the ACS server sends John an error message.
QoS Becomes a Reality
If you're a systems administrator, you've probably dreamed of a tool that can give you better control of your network traffic. When you use QoS to prioritize network traffic and reserve network resources, you can ensure that low-importance network traffic won't bog down mission-critical and time-sensitive applications. By employing QoS policies, you can link network performance to your business priorities. And with Microsoft's support for QoS in NT 5.0 and network vendors' implementation of QoS in network equipment, you can build a QoS-enabled NT network. With QoS, your dream can become a reality.
