
RSVP -- ReSerVation Protocol
USC Information Sciences Institute
Marina del Rey, CA

Release 4.2a2
Date: December 30, 1997

This directory contains the source (and SunOS binaries) for Alpha 2
version of release 4.2 of the ISI implementation of the RSVP protocol.
This version implements the Proposed Standard RSVP protocol as defined
in RFC 2205, and its application to Integrated Services as defined in
RFC 2210.

This release contains a change to the RAPI interface; see below.

For questions or comments on this code, you may send email to:
isi-rsvp@isi.edu.  A general mailing list for discussion of
interoperability problems among different RSVP implementation is:
rsvp-test@isi.edu.

DIRECTORIES

In addition to this README file, the release includes a makefile and
the following directories:

	docs/
		Contains man pages for rsvpd and many of the tools, as
		well as an API interface specification.

	rsvpd/
		Contains source for the user-level daemon program
		rsvpd, which may execute on a host or a router to
		implement the RSVP reservation setup protocol.

		Also contains source for librsvp.a, a client library
		module that can be linked with an application that
		needs to make resource reservations.  This module
		communicates with rsvpd via a Unix socket to implement
		an RSPV API ("RAPI").

	apitools/
		Contains rsvpd diagnostic and management tools that
		depend upon the RAPI API.  See apitools/README file
		for more information.

	tools/
		Contains rsvpd diagnostic and management tools that
		are not based on the API.  See the tools/README file
		for more information.


OVERVIEW

This release conforms to the integrated service rules for RSVP usage
specified in RFC-2210.  It also incorporates a number of bug fixes,
many contributed by others; see the CHANGES files for acknowledgments.

The RSVP daemon rsvpd has three major interfaces:

    (a) To application programs (the API)

	This release of the API client interface has been further
	revised to conform to RFC 2210: (1) the final
	definitions of Flowspecs and Adspecs are now supported; (2) an
	additional parameter is now included in rapi_sender call, to
	optionally pass an Adspec.  In addition, the RAPI type codes
	have been modified.  All applications using RSVP Release 4.1
	will need to be recompiled.

	The current interface is documented in files docs/rsvpapi.ps,
	.txt within this distribution.  See especially Section 4.

        This release includes an important first step towards the future:

	    The RSVP API ("RAPI") interface has been modified to match
	    the RSVP interface that is being proposed to XOPEN as a
	    standard API.  In particular, rapi_lib.h has been
 	    significantly reorganized.  The obsolete "legacy format" code
	    is now removed.

    (b) To a traffic-control kernel

	The RSVP daemon can be used to establish reservation state in
	hosts and routers.  In each node, rsvpd will attempt to pass
	this state to a kernel capable of "traffic control" (TC), via a
	kernel-specific TC adaptation module.  If an rsvpd linked with
	this module is executed on a kernel that does not have ISPS
	support, the ISPS adaptation module will discover this at
	initialization time and prevent further kernel calls.

	In many cases, hosts will not include traffic control in their
	kernels; they will instead depend upon over-provisioning of
	their LAN's to provide adequate QoS.  However, every host using
	RSVP must run an RSVP daemon.  Rsvpd can be compiled without a
	TC adaptation module by leaving the SCHEDULER compile-time
	symbol undefined (see below).

	The TC interface was updated to more exactly match that of the
	spec.

	This release includes a stub adaptation module tc_test.c for
	testing or running RSVP on a host without any local traffic
	control.  If traffic control is to be used, a real tc_xxx.c
	module must be written.

    (c) To routing

	This release uses a general framework known as RSRR (Routing
	Support for Resource Reservation) for interfacing to routing
	protocols.  This release includes:

	--  an RSRR interface to the multicast routing code distributed
	    by Xerox PARC and based upon on the DVMRP protocol.
		
	--  a unicast routing interfaces to:

		* The kernel routing table in Sun OS and other older BSD-
		  derived systems.

		* 4.4BSD derivatives and other systems that implement
		  a 'routing socket'.

		* Sun Solaris 2.5


NEW FEATURES OF THIS RELEASE

Release 4.2 has the following new features:

1. IPV6 SUPPORT

    This release adds support for IPv6.  The current version should be
    able to concurrently support both IPv4 and IPv6 RSVP protocol
    processing on a mixture of network interfaces (but with the
    limitations listed in rsvpd/README).  The IPv6 support led to a
    complete rewrite of the socket interface code.  Hence, this release
    is significantly different from previous releases in the system
    interface area.

2. DIAGNOSTIC MESSAGE SUPPORT

    This release includes experimental support for the RSVP Diagnostic
    messages, as defined in the (expired) Internet Draft
    draft-ietf-rsvp-diagnostic-msgs-03.txt.  The implementation does
    not follow the draft strictly with regard to sending and receiving
    diagnostic messages at the final hops. This is detailed in the
    rsvpd/README.

3. LLDAL MODULARIZATION

    This is described in rsvpd/README.



SYSTEM REQUIREMENTS

