RFC 1967 (rfc1967) - Page 2 of 18
PPP LZS-DCP Compression Protocol (LZS-DCP)
Alternative Format: Original Text Document
RFC 1967 LZS-DCP August 1996
2.5.7 Compressed Data ................................. 11
3. Sending Compressed Datagrams ..................... 11
3.1 Transmitter Process ............................. 11
3.2 Receiver Process ................................ 12
3.3 History Maintenance ............................. 13
3.4 Anti-Expansion Mechanism ........................ 14
3.5 History Resynchronization Mechanism ............. 14
4. Configuration Option Format ........................... 15
SECURITY CONSIDERATIONS ...................................... 16
REFERENCES ................................................... 17
CHAIR'S ADDRESS .............................................. 17
AUTHORS' ADDRESSES ........................................... 18
1. Introduction
Starting with a sliding window compression history, similar to LZ1
[3], Stac Electronics developed a compression algorithm identified as
Stac LZS. A PPP Compression Protocol for this compression algorithm
was developed and published [5]. That protocol was taken as a basis
for data compression work done in TIA for DSU/CSUs. As a part of
that standardization process, the concept of a portable Data
Compression Protocol (DCP) was introduced [6]. The resulting
(pending) TIA/EIA-655 standard uses this LZS-DCP protocol, which
ncorporates DCP into a PPP compression protocol for Stac LZS. A very
similar protocol is currently out for ballot in the Frame Relay
Forum. (It is identical except for the size of the history number
field.)
This publication of the LZS-DCP compression protocol is in the
interest of providing a common compression protocol for Stac-LZS, and
to provide features that are not available with the LZS compression
protocol [5]. Some of the differences between the LZS-DCP and LZS
(compression type 17) protocols are as follows:
1) LZS-DCP provides an option which allows packets containing
uncompressible data to be transferred without requiring the
compression history to be cleared, potentially allowing a
higher compression ratio. A bit is included in the DCP
header to indicate whether the packet contains compressed or
uncompressed data.
2) LZS-DCP uses reset request and acknowledgment bits in the DCP
header that is included on each packet rather than using
CCP's reset request and acknowledge packets, which may result
in fewer discarded data packets during the REQ/ACK handshake.
3) LZS-DCP allows simultaneous use of both sequence numbers and
the LCB for compression error detection.
Schneider & Friend Informational