CONFIGURING OTHER ADVANCED OPTIONS

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.

Central Site Remote Access Switch 413

Page 413
Image 413
Enterasys Networks CSX7000, CSX5500, CSX6000 manual Central Site Remote Access Switch