/* * $Id: README,v 4.20 1998/08/18 23:48:18 lindell 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 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 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.