rfc1979.txt

RFC 的详细文档！


RFC 1979                      PPP Deflate                    August 1996


      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.

2.1.  Packet Format

   A summary of the PPP Deflate 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 PPP Deflate 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 for 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.



Woods                        Informational                      [Page 6]

RFC 1979                      PPP Deflate                    August 1996


   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
      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 basic format of the compressed data is precisely described by
      the 'Deflate' Compressed Data Format Specification[3].  Each
      transmitted packet must begin at a 'deflate' block boundary, to
      ensure synchronization when incompressible data resets the
      transmitter's state; to ensure this, each transmitted packet must
      be terminated with a zero-length 'deflate' non-compressed block
      (BTYPE of 00).  This means that the last four bytes of the
      compressed format must be 0x00 0x00 0xFF 0xFF.  These bytes MUST
      be removed before transmission; the receiver can reinsert them if
      required by the implementation.





























Woods                        Informational                      [Page 7]

RFC 1979                      PPP Deflate                    August 1996


3.  Configuration Option Format


   Description

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

   A summary of the PPP Deflate 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     |Window | Method|    MBZ    |Chk|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Type

      26 for PPP Deflate.

   Length

      3

   Window

      Represents the maximum window size the decompressor is willing to
      allocate; expressed as the base-2 logarithm of the LZ77 window
      size, minus 8.  'Deflate' compliant decompressors must be willing
      to accept the maximum 32KB window size, represented by a value of
      7.  A 'deflate' compliant compressor is at liberty to use a
      reduced window size, so a PPP Deflate compressor MUST either honor
      the restriction requested or reject the option.

   Method

      Must be the binary number 1000.  Represents the 'zlib' Compression
      Method identifier of '8' for 'deflate' compression with up to 32K
      window size.

   MBZ

      Must be all 0 bits.





Woods                        Informational                      [Page 8]

RFC 1979                      PPP Deflate                    August 1996


   Chk

      Must be 00 to specify sequence number check method.

Security Considerations

   Security issues are not discussed in this memo.

References

   [1]   Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
         RFC 1661, July 1994.

   [2]   Rand, D., "The PPP Compression Control Protocol (CCP)",
         RFC 1962, June 1996.

   [3]   Deutsch, L.P., "'Deflate' Compressed Data Format
         Specification", draft available in
         ftp.uu.net:/pub/archiving/zip/doc/deflate-1.1.doc.

   [4]   Gailly, J.-L., "Zlib 0.95 beta".

   [5]   Bell, T.C., Cleary, G. G. and Witten, I.H., "Text Compression",
         Prentice_Hall, Englewood Cliffs NJ, 1990.  The compression
         corpus itself can be found in ftp.uu.net:/pub/archiving/zip/.

   [6]   Simpson, W., "PPP LCP Extensions", RFC 1570, January 1994.

   [7]   Schryver, V., "PPP BSD Compression Protocol", RFC 1977,
         August 1996.

Acknowledgments

   William Simpson provided the very valuable idea of not using any
   additional header bytes for incompressible packets.
















Woods                        Informational                      [Page 9]

RFC 1979                      PPP Deflate                    August 1996


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: [e-mail]

Author's Address

   Questions about this memo can also be directed to:

   John Woods
   Proteon, Inc.
   9 Technology Drive
   Westborough MA 01581-1799

   [phone] ext. 2651
   EMail: [e-mail]





























Woods                        Informational                     [Page 10]