PPP BSD Compression Protocol
RFC 1977
|
| Document |
Type |
|
RFC - Informational
(August 1996; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 1977 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group V. Schryver
Request for Comments: 1977 August 1996
Category: Informational
PPP BSD Compression Protocol
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 Unix Compress compression
protocol for compressing PPP encapsulated packets.
Table of Contents
1. Introduction .................................... 1
1.1 Licensing ................................. 2
2. BSD Compress Packets ............................ 2
2.1 Packet Format ............................. 5
3. Configuration Option Format ..................... 6
APPENDICES ............................................. 7
A. BSD Compress Algorithm .......................... 7
SECURITY CONSIDERATIONS ................................ 24
REFERENCES ............................................. 24
ACKNOWLEDGEMENTS ....................................... 24
CHAIR'S ADDRESS ........................................ 25
AUTHOR'S ADDRESS ....................................... 25
1. Introduction
UNIX compress as embodied in the freely and widely distributed BSD
source has the following features:
- dynamic table clearing when compression becomes less
effective.
Schryver Informational [Page 1]
RFC 1977 PPP BSD Compress August 1996
- automatic turning off of compression when the overall result
is not smaller than the input.
- dynamic choice of code width within predetermined limits.
- heavily used for many years in networks, on modem and other
point-to-point links to transfer netnews.
- an effective code width requires less than 64KBytes of memory
on both sender and receive.
1.1. Licensing
BSD Unix compress command source is widely and freely available, with
no additional license for many computer vendors. The included source
code is based on the BSD compress command source and carries only the
copyright of The Regents of the University of California. Use the
code entirely at your own risk. It has no warranties or
indemnifications of any sort. Note that there are patents on LZW.
2. BSD Compress Packets
Before any BSD Compress packets may be communicated, PPP must reach
the Network-Layer Protocol phase, and the CCP Control Protocol must
reach the Opened state.
Exactly one BSD Compress datagram is encapsulated in the PPP
Information field, where the PPP Protocol field contains 0xFD or
0xFB. 0xFD is used when the PPP multilink protocol is not used or
"above" multilink. 0xFB is used "below" multilink, to compress
independently on individual links of a multilink bundle.
The maximum length of the BSD Compress datagram transmitted over a
PPP link is the same as the maximum length of the Information field
of a PPP encapsulated packet.
Only packets with PPP Protocol numbers in the range 0x0000 to 0x3FFF
and neither 0xFD nor 0xFB are compressed. Other PPP packets are
always sent uncompressed. Control packets are infrequent and should
not be compressed for robustness.
Padding
BSD Compress packets require the previous negotiation of the
Self-Describing-Padding Configuration Option [3] if padding is
added to packets. If no padding is added, than Self-Describing-
Padding is not required.
Schryver Informational [Page 2]
RFC 1977 PPP BSD Compress August 1996
Reliability and Sequencing
BSD Compress requires the packets to be delivered in sequence. It
relies on Reset-Request and Reset-Ack CCP packets or on
renegotiation of the Compression Control Protocol [2] to indicate
loss of synchronization between the transmitter and receiver. The
HDLC FCS detects corrupted packets and the normal mechanisms
discard them. Missing or out of order packets are detected by the
sequence number in each packet. The packet sequence number ought
Show full document text