The second type of outbound bandwidth policy you can create is an integrated service policy. Integrated service provides the capability for IP applications to request and reserve bandwidth using the ReSerVation Protocol (RSVP) and quality of service (QoS) APIs.
Integrated service policies use the RSVP protocol and the Resource Reservation Setup Protocol (RAPI) API (or qtoq socket API) to guarantee an end-to-end connection. This is the highest level of service you can designate; however, it is also the most complex.
Integrated service deals with traffic delivery time and assigning particular traffic special handling instructions. It is important to be conservative with your integrated service policies because it is still relatively expensive to guarantee data transfer. However, over provisioning your resources can be even more expensive.
Integrated service reserves resources for a particular policy before the data is sent. The routers are signaled before data transfer and the network actually agrees to and manages (end-to-end) data transfer based on a policy. A policy is a set of rules that designate an action. It is basically an admission control list. The bandwidth request comes in a reservation from the client. If all the routers in the path agree to the requirements coming from the requesting client, the request gets to the server and IntServ policy. If the request falls within the limits defined by the policy, the QoS server grants permission for the RSVP connection and will then set aside the bandwidth for the application. The reservation is performed using the RSVP protocol and RAPI API, or the RSVP protocol and qtoq QoS sockets APIs.
Every node that your traffic travels through must have the ability to use the RSVP protocol. The routers provide QoS through the following traffic control functions: packet scheduler, packet classifier, and admission control. The ability to carry out this traffic control is often referred to as RSVP-enabled. As a result, the most important part of implementing integrated services policies is being able to control and predict the resources in your network. To get predictable results, every node in the network must be RSVP-enabled. For example, your traffic is routed based on resources, not on which paths have RSVP-enabled routers. Crossing routers that are not RSVP-enabled might cause unpredictable performance problems. The connection is still made, but the performance that the application requests is not guaranteed by that router. The following figure shows how the integrated service function logically works.
The RSVP-enabled application on the server detects a connection request from the client. In response, the server's application issues a PATH command to the client. This command is issued using the RAPI APIs or qtoq QoS sockets APIs and contains router IP address information. A PATH command contains information about the available resources on the server and the routers along the path as well as route information between the server and the client. The RSVP-enabled application on the client then sends a RESV command back along the network path to signal the server that the network resources have been allocated. This command makes the reservation, based on the router information from the PATH command. The server and all routers along the path reserve the resources for the RSVP connection. When the server receives the RESV command, the application starts transmitting data to the client. The data is transmitted along the same route as the reservation. Again, this shows how important the routers' abilities to carry out this reservation are to the success of your policies.
Integrated service is not meant for short term RSVP connections, like HTTP. Of course this is at your discretion. Only you can decide what is best for your network. Consider what areas and applications are having performance problems and need QoS. Applications used in an integrated service policy must be able to use the RSVP protocol. Currently, your server does not have any RSVP-enabled applications, so you will need to write the application to use RSVP.
As packets arrive and attempt to leave your network, your server determines whether it has the resources to send the packet. This acceptance is determined by the amount of space in the token bucket. You manually set the number of bits to allow into your token bucket, any bandwidth limits, token rate limits, and the maximum number of connections your server allows. These values are referred to as performance limits. If the packets remain within the server's limits, the packets conform and are sent out. In integrated services, each connection is granted its own token bucket.
Integrated service using differentiated service markings
If you are unsure that the entire network can guaranteed an RSVP connection, you can still create an integrated service policy. However, if the network resources cannot use RSVP, the connection cannot be guaranteed. In this situation, you might want to apply a codepoint to the policy. This codepoint is typically used in differentiated service policies to give a class of service to traffic. Even if the connection is not guaranteed, this codepoint will attempt to give the connection some priority.