[Docs] [txt|pdf] [draft-ietf-pppe...] [Tracker] [Diff1] [Diff2] [IPR]
INFORMATIONAL
Network Working Group K. Schneider
Request for Comments: 1967 ADTRAN, Inc.
Category: Informational R. Friend
Stac Technology
August 1996
PPP LZS-DCP Compression Protocol (LZS-DCP)
Status of This Memo
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
The PPP Compression Control Protocol [2] provides a method to
negotiate and utilize compression protocols over PPP encapsulated
links.
This document describes the use of the Stac LZS data compression
algorithm for compressing PPP encapsulated packets, using a DCP
header [6]. This protocol is an enhanced version of the non-DCP
(Option 17) PPP Stac LZS compression protocol [5], and will be
referred to as the LZS-DCP Compression Protocol.
Table of Contents
1. Introduction .......................................... 2
1.1 Licensing ....................................... 3
1.2 Specification of Requirements ................... 3
1.3 Terminology ..................................... 3
2. LZS-DCP Packets ....................................... 4
2.1 Example LZS-DCP Packets ......................... 5
2.2 Padding ......................................... 6
2.3 Reliabliity and Squencing ....................... 6
2.4 Data Expansion .................................. 6
2.5 Packet Format ................................... 7
2.5.1 PPP Protocol .................................... 7
2.5.2 DCP-Header ...................................... 8
2.5.3 History Number .................................. 9
2.5.4 Sequence Number ................................. 9
2.5.5 Data ............................................ 10
2.5.6 Longitudinal Check Byte ......................... 10
Schneider & Friend Informational [Page 1]
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 [Page 2]
RFC 1967 LZS-DCP August 1996
The Stac LZS compression algorithm supports both single and multiple
compression histories. A single compression history will require the
minimum amount of memory to implement, but may not provide as much
compression as a multiple history implementation.
Often, many streams of information are interleaved over the same
physical link. Each virtual connection will transmit data that is
independent of other virtual connections. Using multiple compression
histories can improve the compression ratio of a communication link
by associating separate compression histories with separate virtual
links of communication.
1.1. Licensing
Source and object licenses are available on a non-discriminatory
basis. Hardware implementations are also available. Contact Stac
Electronics (hardware.sales@stac.com) for further information.
1.2. Specification of Requirements
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.
MUST This word, or the adjective "required", means that the
definition is an absolute requirement of the specification.
MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.
SHOULD This word, or the adjective "recommended", means that there
may exist valid reasons in particular circumstances to
ignore this item, but the full implications MUST be
understood and carefully weighed before choosing a
different course.
MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST be
prepared to interoperate with another implementation which
does include the option.
1.3. Terminology
This document frequently uses the following terms:
datagram The unit of transmission in the network layer (such as IP).
A datagram may be encapsulated in one or more packets
passed to the data link layer.
Schneider & Friend Informational [Page 3]
RFC 1967 LZS-DCP August 1996
frame The unit of transmission at the data link layer. A frame
may include a header and/or a trailer, along with some
number of units of data.
packet The basic unit of encapsulation, which is passed across the
interface between the network layer and the data link
layer. A packet is usually mapped to a frame; the
exceptions are when data link layer fragmentation is being
performed, or when multiple packets are incorporated into a
single frame.
peer The other end of the point-to-point link.
silently discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter.
2. LZS-DCP Packets
Before any LZS-DCP packets are communicated, PPP MUST reach the
Network-Layer Protocol phase, and the CCP Control Protocol MUST reach
the Opened state.
Exactly one LZS-DCP datagram is encapsulated in the PPP Information
field, where the PPP Protocol field indicates type hex 00FD
(compressed datagram) or type hex 00FB (Individual link compressed
datagram). Type hex 00FD is used when compression is negotiated over
a single physical link or when compression is negotiated over a
single bundle consisting of multiple physical links. Type hex 00FB
is used when compression is negotiated separately over individual
physical links to the same destination. For more information, please
refer to PPP Compression Control Protocol.
The maximum length of the LZS-DCP datagram transmitted over a PPP
link is the same as the maximum length of the Information field of a
PPP encapsulated packet.
Prior to compression, the uncompressed data begins with the PPP
Protocol ID Field. Protocol-Field-Compression MAY be used on this
value, if has been successfully negotiated for the link.
The PPP Protocol ID Field is followed by the original Information
field. The length of the uncompressed data field is limited only by
the allowed size of the compressed data field and the higher protocol
Schneider & Friend Informational [Page 4]
RFC 1967 LZS-DCP August 1996
layers.
PPP Link Control Protocol packets MUST NOT be sent within LZS-DCP
packets. PPP Network Control Protocol packets MUST NOT be sent
within LZS-DCP packets.
2.1. Example LZS-DCP packets (shown using PPP in HDLC-like framing,
using Address-and-Control-Field-Compression and Protocol-Field-
Compression. - RFC 1662 )
Compressed Packet:
PPP | | PPP
PID | HDR SEQ DATA LCB | FCS
+-----+-----+-----+---................---+-----+-----+
| F D | C 0 | n n | Compressed Data | y y | z z |
+-----+-----+-----+---................---+-----+-----+
/ \
/ Compression \
/ Transformation \
/ \
/PPP \
/ PID PPP Information Field \
+-----+----....................----+
| x x | upper layer protocol data |
+-----+----....................----+
Uncompressed Packet
PPP | | PPP
PID | HDR SEQ DATA | FCS
+-----+-----+-----+---................---+-----+
| F D | 8 0 | n n | Un-compressed Data | z z |
+-----+-----+-----+---................---+-----+
/ \
/ \
/ \
/ \
/PPP \
/ PID PPP Information Field \
+-----+----....................----+
| x x | upper layer protocol data |
+-----+----....................----+
where: C0 and 80 are representative LZS-DCP headers; nn, xx, yy,
and zz are values determined by the packet's context.
Schneider & Friend Informational [Page 5]
RFC 1967 LZS-DCP August 1996
2.2. Padding
PPP padding is not allowed in a LZS-DCP packet. However, on
compressed packets, padding may be accomplished by extending the
data field with zeros following the last compressed data octet
(see Section 2.1.1). This is referred to as LZS Padding. The
LCB, if present, MUST be the octet preceding the frame CRC.
2.3. Reliability and Sequencing
When no Compression History is kept, the algorithm does not depend
on a reliable link, and does not require that packets be delivered
in sequence. However, per packet compression results in a lower
compression ratio than it could be on a stream.
Some reasons for clearing the history on a per packet basis
include:
- The link has a high error rate.
- The resources of the transmitter or receiver limit the ability
to maintain a compression history between packets.
When one or more compression Histories are negotiated, the packet
sequence MUST be preserved within specific History Numbers. There
is no sequence requirement between different History Numbers.
When using one or more compression histories, the implementation
MUST rely on either a lower layer reliable link protocol (RFC
1663), use a technique to keep the compressor and decompressor
histories in synchronization, or both. The LZS-DCP protocol
provides the Request-Req and Request-Ack bits in the DCP header
for this purpose. Since this synchronization is done on a per
history basis, the history number fields are required to be the
same size in both directions of the link. Any data contained in
the packet is processed after the signaling bits are processed.
The transmitter MAY clear a Compression History at any time.
The transmitter MUST clear a history after a receiving a Reset-
Request for a given History Number.
2.4. Data Expansion
The maximum expansion of Stac LZS is 12.5%.
A Maximum Receive Unit (MRU) MAY be negotiated that is 12.5%
larger than the size of a normal packet. Then, packets can always
be sent compressed regardless of expansion.
Schneider & Friend Informational [Page 6]
RFC 1967 LZS-DCP August 1996
The transmitter MAY send an uncompressed LZS-DCP packet at any
time, although the typical use of uncompressed LZS-DCP packets is
as an anti-expansion mechanism.
When the expansion plus compression header exceeds the size of the
peer's MRU for the link, the data MUST be sent as an uncompressed
LZS-DCP packet.
An uncompressed LZS-DCP packet is transmitted according to the
format shown in Section 2.1, with the C/U bit set to 0
(Uncompressed-Data). If the Configuration Option Field 'Process
Mode', is set to a value of 1 (Process-Uncompressed), uncompressed
LZS-DCP packets are processed by both the compressor and the
decompressor, updating the histories of each. If the Process Mode
Field is set to a value of 0 (None), and the compressor has
modified its history before sending the uncompressed packet, the
compressor history MUST be clear.
2.5. Packet Format
A summary of the LZS-DCP packet format is shown below. The fields
are transmitted from left to right.
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol | DCP-Header |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (History Number) | (Seq Num) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (LCB) |
+-+-+-+-+-+-+-+-+
2.5.1. PPP Protocol
The PPP Protocol field is described in the Point-to-Point Protocol
Encapsulation [1].
When the LZS-DCP compression protocol is successfully negotiated
by the PPP Compression Control Protocol [2], the value is 00FD or
00FB hex. This value MAY be compressed when Protocol-Field-
Compression is negotiated.
Schneider & Friend Informational [Page 7]
RFC 1967 LZS-DCP August 1996
2.5.2. DCP-Header
The DCP-Header is nominally one octet in length, but may be
extended through the use of the extension bit.
The format of the DCP-Header is as follows:
0 1 2 3 4 5 6 7
+-----+-----+-----+-----+-----+-----+-----+-----+
| E | C/U | R-A | R-R | Res | Res | Res | C/D |
+-----+-----+-----+-----+-----+-----+-----+-----+
E - Extension Bit
The E bit is the extension bit. If set to 0, it indicates that
another octet of the DCP-Header is present. Currently, this
bit is always set to 1, since the DCP-Header field is only one
octet long.
C/U - Compressed/Uncompressed Bit
The C/U indicates whether the data field contains compressed or
uncompressed data. A value of 1 indicates compressed data
(often referred to as a compressed packet), and a value of 0
indicates uncompressed data (or an uncompressed packet).
R-A - Reset-Ack
The R-A bit is used to inform the decompressing peer that
the history buffer specified by the history number in the
packet was in the cleared state just before the data contained
in the packet was processed by the compression transformation
(see section 3., Sending Compressed Datagrams). This bit MUST
be set to a value of "1" to indicate a Reset-Ack, and to
acknowledge a receive failure (R-R) (see section 3., Sending
Compressed Datagrams). This bit is specific to the history
number of the packet containing it.
R-R - Reset-Request
The R-R bit is used to request that the compressing peer
clear the history buffer specified by the history number in the
packet. This bit MUST be set to a value of "1" to indicate a
Reset-Request, and to respond to a receive failure (R-R) (see
section 3., Sending Compressed Datagrams). This bit is
specific to the history number of the packet containing it.
Schneider & Friend Informational [Page 8]
RFC 1967 LZS-DCP August 1996
Res - Reserved
These bits are reserved and MUST be set to 0
C/D - Control/Data
This bit is used by DCP to provide in-band negotiation in
applications where out-of-band negotiation methods are not
provided (i.e. Frame Relay). Since CCP provides an out of band
negotiating mechanism, this feature is not used in this
application. All packets MUST set this bit to a value of 0,
which signifies that the packet is a data packet. (Packets
containing only Reset- Requests are classified as data
packets.)
2.5.3. History Number
The number of the compression history which was used, ranging from
1 to the negotiated value in the History Count field.
If the negotiated History Count is less than 2, this field is
removed. If the negotiated History Count is 2 or more, but less
than 256, this field is 1 octet. If 256 or more histories are
negotiated, this field is 2 octets, most significant octet first.
If multiple histories are used in one direction on a link, the
history number field MUST be present on all packets in both
directions, and sized according to the largest number of histories
in either direction.
If multiple histories are used, this field MUST be present in
uncompressed as well as compressed packets.
2.5.4. Sequence Number
The sequence number field is one octet in length. When the check
mode field is set to the "Sequence Number" or "Sequence Number +
LCB" options, the sequence number field MUST be present in all
data compression packets that contain a data field.
The value of the sequence number field (the sequence number of the
packet) MUST begin with "1" and increment modulo 256 on successive
packets that contain data fields. This number is relative to the
history number used.
On receipt of a packet with the R-A bit set to "0", if the
sequence number of the packet is any number other than (N+1) mod
256, where N is the sequence number of the last packet received
Schneider & Friend Informational [Page 9]
RFC 1967 LZS-DCP August 1996
for the same history, or an initial value of "0", a receive
failure for that history has occurred. The receive failure MUST
be handled according to the synchronization procedure in section
3.5.
The sequence number MUST NOT be reset by the transmitter when a
packet containing a Reset-Ack is sent. The decompressor MUST
resynchronize its sequence number reference for the indicated
history when a packet containing a Reset-Ack is received.
2.5.5. Data
The data field MUST contain a single datagram in either compressed
or uncompressed form, depending on the state of the C/U bit in the
Header. This length of this field is always be an integer number
of octets. This field is required in all packets that do not have
the R-R bit set to "1".
If the C/U bit is set to "0", the data field contains the
uncompressed form of the datagram.
If the C/U bit is set to "1", the form of the data field is one
block of compressed data as defined in 3.2 of X3.241-1994, with
the following exceptions: 1) the end marker may be followed with
additional octets containing only zeros; 2) if the final octet in
the block of compressed data has a value of "0", then it MAY be
removed from the data field.
There is only one end marker per block of compressed data.
2.5.6. Longitudinal Check Byte
The LCB field is one octet in length, and if present MUST be the
last octet in the data compression packet. When the check-mode
field is set to "LCB" or "Sequence Number + LCB", this field MUST
be present in all packets where the data field contains compressed
data. This field MUST NOT be present in data compression packets
where the data field contains uncompressed data. This field
contains the result of the LCB calculation, in accordance with the
following paragraph.
The LCB octet is the Exclusive-OR of FF(hex) and each octet of the
uncompressed datagram (prior to the compression transformation).
On receipt, the receiver computes the Exclusive-OR of FF(hex) and
each octet of the decompressed packet. If this value does not
match the received LCB, then a receive failure for that history
has occurred. The receive failure is handled according to the
history synchronization procedure in section 3.5.
Schneider & Friend Informational [Page 10]
RFC 1967 LZS-DCP August 1996
2.5.7. Compressed Data
The Stac LZS compression algorithm is Defined in ANSI X3.241-1994
[7]. The format of the compressed data is repeated here for
informational purposes ONLY.
<Compressed Stream> := [<Compressed String>] <End Marker>
<Compressed String> := 0 <Raw Byte> | 1 <Compressed Bytes>
<Raw Byte> := <b><b><b><b><b><b><b><b> (8-bit byte)
<Compressed Bytes> := <Offset> <Length>
<Offset> := 1 <b><b><b><b><b><b><b> | (7-bit offset)
0 <b><b><b><b><b><b><b><b><b><b><b> (11-bit offset)
<End Marker> := 110000000
<b> := 1 | 0
<Length> :=
00 = 2 1111 0110 = 14
01 = 3 1111 0111 = 15
10 = 4 1111 1000 = 16
1100 = 5 1111 1001 = 17
1101 = 6 1111 1010 = 18
1110 = 7 1111 1011 = 19
1111 0000 = 8 1111 1100 = 20
1111 0001 = 9 1111 1101 = 21
1111 0010 = 10 1111 1110 = 22
1111 0011 = 11 1111 1111 0000 = 23
1111 0100 = 12 1111 1111 0001 = 24
1111 0101 = 13 ...
3. Sending Compressed Datagrams
The reliable and efficient transport of datagrams on the data link
depends on the following processes.
3.1. Transmitter Process
The compression operation results in either compressed or
uncompressed data. When a network datagram is received, it is
assigned to a particular history buffer and processed according to
ANSI X3.241-1994 to form compressed data or used as is to form
uncompressed data. Prior to the compression operation, if a
Reset-Request is outstanding for the history buffer to be used,
the buffer is cleared. In performing the compression operation,
if the process mode field is set to the value None ("0"), the
history MUST only be updated if the result is compressed data. If
process mode field is set to the value Process-Uncompressed ("1"),
Schneider & Friend Informational [Page 11]
RFC 1967 LZS-DCP August 1996
the history MUST be updated when either compressed data or
uncompressed data is produced. Uncompressed data MAY be sent at
any time. Uncompressed data MUST be sent if compression causes
enough expansion to cause the data compression datagram size to
exceed the Information field's MRU.
If the Process Mode field is set to the value None ("0") and the
compressor has modified the history buffer before sending an
uncompressed datagram, the history buffer MUST be cleared before
the next datagram is processed.
The output of the compression operation is placed in the
information field of the datagram. The C/U bit is set according
to whether the data field contains compressed or uncompressed
data. If the sequence number field is present according the value
of the check mode field, the sequence number counter for the
applicable history number MUST be incremented and its value placed
in the sequence number field. If the data field contains
compressed data, and Check Mode field is set accordingly, the LCB
field is present and its value is computed as specified in section
2.2.6.
Upon reception of a packet containing a Reset-Request, the
transmitting compressor MUST be cleared to an initial state, which
includes clearing the history buffer. If the data field of the
packet containing the Reset-Request contains data, it is delivered
to the local receiver as a normal data packet. In addition to the
reset of the compressor, a packet MUST be transmitted with Reset-
Ack bit set to 1. The data field of this packet MUST be filled
with data. If no data is ready for transmission, the transmitter
MUST wait until data is ready before sending the Reset-Ack.
If the history buffer is in the clear state (the history buffer
contains no data bytes) prior to performing the compression
operation, the resulting compressed or uncompressed packet MUST be
sent with the R-A bit set to "1".
3.2. Receiver Process
When a data compression datagram is received from the peer, the
R-R and R-A bits MUST be checked. If the R-R bit is set, the
local compression engine MUST be signaled that a Reset-Request has
been received for the history specified by the history number
field. If the R-A bit is set, any outstanding receive failure for
the specified history MUST be cleared. If no receive failure is
outstanding, and the sequence number field is present, its value
checked. If a receive failure has occurred, it MUST be handled
according to the history resynchronization mechanism described
Schneider & Friend Informational [Page 12]
RFC 1967 LZS-DCP August 1996
below, and the remainder of the datagram is discarded. If no
receive failure is detected, the data is assigned to the indicated
decompression history buffer and processed according to process
mode field and C/U bit.
If the C/U bit is set to "1", a single octet containing the value
0x00 MUST be appended to the data field and the resulting
compressed data block MUST be decompressed according to ANSI
X3.241-1994. If the LCB field is present on the received
datagram, an LCB for the uncompressed data MUST be computed and
checked against the received LCB according to section 2.1. If a
receive failure has occurred, it MUST be handled according to the
History Resynchronization Mechanism described below.
If the C/U bit is set to "0" and the process mode field is set to
the value Process-Uncompressed ("1"), the specified decompression
history buffer MUST be updated with the received uncompressed
data.
If the C/U bit is set to "0" and process mode field is set to the
value None ("0"), the specified decompression history buffer MUST
NOT be modified.
If the R-A bit is set to "1", the receiving decompressor MAY be
reset to an initial state. (However, due to the characteristics
of the Stac LZS algorithm, a decompressor reset is not required).
After reset, any compressed or uncompressed data contained in the
packet is processed.
On the occurrence of a receive failure, an implementation MUST
transmit a packet with the R-R bit set to "1" (a Reset-Request)
and with the history number matching the history that had the
failure. The data field may be present if data is waiting to be
transported for that history, or the R-R bit may be set in a
packet transmitted without sequence number, data, or LCB fields.
Once a receive failure has occurred, the data in any subsequent
packets received for that history MUST be discarded until a packet
containing a Reset-Ack is received. It is the responsibility of
the receiver to ensure the reliability of the reset request-
acknowledge mechanism. This may require the transmission of an
additional Reset-Request before a Reset-Ack will be received.
3.3. History Maintenance
The History Count field determines the number of history buffers
to be maintained for the compression protocol. For example, each
history buffer could represent a separate logical connection
between the data compression peers. When maintaining a history,
Schneider & Friend Informational [Page 13]
RFC 1967 LZS-DCP August 1996
the peers MUST use link error detection and signaling to ensure
that both the compressor and decompressor copies of each history
buffer are always identical.
Setting the History Count field to the value "0" indicates that
the compression is to be on a connectionless basis. In this case,
a single history buffer is used and MUST be cleared at the
beginning of every datagram. The compressing entity MUST set the
R-A bit on all outgoing datagrams.
When the History Count field is set to the value "1", a single
history buffer is maintained by each of the data compression
peers. (A single logical connection.)
When the History Count field is set to a value greater than "1",
separate history buffers, error detection states, and signaling
states are maintained by the decompressing entity for each
history. The compressing peer may transmit data on any number of
separate histories, up to the value of the History Count field.
3.4. Anti-Expansion Mechanism
When one or more histories are negotiated and the Process Mode
field is set to None ("0"), there are 2 options on how to handle
packets that expand:
1) Send the expanded data and keep the history, thus allowing
loss of current bandwidth but preserving future bandwidth on
the link.
2) Send the uncompressed data and clear the history, thus
conserving current bandwidth, but allowing possible loss of
future bandwidth on the link.
When 1 or more histories are negotiated and the Process Mode field
is set to Process-Uncompressed ("1"), there is an additional
option:
3) Send the uncompressed data and do not clear the compression
history; the decompressor will update its history, thus
conserving the current bandwidth and future bandwidth on the
link.
3.5. History Resynchronization Mechanism
The DCP-Header includes R-R (Reset-Request) and R-A (Reset-Ack)
bits in order to provide a mechanism for indicating a receiver
failure in one direction of a compressed link without affecting
traffic in the other direction. A receive failure is determined
Schneider & Friend Informational [Page 14]
RFC 1967 LZS-DCP August 1996
using the sequence number and/or LCB mechanism, according to the
value of the check mode field.
Reset-Requests and Reset-Acks are specific to the history number
of the packet containing them.
Reset-Request/Reset-Ack history synchronization signaling is
provided to recover from a loss of synchronization between peers,
especially in unreliable transport layers. As with all
compression algorithms, the decompressor can not recover from
dropped, erroneous, or mis-ordered datagrams, and will propagate
errors catastrophically until both peers are reset to an initial
state.
The LZS-DCP protocol provides a means to detect these error
conditions: LCB for erroneous datagrams, and sequence number for
dropped or mis-ordered datagrams. There is a means for correcting
a loss of synchronization: clear both the failing compression and
decompression histories, and follow the transmitter and receiver
processes in sections 3.1. and 3.2.
4. Configuration Option Format
The LZS-DCP Configuration Option negotiates the use of LZS-DCP on the
link. By default or ultimate disagreement, no compression is used.
This Configuration Option is used in CCP, and can be used in other
negotiation mechanisms [2].
All implementations MUST support the default values.
A summary of the LZS-DCP Configuration Option format is shown below.
The fields are transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | History Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Check Mode | Process Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
23
Length
6
Schneider & Friend Informational [Page 15]
RFC 1967 LZS-DCP August 1996
History Count
The History Count field is two octets, most significant octet
first, and specifies the maximum number of Compression Histories.
The value 0 indicates that the implementation expects the peer to
clear the Compression History at the beginning of every packet.
If this value is selected, the transmitter MUST set the Reset-Ack
bit of every packet that contains compressed data.
The value 1 is the default value and is used to indicate that only
one history is maintained.
Other valid values range from 2 to 65535. The peer is not
required to send as many histories as the implementation indicates
that it can accept. However, it should be noted that resources
are allocated in each peer to support the number of negotiated
histories in this field.
Check Mode
The Check Mode indicates support of LCB and/or Sequence checking.
The use of check mode None (0) MUST NOT be used for history counts
greater than zero.
0 None
1 LCB
2 Sequence Number
3 Sequence Number + LCB (default)
Process Mode
The Process Mode specifies how uncompressed packets are handled.
A value of None (0) indicates that uncompressed packets are not
processed by the decompressor. A value of Process-Uncompressed
(1) indicates that uncompressed packets are processed by the
decompressor to update the history.
0 None (default)
1 Process-Uncompressed
Security Considerations
Security issues are not discussed in this memo.
Schneider & Friend Informational [Page 16]
RFC 1967 LZS-DCP August 1996
Acknowledgments
This document is based on, and uses much of the text of [5].
References
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, Daydreamer, July 1994.
[2] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
1962, June 1996.
[3] Lempel, A., and J. Ziv, "A Universal Algorithm for Sequential
Data Compression", IEEE Transactions On Information Theory,
Vol. IT-23, No. 3, May 1977.
[4] Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
1994.
[5] Friend, R., and W. Simpson, "PPP Stac LZS Compression
Protocol", RFC 1974, August 1996.
[6] Motorola Information Systems Group, "Data Compression Protocol
(DCP) Proposal", TR-30.1 ad hoc contribution (email
reflector), September 21, 1995.
[7] ANSI X3.241-1994, "American National Standard Data Compression
Method, Adaptive Coding with Sliding Window of Information
Interchange".
Chair's Address
The working group can be contacted via the current chair:
Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
EMail: karl@ascend.com
Schneider & Friend Informational [Page 17]
RFC 1967 LZS-DCP August 1996
Authors' Addresses
Questions about this memo can also be directed to:
Kevin Schneider
Adtran, Inc.
901 Explorer Blvd.
Huntsville, AL 25806
Phone: (205) 971-8024
EMail: kschneider@adtran.com
Robert Friend
Stac Technology
12636 High Bluff Drive
San Diego, CA 92130-2093
Phone: (619) 794-4542
EMail: rfriend@stac.com
Schneider & Friend Informational [Page 18]
Html markup produced by rfcmarkup 1.129b, available from
https://tools.ietf.org/tools/rfcmarkup/
