RSVP -- ReSerVation Protocol USC Information Sciences Institute Marina del Rey, CA Release 4.2a4 Date: August 18, 1998 This directory contains the source (and SunOS binaries) for Alpha 4 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. 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, and rsvpd/README for more information on what is new in this release. 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 of that document. 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). 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 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; see rsvpd/README for more details. 3. LLDAL MODULARIZATION This is described in rsvpd/README. 4. RSRR v2 A new version of RSRR has been implemented that unifies support for IPv4 and IPv6, including both unicast and multicast routing information. Prior versions of RSRR supported only multicast routing. 5. INTEGRITY The RSVP INTEGRITY implementation has been updated to the last version of the Internet draft. It contains a stronger form of protection against replay attacks. The current implementation does not include the handshake or out of order message tolerance. In addition, key management procedures are not supported. These features will be included in the next release. 6. SCRAPI A new simplified API, called SCRAPI, is provided in the apitools directory. See the apitools/README for more information. 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/2.6 [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 mostly 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.