Background

QOS requires three components to make it work:

• Devices on the network—such as routers and switches—that are aware of this differentiation of services
• Local workstations that can prioritize traffic that they place on the network
• The policy component: who is allowed to use the available bandwidth and how much they are allowed to use

However, before we begin discussing these components, we need to look at the Resource Reservation Protocol, which is the signaling protocol used between QOS senders and QOS receivers. RSVP plays a major role in QOS and the integration of the three major components of QOS.

Resource Reservation Protocol

Resource Reservation Protocol (RSVP) is the glue that binds the network, application, and policy components into one cohesive unit. RSVP carries resource reservation requests through the network, which can be composed of different media. RSVP propagates a user's QOS requests to all RSVP-aware network devices along the data path, allowing resources to be reserved from all RSVP-enabled devices. As a result, the network nodes can indicate whether the network can meet the desired levels of service.

The RSVP protocol reserves network resources by establishing flows end to end through the network. A flow is a network path associated with one or more senders, one or more receivers, and a specific level of QOS. A sending host wanting to send data that requires a specific level of QOS issues a PATH message toward the intended recipient or recipients. This PATH message contains the bandwidth requirements. The relevant parameters are propagated along the path to the intended recipients.

A receiving host that is interested in this data reserves the resources for the flow (and the entire path from the sender) by sending a RESV (reserve) message back toward the sender. As this occurs, intermediate RSVP-enabled devices decide whether they can accommodate the requested bandwidth requirements and ensure that the user who is requesting resources actually has the permission to do so. If the requested bandwidth is available and the user's policy settings indicate the user has the right to the request, each intermediate RSVP-enabled device commits the resources and propagates the RESV message back toward the sender.

When the sender receives the RESV message, QOS data can begin to flow. Periodically, each endpoint within the flow sends out PATH and RESV messages to reaffirm the reservation and to provide network information in case the levels of available bandwidth change. Also, by periodically refreshing PATH and RESV messages, the RSVP protocol remains dynamic. In the event that a better (for example, faster) route becomes available, these refresh messages can discover a new route. When we discuss QOS from Winsock later in this chapter, we'll return to RSVP and how the Winsock API calls invoke it.

Be aware of one important aspect of the session setup and RSVP: it is a one-way reservation. This is the case even if the application requests bandwidth requirements for both sending and receiving. One session is initiated for the sending requirements and another session is started for the receiving requirements. Later in this chapter, we will discuss the criteria required for initiating an RSVP session.

Network Components

In order for end-to-end QOS to work, the network devices between the two endpoints must also be able to differentiate traffic priorities. This way they can route traffic in a manner that satisfies the QOS guarantee that an application received. Additionally, these network devices must be able to determine whether enough bandwidth is available on the network when an application requests bandwidth. To support these requirements, the following components have been created:

• 802.1p A standard for prioritizing packets in a subnet by setting 3 bits within the MAC header of packets
• IP Precedence A method to establish priority for IP packets
• Layer 2 signaling A mechanism for mapping RSVP objects to native WAN QOS components in OSI Layer 2 of a network
• Subnet Bandwidth Manager (SBM) A component that manages shared media network bandwidth
• Resource Reservation Protocol (RSVP) A protocol that carries QOS requests and information to QOS-aware network devices along the path between a sender and one or more receivers

802.1p

A major part of enforcing QOS provisions and avoiding treating all packets equally lies on hubs and switches within the network. Hubs and switches lie within Layer 2 of the OSI reference model and as a result are aware of fields only within the media access control (MAC) header at the beginning of each packet.

802.1p is a standard that prioritizes network packets by setting a 3-bit precedence value in the MAC header. When a subnet becomes congested on non-802.1p networks, switches and routers are unable to keep up with the amount of traffic and a delay is introduced. On the other hand, switches and routers on 802.1p networks can begin prioritizing incoming traffic based on the precedence bits and give the higher-priority packets preferential treatment.

Implementing 802.1p for QOS requires specialized hardware capable of recognizing this 3-bit field. Network interface cards (NIC), network drivers, and network switches all must be 802.1p-aware.

IP Precedence

IP Precedence is a method of specifying precedence values at a higher level than 802.1p. This method allows packets passing through OSI Layer 3 devices—such as routers—to have their relative priorities differentiated. IP Precedence is implemented by using the type of service (TOS) field within the IP header to establish varying levels of priority. Based on these bits, routers can establish priority queues to service the different priority levels, which means higher priority traffic receives better service from routers.

As with 802.1p, in order for IP Precedence to work, all Layer 3 devices on the network must be able to understand the significance of the IP Precedence bits and handle traffic accordingly.

Layer 2 signaling

Layer 2 signaling is necessary when traffic traverses a wide area network (WAN). Typically a WAN links several networks over a variety of communications hardware. Thus, a WAN can manipulate Layer 1, Layer 2, and Layer 3 information as data is transmitted. To guarantee end-to-end QOS, the WAN link must understand the prioritization of QOS traffic. To accomplish this understanding, QOS provides a method for mapping RSVP and other QOS parameters to the WAN's native underlying Layer 2 signaling method—the means by which WAN technologies implement their own native QOS.

Subnet Bandwidth Manager