This RSVP implementation supports workstations used either as end
systems or as routers.

 -- Hardware and Operating Systems supported

    This code supports Sun workstations under SunOS 4.x and PCs under
    FreeBSD.  In addition, earlier versions have been ported to:

	* Sun workstations under Solaris 2.5 [Available from Sun]

	* SGI workstations under IRIX 5.3 (host support only)

	* SGI workstations under IRIX 6.2

	* DEC Alpha workstations under Digital Unix (formerly OSF/1)
	  version 3.0 (host support only)

        The Solaris version is available from Don.Hoffman@eng.sun.com.

	NOTE: Many portability issues have been addressed, but you
	should not expect that the code will compile without
	modification on any particular system.  At least the config.h
	file, and perhaps some others, may need modification for your
	system.

  -- Multicast support

	This release supports the following versions of IP multicast,
	compiled with the RSVP extensions enabled.

	* For use on a router: the pruning version of IP multicast,
	  specifically PARC's release 3.5 of the kernel with the June
	  95 updates or later, and their release 3.6, or later, of mrouted.

	* For use on a host: Any release of IP multicast.  However, UDP
	  encapsulation will be required if the IP multicast release is
	  prior to 3.3.

	* See rsvpd/README for status of multicast routing support for IPv6.

COMPILATION

Make any changes necessary in options in 'Makefile', and then enter:

	make depend
	make


WHAT IS IMPLEMENTED IN THIS RELEASE

This version is intended to implement;

		o HOP objects in ResvErr messages
 		o Creating default Adspec objects in Path messages
		o WF, FF, and SE styles.
		o Unicast and multicast sessions
		o Blockade state
		o Multihoming
		o Port usage rules
		o Confirmation messages
		o Scope objects
		o UDP encapsulation
		o Route change notification and local repair
		o Randomization of refresh timeouts.
		o Sending Router Alert option
		o INTEGRITY objects
		o Forwarding unknown-class objects
		o IPv6 support
		o Adspec initiation from the API


WHAT IS NOT IMPLEMENTED IN THIS RELEASE

 o  Traffic control

    This release, as distributed by ISI, includes no traffic control
    mechanisms: no classifier, packet scheduler, or admission control.

 o  The IPSEC

    The IPSEC extensions to RSVP are only partially implemented.

 o  RSVP MIB

    The RSVP MIB is not implemented.

 o  INTEGRITY

    INTEGRITY is only partially implemented.

 o  POLICY_DATA objects

    A POLICY_DATA is always NULL, and there is no code to build such
    objects or to perform any administrative control over reservations.

 o  Multicast Features

    Multicast tunnels are not supported in this release.

 o  RSVP message fragmentation

    RSVP message fragmentation is not supported (in accord with RFC 2205).

 o  Variable Refresh Times

    This release uses a timeout value R = 30 seconds and K = 3.  It
    does not dynamically adjust R, nor does it support different
    refresh rates on different interfaces.

In addition, there are several features that do not work correctly
under SunOS (and perhaps other OSs) because of limitations of available
RSVP kernel support.  These features include:

	* The IP source address in a Path message is not set to the
	  original sender, but instead it is the address of the node that
	  last forwarded it.

		Note: the logic of the rsvp_trans.c module is
		system-dependent; versions in this release may need to
		be changed for other systems.

	* Multihomed hosts (nodes that do not run mrouted but have more
	  than one interface) may be unable to correctly determine the
	  interface on which a Path message arrives.  However, a heuristic
	  (kludge) is included that will work correctly when routing is
	  symmetric.

	* The TTL of a Path message is not set correctly; it is always
	  sent as 255.


ACKNOWLEDGMENTS

Many people have contributed to the basic design of the RSVP protocol.
These include [in inverse alphabetical order]: Lixia Zhang (PARC),
Daniel Zappala (USC), John Wroclawski (MIT), Scott Shenker (PARC),
Sugih Jamin (PARC/USC), Shai Herzog (ISI), Deborah Estrin(ISI/USC),
Steve Deering (PARC), Dave Clark (MIT), Bob Braden (ISI), and Steven
Berson (ISI).  A number of members of the RSVP Working Group of the
IETF made substantial contributions to the final RSVP design.

The first experimental implementation of RSVP, mostly in a Sun kernel,
was developed at Xerox PARC by Sugih Jamin.  The present daemon
implementation was developed at ISI by Shai Herzog, Steven Berson, Bob
Braden, Daniel Zappala, Subramaniam Vincent, Bob Lindell, and Jeff Kann.
Significant contributions to this code have been made by Don Hoffman at
Sun Microsystems, John Wroclawski and Garrett Wollman at MIT, Joshua
Gahm at BBN, Bill Nowicki at Silicon Graphics, and Andreas Terzis at
UCLA.  The nv application was developed by Ron Frederick at PARC, while
the vic application was developed by Steve McCanne at LBL.

We have received a great many bug and portability fixes from many
people; these are generally noted in the CHANGES files.  We have also
received very helpful input from Lee Breslau at PARC, Fred Baker at
Cisco Systems, and John (jj) Krawczyk at Bay Networks.

Development of this code at ISI was funded by the Advanced Research
Projects Agency (ARPA) of the US Department of Defense.
