PPP BSD Compression Protocol
RFC 1977

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 05

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
      to be checked before decoding the packet.

      Instead of transmitting a Reset-Request packet when detecting a
      decompression error, the receiver MAY momentary force CCP to drop
      out of the Opened state by transmitting a new CCP Configure-