RFC1962 PPP压缩控制协议 (CCP)

组织：中国互动出版网（http://www.china-pub.com/）
RFC文档中文翻译计划（http://www.china-pub.com/compters/emook/aboutemook.htm）
E-mail：mailto:ouyang@china-pub.com
译者：rainman（rainman  hyl@mail.ndsc.com.cn）
译文发布时间：2001-11-8
版权：本中文翻译文档版权归中国互动出版网所有。可以用于非商业用途自由转载，但必须
保留本文档的翻译及版权信息。




Network Working Group                                            D. Rand
Request for Comments: 1962                                        Novell
Category: Standards Track                                      June 1996
 

PPP压缩控制协议（CCP）
（RFC1962――The PPP Compression Control Protocol (CCP)）
 
摘要：
     点到点协议提供了一种在点到点的链路上传输多协议数据包的标准方法。另外
它还定义了一种可扩展的链路控制协议（LCP）。
     本文挡定义了一种在PPP链路上协商数据压缩算法的方法。
 
目录
1.简介	1
2.压缩控制协议（CCP）	2
2.1  发送压缩的数据包	3
3.附加的数据包	3
3.1 Reset-Request和Reset-Ack	4
4.CCP 的配置选项	5
4.1.Proprietary Compression OUI	6
4.2.其它的压缩类型	7
安全考虑	8
参考	8
 
1.简介

   为了在一条PPP链路上建立通信，链路的两端首先发送LCP包来配置和检测数据链路。
链路建起后，可选的功能中的一些值作为需要将被协商。
   其中一种需要协商的功能就是数据的压缩算法，虽然在链路的每个方向只用到一种压缩
算法，但是仍有众多的压缩算法可能被协商。
   考虑到速度，消耗，存储容量和其他的一些原因，链路的每个方向可能采有不同的压缩算
法，
或者只有一个方向上的数据包被压缩。

  2.压缩控制协议（CCP）
   
   压缩控制协议（CCP）负责在PPP链路上的两端配置并协商采用哪种压缩算法。并且用可
靠的方式
来标志压缩和解压缩机制的失败。
   CCP采用和LCP相同的分组交换自动机。直到PPP已经到达网络层协议的阶段，CCP包之
间才交换。
在未达到这个阶段时所接收到的CCP包将被静静地丢弃。
   CCP与LCP基本相同，除了以下几点：

   结构的变化
   
   在链路建立阶段，数据包可能利用任何由于被协商而导致的基本结构的变化。
  
   数据链路层协议域
  
   确切的说每个CCP包被封装在PPP的信息域里，此时PPP协议域的内容为00FD（表明是
CCP）。
   当单个链路的数据压缩算法用在到达同一目的地多重链路上时，PPP协议域的内容为80FB
（表明是
   单链路压缩控制协议）。

   
   代码域

   除了代码1到7外（Configue-Request，Configue-Ack，Configue-Nak,Configue-Reject，
Terminate-Request，Terminate-Ack和Code-Reject),CCP中还定义了代码14和15
（Reset-Request和Reset-Ack),其它被认为上是不可识别的代码则做Code-Reject处理。

   超时设定
  
   直到PPP达到网络层协议阶段时，CCP包之间才交换。在等待Configue-Ack或者其它应
答之前，应当准备执行
等待认证和链路可靠性结论完成的动作。在用户干预或者一段可配置的时间的情况下，建议
不要执行此动作。

   配置选项类型

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

2.1  发送压缩的数据包
   
    在任何压缩过的数据包被传送之前，PPP必须处在网络层协议阶段，且CCP必须处在开
始状态。一个或多个
被压缩的数据包被封状在PPP的信息域里，此时PPP协议域的内容为00FD（压缩的数据包）。
每个压缩算法可能采
用不同的机制来表明在一个数据链路层的桢中包含多了未压缩的数据包。
    当采用多重PPP链路到达同一目的地时，有两种利用数据压缩算法的方法。第一种方法
是在多条链路上发送包
之前压缩数据。第二种方法是把每条链路看作是单独，分离的连接，可能进行压缩，也可能
不进行压缩。在第二种
情况下，PPP协议域的内容为00FB（单链路上的压缩数据包）。
    在每个方向每次只能采用一种主要的算法，并且在发送第一个压缩的桢前进行协商。此
时压缩的数据包的协议
域将表明数据桢被压缩而不是它和算法一同被压缩。
    在PPP链路上传输压缩的数据包的最大长度与封装的PPP包的信息域的最大长度一样。
压缩后增大的数据包
（如果采用某种压缩算法后，由于一些原因导致信息的长度增加）将按标准的数据包格式，
不压缩进行发送，或者
如果压缩算法支持的话 ，可以分解成多个数据包进行发送。   
    每个压缩算法必须提供一种确定其传输数据是否可靠的方法，或者必须要求使用可靠的
传输机制，如LAPB。
非常鼓励供应商采用使压缩后的数据有效的方法，或者能够识别出异步的压缩和解压缩数据
包对。

