.TH RSVPD 8 "28 May 96" .SH NAME rsvpd \- Resource ReSerVations Protocol daemon .SH SYNOPSIS .na .B rsvpd [ .B \-D ] [ .B \-d .I debug_bits ] [ .B \-l .I logging_level ] [ .B \-R .I router_addr ] [ .B \-t .I mstat_TTL ] .br .ad .SH DESCRIPTION .LP \fIRsvpd\fP is a daemon program that uses the RSVP resource reservation protocol to set up reservation state in hosts and routers. It supports an API that allows applications to make reservation requests. It includes an adaptation module to the admission control and traffic control mechanisms provided by the output device drivers in the kernel. .SH OPTIONS .TP .B \-D Execute rsvpd in debugging mode, i.e., do not detatch the process, and print debugging information to stderr. .TP .B \-d Set the debugging mask to the integer \fIdebug_bits\fP. This mask selects which additional information, if any, will be logged when the logging level (see below) is at least LOG_DEBUG. See the section below on LOGGING CONTROLS. .TP .B \-l Set the logging level, which controls logging of data for debugging and diagnosis, to the integer \fIlogging_level\fP. See the section below on LOGGING CONTROLS. .TP .B \-R Specify \fIrsvp_router\fP as the name or dotted-decimal number of a first-hop router to be used by \fIrsvpd\fP running on a host. With this parameter, \fIrsvpd\fP will send a unicast copy of any UDP-encapsulated RSVP message directly to \fIrsvp_router\fP, in addition to copies it normally sends. The \fB\-R\fP parameters is required only when the multicast TTL threshold of a tunnel or firewall would otherwise make the first-hop router inaccessible from the host. .TP .B \-t Set the IP TTL value for multicasting diagnostic information (summary of the state) to \fImcast_TTL\fP. This information is multicast when the DEBUG_MCAST_STATE bit (see LOGGING CONTROLS) is set in the debugging bit mask. The default is TTL = 1, i.e., one hop. .ne 3 .SH CONFIGURATION FILE .LP The RSVP daemon looks for a configuration file named \fIrsvpd.conf\fP in the current directory. This file may contain configuration commands, one command per line. Each command consists of a series of keywords separated by blanks or tabs; some keywords are followed by one or two parameters. The first keyword in the line is the name of the command; other keywords may come in any order. A blank line or a comment line beginning with '#' will be ignored. There are currently two commands defined: \fBinterface\fP \fIiface_name\fP [police] [udpencap] [udpttl \fInn\fP] [refresh \fIrr\fP] [disable] [integrity] [sendkey \fIid\fP \fIkey\fP] \fBrecvkey\fP \fIid\fP \fIkey\fP Here \fIiface_name\fP is the name of a physical interface (e.g., `le0'), to which the following keywords apply. More than one command line may be given for the same interface, and corresponding lines have a cumulative effect. The following keywords are defined for the \fBinterface\fP command: .TP .B police Traffic control policing is to be applied to the specified interface. .TP .B udpencap Force \fIrsvpd\fP to use UDP encapsulation of RSVP messages on the specified interface. In most cases \fIrsvpd\fP will automatically configure itself to do UDP encapsulation on any interfaces on which it is required. The \fBudp\fP keyword should be required only by a router connected to a LAN which has no hosts that act as RSVP senders. .TP .B udpttl \fPttl\fI UDP encapsulation using the specified TTL is to be performed on RSVP messages sent out the specified interface. This keyword implies the \fBudp\fP keyword. The default TTL for encapsulation is 1. The \fBudpttl\fP keyword is required only when the local environment includes RSVP-capable hosts separated by non-RSVP-capable routers, or to satisfy TTL threshold requirements. The TTL value must not exceed the hop distance to the first-hop router; violation of this restriction will cause gratuitous UDP encapsulation between routers. .TP .B disable Disable RSVP on the specified interface. [Not supported yet]. .TP .B refresh \fItime\fP Override the default refresh period for the specified interface. Here \fItime\fP is a new refresh period in seconds. [Not supported yet]. .TP .B integrity Integrity checking is required on messages received on the specified interface. .TP .B sendkey \fIid\fP \fIkey\fP Here \fIid\fP is a key id and \fIkey\fP is a corresponding key for sending messages to the specified interface. \fIId\fP and \fIkey\fP must be 8 and 16 bytes respectively, written in hexadecimal notation, with no spaces. .TP .B recvkey \fIid\fP \fIkey\fP Here \fIid\fP is a key id and \fIkey\fP is a corresponding key for receiving messages. \fIId\fP and \fIKey\fP must be 8 and 16 bytes respectively, written in hexadecimal notation, with no spaces. .TP Here is an example configuration file # rsvpd configuration .br interface le0 udpttl 3 integrity refresh 60 .br interface le0 sendkey 24d12409e9a03a00 c0640a4abda195de6062afe2de5a7e47 .br interface le0 sendkey 24d12409e9a03a01 7fa12385f3ac29b333715ff314d56fc9 .br recvkey 14a2b34ec2b23377 32fc719d796f2ad764f36cf072dfc5d4 .br recvkey 14a2b34ec2b23378 68fa01780355d7772997e5bf92927985 .ne .SH LOGGING CONTROLS .LP The RSVP daemon logs state and event information for management, diagnosis, and debugging. The logged data is written into an rsvpd log file (e.g., \fI/var/tmp/rsvpd.log\fP). It also appears on the console (stderr) if \fIrsvpd\fP is executed in non-daemon mode (i.e., with the \fB\-D\fP flag). The rsvpd log file can grow to a maximum size of approximately 400KB; it will then be closed and renamed to \fIrsvpd.log.prev\fP, and a new log file will be started. Logging is controlled by two integer parameters, the `debugging mask' and the `logging level'. These parameters may be set on the \fBrsvpd\fP command line or dynamically using the \fBrtap\fP console interface (see rtap(8)). Each log message has a priority, and it will appear in the log if its priority is at least equal to the logging level. The priorities (defined in \fI\fP) used by \fIrsvpd\fP are as follows: .TP 0.5i 3 LOG_ERR .RS These messages indicate system errors, configuration errors, internal logical errors within rsvpd, or logical errors in the client end of an API socket. They should never occur in normal operation. .RE 4 LOG_WARNING .RS These messages indicate temporary resource shortage or protocol errors in RSVP messages received from remote hosts. .RE 6 LOG_INFO .RS These message log changes of management parameters. .RE 7 LOG_DEBUG .RS These message contain debugging information. This will generally consist of a one-line summary of the event. Then additional information may follow, depending upon the setting of the debugging mask bits DEBUG_IO and DEBUG_EVENTS. .RE 8 LOG_HEXD .RS Dump all RSVP messages sent and received in hex. .RE For example, a logging_level of LOG_DEBUG will cause all events that occur to be logged, while a logging_level of LOG_INFO will log everything but debug messages. The debugging mask is considered to be a set of bits; the bits and their symbolic designations in the code are as follows: .TP 0.5i 1 DEBUG_IO .RS If this bit is included, the contents of the each RSVP message will be formatted to the log following its transmission or receipt. .RE 2 DEBUG_DS_DUMP .RS If this bit is included, the complete path and reservation state will be written into the log, periodically and when the state changes. .RE 4 DEBUG_EVENTS .RS If this bit is included, additional details on API and kernel scheduling events will be logged following the corresponding event lines. .RE 8 DEBUG_ROUTE .RS If this bit is included, a great deal of information concerning route lookups will be logged. .RE 16 DEBUG_MCAST_STATE .RS This bit does not control logging. If it is on, \fIrsvpd\fP will multicast its internal state periodically. The RSVP tool \fIrsvpeep\fP will receive and format this information. The multicast TTL may be set using the \fB\-t\fP parameter (see above). .RE 32 DEBUG_TIMERS .RS If this bit is included, a great deal of information concerning the timer queue will be logged. .RE .SH SEE ALSO .LP rtap(8), rstat(8), rsvpeep(8) .SH BUGS .LP