Small Office Remote Access Switch 329C ONFIGURING O THER ADVANCED O PTIONSCompression Optionsalgorithm. The peer and remote compression algorithms must be synchronized, this isaccomplished by negotiating compression at channel connect time. Once this has beenaccomplished compressed data can be transmitted. If a transmission problem should ever occur theproblem is detected and compression re-synchronized by the execution of a pre-defined protocol.C OMPRESSION AND CCPThe Compression Control Protocol (CCP) is one of a suite of protocols which operate under theumbrella of the IETF’s Point-to-Point Protocol (PPP) suite. CCP implementation permitscompression and decompression on PPP links.During call establishment, an appropriately configured system will attempt to negotiatecompression using CCP and STAC-LZS. The system will support either of two STAC-LZS modes,sequence numbers or extended mode. This negotiation will take place on all calls. Specific optionsused by CCP include:• STAC-LZS compression algorithm• one history• sequence number check mode or extended modeDuring CCP negotiations, the system will always propose the use of Sequence Number check modefirst for inbound traffic. The peer has the option to accept or reject this proposal. If the peer rejectsthe proposal and counter-proposes STAC-LZS Extended mode, it will be accepted by the system.For outbound traffic, the system will accept either Sequence Number or Extended Mode.Once compression has been negotiated, transfers of compressed data can take place across thePoint-to-Point links. Such compressed data packets will be encapsulated as described in the CCPspecification. Received data packets not so encapsulated will be considered to be uncompresseddata and will be forwarded on in the order they were received. Transmitted packets whosecompressed size increases to the point of exceeding the link’s Maximum Receive Unit (MRU) willbe sent uncompressed.When 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 continue