本备忘录的状态
本备忘录为因特网社区提供信息。本备忘录没有列入任何因特网标准。本备忘录
的分发不受限制。
摘要
点对点协议（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
PallInformational[Page1]
RFC2118MPPCProtocolMarch1997
1.介绍
微软点对点压缩方案可以把任何PPP包表示为压缩形式的方法。MPPC算法设计
为通过优化处理器和带宽的利用，来支持大量并发连接。MPPC算法也用来优化
典型的特定PPP，提高工作效率（例如1500字节的MTU等）。
MPPC算法使用一种带有滑动窗口的历史纪录缓冲器的LZ[3]算法。
MPPC算法保持一个连续的历史纪录，当压缩传输了8192字节数据之后，就总是
有8192字节历史纪录被用来做压缩，除非历史纪录被清空。
1.1.许可
MPPC仅用于实现PPP协议的产品，并且只能和其他的带有MPPC实现的PPP
协议互操作。
Sourceandobjectlicensesareavailableonanon-discriminatory
basisfromStacElectronics.Pleasecontact:
CherylPoland
StacElectronics
12636HighBluffDrive,
SanDeigo,CA92130
Phone:(619)794-4534
Email:cherylp@stac.com
1.2.术语要求
在本文中，一些词被用来表示特定含义，这些词总是大写的。
MUST这个要害字，或是术语"REQUIRED"或"SHALL"，意味着他们的定义是
一个绝对的规范的必要条件。
MUSTNOT这个词组，意味着他们的定义是一个绝对的规范的禁止的条件。
PallInformational[Page2]
RFC2118MPPCProtocolMarch1997
SHOULD这个要害字，或是形容词"RECOMENDED"，意味着在非凡的环境下可
能存在正当的理由忽略一个非凡的项目，但是完整的含义必须能被理
解并且在重新选择一条不同的路径之前要仔细的考虑。
MAY这个要害字，或是形容词"OPTIONAL"，意味着一个项目是真正可选的。
一个买主可以选择包含项目因为一个非凡的市场要求或是因为买主觉
得它能够增强产品当另一个买主可能遗漏了同样的项目时。一个没有
包含一个非凡对象MUST的工具预备用来与另一个不包含这个对象的工
具间相互起作用，因此或许有简化的功能。在同样的脉络里一个包含
了非凡对象MUST的工具预备用来和另一个没有包含这个对象的工具间
相互作用。
2.配置选项格式
描述
CCP配置选项在链路上协商MPPC。缺省的或者最终协商未果，就不使用压缩。
CCP配置选项格式如下所示。这些域从左到右传输。
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TypeLengthSupportedBits
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SupportedBits
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
18
Length
6
SupportedBits
这个域是4个八位组，重要的八位组在前。在最不重要的八位组中的最不重要
的比特设置为为1表示需要协商MPPC。
所有其他的比特必须设置为0。
PallInformational[Page3]
RFC2118MPPCProtocolMarch1997
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可能在可靠的链路上使用。如"PPPReliableTransmision"[5]描述那样，
但这只是象征性地增加了不必要的冗余，因为不再需要连续计数。
数据膨胀
假如压缩数据的结果反而导致数据膨胀了，原始的数据将被作为未压缩的MPPC包
发送。发送方必须在压缩任何数据之前清空历史纪录，并且在下一个外发包设置
FLUSHED比特位。
PallInformational[Page4]
RFC2118MPPCProtocolMarch1997
3.1.包格式
0123
01234567890123456789012345678901
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PPPProtocolABCDCoherencyCount
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CompressedData...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
PPPProtocol
在PPP协议封装中[1]，PPP协议域是需要的。
当MPPC压缩协议成功地由PPP压缩控制协议协商后，这个值是十六进制的
00FD。这个值当协议域压缩选项被协商时可能会被压缩掉。
BitA
这个比特位指明在这个包产生时历史纪录缓冲器被初始化。这个包总是可以被
解压缩的，因为它不依靠于任何以前的历史纪录。典型地，设置这个比特位来
通知对方，发送方在压缩这个包之前已经数市话了历史纪录缓冲器，接收方也
应在解压缩这个包之前初始化它的历史纪录缓冲器。这个比特位称为FLUSHED
比特位。
实现要点：压缩和解压缩历史纪录总是被初始化成全零。
BitB
这个比特位指明本包被移到历史纪录缓冲器的开头，一般是因为历史纪录缓冲
器的尾部没有空间了。这个比特位用来告诉解压缩方设置它自己的历史纪录指
针指向历史纪录缓冲器的开头。
实现要点：
1.这暗示了每压缩发送了8192字节数据，这个比特位至少必须被设置一次。
2.这也暗示了这个比特位可以在发送方的历史纪录缓冲器非空的情况设置。在
压缩包中禁止初始化没有用来压缩数据的历史纪录。
PallInformational[Page5]
RFC2118MPPCProtocolMarch1997
BitC
这个比特位（假如被设置）用来指明本包是压缩的。
BitD
这个比特位必须被设置为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指明的地方拷贝的字节数。
举例来说，下面的字符串:
01234
012345678901234567890123456789012345678901234567890
forwhomthebelltolls,thebelltollsforthee.
压缩算法将产生:
forwhomthebelltolls,<16,15><40,4><19,3>e.
PallInformational[Page6]
RFC2118MPPCProtocolMarch1997
明文和批拷贝记号然后再使用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编码为:1111000011
偏移量值128编码为:111001000000
偏移量值1024编码为:1100001011000000
4.2.2匹配长度Length-of-Match编码
长度值3编码为比特0。
长度值从4到7编码为比特10后跟着值的低2位比特。
长度值从8到15编码为比特110后跟着值的低3位比特。
长度值从16到31编码为比特1110后跟着值的低4位比特。
PallInformational[Page7]
RFC2118MPPCProtocolMarch1997
长度值从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编码为:110111
长度值120编码为:111110111000
长度值4097编码为:111111111110000000000001
最大可编码长度值为8191。
4.3同步
包在传输过程中可能会丢失。假如解压缩方维护的连续计数不匹配接收到的压缩
包的连续计数，解压缩方丢弃这个包，并发送CCP重置请求包。压缩方接收到
这个包必须清空历史纪录缓冲器，并在下一个发送的包中设置FLUSHED比特位。
解压缩方接收到这个带有FLUSHED比特的包清空历史纪录缓冲器，并把自己的
连续计数改为接收到的压缩包的连续计数。这样，同步就完成了。不需要CCP
重置响应包。
安全考虑
本备忘录不讨论安全方面的内容。
PallInformational[Page8]
RFC2118MPPCProtocolMarch1997
参考文献
[1]Simpson,W.,Editor,"ThePoint-to-PointProtocol(PPP)",STD
51,RFC1661,Daydreamer,July1994.
[2]Rand,D.,"ThePPPCompressionControlProtocol(CCP)",RFC
1962,Novell,June1996.
[3]Lempel,A.andZiv,J.,"AUniversalAlgorithmforSequential
DataCompression",IEEETransactionsOnInformationTheory,
Vol.IT-23,No.3,May1977.
[4]Rand,D.,"PPPReliableTransmission",RFC1663,Novell,July
1994.
致谢
ThomasDimitrimadesignificantcontributionstowardsthedesignand
developmentofMicrosoFTPoint-To-PointCompressionProtocol.Robert
FriendofStacTechnologyprovidededitoralinput.
主席地址
Theworkinggroupcanbecontactedviathecurrentchair:
KarlF.Fox
AscendCommunications
3518RiversideDr.,Suite101
Columbus,Ohio43221
(614)451-1883
EMail:karl@ascend.Com
作者地址
Questionsaboutthismemocanalsobedirectedto:
GurdeepSinghPall
1,MicrosoftWay,
Redmond,WA98052
(206)882-8080
Email:gurdeep@microsoft.com
