rfc2118.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

      ALWAYS be decompressed because it is not based on any previous
      history. This bit is typically sent to inform the peer that the
      sender has initialized its history buffer before compressing the
      packet and that the receiving peer must initialize its history
      buffer before decompressing the packet. This bit is referred to as
      FLUSHED bit in this document.

      Implementation Note: Compression and decompression histories are
      always initialized with all zeroes.

   Bit B

      This bit indicates that the packet was moved to the front of the
      history buffer typically because there was no room at the end of
      the history buffer.  This bit is used to tell the decompressor to
      set its history pointer to the beginning of the history buffer.

      Implementation Notes:
      1. It is implied that this bit must be set at least once for every
         8192 bytes of data that is sent compressed.
      2. It is also implied that this bit can be set even if the
         sender's history buffer is not full. Initialized history that
         has not been used for compressing data must not be referred to
         in the compressed packets.



Pall                         Informational                      [Page 5]

RFC 2118                     MPPC Protocol                    March 1997


   Bit C

      This bit (if set) is used to indicate that the packet is
      compressed.

   Bit D

      This bit must be set to 0.

   Coherency Count

      The coherency count is used to assure that the packets are sent in
      proper order and that no packet has been dropped.  This count
      starts at 0 and is always increased by 1 and NEVER decreases or
      goes back. When all bits are 1, the count returns to 0.

   Compressed Data

      The compressed data begins with the protocol field.  For example,
      in case of an IP packet (0021 followed by an IP header), the
      compressor will first try to compress the 0021 protocol field and
      then compress the IP header.

      If the packet contains header compression, the MPPC compressor is
      applied AFTER header compression is preformed and MUST be applied
      to the compressed header as well.  For example, if a packet
      contained the protocol 002d for a compressed TCP/IP header, the
      compressor would first attempt to compress 002d and then it
      would attempt to compress the compressed Van-Jacobsen TCP/IP
      header.

4. Description of Compressor and Encoding

   The compressor runs through the length of the frame producing as
   output a Literal (byte to be sent uncompressed) or a <Offset,
   Length-of-Match> Copy tuple, where Offset is the number of bytes
   before in the history where the match lies and Length-of-Match is the
   number of bytes to copy from the location indicated by Offset.

   For example, comsider the following string:

   0         1         2         3         4
   012345678901234567890123456789012345678901234567890
   for whom the bell tolls, the bell tolls for thee.

   The compressor would produce:

   for whom the bell tolls,<16,15> <40,4><19,3>e.



Pall                         Informational                      [Page 6]

RFC 2118                     MPPC Protocol                    March 1997


   The Literal and Copy tuple tokens are then encoded according to the
   MPPC encoding scheme.

4.1 Literal Encoding

   Literals are bytes sent uncompressed. If the value of the Literal is
   below hex 80, it is encoded with its value itself. If the Literal has
   value greater than hex 7F it is sent as bits 10 followed by the lower
   7 bits of the Literal.

   Example: Literal hex 56 is transmitted as  01010110
            Literal hex E7 is transmitted as 101100111

4.2 Copy Tuple Encoding

   Copy tuples represent compressed data. A tuple has two elements: the
   Offset and Length-of-Match. The Offset is encoded before the Length-
   of-Match.

4.2.1 Offset Encoding

   Offset values less than 64 are encoded as bits 1111 followed by the
   lower 6 bits of the value.

   Offset values between 64 and 320 are encoded as bits 1110 followed by
   the lower 8 bits of the computation (value - 64).

   Offset values between 320 and 8191 are encoded as bits 110 followed
   by the lower 13 bits of the computation (value - 320).

   Examples: Offset value of 3 is encoded as:     1111 000011
             Offset value of 128 is encoded as:   1110 01000000
             Offset value of 1024 is encoded as:   110 0001011000000

4.2.2 Length-of-Match Encoding

   Length of 3 is encoded with bit 0.

   Length values from 4 to 7 are encoded as 10 followed by lower 2 bits
   of the value.

   Length values from 8 to 15 are encoded as 110 followed by lower 3
   bits of the value.

   Length values from 16 to 31 are encoded as 1110 followed by lower 4
   bits of the value.





Pall                         Informational                      [Page 7]

RFC 2118                     MPPC Protocol                    March 1997


   Length values from 32 to 63 are encoded as 11110 followed by lower 5
   bits of the value.

   Length values from 64 to 127 are encoded as 111110 followed by lower
   6 bits of the value.

   Length values from 128 to 255 are encoded as 1111110 followed by
   lower 7 bits of the value.

   Length values from 256 to 511 are encoded as 11111110 followed by
   lower 8 bits of the value.

   Length values from 512 to 1023 are encoded as 111111110 followed by
   lower 9 bits of the value.

   Length values from 1024 to 2047 are encoded as 1111111110 followed by
   lower 10 bits of the value.

   Length values from 2048 to 4095 are encoded as 11111111110 followed
   by lower 11 bits of the value.

   Length values from 4096 to 8191 are encoded as 111111111110 followed
   by lower 12 bits of the value.

   Examples: Length of 15 is encoded as:           110 111
             Length of 120 is encoded as:       111110 111000
             Length of 4097 is encoded as:111111111110 000000000001

   The largest Length value that can be encoded is 8191.

4.3  Synchronization

   Packets may be lost during transfer. If the decompressor maintained
   coherency count does not match the coherency count received in the
   compressed packet, the decompressor drops the packet and sends a CCP
   Reset-Request packet. The compressor on receiving this packet flushes
   the history buffer and sets the FLUSHED bit in the next packet it
   sends. The decompressor on receiving a packet with its FLUSHED bit
   set flushes its history buffer and sets its coherency count to the
   one transmitted by the compressor in that packet. Thus
   synchronization is achieved without a CCP Reset-Ack packet.

Security Considerations

   Security issues are not discussed in this memo.






Pall                         Informational                      [Page 8]

RFC 2118                     MPPC Protocol                    March 1997


References

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

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

   [3]   Lempel, A. and Ziv, J., "A Universal Algorithm for Sequential
         Data Compression", IEEE Transactions On Information Theory,
         Vol. IT-23, No. 3, May 1977.

   [4]   Rand, D., "PPP Reliable Transmission", RFC 1663, Novell, July
         1994.

Acknowledgments

   Thomas Dimitri made significant contributions towards the design and
   development of Microsoft Point-To-Point Compression Protocol. Robert
   Friend of Stac Technology provided editoral input.

Chair's Address

   The working group can be contacted via the current chair:

         Karl F. Fox
         Ascend Communications
         3518 Riverside Dr., Suite 101
         Columbus, Ohio  43221

         [phone]

         EMail: [e-mail]

Author's Address

   Questions about this memo can also be directed to:

         Gurdeep Singh Pall
         1, Microsoft Way,
         Redmond, WA 98052

         [phone]

         Email: [e-mail]






Pall                         Informational                      [Page 9]