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.

SEE ALSO

atm(8), atmarpd(8)

Server Cache Synchronization Protocol (SCSP), RFC 2334.

A Distributed ATMARP Service Using SCSP, draft-ietf-ion-scsp-atmarpd-00.txt.

COPYRIGHT

Copyright (c) 1994-1998, Network Computing Services, Inc.

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

BSD