rfc1977.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,404 行 · 第 1/4 页

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-
      Request.  This method is more expensive than using Reset-Requests.

      When the receiver first encounters an unexpected sequence number
      it SHOULD send a Reset-Request CCP packet as defined in the
      Compression Control Protocol.  When the transmitter sends the
      Reset-Ack or when the receiver receives a Reset-ACK, they must
      reset the sequence number to zero, clear the compression
      dictionary, and resume sending and receiving compressed packets.
      The receiver MUST discard all compressed packets after detecting
      an error and until it receives a Reset-Ack.  This strategy can be
      thought of as abandoning the transmission of one "file" and
      starting the transmission of a new "file."

      The transmitter must clear its compression dictionary and respond
      with a Reset-Ack each time it receives a Reset-Request, because it
      cannot know if previous Reset-Acks reached the receiver.  The
      receiver MUST clear its compression dictionary each time it
      receives a Reset-Ack, because the transmitter will have cleared
      its compression dictionary.

      When the link is busy, one decompression error is usually followed
      by several more before the Reset-Ack can be received.  It is
      undesirable to transmit Reset-Requests more frequently than the
      round-trip-time of the link, because redundant Reset-Requests
      cause unnecessary compression dictionary clearing.  The receiver
      MAY transmit an additional Reset-Request each time it receives a
      compressed or uncompressed packet until it finally receives a
      Reset-Ack, but the receiver ought not transmit another Reset-
      Request until the Reset-Ack for the previous one is late.  The
      receiver MUST transmit enough Reset-Request packets to ensure that
      the transmitter receives at least one.  For example, the receiver
      might choose to not transmit another Reset-Request until after one
      second (or, of course, a Reset-Ack has been received and
      decompression resumed).



Schryver                     Informational                      [Page 3]

RFC 1977                    PPP BSD Compress                 August 1996


   Data Expansion

      When significant data expansion is detected, the PPP packet MUST
      be sent without compression.  Packets that would expand by fewer
      than 3 bytes SHOULD be sent without compression, but MAY be sent
      compressed provided the result does not exceed the MTU of the
      link.  This makes moot standards document exegesises about exactly
      which bytes, such as the Protocol fields, count toward expansion.

      When a packet is received with PPP Protocol numbers in the range
      0x0000 to 0x3FFF, (except, of course, 0xFD and 0xFB) it is assumed
      that the packet would have caused expansion.  The packet is
      locally compressed to update the compression history.

      Sending incompressible packets in their native encapsulation
      avoids maximum transmission unit complications.  If uncompressed
      packets could be larger than their native form, then it would be
      necessary for the upper layers of an implementation to treat the
      PPP link as if it had a smaller MTU, to ensure that compressed
      incompressible packets are never larger than the negotiated PPP
      MTU.

      Using native encapsulation for incompressible packets complicates
      the implementation.  The transmitter and the receiver must start
      putting information into the compression dictionary starting with
      the same packets, without relying upon seeing a compressed packet
      for synchronization.  The first few packets after clearing the
      dictionary are usually incompressible, and so are likely to sent
      in their native encapsulation, just like packets before
      compression is turned on.  If CCP or LCP packets are handled
      separately from Network-Layer packets (e.g. a "daemon" for control
      packets and "kernel code" for data packets), care must be taken to
      ensure that the transmitter synchronizes clearing the dictionary
      with the transmission of the configure-ACK or Reset-Ack that
      starts compression, and the receiver must similarly ensure that
      its dictionary is cleared before it processes the next packet.

      A difficulty caused by sending data that would expand uncompressed
      is that the receiver must adaptively clear its dictionary at
      precisely the same times as the sender.  In the classic BSD
      compression code, the dictionary clearing is signaled by the
      reserved code 256.  Because data that would expend is sent without
      compression, there is no reliable way for the sender to signal
      explicitly when it has cleared its dictionary.  This difficulty is
      resolved by specifying the parameters that control the dictionary
      clearing, and having both sender and receiver clear their
      dictionaries at the same times.




Schryver                     Informational                      [Page 4]

RFC 1977                    PPP BSD Compress                 August 1996


2.1.  Packet Format

   A summary of the BSD Compress packet 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PPP Protocol          |           Sequence
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Data ...
   +-+-+-+-+-+-+-+-+


   PPP Protocol

      The PPP Protocol field is described in the Point-to-Point Protocol
      Encapsulation [1].

      When the BSD Compress compression protocol is successfully
      negotiated by the PPP Compression Control Protocol [2], the value
      of the protocol field is 0xFD or 0xFB.  This value MAY be
      compressed when Protocol-Field-Compression is negotiated.

   Sequence

      The sequence number is sent most significant octet first.  It
      starts at 0 when the dictionary is cleared, and is incremented by
      1 after each packet, including uncompressed packets.  The sequence
      number after 65535 is zero.  In other words, the sequence number
      "wraps" in the usual way.

      The sequence number ensures that lost or out of order packets do
      not cause the compression databases of the peers to become
      unsynchronized.  When an unexpected sequence number is
      encountered, the dictionaries must be resynchronized with a CCP
      Reset-Request or Configure-Request.  The packet sequence number
      can be checked before a compressed packet is decoded.

   Data

      The compressed PPP encapsulated packet, consisting of the Protocol
      and Data fields of the original, uncompressed packet follows.

      The Protocol field compression MUST be applied to the protocol
      field in the original packet before the sequence number is
      computed or the entire packet is compressed, regardless of whether



Schryver                     Informational                      [Page 5]

RFC 1977                    PPP BSD Compress                 August 1996


      the PPP protocol field compression has been negotiated.  Thus, if
      the original protocol number was less than 0x100, it must be
      compressed to a single byte.

      The format of the compressed data is more precisely described by
      the example code in the "BSD Compress Algorithm" appendix.

3.  Configuration Option Format


   Description

      The CCP BSD Compress Configuration Option negotiates the use of
      BSD Compress on the link.  By default or ultimate disagreement, no
      compression is used.

   A summary of the BSD Compress Configuration Option 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Vers|   Dict  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      21 or 0x15 for BSD compress.

   Length

      3

   Vers

      Must be the binary number 001.

   Dict

      The size in bits of the largest code used.  It can range from 9 to
      16.  A common choice is 12.  The code included below can support
      code sizes from 9 to 15.

      It is convenient to treat the byte containing the Vers and Dict
      fields as a single field with legal values ranging from 0x29 to
      0x30.




Schryver                     Informational                      [Page 6]

RFC 1977                    PPP BSD Compress                 August 1996


      Note that the peer receiving compressed data must use the same
      code size as the peer sending data. It is not practical for the
      receiver to use a larger dictionary or code size, because both
      dictionaries must be cleared at the same time, even when the data
      is not compressible, so that uncompressed packets are being sent,
      and so the receiver cannot receive LZW "CLEAR" codes.

      When a received Configure-Request specifies a smaller dictionary
      than the local preference, it is often best to accept it instead