ReSerVation Protocol API (RAPI)
Copyright © 1998 The Open Group
This Appendix contains some general remarks based on ISI's experience in implementing this API with their release of RSVP code.
There are three protocol interfaces involved in invoking RSVP via the API:
The term RAPI (RSVP API) is used for the function call interface to applications, and for the data structures (objects) used in that interface. This document is primarily concerned with the RAPI interface. This interface is realized by functions included in the library routine librsvp.a, which is compiled from rapi_lib.c and rapi_fmt.c.
The term API is used in the code for the local protocol across the socket between the librsvp.a routines and the RSVP daemon rsvpd. This protocol generally uses RSVP object bodies but RAPI object framing.
The RSVP protocol is used in the Internet between RSVP daemon programs.
The code is organized to make these three interfaces logically
independent, so they can be changed independently. Each of these three
protocol interfaces has an independent version number, defined in
The RAPI call library librsvp.a includes routines which convert objects between RAPI and API formats. Similarly, the file rsvp_api.c included in the RSVP daemon includes routines that convert between the API representation and the RSVP representation. In some cases, these conversion functions are identity transformations (that is, pure copies). However, they provide the structure to allow any of the three interfaces to be changed in the future.
There are two different object framing conventions. RAPI and API objects have a 2-word header - a total length in bytes, and a format code - and a body. RSVP objects have a 1-word header. In general, objects in the API interface (that is, across the socket) carry the 2-word RAPI object header, but their body is that of the corresponding RSVP object. Therefore, the API<->RSVP conversion in rsvp_api.c simply maps the framing convention.
In the RAPI interface, the application is given some choice of data formats. For example, QoS control objects (that is, flowspecs, Tspecs, and Adspecs) can be represented in either the RSVP (really Int-Serv) format, which has complex packing, or in the more convenient Simplified format. The RAPI library routines map between Simplified format and Int-Serv format, which is used across the API.
Each instance of the RAPI library routines keeps a local (to the application process) table of open RAPI sessions. The index into this table is the session handle (a_sid) used locally.
The RSVP daemon keeps its own table of RAPI sessions. From the daemon's viewpoint, a RAPI session is defined by the triple (fd, pid, a_sid), where fd is the file descriptor for the socket, pid is the process id, and a_sid is an application session id received over fd from pid.
In the ISI reference implementation of RSVP: