scspd(8)

NAME

scspd - SCSP daemon

SYNOPSIS

scspd [-f <cfg-file>] [-d] [-T<options>]

DESCRIPTION

The scspd utility is an implementation of the Server Cache
Synchronization Protocol (SCSP) for the Host ATM Research Platform
(HARP) networking
software. The scspd utility synchronizes the cache(s) of
server(s) running on a host with the caches of servers on remote hosts.
SCSP is defined for a number of different protocols, but the present
version of
scspd only supports ATMARP.
By using scspd and atmarpd(8), one can provide multiple AT
MARP servers in a single ATM LIS. This might be useful, for example, when a
LIS consists of a number of local-area ATM networks connected by long
distance links. Each local-area network could have its own ATMARP server,
with all the servers' caches being synchronized by SCSP. Then, if a
long-distance link fails, hosts on a local-area network will still have
connectivity to other local hosts (since they all use the local ATMARP serv
er); when the long-distance link is restored, SCSP will re-synchronize the
servers'
caches, restoring connectivity to remote hosts. Both scspd
and atmarpd(8) must be running before any ATMARP cache synchro
nization can take place.
The scspd utility implements SCSP as specified in RFC 2334,
Server Cache Synchronization Protocol (SCSP) and
draft-ietf-ion-scspd-atmarpd-00.txt, A Distributed ATMARP Service using SCSP.
When scspd starts, it parses its command line and puts it
self into the background.

TERMINOLOGY

Some of the vocabulary associated with SCSP can be confus
ing. In this document, the following definitions are used:
Client server or local server means the server running on
the same host
as scspd whose cache is to be synchronized with that of one
or more remote servers. When the word server is used alone, it
means client server.
Remote server means a server running on some host other than
the one
where scspd is running.
Directly Connected Server (DCS) means a remote server that
scspd communicates with directly. The remote server will also be running
an implementation of SCSP.
Cache Alignment (CA) has two meanings. The Cache Alignment
protocol is a part of the SCSP protocol specification, and the Cache
Alignment finite state machine (FSM) is a finite state machine that imple
ments the Cache Alignment protocol.

OPTIONS

The command-line options are:

-f <cfg-file> Specifies the name of the configuration file.
If this: option is not specified, scspd looks for the; file
/etc/scspd.conf.
-d Specifies that scspd is to be run in debug
mode. In debug: mode, the daemon is not put into the back; ground. Log messages are written to standard output instead; of to the log
file specified in the configuration file.
-T<options> Specifies that scspd will trace specified
events and mes: sages as it executes. The -T flag is fol; lowed by one or
more of the following options:; c trace scspd's CA Finite State Machine; (FSM),
h trace scspd's Hello FSM,
i trace scspd's Client Interface FSM,
C trace CA, CSUS, CSU Request, and CSU; Reply messages,
H trace Hello messages,
I trace interface messages to and from; scspd's
clients.

CONFIGURATION

The configuration file consists of a sequence of configura
tion statements. These statements specify information about the
servers, both local and remote, whose caches are to be synchronized by
scspd. RFC
2334, Server Cache Synchronization Protocol (SCSP) and draft-ietf-ion-scspd-atmarpd-00.txt, A Distributed ATMARP
Service using SCSP will be valuable in understanding how to configure
scspd.
A configuration statement other than a comment is terminated
by a semicolon. Some statements contain blocks, delimited by braces
(``{'' and ``}''). Configuration statement keywords are not case-sen
sitive, but some parameters (e.g. interface names) are. Configuration
statements can span multiple lines.
Comments: Three types of comments are allowed:; # comments: any characters from ``#'' to the end of the line; are ignored.; C comments: any characters between ``/*'' and ``*/'' are ig; nored.; C++ comments: any characters from ``//'' to the end of the; line are
ignored.
Statements: The configuration statements recognized by scspd are:; Server <name> {
Protocol <protocol ID>;
Netif <if_name>;
ServerGroupID <ID>;
FamilyID <ID>;
DCS {
ATMaddr <ATM address>;
ID <host>;
CAReXmitInt <int>;
CSUSReXmitInt <int>;
CSUReXmitInt <int>;
CSUReXmitMax <cnt>;
HelloDead <cnt>;
HelloInt <int>;
Hops <cnt>;

};; };; Log {
File <file name>;
Syslog;; };; Where a host address needs to be specified in the configura; tion file,
either a DNS name or an IP address in dotted decimal format; can be used.; ATM addresses are specified as strings of hex digits, with; an optional
leading ``0x''. Fields within the address may be separated; by periods,
but periods are for readability only and are ignored. ATM; addresses are
20 bytes long. The full address, including any leading ze; roes, must be
given. For example:

0x47.0005.80.ffe100.0000.f21a.0170.0020481a0170.00
Server Statement: The server statement specifies a client server whose cache; to be synchronized with the caches of other servers running on remote; hosts. There
will be one server statement in the configuration file for; each client
server whose cache is to be synchronized by scspd. The for; mat of the
server statement is:

Server <name> { <statements> };; A name must be specified on the server statement, but it is; not used by
scspd. It is expected to give a brief description of the; server's purpose.; The server statement has several sub-statements that specify; the details
of the scspd's configuration. They are:; Protocol ATMARP;
The only protocol supported by the current version

of scspd is
ATMARP. The protocol statement must always be spec

ified.
Netif <intf>;: The netif statement specifies the name of the ATM; network interface on which a client server is providing service.; The netif
statement must always be specified.
ServerGroupID <ID>;: The ServerGroupID statement specifies an identifier; for the group
of servers being synchronized by scspd. The ID is; specified as a
decimal number in the range 0 - 65,535. The server; group ID must
be the same for all servers whose caches are being; synchronized
by an SCSP session. That is, the server group ID; for a host must
be the same for all Directly Connected Servers (DC; Ss) pointed to
within a server statement. The ServerGroupID state; ment must
always be specified.
FamilyID <ID>;: The familyID statement specifies an identifier for a; family of
parallel SCSP sessions running between a group of; hosts (i.e., a
set of SCSP sessions with different protocol IDs but; the same set
of servers). The ID is specified as a decimal num; ber in the
range 0 - 65,535. The family ID is currently not; used by scspd.
DCS Statement: The DCS statement is a sub-statement of the server statement; that specifies the characteristics of a Directly Connected Server; (DCS). The
server statement will have one DCS statement for each DCS; that scspd is
to exchange information with. The DCS statement has a num; ber of substatements that specify the details of the configuration for; the DCS.
They are:; ATMaddr <ATM address>;
The ATMaddr statement specifies the ATM address of

the DCS. The
ATMaddr statement must always be specified.
ID <host>;: The ID statement specifies the SCSP identifier of; the DCS. For
ATMARP, the ID is the IP address or DNS name associ; ated with the
ATM interface of the DCS. The ID statement must al; ways be specified.
CAReXmitInt <int>;: The CAReXmitInt statement specifies the interval; that is allowed
to elapse between retransmissions of CA messages.; If a CA message is sent and an acknowledgement is not received; within
CAReXmitInt seconds, the message will be retransmit; ted. The
default value for CAReXmitInt is 3 seconds.
CSUSReXmitInt <int>;: The CSUSReXmitInt statement specifies the interval; that is
allowed to elapse between retransmissions of CSU So; licit messages. When a CSUS message is sent, any Cache State; Advertisements (CSAs) requested by the CSUS that have not; been received
within CSUSReXmitInt seconds will be requested again; by another
CSUS message. The default value for CSUSReXmitInt; is 3 seconds.
Be careful not to confuse CSUSReXmitInt and

CSUReXmitInt

CSUReXmitInt <int>;: The CSUReXmitInt statement specifies the interval; that is allowed
to elapse between retransmissions of CSU Request; messages. When
a CSU Request message is sent, any CSAs that are not; acknowledged
by a CSU Reply message within CSUReXmitInt seconds; will be
retransmitted. The default value for CSUReXmitInt; is 2 seconds.
Be careful not to confuse CSUReXmitInt and

CSUSReXmitInt

CSUReXmitMax <cnt>;: The CSUReXmitMax statement specifies the number of; times that a
CSA will be retransmitted as described above before; SCSP gives up
on the CSA and discards it. The default value for

CSUReXmitMax

is 5.
HelloDead <cnt>;: The HelloDead statement specifies the Hello Dead; Factor that will
be sent to the DCS in Hello messages. A ``DCS; down'' condition
will be detected when nothing is received from a DCS; in HelloDead
* HelloInt seconds. The default value for HelloDead; is 3.
HelloInt <int>;: The HelloInt statement specifies the Hello Interval; that will be
sent to the DCS in Hello messages. The default val; ue for
HelloInt is 3 seconds.
Hops <cnt>;: The Hops statement specifies the number of hops (DCS; to DCS) that
will be specified in CSAs originating from the local; server.
This number must be at least as large as the diame; ter of the
server group. That is, it must be large enough for; a CSA to be
propagated from server to server all the way across; the server
group. The default value for Hops is 3.
Log Statement: The log statement specifies how scspd is to log information; about its
operation. The scspd utility can write log information to a; file, to the
system log, or both.; File <file name>;
The file statement specifies that scspd is to write

its log messages to the named file. Log messages will be ap

pended to the
end of the file if it already exists.
Syslog;: The syslog statement specifies that scspd is to; write its log
messages to the syslog facility. The scspd utility; writes its
messages to syslog with a facility code of LOG_DAE; MON.
If no log statement is specified, scspd writes log messages
to the system
log. If both file and syslog are specified, scspd will
write log messages to both the named file and the system log.
Examples: An example of a simple configuration file for scspd might; be:

server atmarp_ni0 {
protocol ATMARP;
netif ni0;
ServerGroupID 23;
DCS {
ID 10.1.1.2;
ATMaddr

0x47.0005.80.ffdc00.0000.0002.0001.002048061de7.00;
hops 2;

};

};; This configuration would synchronize the cache of the ATMARP; server operating on network interface ni0 with the cache of a second; server running
on a host whose IP address is 10.1.1.2. Log messages would; be written to
the system log.

SIGNAL PROCESSING

The following signals can be used to control scspd:

SIGHUP Reread the configuration file and restart scspd.

SIGINT Dump debugging information to a file. When it re
ceives a SIGINT: signal, scspd dumps a summary of its control blocks; to a text
file (see FILES).

FILES

/etc/scspd.conf: scspd default configuration file name. A different; file name can
be specified with the -f command-line option.
/tmp/scspd.<pid>.<seq>.out: debugging information dump file name. The scspd; utility writes a
summary of its control blocks to this file when it; receives a
SIGINT signal. <pid> is the process ID of the dae; mon and <seq>
is a sequence number which is incremented every time; a dump is
taken.
/tmp/scspd.<pid>.trace: trace file. The scspd utility writes trace informa; tion to this
file if the -T option is specified on the command; line.

COPYRIGHT

AUTHORS

John Cavanaugh, Network Computing Services, Inc.
Mike Spengler, Network Computing Services, Inc.
Joe Thomas, Network Computing Services, Inc.

ACKNOWLEDGMENTS

This software was developed with the support of the Defense
Advanced Research Projects Agency (DARPA).

BUGS

If scspd terminates and is restarted, there will be a period
of instability while previously-synchronized cache entries time out and
are refreshed.
Please report any bugs to <harp-bugs@magic.net>.
BSD August 21, 1998

docs.sk

comprehensive documentation repository

See also