As per Relevance of the word standard, we have this rfc below:
Network Working Group J.
Request for Comments: 2334 Bay
Category: Standards Track G.
J.
N.
Bay
April 1998
Server Cache Synchronization Protocol (SCSP
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document describes the Server Cache Synchronization
(SCSP) and is written in terms of SCSP's use within Non
Multiple Access (NBMA) networks; although, a somewhat
forward usage is applicable to BMA networks. SCSP attempts to
the generalized cache synchronization/cache-replication problem
distributed protocol entities. However, in this document, SCSP
couched in terms of the client/server paradigm in which
server entities, which are bound to a Server Group (SG) through
means, wish to synchronize the contents (or a portion thereof)
their caches which contain information about the state of
being served
1.
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in
document, are to be interpreted as described in [10].
It is perhaps an obvious goal for any protocol to not limit itself
a single point of failure such as having a single server in
client/server paradigm. Even when there are redundant servers,
Luciani, et. al. Standards Track [Page 1]
RFC 2334 SCSP April 1998
still remains the problem of cache synchronization; i.e., when
server becomes aware of a change in state of cache information
that server must propagate the knowledge of the change in state
all servers which are actively mirroring that state information
Further, this must be done in a timely fashion without putting
resource strains on the servers. Assuming that the state
kept in the server cache is the state of clients of the server,
in order to minimize the burden placed upon the client it is
highly desirable that clients need not have complete knowledge of
servers which they may use. However, any mechanism
synchronization should not preclude a client from having access
several (or all) servers. Of course, any solution must be
scalable, capable of using some auto-configuration service, and
itself to a wide range of authentication methodologies
This document describes the Server Cache Synchronization
(SCSP). SCSP solves the generalized server synchronization/cache
replication problem while addressing the issues described above
SCSP synchronizes caches (or a portion of the caches) of a set
server entities of a particular protocol which are bound to a
Group (SG) through some means (e.g., all NHRP servers belonging to
Logical IP Subnet (LIS)[1]). The client/server protocol which
particular server uses is identified by a Protocol ID (PID). SGs
identified by an ID which, not surprisingly, is called a SGID. Note
therefore, that the combination PID/SGID identifies both
client/server protocol for which the servers of the SG are
synchronized as well as the instance of that protocol. This
that multiple instances of the same protocol may be in operation
the same time and have their servers synchronized independently
each other. An example of types of information that must
synchronized can be seen in NHRP[2] using IP where the
includes the registered clients' IP to NBMA mappings in the SG LIS
The simplest way to understand SCSP is to understand that
algorithm used here is quite similar to that used in OSPF[3].
fact, if the reader wishes to understand more details of
tradeoffs and reliability aspects of SCSP, they should refer to
Hello, Database Synchronization, and Flooding Procedures in OSPF [3].
As described later, the protocol goes through three phases.
first, very brief phase is the hello phase where two
determine that they can talk to each other. Following that
database synchronization. The operation of SCSP assumes that up
the point when new information is received, two entities have
same data available. The database synchronization phase
this
Luciani, et. al. Standards Track [Page 2]
RFC 2334 SCSP April 1998
In database synchronization, the two neighbors exchange
information about each entry in their database. Summaries are
since the database itself is potentially quite large. Based on
summaries, the neighbors can determine if there is information
each needs from the other. If so, that is requested and provided
Therefore, at the end of this phase of operation, the two
have the same data in their databases
After that, the entities enter and remain in flooding state.
flooding state, any new information that is learned is sent to
neighbors, except the one (if any) that the information was
from. This causes all new information in the system to propagate
all nodes, thus restoring the state that everyone knows the
thing. Flooding is done reliably on each link, so no pattern of
rate packet loss will cause a disruption. (Obviously, a
high rate of packet loss will cause the entire neighbor
to come down, but if the link does not work, then that is what
wants.)
Because the database synchronization procedure is run whenever a
comes up, the system robustly ensures that all participating
have all available information. It properly recovers
partitions, and copes with other failures
The SCSP specification is not useful as a stand alone protocol.
must be coupled with the use of an SCSP Protocol
specification which defines how a given protocol would make use
the synchronization primitives supplied by SCSP. Such
will be done in separate documents; e.g., [8] [9].
2.
SCSP places no topological requirements upon the SG. Obviously
however, the resultant graph must span the set of servers to
synchronized. SCSP borrows its cache distribution mechanism from
link state protocols [3,4]. However, unlike those technologies
there is no mandatory Shortest Path First (SPF) calculation, and
imposes no additional memory requirements above and beyond that
is required to save the cached information which would
regardless of the synchronization technology
Luciani, et. al. Standards Track [Page 3]
RFC 2334 SCSP April 1998
In order to give a frame of reference for the following discussion
the terms Local Server (LS), Directly Connected Server (DCS),
Remote Server (RS) are introduced. The LS is the server
scrutiny; i.e., all statements are made from the perspective of
LS when discussing the SCSP protocol. The DCS is a server which
directly connected to the LS; e.g., there exists a VC between the
and DCS. Thus, every server is a DCS from the point of view of
other server which connects to it directly, and every server is an
which has zero or more DCSs directly connected to it. From
perspective of an LS, an RS is a server, separate from the LS,
is not directly connected to the LS (i.e., an RS is always two
more hops away from an LS whereas a DCS is always one hop away
an LS).
SCSP contains three sub protocols: the "Hello" protocol, the "
Alignment" protocol, and the "Cache State Update" protocol.
"Hello" protocol is used to ascertain whether a DCS is
and whether the connection between the LS and DCS is bidirectional
unidirectional, or non-functional. The "Cache Alignment" (CA
protocol allows an LS to synchronize its entire cache with that
the cache of its DCSs. The "Cache State Update" (CSU) protocol
used to update the state of cache entries in servers for a given SG
Sections 2.1, 2.2, and 2.3 contain a more in-depth explanation of
Hello, CA, and CSU protocols and the messages they use
SCSP based synchronization is performed on a per protocol
basis. That is, a separate instance of SCSP is run for each
of the given protocol running in a given box. The protocol
identified in SCSP via a Protocol ID and the instance of the
is identified by a Server Group ID (SGID). Thus the PID/SGID
uniquely identify an instance of SCSP. In general, this is not
issue since it is seldom the case that many instances of a
protocol (which is distributed and needs cache synchronization)
running within the same physical box. However, when this is
case, there is a mechanism called the Family ID (described briefly
the Hello Protocol) which enables a substantial reduction
maintenance traffic at little real cost in terms of control. The
of the Family ID mechanism, when appropriate for a given
which is using SCSP, will be fully defined in the given SCSP
specific specification
Luciani, et. al. Standards Track [Page 4]
RFC 2334 SCSP April 1998
+---------------+
| |
+------->| DOWN |<-------+
| | | |
| +---------------+ |
| | ^ |
| | | |
| | | |
| | | |
| @ | |
| +---------------+ |
| | | |
| | WAITING | |
| +--| |--+ |
| | +---------------+ | |
| | ^ ^ | |
| | | | | |
| @ | | @ |
+---------------+ +---------------+
| BIDIRECTIONAL |---->| UNIDIRECTIONAL
| | | |
| CONNECTION |<----| CONNECTION |
+---------------+ +---------------+
Figure 1: Hello Finite State Machine (HFSM
2.1 Hello
"Hello" messages are used to ascertain whether a DCS is
and whether the connections between the LS and DCS are bidirectional
unidirectional, or non-functional. In order to do this, every LS
periodically send a Hello message to its DCSs
An LS must be configured with a list of NBMA addresses
represent the addresses of peer servers in a SG to which the
wishes to have a direct connection for the purpose of running SCSP
that is, these addresses are the addresses of would-be DCSs.
mechanism for the configuration of an LS with these NBMA address
beyond the scope of this document; although one possible
would be an autoconfiguration server
An LS has a Hello Finite State Machine (HFSM) associated with each
its DCSs (see Figure 1) for a given SG, and the HFSM monitors
state of the connectivity between the servers
Luciani, et. al. Standards Track [Page 5]
RFC 2334 SCSP April 1998
The HFSM starts in the "Down" State and transitions to the "Waiting
State after NBMA level connectivity has been established. Once
the Waiting State, the LS starts sending Hello messages to the DCS
The Hello message includes: a Sender ID which is set to the LS's
(LSID), zero or more Receiver IDs which identify the DCSs from
the LS has recently heard a Hello message (as described below), and
HelloInterval and DeadFactor which will be described below. At
point, the DCS may or may not already be sending its own
messages to the LS
When the LS receives a Hello message from one of its DCSs, the
checks to see if its LSID is in one of the Receiver ID fields of
message which it just received, and the LS saves the Sender ID
that Hello message. If the LSID is in one of the Receiver ID
then the LS transitions the HFSM to the Bidirectional
state otherwise it transitions the HFSM into the
Connection state. The Sender ID which was saved is the DCS's
(DCSID). At some point before the next time that the LS sends
own Hello message to the DCS, the LS will check the saved
against a list of Receiver IDs which the LS uses when sending
LS's own Hello messages. If the DCSID is not found in the list
Receiver IDs then it is added to that list before the LS sends
Hello message
Hello messages also contain a HelloInterval and a DeadFactor.
Hello interval advertises the time (in seconds) between sending
consecutive Hello messages by the server which is sending
"current" Hello message. That is, if the time between reception
Hello messages from a DCS exceeds the HelloInterval advertised
that DCS then the next Hello message is to be considered late by
LS. If the LS does not receive a Hello message, which contains
LS's LSID in one of the Receiver ID fields, within the
HelloInterval*DeadFactor seconds (where DeadFactor was advertised
the DCS in a previous Hello message) then the LS MUST consider
DCS to be stalled. At which point one of two things will happen: 1)
if any Hello messages have been received during the
HelloInterval*DeadFactor seconds then the LS should transition
HFSM for that DCS to the Unidirectional Connection State; otherwise
the LS should transition the HFSM for that DCS to the Waiting
and remove the DCSID from the Receiver ID list
Note that the Hello Protocol is on a per PID/SGID basis. Thus,
example, if there are two servers (one in SG A and the other in SG B
associated with an NBMA address X and another two servers (also
in SG A and the other in SG B) associated with NBMA address Y
there is a suitable point-to-point VC between the NBMA addresses
there are two HFSMs running on each side of the VC (one
PID/SGID).
Luciani, et. al. Standards Track [Page 6]
RFC 2334 SCSP April 1998
Hello messages contain a list of Receiver IDs instead of a
Receiver ID in order to make use of point to multipoint connections
While there is an HFSM per DCS, an LS MUST send only a single
message to its DCSs attached as leaves of a point to
connection. The LS does this by including DCSIDs in the list
Receiver IDs when the LS's sends its next Hello message. Only
DCSIDs from non-stalled DCSs from which the LS has heard a
message are included
Any abnormal event, such as receiving a malformed SCSP message
causes the HFSM to transition to the Waiting State; however, a
of NBMA connectivity causes the HFSM to transition to the Down State
Until the HFSM is in the Bidirectional Connection State, if
properly formed SCSP messages other than Hello messages are
then those messages MUST be ignored (this is for the case where,
example, there is a point to multipoint connection involved).
Luciani, et. al. Standards Track [Page 7]
RFC 2334 SCSP April 1998
+------------+
| |
+--->| DOWN |
| | |
| +------------+
| |
^ |
| @
| +------------+
| |Master/Slave
|-<--| |<---+
| |Negotiation | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | Cache | |
|-<--| |-->-|
| | Summarize | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | Update | |
|-<--| |-->-|
| | Cache | |
| +------------+ |
| | |
^ | ^
| @ |
| +------------+ |
| | | |
+-<--| Aligned |-->-+
| |
+------------+
Figure 2: Cache Alignment Finite State
2.2 Cache Alignment
"Cache Alignment" (CA) messages are used by an LS to synchronize
cache with that of the cache of each of its DCSs. That is,
messages allow a booting LS to synchronize with each of its DCSs.
CA message contains a CA header followed by zero or more Cache
Advertisement Summary records (CSAS records).
Luciani, et. al. Standards Track [Page 8]
RFC 2334 SCSP April 1998
An LS has a Cache Alignment Finite State Machine (CAFSM)
(see Figure 2) with each of its DCSs on a per PID/SGID basis, and
CAFSM monitors the state of the cache alignment between the servers
The CAFSM starts in the Down State. The CAFSM is associated with
HFSM, and when that HFSM reaches the Bidirectional State, the
transitions to the Master/Slave Negotiation State. The Master/
Negotiation State causes either the LS or DCS to take on the role
master over the cache alignment process. In a sense, the
server sets the tempo for the cache alignment
When the LS's CAFSM reaches the Master/Slave Negotiation State,
LS will send a CA message to the DCS associated with the CAFSM.
format of CA messages are described in Section B.2.1. The first
message which the LS sends includes no CSAS records and a CA
which contains the LSID in the Sender ID field, the DCSID in
Receiver ID field, a CA sequence number, and three bits. These
bits are the M (Master/Slave) bit, the I (Initialization of master
bit, and the O (More) bit. In the first CA message sent by the LS
a particular DCS, the M, O, and I bits are set to one. If the
does not receive a CA message from the DCS in CAReXmtInterval
then it resends the CA message it just sent. The LS continues to
this until the CAFSM transitions to the Cache Summarize State
until the HFSM transitions out of the Bidirectional State. Any
the HFSM transitions out of the Bidirectional State, the
transitions to the Down State
2.2.1 Master Slave Negotiation
When the LS receives a CA message from the DCS while in
Master/Slave Negotiation State, the role the LS plays in the
depends on packet processing as follows
1) If the CA from the DCS has the M, I, and O bits set to one
there are no CSAS records in the CA message and the Sender
as specified in the DCS's CA message is larger than the LSID
a) The timer counting down the CAReXmtInterval is stopped
b) The CAFSM corresponding to that DCS transitions to
Cache Summarize State and the LS takes on the role of slave
c) The LS adopts the CA sequence number it received in the
message as its own CA sequence number
d) The LS sends a CA message to the DCS which is formated
follows: the M and I bits are set to zero, the Sender ID
is set to the LSID, the Receiver ID field is set to the DCSID
and the CA sequence number is set to the CA sequence number
appeared in the DCS's CA message. If there are CSAS records
be sent (i.e., if the LS's cache is not empty), and if all
them will not fit into this CA message then the O bit is set
Luciani, et. al. Standards Track [Page 9]
RFC 2334 SCSP April 1998
one and the initial set of CSAS records are included in the
message; otherwise the O bit is set to zero and if any
Records need to be sent then those records are included in
CA message
2) If the CA message from the DCS has the M and I bits off and
Sender ID as specified in the DCS's CA message is smaller
the LSID
a) The timer counting down the CAReXmtInterval is stopped
b) The CAFSM corresponding to that DCS transitions to
Cache Summarize State and the LS takes on the role of master
c) The LS must process the received CA message
An explanation of CA message processing is given below
d) The LS sends a CA message to the DCS which is formated
follows: the M bit is set to one, I bit is set to zero,
Sender ID field is set to the LSID, the Receiver ID field is
to the DCSID, and the LS's current CA sequence number
incremented by one and placed in the CA message. If there
any CSAS records to be sent from the LS to the DCS (i.e., if
LS's cache is not empty) then the O bit is set to one and
initial set of CSAS records are included in the CA message
the LS is sending to the DCS
3) Otherwise, the packet must be ignored
2.2.2 The Cache Summarize
At any given time, the master or slave have at most one
CA message. Once the LS's CAFSM has transitioned to the
Summarize State the sequence of exchanges of CA messages occurs
follows
1) If the LS receives a CA message with the M bit set
(e.g., the M bit is set in the CA of the DCS and the LS is master
or if the I bit is set then the CAFSM transitions back to
Master/Slave Negotiation State
2) If the LS is master and the LS receives a CA message with
CA sequence number which is one less than the LS's
CA sequence number then the message is a duplicate and the
MUST be discarded
3) If the LS is master and the LS receives a CA message with
CA sequence number which is equal to the LS's current CA
number then the CA message MUST be processed. An explanation
"CA message processing" is given below. As a result of
received the CA message from the DCS the following will occur
Luciani, et. al. Standards Track [Page 10]
RFC 2334 SCSP April 1998
a) The timer counting down the CAReXmtInterval is stopped
b) The LS must process any CSAS records in the received CA message
c) Increment the LS's CA sequence number by one
d) The cache exchange continues as follows
1) If the LS has no more CSAS records to send and the received
message has the O bit off then the CAFSM transitions to
Update Cache State
2) If the LS has no more CSAS records to send and the received
message has the O bit on then the LS sends back a CA
(with new CA sequence number) which contains no CSAS
and with the O bit off. Reset the timer counting down
CAReXmtInterval
3) If the LS has more CSAS records to send then the LS sends
next CA message with the LS's next set of CSAS records. If
is sending its last set of CSAS records then the O bit is
off otherwise the O bit is set on. Reset the timer
down the CAReXmtInterval
4) If the LS is slave and the LS receives a CA message with
CA sequence number which is equal to the LS's
CA sequence number then the CA message is a duplicate and
LS MUST resend the CA message which it had just sent to the DCS
5) If the LS is slave and the LS receives a CA message with
CA sequence number which is one more than the LS's
CA sequence number then the message is valid and MUST
processed. An explanation of "CA message processing" is
below. As a result of having received the CA message from
DCS the following will occur
a) The LS must process any CSAS records in the received CA message
b) Set the LS's CA sequence number to the CA sequence number in
CA message
c) The cache exchange continues as follows
1) If the LS had just sent a CA message with the O bit off
the received CA message has the O bit off then the
transitions to the Update Cache State and the LS sends a
message with no CSAS records and with the O bit off
2) If the LS still has CSAS records to send then the LS MUST
a CA message with CSAS records in it
a) If the message being sent from the LS to the DCS does
contain the last CSAS records that the LS needs to
then the CA message is sent with the O bit on
b) If the message being sent from the LS to the DCS
contain the last CSAS records that the LS needs
Luciani, et. al. Standards Track [Page 11]
RFC 2334 SCSP April 1998
send and the CA message just received from the DCS had
O bit off then the CA message is sent with the O bit off
and the LS transitions the CAFSM to the Update Cache State
c) If the message being sent from the LS to the DCS
contain the last CSAS records that the LS needs to
and the CA message just received from the DCS had the O
on then the CA message is sent with the O bit off and
alignment process continues
6) If the LS is slave and the LS receives a CA message with
CA sequence number that is neither equal to nor one more
the current LS's CA sequence number then an error has
and the CAFSM transitions to the Master/Slave Negotiation State
Note that if the LS was slave during the CA process then the LS
transitioning the CAFSM to the Update Cache state MUST keep a copy
the last CA message it sent and the LS SHOULD set a timer equal
CAReXmtInterval. If either the timer expires or the LS receives a
Solicit (CSUS) message (CSUS messages are described in Section 2.2.3)
from the DCS then the LS releases the copy of the CA message.
reason for this is that if the DCS (which is master) loses the
CA message sent by the LS then the DCS will resend its previous
message with the last CA Sequence number used. If that were to
the LS would need to resend its last sent CA message as well
2.2.2.1 "CA message processing":
The LS makes a list of those cache entries which are more "up
date" in the DCS than the LS's own cache. This list is called
CSA Request List (CRL). See Section 2.4 for a description of what
means for a CSA (Client State Advertisement) record or CSAS record
be more "up to date" than an LS's cache entry
2.2.3 The Update Cache
If the CRL of the associated CAFSM of the LS is empty upon
into the Update Cache State then the CAFSM immediately
into the Aligned State
If the CRL is not empty upon transition into the Update Cache
then the LS solicits the DCS to send the CSA records corresponding
the summaries (i.e., CSAS records) which the LS holds in its CRL.
solicited CSA records will contain the entirety of the
information held in the DCS's cache for the given cache entry.
LS solicits the relevant CSA records by forming CSU Solicit (CSUS
messages from the CRL. See Section B.2.4 for the description of
CSUS message format. The LS then sends the CSUS messages to the DCS
The DCS responds to the CSUS message by sending to the LS one or
Luciani, et. al. Standards Track [Page 12]
RFC 2334 SCSP April 1998
CSU Request messages containing the entirety of newer
information identified in the CSUS message. Upon receiving the
Request the LS will send one or more CSU Replies as described
Section 2.3. Note that the LS may have at most one CSUS
outstanding at any given time
Just before the first CSUS message is sent from an LS to the
associated with the CAFSM, a timer is set to
seconds. If all the CSA records corresponding to the CSAS records
the CSUS message have not been received by the time that the
expires then a new CSUS message will be created which contains
the CSAS records for which no appropriate CSA record has
received plus additional CSAS records not covered in the
CSUS message. The new CSUS message is then sent to the DCS. If,
some point before the timer expires, all CSA record updates have
received for all the CSAS records included in the previously
CSUS message then the timer is stopped. Once the timer is stopped
if there are additional CSAS records that were not covered in
previous CSUS message but were in the CRL then the timer is reset
a new CSUS message is created which contains only those CSAS
from the CRL which have not yet been sent to the DCS. This
continues until all the CSA records corresponding CSAS records
were in the CRL have been received by the LS. When the LS has
completely updated cache then the LS transitions CAFSM
with the DCS to the Aligned State
If an LS receives a CSUS message or a CA message with a Receiver
which is not the LS's LSID then the message must be discarded
ignored. This is necessary since an LS may be a leaf of a point
multipoint connection with other servers in the SG
2.2.4 The Aligned
While in the Aligned state, an LS will perform the Cache State
Protocol as described in Section 2.3.
Note that an LS may receive a CSUS message while in the Aligned
and, the LS MUST respond to the CSUS message with the appropriate
Request message in a similar fashion to the method
described in Section 2.2.3.
2.3 Cache State Update
"Cache State Update" (CSU) messages are used to dynamically
the state of cache entries in servers on a given PID/SGID basis.
messages contain zero or more "Cache State Advertisement" (CSA
records each of which contains its own snapshot of the state of
particular cache entry. An LS may send/receive a CSU to/from a
Luciani, et. al. Standards Track [Page 13]
RFC 2334 SCSP April 1998
only when the corresponding CAFSM is in either the Aligned State
the Update Cache State
There are two types of CSU messages: CSU Requests and CSU Replies
See Sections B.2.2 and B.2.3 respectively for message formats. A
Request message is sent from an LS to one or more DCSs for one of
reasons: either the LS has received a CSUS message and MUST
only to the DCS which originated the CSUS message, or the LS
become aware of a change of state of a cache entry. An LS
aware of a change of state of a cache entry either through
a CSU Request from one of its DCSs or as a result of a change
state being observed in a cached entry originated by the LS. In
former case, the LS will send a CSU Request to each of its
except the DCS from which the LS became aware of the change in state
In the latter case, the LS will send a CSU Request to each of
DCSs. The change in state of a particular cache entry is noted in
CSA record which is then appended to the end of the CSU
message mandatory part. In this way, state changes are
throughout the SG
Examples of such changes in state are as follows
1) a server receives a request from a client to add an entry
its cache
2) a server receives a request from a client to remove an
from its cache
3) a cache entry has timed out in the server's cache, has
refreshed in the server's cache, or has been
modified
When an LS receives a CSU Request from one of its DCSs, the
acknowledges one or more CSA Records which were contained in the
Request by sending a CSU Reply. The CSU Reply contains one or
CSAS records which correspond to those CSA records which are
acknowledged. Thus, for example, if a CSA record is dropped (
delayed in processing) by the LS because there are
resources to process it then a corresponding CSAS record is
included in the CSU Reply to the DCS
Note that an LS may send multiple CSU Request messages
receiving a CSU Reply acknowledging any of the CSA Records
in the CSU Requests. Note also that a CSU Reply may
acknowledgments for CSA Records from multiple CSU Requests. Thus
the terms "request" and "reply" may be a bit confusing
Note that a CSA Record contains a CSAS Record followed
client/server protocol specific information contained in a
entry (see Section B.2.0.2 for CSAS record format information
Luciani, et. al. Standards Track [Page 14]
RFC 2334 SCSP April 1998
Section B.2.2.1 for CSA record format information). When a
record is considered by the LS to represent cached information
is more "up to date" (see Section 2.4) than the cached
contained within the cache of the LS then two things happen: 1)
LS's cache is updated with the more up to date information, and 2)
the LS sends a CSU Request containing the CSA Record to each of
DCSs except the one from which the CSA Record arrived. In this way
state changes are propagated within the PID/SGID. Of course, at
point, the LS will also acknowledge the reception of the CSA
by sending the appropriate DCS a CSU Reply message containing
corresponding CSAS Record
When an LS sends a new CSU Request, the LS keeps track of
outstanding CSA records in that CSU Request and to which DCSs the
sent the CSU Request. For each DCS to which the CSU Request
sent, a timer set to CSUReXmtInterval seconds is started just
to sending the CSU Request. This timer is associated with the
Records contained in that CSU Request such that if that timer
prior to having all CSA Records acknowledged from that DCS then (
only then) a CSU Request is re-sent by the LS to that DCS. However
the re-sent CSU Request only contains those CSA Records which
not yet been acknowledged. If all CSA Records associated with
timer becomes acknowledged then the timer is stopped. Note that
re-sent CSA Records follow the same time-out and retransmit rules
if they were new. Retransmission will occur a configured number
times for a given CSA Record and if acknowledgment fails to
then an "abnormal event" has occurred at which point the then
HFSM associated with the DCS is transitioned to the Waiting State
A CSA Record instance is said to be on a "DCS retransmit queue"
it is associated with the previously mentioned timer. Only the
up-to-date CSA Record is permitted to be queued to a given
retransmit queue. Thus, if a less up-to-date CSA Record is queued
the DCS retransmit queue when a newer CSA Record instance is about
be queued to that DCS retransmit queue then the older CSA
instance is dequeued and disassociated with its timer
prior to enqueuing the newer instance of the CSA Record
When an LS receives a CSU Reply from one of its DCSs then the
checks each CSAS record in the CSU Reply against the CSAS
portion of the CSA Records which are queued to the DCS
queue
1) If there exists an exact match between the CSAS record
of the CSA record and a CSAS Record in the CSU Reply
that CSA Record is considered to be acknowledged and is
dequeued from the DCS retransmit queue and
disassociated with its timer
Luciani, et. al. Standards Track [Page 15]
RFC 2334 SCSP April 1998
2) If there exists a match between the CSAS record
of the CSA record and a CSAS Record in the CSU Reply
for the CSA Sequence number
a) If the CSA Record queued to the DCS retransmit queue has
CSA Sequence Number which is greater than
CSA Sequence Number in the CSAS Record of the the CSU
then the CSAS Record in the CSU Reply is ignored
b) If the CSA Record queued to the DCS retransmit queue has
CSA Sequence Number which is less than
CSA Sequence Number in the CSAS Record of the the CSU
then CSA Record which is queued to the DCS retransmit queue
dequeued and the CSA Record is disassociated with its timer
Further, a CSUS Message is sent to that DCS which sent
more up-to-date CSAS Record. All normal CSUS
occurs as if the CSUS were sent as part of the CA protocol
When an LS receives a CSU Request message which contains a CSA
which contains a CSA Sequence Number which is smaller than the
Sequence number of the cached CSA then the LS MUST acknowledge
CSA record in the CSU Request but it MUST do so by sending a
Reply message containing the CSAS Record portion of the CSA
stored in the cache and not the CSAS Record portion of the CSA
contained in the CSU Request
An LS responds to CSUS messages from its DCSs by sending CSU
messages containing the appropriate CSA records to the DCS. If an
receives a CSUS message containing a CSAS record for an entry
is no longer in its database (e.g., the entry timed out and
discarded after the Cache Alignment exchange completed but before
entry was requested through a CSUS message), then the LS will
by copying the CSAS Record from the CSUS message into a CSU
message and the LS will set the N bit signifying that this record
a NULL record since the cache entry no longer exists in the LS'
cache. Note that in this case, the "CSA Record" included in the
Request to signify the NULL cache entry is literally only a
Record since no client/server protocol specific information
for the cache entry
If an LS receives a CSA Record in a CSU Request from a DCS for
the LS has an identical CSA record posted to the corresponding DCS'
DCS retransmit queue then the CSA Record on the DCS retransmit
is considered to be implicitly acknowledged. Thus, the CSA Record
dequeued from the DCS retransmit queue and is disassociated with
timer. The CSA Record sent by the DCS MUST still be acknowledged
the LS in a CSU Reply, however. This is useful in the case of
Luciani, et. al. Standards Track [Page 16]
RFC 2334 SCSP April 1998
to multipoint connections where the rule that "when an LS receives
CSA record from a DCS, that LS floods the CSA Record to every
except the DCS from which it was received" might be broken
If an LS receives a CSU with a Receiver ID which is not equal to
LSID and is not set to all 0xFFs then the CSU must be discarded
ignored. This is necessary since the LS may be a leaf of a point
multipoint connection with other servers in the LS's SG
An LS MAY send a CSU Request to the all 0xFFs Receiver ID when the
is a root of a point to multipoint connection with a set of its DCSs
If an LS receives a CSU Request with the all 0xFFs Receiver ID
it MUST use the Sender ID in the CSU Request as the Receiver ID
the CSU Reply (i.e., it MUST unicast its response to the sender
the request) when responding. If the LS wishes to send a CSU
to the all 0xFFs Receiver ID then it MUST create a time-out
retransmit timer for each of the DCSs which are leaves of the
to multipoint connection prior to sending the CSU Request. If
this case, the time-out and retransmit timer expires for a given
prior to acknowledgment of a given CSA Record then the LS MUST
the specific DCSID as the Receiver ID rather than the all 0
Receiver ID. Similarly, if it is necessary to re-send a CSA
then the LS MUST specify the specific DCSID as the Receiver ID
than the all 0xFFs Receiver ID
Note that if a set of servers are in a full mesh of point
multipoint connections, and one server of that mesh sends a
Request into that full mesh, and the sending server sends the
Records in the CSU Request to the all 0xFFs Receiver ID then it
not be necessary for every other server in the mesh to source
own CSU Request containing those CSA Records into the mesh in
to properly flood the CSA Records. This is because every server
the mesh would have heard the CSU Request and would have
the included CSA Records as appropriate. Thus, a server in a
mesh could consider the mesh to be a single logical port and so
rule that "when an LS receives a CSA record from a DCS, that
floods the CSA Record to every DCS except the DCS from which it
received" is not broken. A receiving server in the full mesh
still need to acknowledge the CSA records with CSU Reply
which contain the LSID of the replying server as the Sender ID
the ID of the server which sent the CSU Request as the Receiver
field. In the time out and retransmit case, the Receiver ID of
CSU Request would be set to the specific DCSID which did
acknowledge the CSA Record (as opposed to the all 0xFFs Receiver ID).
Since a full mesh emulates a broadcast media for the servers
to the full mesh, use of SCSP on a broadcast medium might use
technique as well. Further discussion of this use of a full mesh
use of a broadcast media is left to the client/server
Luciani, et. al. Standards Track [Page 17]
RFC 2334 SCSP April 1998
specific documents
2.4 The meaning of "More Up To Date"/"Newness
During the cache alignment process and during normal CSU processing
a CSAS Record is compared against the contents of an LS's cache
to decide whether the information contained in the record is more "
to date" than the corresponding cache entry of the LS
There are three pieces of information which are used in
whether a record contains information which is more "up to date"
the information contained in the cache entry of an LS which
processing the record: 1) the Cache Key, 2) the Originator which
described by an Originator ID (OID), and 3) the CSA Sequence number
See Section B.2.0.2 for more information on these fields
Given these three pieces of information, a CSAS record (be it part
a CSA Record or be it stand-alone) is considered to be more "up
date" than the information contained in the cache of an LS if all
the following are true
1) The Cache Key in the CSAS Record matches the stored Cache
in the LS's cache entry
2) The OID in the CSAS Record matches the stored
in the LS's cache entry
3) The CSA Sequence Number in the CSAS Record is greater
CSA Sequence Number in the LS's cache entry
Discussion and
While the above text is couched in terms of synchronizing
knowledge of the state of a client within the cache of
contained in a SG, this solution generalizes easily to any number
database synchronization problems (e.g., LECS synchronization).
SCSP defines a generic flooding protocol. There are a number
related issues relative to cache maintenance and topology
which are more appropriately defined in the client/server
specific documents; for example, it might be desirable to define
generic cache entry time-out mechanism for a given protocol or
advertise adjacency information between servers so that one
obtain a topo-map of the servers in a SG. When mechanisms like
are desirable, they will be defined in the client/server
specific documents
Luciani, et. al. Standards Track [Page 18]
RFC 2334 SCSP April 1998
Appendix A: Terminology and
CA Message - Cache Alignment
These messages allow an LS to synchronize its entire cache
that of the cache of one of its DCSs
CAFSM - Cache Alignment Finite State
The CAFSM monitors the state of the cache alignment between an
and a particular DCS. There exists one CAFSM per DCS as seen
an LS
CSA Record - Cache State Advertisement
A CSA is a record within a CSU message which identifies an
to the status of a "particular" cache entry
CSAS Record - Cache State Advertisement Summary
A CSAS contains a summary of the information in a CSA. A
will send CSAS records describing its cache entries to
server during the cache alignment process. CSAS records are
included in a CSUS messages when an LS wants to request the
CSA from the DCS. The LS is requesting the CSA from the
because the LS believes that the DCS has a more recent view of
state of the cache entry in question
CSU Message - Cache State Update
This is a message sent from an LS to its DCSs when the LS
aware of a change in state of a cache entry
CSUS Message - Cache State Update Solicit
This message is sent by an LS to its DCS after the LS and DCS
exchanged CA messages. The CSUS message contains one or more
records which represent solicitations for entire CSA records (
opposed to just the summary information held in the CSAS).
DCS - Directly Connected
The DCS is a server which is directly connected to the LS; e.g.,
there exists a VC between the LS and DCS. This term, along with
terms LS and RS, is used to give a frame of reference when
about servers and their synchronization. Unless explicitly
to the contrary, there is no implied difference in
between a DCS, LS, and RS
HFSM - Hello Finite State
An LS has a HFSM associated with each of its DCSs. The
monitors the state of the connectivity between the LS and
particular DCS
Luciani, et. al. Standards Track [Page 19]
RFC 2334 SCSP April 1998
LS - Local
The LS is the server under scrutiny; i.e., all statements are
from the perspective of the LS. This term, along with the
DCS and RS, is used to give a frame of reference when talking
servers and their synchronization. Unless explicitly stated to
contrary, there is no implied difference in functionality between
DCS, LS, and RS
LSID - Local Server
The LSID is a unique token that identifies an LS. This value
be taken from the protocol address of the LS
PID - Protocol
This field contains an identifier which identifies
client/server protocol which is making use of SCSP for the
message. The assignment of Protocol IDs for this field is
over to IANA as described in Section C
RS - Remote Server (RS
From the perspective of an LS, an RS is a server, separate from
LS, which is not directly connected to the LS (i.e., an RS
always two or more hops away from an LS whereas a DCS is always
hop away from an LS). Unless otherwise stated an RS refers to
server in the SG. This term, along with the terms LS and DCS,
used to give a frame of reference when talking about servers
their synchronization. Unless explicitly stated to the contrary
there is no implied difference in functionality between a DCS, LS
and RS
SG - Server
The SCSP synchronizes caches (or a portion of the caches) of a
of server entities which are bound to a SG through some
(e.g., all servers belonging to a Logical IP Subnet (LIS)[1]).
Thus an SG is just a grouping of servers around some commonality
SGID - Server Group
This ID is a 16 bit identification field that uniquely
the instance client/server protocol for which the servers of the
are being synchronized. This implies that multiple instances
the same protocol may be in operation at the same time and
their servers synchronized independently of each other
Luciani, et. al. Standards Track [Page 20]
RFC 2334 SCSP April 1998
Appendix B: SCSP Message
This section of the appendix includes the message formats for SCSP
SCSP protocols are LLC/SNAP encapsulated with an LLC=0xAA-AA-03
OUI=0x00-00-5e and PID=0x00-05.
SCSP has 3 parts to every packet: the fixed part, the mandatory part
and the extensions part. The fixed part of the message exists
every packet and is shown below. The mandatory part is specific
the particular message type (i.e., CA, CSU Request/Reply, Hello
CSUS) and, it includes (among other packet elements) a
Common Part and zero or more records each of which
information pertinent to the state of a particular cache
(except in the case of a Hello message) whose information is
synchronized within a SG. The extensions part contains the set
extensions for the SCSP message
In the following message formats, the fields marked as "unused"
be set to zero upon transmission of such a message and ignored
receipt of such a message
B.1 Fixed
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Type Code | Packet Size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Start Of Extensions |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is the version of the SCSP protocol being used. The
version is 1.
Type
This is the code for the message type (e.g., Hello (5),
Request(2), CSU Reply(3), CSUS (4), CA (1)).
Packet
The total length of the SCSP packet, in octets (excluding
layer and/or other protocol encapsulation).
The standard IP checksum over the entire SCSP packet starting
the fixed header. If the packet is an odd number of bytes
length then this calculation is performed as if a byte set to 0x00
is appended to the end of the packet
Luciani, et. al. Standards Track [Page 21]
RFC 2334 SCSP April 1998
Start Of
This field is coded as zero when no extensions are present in
message. If extensions are present then this field will be
with the offset from the top of the fixed header to the
of the first extension
B.2.0 Mandatory
The mandatory part of the SCSP packet contains the operation
information for a given message type (e.g., SCSP Cache State
Request/Reply, etc.), and it includes (among other packet elements)
Mandatory Common Part (described in Section B.2.0.1) and zero or
records each of which contains information pertinent to the state
a particular cache entry (except in the case of a Hello message
whose information is being synchronized within a SG. These
may, depending on the message type, be either Cache
Advertisement Summary (CSAS) Records (described in Section B.2.0.2)
or Cache State Advertisement (CSA) Records (described in
B.2.2.1). CSA Records contain a summary of a cache entry'
information (i.e., a CSAS Record) plus some additional client/
protocol specific information. The mandatory common part format
CSAS Record format is shown immediately below, prior to showing
use in SCSP messages, in order to prevent replication within
message descriptions
B.2.0.1 Mandatory Common
Sections B.2.1 through B.2.5 have a substantial overlap in format
This overlapping format is called the mandatory common part and
format is shown below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol ID | Server Group ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused | Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID Len | Recvr ID Len | Number of Records |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender ID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver ID (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Luciani, et. al. Standards Track [Page 22]
RFC 2334 SCSP April 1998
Protocol
This field contains an identifier which identifies
client/server protocol which is making use of SCSP for the
message. The assignment of Protocol IDs for this field is
over to IANA as described in Section C. Protocols with
documents have the following defined values
1 -
2 -
3 -
4 -
5 -
Server Group
This ID is uniquely identifies the instance of a
client/server protocol for which servers are being synchronized
The Flags field is message specific, and its use will be
in the specific message format sections below
Sender ID
This field holds the length in octets of the Sender ID
Recvr ID
This field holds the length in octets of the Receiver ID
Number of
This field contains the number of additional records
with the given message. The exact format of these records
specific to the message and will be described for each message
in the sections below
Sender
This is an identifier assigned to the server which is sending
given message. One possible assignment might be the
address of the sending server
Receiver
This is an identifier assigned to the server which is to
the given message. One possible assignment might be the
address of the server which is to receive the given message
Luciani, et. al. Standards Track [Page 23]
RFC 2334 SCSP April 1998
B.2.0.2 Cache State Advertisement Summary Record (CSAS record
CSAS records contain a summary of information contained in a
entry of a given client/server database which is being
through the use of SCSP. The summary includes enough information
SCSP to look into the client/server database for the
database cache entry and then compare the "newness" of the
against the "newness" of the cached entry
Note that CSAS records do not contain a Server Group ID (SGID) nor
they contain a Protocol ID. These IDs are necessary to
which protocol and which instance of that protocol for which
summary is applicable. These IDs are present in the mandatory
part of each message
Note also that the values of the Hop Count and Record Length
of a CSAS Record are dependent on whether the CSAS record exists as
"stand-alone" record or whether the CSAS record is "embedded" in
Record. This is further described below
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hop Count | Record Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key Len | Orig ID Len |N| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cache Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originator ID ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hop
This field represents the number of hops that the record may
before being dropped. Thus, at each server that the
traverses, the Hop Count is decremented. This field is set to 1
when the CSAS record is a "stand-alone" record (i.e., it is
embedded within a CSA record) since summaries do not go beyond
hop during the cache alignment process. If a CSAS record
"embedded" within a CSA record then the Hop Count is set to
administratively defined value which is almost certainly
than or equal to the the cardinality of the SG minus one.
that an exception to the previous rule occurs when the CSA
is carried within a CSU Request which was sent in response to
solicitation (i.e., in response to a CSAS Record which was sent
a CSUS message); in which case, the Hop Count SHOULD be set to 1.
Luciani, et. al. Standards Track [Page 24]
RFC 2334 SCSP April 1998
Record
If the CSAS record is a "stand-alone" record then this value
12+"Cache Key Leng"+"Orig ID Len" in bytes; otherwise, this
is set to 12+"Cache Key Leng"+"Orig ID Len"+ sizeof("Client/
Protocol Specific Part for cache entry"). The size of
Client/Server Protocol Specific Part may be obtained from
client/server protocol specific document for the given Protocol ID
Cache Key
Length of the Cache Key field in bytes
Orig ID Len
Length of the Originator ID field in bytes
The "N" bit signifies that this CSAS Record is actually a
record. This bit is only used in a CSAS Record contained in a
Request/Reply which is sent in response to a CSUS message. It
possible that an LS may receive a solicitation for a CSA
when the cache entry represented by the solicited CSA Record
longer exists in the LS's cache (see Section 2.3 for details).
this case, the LS copies the CSAS Record directly from the
message into the CSU Request, and the LS sets the N bit
that the cache entry does not exist any longer. The DCS
solicited the CSA record which no longer exists will still
with a CSU Reply. This bit is usually set to zero
CSA Sequence
This field contains a sequence number that identifies the "newness
of a CSA record instance being summarized. A "larger"
number means a more recent advertisement. Thus, if the state
part (or all) of a cache entry needs to be updated then the
record advertising the new state MUST contain a CSA Sequence
which is larger than the one corresponding to the
advertisement. This number is assigned by the originator of
CSA record. The CSA Sequence Number may be assigned by
originating server or by the client which caused its server
advertise its existence
The CSA Sequence Number is a signed 32 bit number. Within the
Sequence Number space, the number -2^31 (0x80000000) is reserved
Thus, the usable portion of the CSA Sequence Number space for
given Cache Key is between the numbers -2^31+1 (0x80000001)
2^31-1 (0x7fffffff). An LS uses -2^31+1 the first time
originates a CSA Record for a cache entry that it created.
time the cache entry is modified in some manner and when
modification needs to be synchronized with the other servers in
SG, the LS increments the CSA Sequence number associated with
Luciani, et. al. Standards Track [Page 25]
RFC 2334 SCSP April 1998
given Cache Key and uses that new CSA Sequence Number
advertising the update. If it is ever the case that a given
Sequence Number has reached 2^31-2 and the associated cache
has been modified such that an update must be sent to the rest
the servers in the SG then the given cache entry MUST first
purged from the SG by the LS by sending a CSA Record which
the cache entry to be removed from other servers and this
Record carries a CSA Sequence Number of 2^31-1. The exact
format and mechanism by which a cache entry is purged is defined
the appropriate protocol specific document. After the purging
Record has been acknowledged by each DCS, an LS will then send
new CSA Record carrying the updated information, and this new
Record will carry a CSA Sequence Number of -2^31+1.
After a restart occurs and after the restarting LS's CAFSM
achieved the Aligned state, if an update to an existing cache
needs to be synchronized or a new cache entry needs to
synchronized then the ensuing CSA Record MUST contain a
Sequence Number which is unique within the SG for the given OID
Cache Key. The RECOMMENDED method of obtaining this number (
explicitly stated to the contrary in the protocol
document) is to set the CSA Sequence Number in the CSA Record
the CSA Sequence Number associated with the existing cache
(if an out of date cache entry already exists and zero if not)
a configured constant. Note that the protocol specific
may require that all cache entries containing the OID of
restarting LS be purged prior to updating the cache entries;
this case, the updating CSA Record will still contain a
Sequence Number set to the CSA Sequence Number associated with
previously existing cache entry plus a configured constant
Cache
This is a database lookup key that uniquely identifies a piece
data which the originator of a CSA Record wishes to
with its peers for a given "Protocol ID/Server Group ID" pair
This key will generally be a small opaque byte string which
will associate with a given piece of data in a cache. Thus,
example, an originator might assign a particular 4 byte string
the binding of an IP address with that of an ATM address
Generally speaking, the originating server of a CSA record
responsible for generating a Cache Key for every element of
that the the given server originates and which the server wishes
synchronize with its peers in the SG
Originator
This field contains an ID administratively assigned to the
which is the originator of CSA Records
Luciani, et. al. Standards Track [Page 26]
RFC 2334 SCSP April 1998
B.2.1 Cache Alignment (CA
The Cache Alignment (CA) message allows an LS to synchronize
entire cache with that of the cache of its DCSs within a
group. The CA message type code is 1. The CA message mandatory
format is as follows
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CA Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSAS Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CA Sequence
A value which provides a unique identifier to aid in the
of the cache alignment process. A "larger" sequence number means
more recent CA message. The slave server always copies
sequence number from the master server's previous CA message
its current CA message which it is sending and the the
acknowledges the master's CA message. Since the initial CA
is lock-step, if the slave does not receive the same
number which it previously received then the information in
slave's previous CA message is implicitly acknowledged. Note
there is a separate CA Sequence Number space associated with
CAFSM
Whenever it is necessary to (re)start cache alignment and the
enters the Master/Slave Negotiation state, the CA Sequence
should be set to a value not previously seen by the DCS.
possible scheme is to use the machine's time of day counter
Mandatory Common
The mandatory common part is described in detail in
B.2.0.1. There are two fields in the mandatory common part
codings are specific to a given message type. These fields are
"Number of Records" field and the "Flags" field
Luciani, et. al. Standards Track [Page 27]
RFC 2334 SCSP April 1998
Number of
The Number of Records field of the mandatory common part for
CA message gives the number of CSAS Records appended to the
message mandatory part
The Flags field of the mandatory common part for the CA
has the following format
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|I|O| unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This bit is part of the negotiation process for the
alignment. When this bit is set then the sender of the
message is indicating that it wishes to lead the
process. This bit is the "Master/Slave bit".
When set, this bit indicates that the sender of the CA
believes that it is in a state where it is negotiating for
status of master or slave. This bit is the "
bit".
This bit indicates that the sender of the CA message has
CSAS records to send. This implies that the cache
process must continue. This bit is the "mOre bit" despite
dubious name
All other fields of the mandatory common part are coded
described in Section B.2.0.1.
CSAS
The CA message appends CSAS records to the end of its
part. These CSAS records are NOT embedded in CSA records.
Section B.2.0.2 for details on CSAS records
B.2.2 Cache State Update Request (CSU Request
The Cache State Update Request (CSU Request) message is used
update the state of cache entries in servers which are
connected to the server sending the message. A CSU Request
is sent from one server (the LS) to directly connected server (
DCS) when the LS observes changes in the state of one or more
Luciani, et. al. Standards Track [Page 28]
RFC 2334 SCSP April 1998
entries. An LS observes such a change in state by either receiving
CSU request which causes an update to the LS's database or
observing a change of state of a cached entry originated by the LS
The change in state of a cache entry is noted in a CSU message
appending a "Cache State Advertisement" (CSA) record to the end
the mandatory part of the CSU Request as shown below
The CSU Request message type code is 2. The CSU Request
mandatory part format is as follows
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mandatory Common Part |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.......
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CSA Record |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mandatory Common
The mandatory common part is described in detail in
B.2.0.1. There are two fields in the mandatory common part
codings are specific to a given message type. These fields are
"Number of Records" field and the "Flags" field
Number of
The Number of Records field of the mandatory common part for
CSU Request message gives the number of CSA Records appended
the CSU Request message mandatory part
Currently, there are no flags defined for the Flags field of
mandatory common part for the CSU Request message
All other fields of the mandatory common part are coded
described in Section B.2.0.1.
CSA
See Section B.2.2.1.
Luciani, et. al. Standards Track [Page 29]
RFC 2334 SCSP April 1998
B.2.2.1 Cache State Advertisement Record (CSA record
CSA records contain the information necessary to relate the
state of a cache entry in an SG to the servers being synchronized
CSA records contain a CSAS Record header and a client/server
specific part. The CSAS Record includes enough information for
to look into the client/server database for the appropriate
cache entry and then compare the "newness" of the summary against
"newness" of the cached entry. If the information contained in
CSA is more new than the cached entry of the receiving server
the cached entry is updated accordingly with the contents of the
Record. The client/server protocol specific part of the CSA
is documented separately for each such protocol. Examples of
protocol specific parts for NHRP and ATMARP are shown in [8] and [9]
respectively
The amount of information carried by a specific CSA record may
the size of a link layer PDU. Hence, s