Central Site Remote Access Switch 413C ONFIGURING O THER ADVANCED O PTIONSCompression OptionsWhen using Sequence Number check mode and a non-zero number of histories, the STAC-LZSalgorithm requires that incoming data packets be decompressed in the order they werecompressed. The sequence numbers are used to assure proper ordering and that no packets havebeen lost. Should a packet loss be detected, the system will send a CCP Reset-Request packet asdescribed in the CCP specification to the peer and will discard any accumulated history andqueued receive packets. The peer will be expected to also discard its outbound history and respondwith a CCP Reset-Acknowledgment. At this point, both sides will have been resynchronized andcompressed data transfers can continue.When using Extended mode, a coherency count is checked to detect lost packets. If a packet loss isdetected by the receiver, a Reset-Request is sent to the transmitter. The next compressed datapacket 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 isassumed to be valid. The correct CRC check of the underlying link, combined with the in-ordersequencing of the frames, is the basis for assuming that the data yielded by the decompression isaccurate. However, even when these conditions have been met, the internal STAC library can stillsignal a decompression failure. This type of error in the peer device is not considered to berecoverable, as it indicates a flawed compressed packet from the decompressing system’s point ofview. Therefore, should such an error occur, CCP will be closed and the connection will continueto operate, albeit without compression. An error message will be logged indicating an internaldecompression failure.Compression is negotiated independently on inbound and outbound channels. It is possible toprovide 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 continueto 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 isnegotiated to aggregate multiple links. Multiple links to a single destination will be treatedas a single high capacity link as far as PPP compression is concerned. One history will bekept for the group of links, and packets will be compressed before they are fragmented fortransmission 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.