rfc2118.txt

很多RFC的中文文档

      当 MPPC 压缩协议成功地由 PPP 压缩控制协议协商后，这个值是十六进制的
	  00FD。这个值当协议域压缩选项被协商时可能会被压缩掉。

   Bit A

      这个比特位指明在这个包产生时历史纪录缓冲器被初始化。这个包总是可以被
	  解压缩的，因为它不依赖于任何以前的历史纪录。典型地，设置这个比特位来
	  通知对方，发送方在压缩这个包之前已经数市话了历史纪录缓冲器，接收方也
	  应在解压缩这个包之前初始化它的历史纪录缓冲器。这个比特位称为 FLUSHED
	  比特位。

      实现要点：压缩和解压缩历史纪录总是被初始化成全零。

   Bit B

      这个比特位指明本包被移到历史纪录缓冲器的开头，一般是因为历史纪录缓冲
	  器的尾部没有空间了。这个比特位用来告诉解压缩方设置它自己的历史纪录指
	  针指向历史纪录缓冲器的开头。

      实现要点：
      1. 这暗示了每压缩发送了8192字节数据，这个比特位至少必须被设置一次。
      2. 这也暗示了这个比特位可以在发送方的历史纪录缓冲器非空的情况设置。在
	     压缩包中禁止初始化没有用来压缩数据的历史纪录。



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


   Bit C

      这个比特位（如果被设置）用来指明本包是压缩的。

   Bit D

      这个比特位必须被设置为 0.

   连续计数

      连续计数用来保证包以正确顺序被发送，这样就不会有包被丢弃。这个计数
	  从 0 开始，每次加 1 ，从来不会减，也不会回环。当所有比特位都是 1 时，
	  计数返回到 0。

   压缩数据

      压缩数据从协议域开始，例如，一个 IP 包（0021后接着是 IP 头部），压缩
	  方将首先尝试压缩 0021 协议域然后再压缩 IP 头。

      假如这个包包含头部压缩，预先使用头部压缩，之后，再应用MPPC 压缩。例如，
	  假如包内包含协议类型值 002D ，表明使用 TCP/IP 头部压缩，必须首先压缩协
	  议类型值 002D ，然后压缩那个已经被 Van-Jacobsen 算法压缩过的 TCP/IP 头
	  部。

4. 压缩和编码描述

   压缩算法遍历生成的帧，输出明文（未压缩过的待发送字节）或者<Offset,
   Length-of-Match> 批拷贝，这里 Offset 是历史纪录中匹配位置字节数。
   Length-of-Match 是从 Offset 指明的地方拷贝的字节数。

   举例来说，下面的字符串:

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

   压缩算法将产生:

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



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


   明文和批拷贝记号然后再使用 MPPC 编码方法编码。

4.1 明文编码

   明文是未压缩过的待发送字节. 假如明文的值小于十六进制 80 ，就用本身值来
   编码。如果明文值大于十六进制 7F ，它被编码为两比特 10 ，接着是字节的低
   7 位比特。

   例如:    十六进制明文 56 编码为  01010110
            十六进制明文 E7 编码为 101100111

4.2 批拷贝编码

   批拷贝表示压缩数据。一个“批”有两个元素 Offset 和 Length-of-Match。
   偏移量 Offset 在 Length-of-Match 之前被编码。

4.2.1 偏移量 Offset 编码

   Offset 值小于 64 被编码为四比特 1111 后跟着值的低6位比特。

   Offset 值在 64 到 320 之间被编码为比特 1110 后跟着计算值（值 - 64）的
   低8位比特。

   Offset 值在 320 到 8191 之间被编码为比特 110 后跟着计算值（值 - 320）
   的低13位比特。

   例子:     偏移量值 3 编码为:     1111 000011
             偏移量值 128 编码为:   1110 01000000
             偏移量值 1024 编码为:   110 0001011000000

4.2.2 匹配长度 Length-of-Match 编码

   长度值 3 编码为比特 0。

   长度值从 4 到 7 编码为比特 10 后跟着值的低2位比特。

   长度值从 8 到 15 编码为比特 110 后跟着值的低3位比特。
   
   长度值从 16 到 31 编码为比特 1110 后跟着值的低4位比特。





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


   长度值从 32 到 63 编码为比特 11110 后跟着值的低5位比特。

   长度值从 64 到 127 编码为比特 111110 后跟着值的低6位比特。

   长度值从 128 到 255 编码为比特 1111110 后跟着值的低7位比特。

   长度值从 256 到 511 编码为比特 11111110 后跟着值的低8位比特。

   长度值从 512 到 1023 编码为比特 111111110 后跟着值的低9位比特。
   
   长度值从 1024 到 2047 编码为比特 1111111110 后跟着值的低10位比特。

   长度值从 2048 到 4095 编码为比特 11111111110 后跟着值的低11位比特。

   长度值从 4096 到 8191 编码为比特 111111111110 后跟着值的低12位比特。

   例子:     长度值 15 编码为:           110 111
             长度值 120 编码为:       111110 111000
             长度值 4097 编码为:111111111110 000000000001

   最大可编码长度值为8191。

4.3  同步

   包在传输过程中可能会丢失。如果解压缩方维护的连续计数不匹配接收到的压缩
   包的连续计数，解压缩方丢弃这个包，并发送 CCP 重置请求包。压缩方接收到
   这个包必须清空历史纪录缓冲器，并在下一个发送的包中设置 FLUSHED 比特位。
   解压缩方接收到这个带有 FLUSHED 比特的包清空历史纪录缓冲器，并把自己的
   连续计数改为接收到的压缩包的连续计数。这样，同步就完成了。不需要 CCP 
   重置响应包。

安全考虑

   本备忘录不讨论安全方面的内容。






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


参考文献

   [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.

致谢

   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.

主席地址

   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]

作者地址

   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]