/*
 *  $Id: README,v 4.13 1997/12/31 00:01:37 braden Exp $
 */

README File for RSVP Daemon Program rsvpd
Release 4.2a2

OVERVIEW OF RELEASE

Release 4.2a2 adds two new features: LLDAL modularization and IPv6
unicast routing support.  Otherwise it is a maintenance release,
fixing a number of bugs that were found in 4.2a1.

LLDAL MODULARIZATION

In previous versions of rsvpd, the organization of the interface to
traffic control really assumed the use of simple static point-to-point
virtual circuits or leased lines.  In order to provide a framework for
supporting link layers with more complex structure (e.g., ATM or frame
relay), we redesigned rsvpd's interface to traffic control.  In
particular, we introduced a link-layer-dependent adaptation layer
(LLDAL) between the core processing of RSVP and traffic control.

An LLDAL module for a particular link layer technology will generally
contain its own internal reservation data structures; for example, for
a point-to-point circuit LLDAL, this is the TCSB.  The core RSVP
processing deals only with RSBs.  An LLDAL for a link layer technology
that creates its own virtual circuits and perhaps has its own
multicasting mechanisms may contain more complicated internal data
structures.  Note that the rules for merging reservations from
different next hops on the same outgoing interface may be quite
different for a different link layer (LLDAL module).

This release includes one LLDAL module, for point-to-point circuits.
The LLDAL reorganization made significant changes in the detailed
code for reservation processing.


IPv6 SUPPORT: KNOWN LIMITATIONS AND PROBLEMS