The Subnet Bandwidth Manager (SBM) manages the resources on a given shared media network, such as Ethernet. The SBM is also responsible for handling policy-based admission control for QOS applications. An SBM is necessary on shared media networks because when an endpoint requests QOS for an application, each network device admits or rejects the request based on the allocation of the network device's private resources. The network devices are not aware of the available resources on the shared media. The SBM solves this problem by becoming a broker for these devices. The SBM is also closely tied to the Admission Control Service (ACS) that is a part of the policy component. The SBM must check to ensure that an application (or user) requesting bandwidth has the privileges to do so. Note that the SBM for a network can be a host running Windows 2000 Server.

Application Components

You now have a good idea of network requirements for supporting QOS. We must consider how the local system prioritizes data based on the QOS levels that an application has requested. For the local system to support QOS, the following components are necessary:

• GQOS service provider A service provider that invokes other QOS components
• Traffic Control module The module that controls the traffic leaving the computer (This module includes the Generic Packet Classifier, the Packet Scheduler, and the Packet Shaper.)
• Resource Reservation Protocol (RSVP) The protocol that is invoked by the GQOS service provider and that carries the reservation request across the network
• GQOS API The programmatic interface to GQOS, such as Winsock
• Traffic Control (TC) API The programmatic interface to the Traffic Control components regulating traffic on the local host

GQOS service provider

The GQOS service provider is the GQOS component that invokes nearly all resulting QOS facilities. The GQOS service provider initiates Traffic Control functionality (if appropriate) and implements, maintains, and handles RSVP signaling for all GQOS functionality.

In order to find the QOS-enabled service provider(s) on your host, you can query the provider catalog with WSAEnumProtocols. The flag to check whether a provider is QOS-enabled is within the WSAPROTOCOL_INFO structure returned from WSAEnumProtocols. The field of interest is dwServiceFlags1, and the flag to check for is XP1_QOS_SUPPORTED. For more information about WSAEnumProtocols, consult Chapter 5.

Traffic Control module

Traffic Control (TC) plays a significant and central role in QOS. Within TC, packets are prioritized both within and outside the network node on which TC is enabled. The effects of this preferential treatment of packets as they flow through the system and through the network reach across the entire network and therefore directly affect QOS characteristics. The TC module is implemented through three modules: the Generic Packet Classifier, the Packet Scheduler, and the Packet Shaper.

Generic Packet Classifier

The duty of the Generic Packet Classifier (GPC) is to classify and prioritize packets within network components. The GPC performs this prioritization for activities such as CPU time or transmission onto the network.

The GPC accomplishes this prioritization by creating lookup tables and classification services within the network stack. This becomes the first step in the prioritization process for network traffic.

Packet Scheduler

Packet scheduling controls the way data transmission is performed, which is a key function of QOS. The Packet Scheduler is the traffic control module that regulates how much data an application, or flow, is allowed, essentially enforcing QOS parameters set for a particular flow.

The Packet Scheduler takes the prioritization scheme provided by the GPC and provides different levels of service to the various priority levels. For example, data that has been classified by the GPC as high priority receives preferential treatment within the Packet Scheduler.

Packet Shaper

The purpose of the Packet Shaper is to regulate the transmission of data from data flows onto the network. Most applications read and write data in bursts; however, many QOS applications need a particular data rate for sent data. Therefore, the Packet Shaper schedules the transmission of data over a period of time, smoothing out network usage and resulting in a more evenly loaded network.

Traffic Control API

The Traffic Control API is the interface to the components that regulate network traffic on the local host. This includes methods for manipulating the Generic Packet Classifier, the Packet Scheduler, and the Packet Shaper. Some of the Traffic Control functions are implicitly invoked through calls made to Winsock GQOS-enabled functions that are serviced by the GQOS Service Provider. However, applications that need to manipulate the Traffic Control components directly can do so with the Traffic Control API functions. These functions are beyond the scope of this book. (Consult the Platform SDK for more information.) We will cover the Winsock GQOS API later in this chapter.

Policy Components

Policy, the third and final component of GQOS, controls the allocation of resources to QOS-enabled applications. Policy components are of most interest to system administrators who want to control the allocation of resources based on users or on the class of application requesting bandwidth. Policy components include the following:

• Admission Control Service (ACS) A Windows 2000 Server service that intercepts RSVP PATH and RESV messages to control access of QOS-enabled clients to the various levels of guarantees offered through QOS
• Local Policy Module (LPM) Provides resource-access decisions based on policies configured through ACS for the SBM
• Policy Element (PE) Resides on the client and provides authentication information to facilitate reservation requests

Admission Control Service

The Admission Control Service (ACS) regulates network usage for QOS-enabled applications. This is done through the RSVP protocol. The ACS intercepts both PATH and RESV messages in order to verify that the requesting application has sufficient privileges. Once an RSVP message is intercepted, it is passed to the Local Policy Module (LPM), which performs the actual authentication.

The ACS resides on a Windows 2000 machine and can be configured by the system administrator, who can set resource limits on users, applications, or groups.

Local Policy Module

The Local Policy Module (LPM) is closely related to the ACS in that the ACS intercepts RSVP messages, inserts user information, and passes them to the LPM. At this point, the LPM looks the user up in the Active Directory to verify policy information. If network resources are available (as determined by the SBM), and if the authentication check succeeds, the RSVP message intercepted by the ACS is sent to the next hop. Of course, if the user does not have the necessary permissions to request a certain level of QOS, an error indicating this is generated and returned within the RSVP message.

NOTE

---

For policy checks to succeed, users must be part of a Windows 2000 domain.

Policy Element

This component actually contains the policy information that the Local Policy Module requests. These data structures are not covered in this book because they deal mainly with administration of network resources, which is not the focus of the book.