Server Cache Synchronization Protocol (SCSP)
Extracted elements (32)
Cache entry 'newness' is determined by three conditions in order: matching Cache Key, matching Originator ID, and a strictly greater CSA Sequence Number. This three-part key ensures that entries for the same resource but from different originators are kept distinct and the most recently modified state wins.
Receiver ID lists (rather than a single Receiver ID) in Hello messages enable efficient use of point-to-multipoint connections: a single Hello carrying all known DCSIDs replaces N unicast Hellos, at the cost of slightly larger messages.
SCSP deliberately borrows its cache distribution algorithm from OSPF link-state flooding, providing well-understood reliability and partition-recovery properties, but deliberately omits any mandatory SPF calculation and imposes no memory overhead beyond what the cached data already requires.
SCSP is not a standalone protocol; it must be paired with a protocol-specific specification that defines how a given client/server protocol (e.g., NHRP, ATMARP) maps its cache entries to SCSP primitives. Protocol-specific fragmentation, purge mechanisms, and Family ID use are all delegated to those documents.
SCSP packets are LLC/SNAP encapsulated with LLC=0xAA-AA-03, OUI=0x00-00-5e, and PID=0x00-05. All fields marked 'unused' MUST be set to zero on transmission and ignored on receipt to allow future extension.
After a restart, any CSA Record sent by the restarting LS MUST carry a CSA Sequence Number unique within the SG for the given OID/Cache Key pair. The RECOMMENDED method is the previously-known sequence number plus a configured constant.
Every LS MUST periodically send a Hello message to each of its DCSs to ascertain connectivity status (bidirectional, unidirectional, or non-functional).
If an LS receives a CSU whose Receiver ID is neither the LS's LSID nor all-0xFFs, the CSU MUST be discarded and ignored, because the LS may be a leaf on a point-to-multipoint connection.
If the LS does not receive a Hello containing its own LSID within HelloInterval*DeadFactor seconds (as advertised by the DCS), the LS MUST consider the DCS stalled: if any Hello was received during that window, transition the HFSM to Unidirectional Connection; otherwise transition to Waiting and remove the DCSID from the Receiver ID list.
On a point-to-multipoint connection, an LS MUST send only a single Hello message to all leaf DCSs, including all non-stalled DCSIDs in the Receiver ID list rather than sending per-DCS hellos.
Only the most up-to-date CSA Record instance may be queued on a given DCS retransmit queue; if a newer CSA Record for the same entry arrives while an older one is queued, the older one MUST be immediately dequeued and its timer disassociated before enqueuing the newer instance.
The SCSP Authentication Extension default hash algorithm MUST be HMAC-MD5-128; manual keying MUST be supported. If a received packet fails authentication, it is discarded and the event logged.
Until the HFSM reaches Bidirectional Connection state, any properly formed SCSP messages other than Hello messages that are received MUST be ignored. This handles point-to-multipoint scenarios where messages from other leaves may arrive prematurely.
When a CSA Sequence Number reaches 2^31-2 and the cache entry is modified, the originating LS MUST purge the entry from the SG by sending a CSA with sequence number 2^31-1, wait for acknowledgment from all DCSs, then re-advertise the updated entry starting at sequence number -2^31+1.
When an LS receives a CSU Request with a CSA Sequence Number smaller than its cached entry's sequence number, the LS MUST acknowledge using the CSAS Record from its own cache (not from the incoming request), so the DCS is corrected to the newer state.
When the slave LS transitions its CAFSM to the Update Cache state, it MUST retain a copy of its last sent CA message and SHOULD start a CAReXmtInterval timer, releasing the copy on timer expiry or receipt of a CSUS message. This handles the case where the master drops the last slave CA message and retransmits.
A CSA Record consists of a CSAS Record header followed by a client/server protocol-specific part. If a CSA Record exceeds the link-layer PDU size, it MUST be fragmented across multiple CSU Request messages using a method defined in the protocol-specific document.
The CSA Sequence Number is a signed 32-bit value (range -2^31+1 to 2^31-1; 0x80000000 reserved) assigned by the originator. A strictly larger sequence number means a more recent advertisement; the originator increments it on each cache-entry modification requiring synchronization.
The Family ID field in Hello messages groups multiple PID/SGID pairs under a single HFSM, creating a one-to-many mapping between one HFSM and the CAFSMs for each protocol instance. This substantially reduces Hello maintenance traffic when multiple protocol instances share a physical link.
The Hop Count in a CSAS Record controls flood propagation: set to 1 for stand-alone records (CA alignment, one hop only) and to an administratively configured value >= (|SG|-1) when embedded in CSA Records for flooding, except when responding to a solicitation where Hop Count SHOULD be 1.
The PID/SGID pair uniquely identifies an SCSP instance: Protocol ID names the client/server protocol (ATMARP=1, NHRP=2, MARS=3, DHCP=4, LNNI=5), and the 16-bit Server Group ID identifies the specific protocol instance. Multiple instances of the same protocol can be synchronized independently.
IANA assigns Protocol ID values used in the Mandatory Common Part to identify which protocol employs SCSP (currently: ATMARP=1, NHRP=2, MARS=3, DHCP=4, LNNI=5). IANA also assigns hash algorithm identifiers for the Authentication Extension.
Authentication is pairwise between LS and DCS; the SPI indexes a per-pair table of {lifetime, algorithm, key}. The SPI and parameters can be negotiated manually or via an Internet key management protocol, and multiple SPIs for the same DCS ID may be active simultaneously to support key rollover.
The Cache Alignment Finite State Machine (CAFSM) has five states: Down, Master/Slave Negotiation, Cache Summarize, Update Cache, and Aligned. It is coupled to the HFSM per DCS per PID/SGID: when the HFSM reaches Bidirectional, the CAFSM moves to Master/Slave Negotiation; any HFSM departure from Bidirectional forces the CAFSM back to Down. The Aligned state enables normal CSU flooding.
The Hello Finite State Machine (HFSM) has four states: Down, Waiting, Bidirectional Connection, and Unidirectional Connection. It starts in Down, transitions to Waiting when NBMA-level connectivity is established, advances to Bidirectional Connection when the LS finds its own LSID in the DCS's Hello Receiver ID list, or to Unidirectional Connection otherwise. Loss of NBMA connectivity returns to Down; abnormal events (e.g., malformed packet) return to Waiting.
Extensions use TLV encoding: Type (2 bytes), Length (2 bytes, value only), Value (variable). The extensions block is terminated by End-of-Extensions with Type=0, Length=0. Each extension type may appear at most once per packet; an LS MUST NOT reorder extensions.
The Authentication Extension (Type=1) contains a 4-byte Security Parameter Index (SPI) followed by variable-length Authentication Data holding the MAC computed over the entire SCSP payload with the authentication data field zeroed during computation.
The CA message mandatory part begins with CA Sequence Number (4 bytes) followed by the Mandatory Common Part whose Flags field carries M (Master/Slave), I (Initialization), and O (mOre) bits. Zero or more CSAS Records (not embedded in CSA Records) are appended.
The CSAS Record contains: Hop Count (2 bytes), Record Length (2 bytes), Cache Key Len (1 byte), Orig ID Len (1 byte), N bit plus unused (2 bytes), CSA Sequence Number (4 bytes, signed 32-bit, 0x80000000 reserved), followed by variable-length Cache Key and Originator ID.
The Hello message mandatory part prepends HelloInterval (2 bytes), DeadFactor (2 bytes), unused (2 bytes), and Family ID (2 bytes) before the Mandatory Common Part, followed by zero or more Additional Receiver ID Records each consisting of Rec ID Len (1 byte) and variable-length Receiver ID.
The Mandatory Common Part contains: Protocol ID (2 bytes), Server Group ID (2 bytes), unused (2 bytes), Flags (2 bytes, message-specific), Sender ID Len (1 byte), Receiver ID Len (1 byte), Number of Records (2 bytes), followed by variable-length Sender ID and Receiver ID fields.
The SCSP Fixed Part header is 8 bytes: Version (1 byte, current=1), Type Code (1 byte; CA=1, CSU-Request=2, CSU-Reply=3, CSUS=4, Hello=5), Packet Size (2 bytes, total octets excluding link-layer encapsulation), Checksum (2 bytes, IP checksum over entire packet), and Start Of Extensions (2 bytes, offset to first extension or zero).