You can read this topic to learn about protocols, APIs, and requirements for a router that is enabled for the ReSerVation Protocol (RSVP). The current quality of service (QoS) APIs include the RAPI API, the qtoq socket API, the sendmsg() API, and the monitor APIs.
Most QoS policies require the use of an API. The following APIs might be used in conjunction with either a differentiated service or integrated service policies. There are also a number of APIs to use with the QoS monitor.
The RSVP, along with the RAPI APIs or qtoq QoS sockets APIs, performs your integrated service reservation. Every node that your traffic travels through must have the ability to use RSVP. The ability to carry out integrated services policies is often referred to as RSVP-enabled. The traffic control functions can be used to determine which router functions are needed to use RSVP.
RSVP is used to create an RSVP reservation in all the network nodes along your traffic's pathway. It maintains this reservation long enough to provide your policies requested services. The reservation defines the handling and bandwidth that the data in this conversation will require. The network nodes each agree to provide the data handling defined in the reservation.
RSVP is a simple protocol in that reservations are only made in one direction (from the receiver). For more complex connections, such as audio and video conferences, each sender is also a receiver. In this case, you must set up two RSVP sessions for each side.
In addition to RSVP-enabled routers, you need to have RSVP-enabled applications to use integrated services. Because the iSeries™ server does not have any RSVP-enabled applications at this time, you will need to write the applications using the RAPI API or the qtoq QoS socket APIs. This will enable the applications to use the RSVP protocol. If you want an in-depth explanation, there are many sources that explain these models, their operation, and message handling. You need a thorough understanding of the RSVP protocol and the contents of Internet RFC 2205.
qtoq socket APIs
You can use the qtoq QoS socket APIs to simplify the work required to use the RSVP protocol on the iSeries system. The qtoq socket APIs call the RAPI APIs and perform some of the more complex tasks. The qtoq socket APIs are not as flexible as the RAPI APIs, but they provide the same functions with less effort. The no-signal versions of the APIs allow you to write the following applications:
The RSVP signaling is done automatically on behalf of the client side.
See the QoS API Connection oriented functional flow page, or the QoS API Connectionless functional flow page for typical QoS API flow for an application/protocol using connection oriented or connectionless qtoq QoS sockets.
If you decide to use an application token in a differentiated service policy, the application providing this information must be specifically coded to use the sendmsg() API. This is done by the application programmer. The application's documentation must provide valid values (token and priority), which the QoS administrator will use in the differentiated service policy. The differentiated service policy then applies its own priority and classification to traffic which matches the token set in the policy. If the application does not have values which match the values set in the policy, either the application must be changed, or you need to use different application data parameters for the differentiated service policy.
The following information briefly describes the server data parameters: application token and application priority.
What is an application token?
An application token is a Uniform Resource Identifier (URI) that represents a defined resource. The token you specify in the QoS policy is matched against the token provided by the outbound application. The application provides the token value by using the sendmsg() API. If the tokens match, the application traffic is included in the differentiated service policy.
What is an application priority?
The application priority you specify is matched against the application priority provided by the outbound application. The application provides the priority value by using the sendmsg() API. If the priorities match, the application traffic is included in the differentiated service policy. All traffic defined in the differentiated service policy will still receive the priority given to the entire policy.
For more information about the DiffServ policy type, see Differentiated service.
The Resource Reservation Setup Protocol APIs include the monitor APIs. The APIs that apply to the monitor will have the word monitor in the title. For example, QgyOpenListQoSMonitorData. The following list briefly describes each monitor API: