rfc1967.txt
来自「RFC 的详细文档！」· 文本 代码 · 共 1,012 行 · 第 1/3 页
TXT
1,012 行
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]
⌨️ 快捷键说明
复制代码Ctrl + C
搜索代码Ctrl + F
全屏模式F11
增大字号Ctrl + =
减小字号Ctrl + -
显示快捷键?