readme

radius协议源码÷The Radius Stack will connect to a Radius Server. This stack implementation is built upo

/*
 *  $Id: README,v 1.1.1.1 2000/05/08 22:51:24 wenqing Exp $
 */

README File for RSVP Daemon Program rsvpd
Release 4.2a4

OVERVIEW OF RELEASE

Release 4.2a4 has the following major features: (1) upgrade of the RSRR
interface to RSRR v2; (2) revision of the INTEGRITY code to the new
Internet Draft; (3) support for network byte order across the Unix
socket between rsvpd and an application; and (4) bug fixes for a number
of bugs, particularly in the API upcall logic.

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.  The symbol NO_IPV6 can be
defined to prevent this automatically detection and inclusion of IPv6
support.

  Specific Operating Systems:
     Solaris

	When USE_IPV6 is 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.

	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.

	IPv6 support has not been tested under Solaris 2.6.

     FreeBSD

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

Release 4.2a4 includes support for both unicast and multicast IPv4 and
IPv6 flows.  The IPv6 multicast support assumes an IPv6 multicast
routing protocol is available with the necessary RSRRv2 hooks added;
none is generally available at this time.  In our tests, a FreeBSD
system running as a router was able to simultaneously forward unicast
and multicast Path message using both IPv4 and IPv6.  The IPv4
multicast messages were under control of mrouted, while the IPv6
multicast messages were routed using PIM-DMv6 under gated.  RSRRv2 was
the common interface to routing in all these cases.  RESV messages also
worked for both IPv4 and IPv6.
 
Release 4.2a4 supports both IPv4 and IPv6 logical and physical network
interfaces that are contained in the kernel interface table.

   Unsupported in this release:

	-- IPv6 flow ids.

	-- The Router Alert option for RSVP/IPv6 packets

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 latest
04 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.

INTEGRITY SUPPORT

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.

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

    This version supports a choice of byte order across the API
    interface between rsvpd and rapi_lib.c.

    Previously we assumed that, since the application and the daemon
    were assumed to be on the same system, all API parameters across
    the Unix socket could be in host byte order (except IP addresses
    and port numbers that are assumed to be in network order).
    However, there may be circumstances in which network byte order is
    more convenient (e.g., application and daemon are on separate
    systems, or (local) UDP is more convenient for this communication.

    The byte order at the rsvpd end is determined dynamically by a new
    bit in an API request message.  It is determined at compile time in
    the rapi_lib end: defining API_USE_NET_BO causes network byte order
    to be used.

(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.

	NO_IPV6
		Do not include IPv6 support code.

	API_USE_NET_BO
		Causes API request and reply messages on Unix socket to
		use network byte order.

EXECUTION

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