Previous section.

Resource ReSerVation Protocol API (RAPI)
Copyright © 1998 The Open Group

Example Implementation

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 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 <rapi.h> and <rsvp.h>, for RAPI and RSVP, respectively.

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<-&#62;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.

RAPI Sessions

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.

The first rapi_session() call in a particular instance of the RAPI library opens a UNIX-domain RAPI socket to the RSVP daemon and passes the session registration request across it. If the application (or the daemon) crashes without properly closing the RAPI socket, the other side will be notified to perform a cleanup. In particular, if the user process terminates without explicitly closing the RAPI session, the daemon will delete the corresponding reservation state from the routers.

Implementation Restrictions

In the ISI reference implementation of RSVP:

Implementation Model

ISI RAPI Implementation Model shows RAPI's implementation model.

Figure: ISI RAPI Implementation Model

Contents Next section Index