Central Site Remote Access Switch 413
C
ONFIGURING
O
THER
A
DVANCED
O
PTIONS
Compression Options
When using Sequence Number check mode and a non-zero number of histories, the STAC-LZS
algorithm requires that incoming data packets be decompressed in the order they were
compressed. The sequence numbers are used to assure proper ordering and that no packets have
been lost. Should a packet loss be detected, the system will send a CCP Reset-Request packet as
described in the CCP specification to the peer and will discard any accumulated history and
queued receive packets. The peer will be expected to also discard its outbound history and respond
with a CCP Reset-Acknowledgment. At this point, both sides will have been resynchronized and
compressed data transfers can continue.
When using Extended mode, a coherency count is checked to detect lost packets. If a packet loss is
detected by the receiver, a Reset-Request is sent to the transmitter. The next compressed data
packet transmitted will have a bit set to indicate that the history has been reset.
With the use of sequence numbers, the decompressed output of all in-order compressed frames is
assumed to be valid. The correct CRC check of the underlying link, combined with the in-order
sequencing of the frames, is the basis for assuming that the data yielded by the decompression is
accurate. However, even when these conditions have been met, the internal STAC library can still
signal a decompression failure. This type of error in the peer device is not considered to be
recoverable, as it indicates a flawed compressed packet from the decompressing system’s point of
view. Therefore, should such an error occur, CCP will be closed and the connection will continue
to operate, albeit without compression. An error message will be logged indicating an internal
decompression failure.
Compression is negotiated independently on inbound and outbound channels. It is possible to
provide compression in one direction while not in the opposite direction.
Should the peer not support PPP compression, CCP will fail to converge and the link will continue
to operate without providing compression. Should the peer support CCP, but not the Stac protocol,
the CCP negotiation will succeed, but no actual compression will occur on the connection.
Note:
The CyberSWITCH does not support individual link compression when PPP Multilink is
negotiated to aggregate multiple links. Multiple links to a single destination will be treated
as a single high capacity link as far as PPP compression is concerned. One history will be
kept for the group of links, and packets will be compressed before they are fragmented for
transmission across the multiple links.
The following documents provide additional information about PPP Compression:
•
The PPP Compression Control Protocol (CCP); RFC 1962; Dave Rand; June, 1996.
•
PPP Stac LZS Compression Protocol; RFC 1974; Robert Friend and William Allen Simpson; Au-
gust 1996.
