Policies and RSVP processing

Policies can be defined with RSVP scope. The RSVP Agent obtains a service policy for which traffic is mapped (if any) from the Policy Agent when an application that is using RAPI indicates it is a sender (when the Tspec is first provided), or when it requests a reservation as a receiver (when the Rspec is first provided for Guaranteed service). At both of these times, if a service policy is defined that maps to the data traffic, the RSVP Agent uses values in the service policy to limit the request from the application. Specifically, the following are limited:

Total number of RSVP flows.
The MaxFlows keyword on the PolicyAction statement of the policy definition can be used to limit the total number of application flows that use RSVP services.
Tspec token bucket values.
The MaxRatePerFlow and MaxTokenBucketPerFlow keywords on the PolicyAction statement of the policy definition can be used to limit the r and b values, respectively, in the sender supplied Tspec.
Rspec values.
The MaxRatePerFlow keyword on the PolicyAction statement of the policy definition can be used to limit the R value in the receiver supplied Rspec.
Reservation type.
The FlowServiceType keyword on the PolicyAction statement of the policy definition can be used to limit the type of reservation requested. A Guaranteed type request is considered to be "greater than" a Controlled Load type request. So if an application requests Guaranteed, but the policy limits the type to Controlled Load, the reservation uses Controlled Load.

RSVP processing proceeds as follows.

When an application uses RAPI to indicate it is a sender, the RSVP Agent packages the sender Tspec (along with other information) in an RSVP PATH packet, and sends the packet to the final destination. The packet is sent using RAW sockets, with the IP Router Alert option set. This option causes each router that supports RSVP to intercept the PATH packet, for the purpose of remembering the PATH request, and to insert a "previous hop" object into the packet, which is then sent again to the final destination. This causes the packet to eventually arrive at the destination, with all RSVP routers in the data path aware of the RSVP flow.

At the destination, the RSVP Agent passes the PATH packet to the application, using RAPI. The receiver application uses the Tspec and other information to arrive at a reservation request (flowspec). The receiver application uses RAPI to pass this flowspec to the RSVP Agent. The RSVP Agent then sends an RSVP RESV packet (containing the flowspec and other information) to the previous hop.

Each router or host along the path back to the sender receives this RESV packet, uses the flowspec to install the appropriate reservation (if possible), and forwards the RESV to its previous hop. In this way, each RSVP-capable router or host along the data path installs the reservation according to its capabilities. At the sender, the RSVP Agent passes the RESV packet information to the sender application, which then has information that indicates the actual reservation in place. The sender might choose to wait for the reservation to be in place, or might begin sending data before this happens (although such data is treated by the network as though no reservation were in place). Any router or host that is incapable of supporting the requested reservation might send an error to the receiver, which is then free to perhaps try a lesser reservation.

The z/OS UNIX RSVP agent can provide actual resource reservations on ATM interfaces. The RSVP agent passes the reservation request to the TCP/IP stack, where a bandwidth reserved SVC is established on the ATM link to support the reservation request. The RSVP agent can also cause the Type of Service (TOS) byte to be set for any given RSVP flow, by using the OutgoingTOS keyword on the PolicyAction statement of a defined service policy.