组织：中国互动出版网
（http://www.china-pub.com）
RFC文档中文翻译计划
（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：ouyang@china-pub.com
译者：方桂成（fangguicheng fangguicheng@21cn.com）
广东视聆通应用研究开发中心（http://www.shiningsoft.com）
译文发布时间：2002-01-09
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载
，但必须保留本文档的翻译及版权信息。
Network Working Group G. Pall
Request for Comments: 2118 Microsoft Corporation
Category: Informational March 1997
微软点对点压缩（MPPC）协议
本备忘录的状态
本备忘录为因特网社区提供信息。本备忘录没有列入任何因特网标准。本备忘录
的分发不受限制。
摘要
点对点协议（PPP） [1] 为在点对点链路上传输多种协议数据报提供了一个标准
的方法。
PPP 压缩控制协议 [2] 为在 PPP 封装的链路上协商和利用压缩控制协议提供了
一种方法。
本文档描述了微软点对点压缩协议（以下简称MPPC）在压缩 PPP 封装包上的用法。
目录
1. 介绍 .................................................. 2
1.1 许可 ............................................ 2
1.2. 术语要求 ........................................ 2
2. 配置选项格式 .......................................... 3
3. MPPC 包 ............................................... 4
3.1 包格式 .......................................... 5
4. 压缩和编码描述 ............................................ 6
4.1 明文编码 ........................................ 7
4.2 批拷贝编码 ...................................... 7
4.2.1 偏移量编码 .................................. 7
4.2.2 匹配长度编码 ................................ 7
4.3 同步 ............................................ 8
安全考虑 ..................................................... 8
参考文献 ..................................................... 9
致谢 ......................................................... 9
主席地址 ..................................................... 9
作者地址 ..................................................... 9
Pall Informational [Page 1]
RFC 2118 MPPC Protocol March 1997
1. 介绍
微软点对点压缩方案可以把任何PPP包表示为压缩形式的方法。MPPC 算法设计
为通过优化处理器和带宽的利用，来支持大量并发连接。MPPC 算法也用来优化
典型的特定 PPP ，提高工作效率（例如1500字节的MTU等）。
MPPC 算法使用一种带有滑动窗口的历史纪录缓冲器的 LZ [3] 算法。
MPPC 算法保持一个连续的历史纪录，当压缩传输了8192字节数据之后，就总是
有8192字节历史纪录被用来做压缩，除非历史纪录被清空。
1.1. 许可
MPPC 仅用于实现 PPP 协议的产品，并且只能和其他的带有 MPPC 实现的 PPP
协议互操作。
Source and object licenses are available on a non-discriminatory
basis from Stac Electronics. Please contact:
Cheryl Poland
Stac Electronics
12636 High Bluff Drive,
San Deigo, CA 92130
Phone: (619)794-4534
Email: cherylp@stac.com
1.2. 术语要求
在本文中，一些词被用来表示特定含义，这些词总是大写的。
MUST 这个关键字，或是术语"REQUIRED"或"SHALL"，意味着他们的定义是
一个绝对的规范的必要条件。
MUST NOT 这个词组，意味着他们的定义是一个绝对的规范的禁止的条件。
Pall Informational [Page 2]
RFC 2118 MPPC Protocol March 1997
SHOULD 这个关键字，或是形容词"RECOMENDED"，意味着在特殊的环境下可
能存在正当的理由忽略一个特殊的项目，但是完整的含义必须能被理
解并且在重新选择一条不同的路径之前要仔细的考虑。
MAY 这个关键字，或是形容词"OPTIONAL"，意味着一个项目是真正可选的。
一个买主可以选择包含项目因为一个特殊的市场要求或是因为买主觉
得它能够增强产品当另一个买主可能遗漏了同样的项目时。一个没有
包含一个特殊对象MUST的工具准备用来与另一个不包含这个对象的工
具间相互起作用，因此或许有简化的功能。在同样的脉络里一个包含
了特殊对象MUST的工具准备用来和另一个没有包含这个对象的工具间
相互作用。
2. 配置选项格式
描述
CCP 配置选项在链路上协商 MPPC。缺省的或者最终协商未果，就不使用压缩。
CCP 配置选项格式如下所示。这些域从左到右传输。
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 | Supported Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
18
Length
6
Supported Bits
这个域是4个八位组，重要的八位组在前。在最不重要的八位组中的最不重要
的比特设置为为1表示需要协商 MPPC。
所有其他的比特必须设置为 0。
Pall Informational [Page 3]
RFC 2118 MPPC Protocol March 1997
3. MPPC 包
PPP 必须到达网络层协议阶段，并且 CCP 控制协议必须到达打开状态。一个 MPPC
包才可能被用于通信。
确切地说，一个 MPPC 数据报封装在 PPP 信息域中。PPP 协议域指明十六进制协议
类型 00FD 。
MPPC 数据报在 PPP 链路上传输的最大长度与 PPP 信息域所能够封装的包的最大值
是一样的。由于历史纪录缓冲器限制为8192字节，这个长度不能大于8192字节。
只有 PPP 协议类型值在十六进制 0021 到十六进制 00FA 的包才被压缩。其他的包
不使用 MPPC 处理，并且以原来的 PPP 协议类似值发送。
填料
推荐 MPPC 不使用填料，因为这样一来达不到压缩的目的。假如发送者必须使用
填料，它必须在 LCP 阶段协商 Self-Describing-Padding 配置选项然后使用自
描述的填料。
可靠性和次序
MPPC 方案不需要可靠链路。然而，它依赖于在每个包中的12比特连续计数器来保
持历史纪录缓冲器的同步。假如接收方辨别出在接收到的包中的连续计数不符合预
期计数，它就发送一个 CCP 重置请求包来使它的历史纪录缓冲器和发送方的历史
纪录缓冲器同步。
MPPC 期望数据包是顺序地提交的，这样，历史纪录缓冲器就不会重新同步。
MPPC 可能在可靠的链路上使用。如 "PPP Reliable Transmision" [5] 描述那样，
但这只是象征性地增加了不必要的冗余，因为不再需要连续计数。
数据膨胀
假如压缩数据的结果反而导致数据膨胀了，原始的数据将被作为未压缩的 MPPC 包
发送。发送方必须在压缩任何数据之前清空历史纪录，并且在下一个外发包设置
FLUSHED 比特位。
Pall Informational [Page 4]
RFC 2118 MPPC Protocol March 1997
3.1. 包格式
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 |A|B|C|D| Coherency Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Compressed Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PPP Protocol
在 PPP 协议封装中[1]，PPP 协议域是需要的。
当 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 指明的地方拷贝的字节数。
举例来说，下面的字符串:
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
(614) 451-1883
EMail: karl@ascend.Com
作者地址
Questions about this memo can also be directed to:
Gurdeep Singh Pall
1, Microsoft Way,
Redmond, WA 98052
(206) 882-8080
Email: gurdeep@microsoft.com
Pall Informational [Page 9]
京公网安备 11010502044972号