计算机网络-RFC阅读笔记

PPP压缩控制协议(CCP）阅读笔记
PPP压缩控制协议（CCP）的由来
点到点协议（PPP）[1]提供了一种在点到点链路上传输多协议数据报的标准方法。

PPP包含以下三个成分：
1．压缩多协议自寻址数据包的方法。

2．用于建立、设定和测试数据链路连接的LCP。

3．一族用于建立、设定不同网络层协议的NCP。

为了在一条PPP链路上建立通信，链路的两端首先发送LCP（链路控制协议）包来配置和检测数据链路。

链路建起后，可选的功能中的一些值作为需要将被协商。

其中一种需要协商的功能就是数据的压缩算法，虽然在链路的每个方向只用到一种压缩算法，但是仍有众多的压缩算法可能被协商。

考虑到速度，消耗，存储容量和其他的一些原因，链路的每个方向可能采有不同的压缩算法，或者只有一个方向上的数据包被压缩。

压缩控制协议（CCP）[2]就提供了一种在PPP封装链路上协商和使用压缩协议的方法。

P的基本内容
压缩控制协议（CCP）负责在PPP链路上的两端配置并协商采用哪种压缩算法，并且用可靠的方式来标志压缩和解压缩机制的失败。

CCP采用和LCP相同的分组交换自动机。

直到PPP已经到达网络层协议的阶段，CCP包之间才交换。

在未达到这个阶段时所接收到
的CCP包将被静静地丢弃。

P特点
CCP与LCP基本相同，但在一下几点有所变化：
一．结构的变化
在链路建立阶段，数据包可能利用任何由于被协商而导致的基本结构的变化。

二．数据链路层协议域
确切的说每个CCP包被封装在PPP的信息域里，此时PPP协议域的内容为00FD（表明是CCP）。

当单个链路的数据压缩算法用在到达同一目的地多重链路上时，PPP协议域的内容为80FB（表明是单链路压缩控制协议）。

三．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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
在代码域，除了代码1到7外（Configue-Request，Configue-Ack，Configue-Nak,Configue-Reject，Terminate-Request，Terminate-Ack和Code-Reject),CCP中还定义了代码14和15（Reset-Request和Reset-Ack),其它（Protocol-Reject, Echo-Request, Echo-Reply, 和Discard-Request）被认为上是不可识别的代码则做Code-Reject处理。

下面解释下上述结构：
代码
代码域是一个八位字节，确定CCP包的种类。

当收到一个带有未知域的包时，一个Code-Reject包被传送。

标识符
标识符域是一个八位字节，对匹配请求和回复中有帮助。

当带有无效标识符域的包被接收时候，该包将不影响自动机制，被静静的丢弃。

长度
长度域是二个八位字节，指出LCP包的长度，包括代码，标识符，长度和数据域。

该长度必须不超过链路的MRU。

长度域以外的字节被当作填料而忽略处理。

当收到带有无效标识符该包将不影响自动机制，被静静的丢弃。

数据
数据域是零或多个八位字节，由长度域声明。

数据域的格式由代码域决定。

四．超时设定
直到PPP达到网络层协议阶段时，CCP包之间才交换。

在等待Configue-Ack或者其它应答之前，应当准备执行等待认证和链路可靠性结论完成的动作。

在用户干预或者一段可配置的时间的情况下，建议不要执行此动作。

五．配置
CCP有一组清晰的配置选项。

P的配置选项
CCP的配置选项允许协商压缩算法和其参数。

CCP采用LCP中定义的配置选项的格式，并包含一组独立的选项。

在CCP中，配置选项指定的算法是接收端希望接收到的，或者能够用来解压缩发送端送来的数据的算法。

因此希望系统能够提供一些可接受的算法，之后采用协商出的一种算法。

有可能没有协商出任何压缩算法，此时，不采用任何压缩算法，链路在没有压缩算法应用的情况下继续运作。

如果链路的可靠性单独被协商，则此链路可继续使用，直到LCP再次被协商。

我们期望那些想用自己开发的压缩算法的供应商，能够有一种可利用的机制---在用自己的算法编号时不影响Internet 所分配编号的情况下，协商他们的压缩算法。

在这里LCP 协商选项的方法要用到，如果某个选项不被识别，则发送Configue-Reject数据包，如果发送端执行的所有压缩协议都被接收端发送Configue-Reject数据抱而拒绝，则在链路的这个方向上不采用任何压缩算法。

如果一个选项被承认，但是由于其在请求中的值（或者可选的参数不在请求中）不被接受，此时，接收端将发送带有修改后认为合适的选项的Configue-Nak数据包。

Configue-Nak数据包必须包含可被接受的那些选项。

之后，一个新的Configue-Request数据包应当被发送，并带有一个可取的选项，此选项是在Configue-Nak数据包中指定的。

CCP选项类型域中最新的一些值请参考最近的"Assigned Numbers"RFC.下面列出了当前
的一些值：
CCP Option Compression type
0 OUI
1 Predictor type 1
2 Predictor type 2
3 Puddle Jumper
4-15 unassigned
16 Hewlett-Packard PPC
17 Stac Electronics LZS
18 Microsoft PPC
19 Gandalf FZA
20 V.42bis compression
21 BSD LZW Compress
255 Reserved
未利用的值4-15准备分配给不需要版权费用可免费得到的压缩算法。

参考文献
[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] Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", RFC
1548, December 1993.
[4] Reynolds, J., and Postel, J.; "Assigned Numbers", STD 2, RFC
1340, USC/Information Sciences Institute, July 1992.
[5] Rand, D., "PPP Reliable Transmission", work in progress.。