Example Implementation

This Appendix contains some general remarks based on ISI's experience in implementing this API with their release of RSVP code.

Protocols

There are three protocol interfaces involved in invoking RSVP via the API:

• Procedure Call Interface to Application

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.

• Application-Daemon Protocol

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.

• RSVP Protocol

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 <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:

• The RAPI_FILTERFORM_GPI and RAPI_FILTERFORM_GPI objects and the session flag RAPI_GPI_SESSION were implemented in RAPI and the API, but the IPSEC extensions were not fully implemented in RSVP.
• The SenderAdspec and SenderPolicy parameters in rapi_sender() were not implemented.
• The Style_Ext and Rcvr_Policy parameters in rapi_reserve() were not implemented.

Implementation Model

ISI RAPI Implementation Model shows RAPI's implementation model.