Background

Background

QOS requires three components to make it work:

• Devices on the network—such as routers and switches—that are QOS aware

• 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

Before we begin discussing these components, we need to look at the RSVP, 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.

RSVP

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 an 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 requesting resources 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. If 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

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. In addition, these network devices must be able to determine whether enough bandwidth is available on the network when an application requests it. To support these requirements, the following components have been created:

• 802.1p A standard for prioritizing packets in a subnet by setting three bits within the media access control (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 a network's OSI Layer 2

• Subnet Bandwidth Manager (SBM) A component that manages shared media network bandwidth

• 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 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 special 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 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, so higher priority traffic receives better service from routers.

As with 802.1p, 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 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.

SBM

The 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 (TC) module The module that controls the traffic leaving the computer. (This module includes the Generic Packet Classifier (GPC), the Packet Scheduler, and the Packet Shaper.)

• 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

• TC API The programmatic interface to the TC 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 TC functionality (if appropriate) and implements, maintains, and handles RSVP signaling for all GQOS functionality.

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 2.

TC Module

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.

GPC

The duty of the 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 TC 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 that the GPC provides and offers 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.

TC API

The TC API is the interface to the components that regulate network traffic on the local host. This includes methods for manipulating the GPC, the Packet Scheduler, and the Packet Shaper. Some TC 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 TC components directly can do so with the TC API functions. These functions are beyond the scope of this book. (Consult the Platform Software Development Kit (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:

• 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 that QOS offers

• 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

ACS

The ACS regulates network usage for QOS-enabled applications. This is done through the RSVP protocol. The ACS intercepts both PATH and RESV messages to verify that the requesting application has sufficient privileges. Once an RSVP message is intercepted, it is passed to the 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.

LPM

The LPM is closely related to the ACS in that the ACS intercepts RSVP messages, inserts user information, and passes the messages to the LPM. At this point, the LPM looks the user up in 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 that the ACS intercepts 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.

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

Policy Element

This component contains the policy information that the LPM 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 this book.