Enterasys csx150 Guida Utente
Small Office Remote Access Switch 329
C
ONFIGURING
O
THER
A
DVANCED
O
PTIONS
Compression Options
algorithm. The peer and remote compression algorithms must be synchronized, this is
accomplished by negotiating compression at channel connect time. Once this has been
accomplished compressed data can be transmitted. If a transmission problem should ever occur the
problem is detected and compression re-synchronized by the execution of a pre-defined protocol.
accomplished by negotiating compression at channel connect time. Once this has been
accomplished compressed data can be transmitted. If a transmission problem should ever occur the
problem is detected and compression re-synchronized by the execution of a pre-defined protocol.
C
OMPRESSION
AND
CCP
The Compression Control Protocol (CCP) is one of a suite of protocols which operate under the
umbrella of the IETF’s Point-to-Point Protocol (PPP) suite. CCP implementation permits
compression and decompression on PPP links.
umbrella of the IETF’s Point-to-Point Protocol (PPP) suite. CCP implementation permits
compression and decompression on PPP links.
During call establishment, an appropriately configured system will attempt to negotiate
compression 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 options
used by CCP include:
•
compression 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 options
used by CCP include:
•
STAC-LZS compression algorithm
•
one history
•
sequence number check mode or extended mode
During CCP negotiations, the system will always propose the use of Sequence Number check mode
first for inbound traffic. The peer has the option to accept or reject this proposal. If the peer rejects
the 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.
first for inbound traffic. The peer has the option to accept or reject this proposal. If the peer rejects
the 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 the
Point-to-Point links. Such compressed data packets will be encapsulated as described in the CCP
specification. Received data packets not so encapsulated will be considered to be uncompressed
data and will be forwarded on in the order they were received. Transmitted packets whose
compressed size increases to the point of exceeding the link’s Maximum Receive Unit (MRU) will
be sent uncompressed.
Point-to-Point links. Such compressed data packets will be encapsulated as described in the CCP
specification. Received data packets not so encapsulated will be considered to be uncompressed
data and will be forwarded on in the order they were received. Transmitted packets whose
compressed size increases to the point of exceeding the link’s Maximum Receive Unit (MRU) will
be sent uncompressed.
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.
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.
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
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