How QoS ACS Works

To deploy real-time multimedia or other mission-critical applications with an acceptable traffic rate, a network must commit to some level of guaranteed resource availability. In addition, the subnet management service must find some way for this priority traffic to coexist with traditional traffic. The alternative is a different physical network for each type of traffic: a very costly, high-administration solution.

The QoS ACS solves this problem by allowing the network administrator to centrally designate how, by whom, and when shared network resources are used. An QoS ACS performs logical allocation of network resources by participating in the signaling protocol, but does not allocate physical network resources such as network bandwidth or network queues. Note that it is RSVP messages that are passed to the QoS ACS, not the data packets which are ultimately transmitted from sender to receiver.

A host application can still send traffic not associated with a RSVP request and potentially overcommit the network. However, QoS ACS deployed with other traffic separation mechanisms can prevent network overcommitment. For example, on an Ethernet switch supporting IEEE 802.1p priority management, an QoS ACS can perform admission control to the high-priority band of traffic, and the 802.1p priority mechanism prevents the best-effort traffic from starving the high-priority traffic.

The QoS ACS server controls bandwidth for the subnet to which it is connected. Any devices on the same subnet (subnet clients) submit their priority bandwidth requests to that QoS ACS server.

Figure 9.9 shows an QoS ACS server configured to allow a maximum bandwidth reservation of 20 megabytes (MB). Each client represents a device on the managed subnet.

As each request is received by the QoS ACS server:

• The QoS ACS verifies whether network resource levels are adequate. The ACS can verify for the sender, receiver, or both.
• The requesting user identity is verified using the Kerberos protocol (the default Windows 2000 authentication service).
• The QoS ACS policy for that user is retrieved from Active Directory (it might already be cached on the QoS ACS server).
• The QoS ACS server checks the policy to see if the user has adequate rights for the request.
• The QoS ACS approves or rejects the request.

Enlarge figure

Figure 9.9 How QoS ACS Works

1. A video-conferencing application on Client A requests 10 MB of reserved bandwidth. The QoS ACS server determines that there is available bandwidth and logically grants the reservation. This leaves 10 MB of available bandwidth out of the possible 20 MB.
2. A video-conferencing application on Client B requests 10 MB of reserved bandwidth. Because there is still bandwidth available, the QoS ACS server logically grants the reservation. No additional bandwidth is available.
3. A video-conferencing application on Client C requests 10 MB of reserved bandwidth. Because no priority bandwidth is available at this time, the QoS ACS server rejects the reservation. The application on Client C can then determine whether to send the data now at a best-effort service level or wait until priority bandwidth becomes available.

Clients and servers running Microsoft® Windows® 98 or Windows 2000 or subnet bandwidth management client software are automatically configured to use an available QoS ACS server to request priority bandwidth. The QoS ACS server sends IP multicast beacons, messages that notify subnet clients that the QoS ACS server is ready to receive bandwidth reservation requests. A client does not attempt to send a request to an QoS ACS server that is not currently beaconing on the subnet. The beacon protocol is documented in the IETF RSVP working group draft on Subnet Bandwidth Manager (SBM). A client connected to the shared media subnet listens for an QoS ACS beacon, and if it hears the beacon it sends its RSVP and PATH messages to the QoS ACS. If the client is not on an QoS ACS-managed subnet, or there is not currently an QoS ACS server operating on the subnet, RSVP messages are forwarded following standard IP routing methodology. Routers and bridges supporting the Subnet Bandwidth Manager client, that are connected to shared media such as Ethernet must also detect the QoS ACS on the segment and forward RSVP messages to the QoS ACS for that subnet.

The QoS ACS server grants or rejects bandwidth requests based on the QoS ACS policy rights of the requesting user. When the request is granted, priority bandwidth is logically (each hop must physically allocate bandwidth when it grants the request) allocated by the QoS ACS server, and the request is forwarded to the receiving client. The QoS ACS server rejects a request if the user does not have the right to reserve priority bandwidth on that subnet, to reserve the requested amount of bandwidth, or if the subnet itself is not capable of making the guarantee at the time of the request.

Traffic is never blocked if a request cannot be granted. Instead, the sending application is immediately notified and it determines whether to continue sending the data at a best-effort service level or wait and request priority bandwidth later. If the application chooses to send the data anyway, the traffic is carried by the network as best-effort traffic with no reservation.

Note that the QoS ACS performs admission control for both PATH (sender) and RESV (receiver) RSVP messages.

© 1985-2000 Microsoft Corporation. All rights reserved.