The IPv6 support is included only if the symbol USE_IPV6 is defined.
On most systems this should get automatically set at compile time, when
appropriate, without manual intervention.  With this symbol defined,
this version of the IPv6 support compiles and runs under Sun Solaris
2.5.1 with release 5.3 of the IPv6 for Solaris package
(http://playground.sun.com/pub/solaris2-ipv6/html/solaris2-ipv6.html).
However, since the SUN Solaris RSVP package cannot yet be loaded with
the IPv6 package, only UDP encapsulation mode is currently available
for IPv6 under Solaris.

The IPv6 support in this release also compiles and runs under FreeBSD
2.2.2.

Release 4.2a2 includes support for IPv6 unicast routing.  However, the
interface to multicast routing, known as RSRR, does not yet support
IPv6.  This version of rsvpd does understand both IPv4 and IPv6 logical
and physical network interfaces that are contained in the kernel
interface table.

There is no support for IPv6 flow ids at this time.

The Router Alert option for RSVP/IPv6 packets is not implemented.

A couple of socket options for IPv6 that rsvpd uses are not implemented
under Solaris 2.5.1/IPv6 5.3.  Use the conditional WORKAROUNDS when
compiling the code, to get around these.

DIAGNOSTIC MESSAGE SUPPORT

This release contains an experimental implementation of the RSVP
diagnostic message, implemented by Andreas Terzis of UCLA in
collaboration with Subramaniam Vincent of ISI.  In particular, this
release implements a version of the Diagnostic message defined in an
unpublished draft, interpolated between the 02 draft and the current
draft draft-ietf-rsvp-diagnostic-msgs-03.txt.  Support for the 03 draft
will be in the next release.

This implementation uses UDP encapsulation for the first and last
diagnostic hops.  As a result, the "response address" (to which the
final diagnostic reply is sent) is implemented as an (IP address, UDP
port) pair; the protocol spec called for only an IP address.  The
advantages of using UDP are that muliple traces can be simultaneously
be run from the same system and that this is independent of whether
Rsvpd is running on the system or not.

The implementation has been done in two parts: RSVP daemon support for
the diagnostic protocol extension, and a new client tool called
Rsvptrace.  Rsvptrace is a user program that sends diagnostic request
messages and collects path and reservation state for a session along
the reverse path to a sender; it appears in the /tools/ directory.

To enable daemon support for diagnostics, the rsvpd module must be compiled 
with a -DRSVP_DIAGS symbol turned on in the Makefile.  Correspondingly, to 
compile Rsvptrace in the tools module, the symbols -DRSVPTRACE -DRSVP_DIAGS 
must be turned on in the tools makefile.

This version of RSVP diagnostic messages has been tested under SunOS and 
FreeBSD.  It support diagnostics only for IPv4 reservations.  The RSVP 
diagnostics specification is currently defined only for IPv4.  The usage of 
the Rsvptrace tool along with an example is explained in the man page, which 
is distributed with the docs module. 

Known problems with diagnostic messages in this release : 

The link MTU check (along the path of the diagnostic request) for
fragmentation of replies is currently disabled.  Consequently,
fragmentation of a diagnostic reply at message boundaries will not
happen automatically.

Upcoming releases will have a fix for this problem.

COMPILATION

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

	make depend
	make

PORTABILITY ISSUES

(a) Byte-order and integer-size issues

    Byte-order and data size controls are centralized in the header
    file rsvpd/rsvp_types.h'.  If you are running SunOS 4.1.x, BSD, or
    OSF/1, then you probably don't need to touch this file.  Otherwise,
    you will probably have to edit `rsvp_types.h' and maybe
    `bsdendian.h' to suit your CPU and operating system.  If you have a
    <machine/endian.h> header file, then you can define
    HAVE_MACHINE_ENDIAN_H and it will try to get that part right on its
    own.

(b) Byte order in the API

    All API parameters are in host byte order, except IP addresses and
    port numbers, which are assumed to be in network order.  This
    combination was chosen for application programmer convenience.

(c) Processor Type

    Code that is dependent on the processor type is conditionalized by
    the following symbols, that are expected to be defined by the local
    compilers:

	__alpha
	__MIPSEL__

(d) Operating-System

    Code which is dependent on a single OS is conditionalized by OS.

	SunOS
	SOLARIS
	freebsd
	sgi or sgi_53

    The symbol "sgi" implies the currently shipping release, IRIX 6.2.
    To compile for IRIX 5.3, set sgi_53 instead. Please note that an rsvpd 
    binary compiled under FreeBSD 2.2 may not run correctly on older releases 
    of FreeBSD - (for eg. release 2.1). Rsvpd will need to be recompiled to 
    run correctly.  

(e) OS-dependent configuration options

    Code which is dependent on a particular OS -feature- is
    conditionalized in the file rsvpd/config.h.  This file is a
    placeholder for an automatically generated config file (by GNU
    autoconf or similar).  It is intended to group together the
    definition of all OS-dependent configuration options.  Until this
    file is automatically generated, please add new conditionals to it
    as required.

(f) Host-only compilation

    If your operating system does not support multicast routing, then 
    you can define HOST_ONLY to allow the code to compile (and execute)
    without error.


COMPILATION OPTIONS

There are several compiler options that can be turned up by the
appropriate -D flag in the Makefile.  These are:

	RTAP
		If defined, causes rtap to be directly linked into the
		rsvpd module, so that it provides an interactive control
		and debugging interface to rsvpd.

	SECURITY
		If defined, this symbol caused the MD5 INTEGRITY code to
		be included in the daemon.

	STATS
		If defined, this symbol causes statistical-data-gathering
		code to be included.

	SCHEDULE
		If defined, this symbol includes code in rsvpd to call
		the kernel Traffic Control (TC) mechanism through the
		TC adaptation module.  If SCHEDULE is undefined, no TC
		adaptation module is required.  Note that if rsvpd is
		compiled with this symbol defined, the adaptation
		module will still make a run-time check for the
		existence of Traffic Control in the kernel.

	PF_ROUTE
		If defined, this symbol selects unicast routing
		code using the routing socket available in newer
		BSD-based systems.

	HOST_ONLY
		If defined, this symbol allows compilation of a
		host-only rsvpd.  It omits code that is dependent upon
		kernel-specific symbols (e.g., multicast and RSVP
		hooks), which may not be defined in a particular host
		system.  Note that an rsvpd that is compiled with this
		symbol undefined will still make a run-time check for
		the existence of the corresponding kernel features, and
		act accordingly.

		--> This conditional compilation is almost certainly
		wrong in places.

	DEBUG
		If defined, this symbol includes some additional
		internal consistency checking code.  Including this
		code adds negligible overhead, and at present we
		recommend that DEBUG be defined.  It serves as a marker
		for code that is ultimately expendable.

	NDEBUG
		If defined, this symbol causes the assert() macro to
		continue execution, rather than calling exit(), when an
		assertion fails.  See <assert.h> for details.  Defining
		this symbol saves some small overhead, but in the
		present state of the code we recommend that it be left
		undefined.

	RSVP_DIAGS 
		If defined, this symbol enables trapping of RSVP diagostic 
		message packets, for processing within the daemon. This 
		symbol must be defined during compile time, if the 
		diagnostic messages feature is to be used. 

	USE_IPV6
		Include IPv6 support code.


EXECUTION

Usage of rsvpd is described in the man page rsvpd.8, contained in
the docs/ directory.