3.附加的数据包
 
     数据包的格式和一些基本的功能已经在LCP中定义过了。

     CCP代码域中的一些最新的值请参考最近的“Assigned Numbers"RFC中。这里只涉及到
下面的取值：
  
      14       Reset-Request
      15       Reset-Ack
    
3.1 Reset-Request和Reset-Ack
    
     说明
  
     为了提供一种机制，来指示一条压缩链路上某个方向的解压缩失败，同时又不影响其它
方向上传输的数据，
CCP中包含了Reset-Request和Reset-Ack的定义。通过定期的传递一个随机值，对被解压
缩的数据执行CRC校验，或者
其它机制来确定是否发生了解压缩失败。在所有的压缩算法中，强烈推荐那些能够使被解压
缩的数据有效后，
再将其传递到系统中其它部分的机制。
     为了表明解压缩失败，CCP应传递一个代码域内容为14（Reset-Request)的CCP数据包,
数据域中包含需要
的数据。一旦Reset-Request数据包发送后，发送端将会丢弃任何接收到的压缩数据包，并
且在收到一个有效的
Reset-Ack数据包前，发送另外一个带有相同标识符的Reset-Request数据包。
     当接收到Reset-Request数据包后，正在传递的压缩数据包将被置为初始状态。这包括
清空可运行程序库，
重置HASH的值，或者采取其它的机制。之后，一个代码域内容为15的CCP数据包被传递，
其标识符域的内容从
Reset-Request的相应域拷贝而来，数据域中包含着需要的数据。
     当接收到Reset-Ack后，正被接收到的需被解压缩的数据包被置为初始状态。这包括清
空可运行程序库，
重置hash的值，或者采用其它的机制。因为每个管道有不止一个的Reset-Ack数据包，所以
要找到与当前指定的
标识符相匹配的Reset-Ack数据包相对应的要被解压缩的数据包，并将其重置为初始状态。
       
     Reset-Request和Reset-Ack数据包大致的格式如下所示，各域的内容从左到右传递。

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


   Code

      14 for Reset-Request;

      15 for Reset-Ack.


   标识符

      在传输时，标识符域的内容随着数据域内容的变化而变化，无论何时接收到的有效应
答都应与之前发送
的请求相对应。重传时，标识符保持不变。
      接收到Reset-Request数据包后，将其标识符域的内容拷贝到Reset-Ack数据包中的
相应域。
   

   数据
  
      数据域有零个或多个字节，可包含连续的数据供发送者使用。数据可能由二进制值组
成，其长度可能为
零到对方的MRU（最大接受单元）减4。

  
4.CCP 的配置选项
  
     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准备分配给不需要版权费用可免费得到的压缩算法。

4.1.Proprietary Compression OUI

  说明
  
      这个配置选项提供了一种协商使用私有压缩协议的方法。

      因为第一个匹配的压缩算法会被采用，所以，最好在普通的选项被采用之前，首先传
输任何可知的OUI
压缩选项。
      在接受这个选项之前，结构中唯一的标识符确定的私有压缩算法是否能够解压缩要得
到证实，并且
任何供应商指定的具体的协商值能被充分理解。
           
       Proprietary Compression OUI配置选项大致的格式如下所示，各域的内容从左到右
进行传输。
      
   
   
        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     |       OUI ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         OUI       |    Subtype    |  Values...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Type

      0

   Length

      >= 6
   
   IEEE OUI
 
      供应商所提供的结构中唯一的标识符，是由IEEE 802分配给供应商的以太网物理地址
最重要的三个字节。
它确定的选项是被指定的供应商私有的。每个字节中各位按规范的顺序排列，并且最重要的
字节最先被传送。

   Subtype

   这个域明确到每个OUI，并且为那个OUI指定了压缩类型。对这个域并没有进行标准化。
每个OUI执行它们
  自己的值。

   Values

   这个有零个或多个字节，并且包含供应商提供的压缩协议指定的附加数据。

4.2.其它的压缩类型
 
   说明

      这些配置选项提供一种协商使用公开已定义的压缩算法。并包含了许多的压缩算法。
没有什么特别的
    压缩技术作为Internet 的标准出现。
      感兴趣的有关人员可以得到这些协议，但会遇到相关协议的授权许可限制。想得到各
多的信息，请参考
    已定义的每个压缩类型的相关压缩协议文档。
  
      各压缩类型配置选项的大致格式如下所示。各域的内容从左到右进行传输。
 
    
      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     |  Values...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-


   Type

      1 to 254

   Length

      >= 2

   Values

      这个域有零个或多个字节，并且包含由此压缩协议指定的附加数据。
  
安全考虑

      安全问题不在此备注中讨论。
  
参考

   [1]   Simpson, W., Editor; "The Point-to-Point Protocol (PPP)", RFC
         1548, December 1993.

   [2]   Reynolds, J., and Postel, J.; "Assigned Numbers", STD 2, RFC
         1340, USC/Information Sciences Institute, July 1992.

   [3]   Rand, D., "PPP Reliable Transmission", work in progress.





   

   
   
   
   
RFC1962――The PPP Compression Control Protocol (CCP)                    PPP压缩控制协议（CCP）


3
RFC文档中文翻译计划