Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
SCSPD(8)		  BSD System Manager's Manual		      SCSPD(8)

     scspd -- SCSP daemon

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

     The scspd utility is an implementation of the Server Cache	Synchroniza-
     tion Protocol (SCSP) for the Host ATM Research Platform (HARP) networking
     software.	The scspd utility synchronizes the cache(s) of server(s) run-
     ning on a host with the caches of servers on remote hosts.	 SCSP is de-
     fined 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 ATMARP 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 server); 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	synchronization	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 itself into	the

     Some of the vocabulary associated with SCSP can be	confusing.  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 re-
     mote servers.  When the word server is used alone,	it means client

     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 communi-
     cates with	directly.  The remote server will also be running an implemen-
     tation 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	implements the Cache
     Alignment protocol.

     The command-line options are:

     -f	<cfg-file>  Specifies the name of the configuration file.  If this op-
		    tion is not	specified, scspd looks for the file

     -d		    Specifies that scspd is to be run in debug mode.  In debug
		    mode, the daemon is	not put	into the background.  Log mes-
		    sages 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 followed 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

     The configuration file consists of	a sequence of configuration state-
     ments.  These statements specify information about	the servers, both lo-
     cal 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 semi-
     colon.  Some statements contain blocks, delimited by braces ("{" and
     "}").  Configuration statement keywords are not case-sensitive, but some
     parameters	(e.g. interface	names) are.  Configuration statements can span
     multiple lines.

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

     C++ comments: any characters from "//" to the end of the line are ig-

     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>;

     Where a host address needs	to be specified	in the configuration file, ei-
     ther 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 zeroes, must be
     given.  For example:


   Server Statement
     The server	statement specifies a client server whose cache	to be synchro-
     nized 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 format 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	pur-

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

     Netif <intf>;
	     The netif statement specifies the name of the ATM network inter-
	     face 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 (DCSs) pointed to
	     within a server statement.	 The ServerGroupID statement must al-
	     ways 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 number 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 speci-
     fies 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 number of sub-
     statements	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 associated with the
	     ATM interface of the DCS.	The ID statement must always be	speci-

     CAReXmitInt <int>;
	     The CAReXmitInt statement specifies the interval that is allowed
	     to	elapse between retransmissions of CA messages.	If a CA	mes-
	     sage is sent and an acknowledgement is not	received within
	     CAReXmitInt seconds, the message will be retransmitted.  The de-
	     fault value for CAReXmitInt is 3 seconds.

     CSUSReXmitInt <int>;
	     The CSUSReXmitInt statement specifies the interval	that is	al-
	     lowed to elapse between retransmissions of	CSU Solicit 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	re-
	     transmitted.  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 value 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 diameter 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 op-
     eration.  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 mes-
	     sages to the named	file.  Log messages will be appended to	the
	     end of the	file if	it already exists.

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

     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 mes-
     sages to both the named file and the system log.

     An	example	of a simple configuration file for scspd might be:

	   server atmarp_ni0 {
		protocol ATMARP;
		netif ni0;
		ServerGroupID 23;
		DCS {
		     ATMaddr 0x47.0005.80.ffdc00.0000.0002.0001.002048061de7.00;
		     hops 2;

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

     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 receives a SIGINT
	     signal, scspd dumps a summary of its control blocks to a text
	     file (see FILES).

	     scspd default configuration file name.  A different file name can
	     be	specified with the -f command-line option.

	     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 daemon and <seq>
	     is	a sequence number which	is incremented every time a dump is

	     trace file.  The scspd utility writes trace information to	this
	     file if the -T option is specified	on the command line.

     atm(8), atmarpd(8)

     Server Cache Synchronization Protocol (SCSP), RFC 2334.

     A Distributed ATMARP Service Using	SCSP,

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

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

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

     If	scspd terminates and is	restarted, there will be a period of instabil-
     ity while previously-synchronized cache entries time out and are re-

     Please report any bugs to <>.

BSD				August 21, 1998				   BSD


Want to link to this manual page? Use this URL:

home | help