云南龙网

  1. 首页 > 云知道 > >

IPComp IP有效载荷压缩协议( 二 )

云知道


2.2.非扩展策略
假如已压缩的上层协议数据和IPComp头的总长度，第3节定义的，不小于原来上层协议数据的长度，IP数据报必须以不压缩的格式发出 。需要阐明：假如IP数据报没有压缩就发出，不会添加IPComp头 。这个策略确保节省解压缩过程的循环，避免扩展数据报大于MTU时，IP数据报分片 。
小的IP数据报有可能压缩之后却扩大，所以，压缩之前应该定义一个最小的数值极限 。假如IP数据报小于这个值，不压缩而以原始格式发出该数据报 。最小数值极限的定义与实现有关 。
一个数据报的有效载荷已经压缩过，往往不再进一步压缩 。先前已压缩的有效载荷可能是外部处理的结果，例如在通信栈高层应用的压缩，或者由离线压缩工具进行的压缩 。应该实现一种适应性的算法避免性能受到影响 。例如，假如一个IPCA上I个连续IP数据报压缩失败，下面k个IP数据报将不尝试压缩而被发送出去 。假如再下面j个数据报压缩又失败了，那么后面k n个数据报将不尝试压缩直接发送 。一旦一个数据报成功压缩，IPComp正常处理重新开始 。这样的适应性算法，包括所有相关的最低限度，与实现有关 。
有效载荷处理期间，压缩算法可能定期进行测试，确定被处理数据的可压缩性，类似与[V42BIS]的要求 。测试的特性和算法相关 。一旦压缩算法检测到数据不可压缩，算法应该停止处理数据，有效载荷以原始、不压缩格式传递 。
3.已压缩的IP数据报头结构
一个已压缩的IP数据报通过修改IP头，在被压缩的有效载荷之前插入IPComp头，来封装它 。本节定义IPv4和IPv6中IP头修改的字段和IPComp头结构 。
3.1.IPv4头修改字段
下面IPv4头字段在传输已压缩的IP数据报之前设置：
TotalLength总长度
整个被封装的IP数据报长度，包括IP头、IPComp头和已压缩的有效载荷 。
Protocol协议
设置为108，表示IPComp数据报 。[RFC-1700]
HeaderChecksum首部校验和
IP头的内部头校验和 。[RFC-0791]
所有其它IPv4头字段保持不变，包括所有头中的选项 。
3.2.IPv6头修改
下列IPv6头字段在传输压缩IP数据报之前设置 。
PayloadLength载荷长度
压缩IP载荷长度
NextHeader下一个头
该字段设置为108，表示IPComp数据报[RFC-1700]
所有其他的IPv6头字段保持不变，包括任何没有压缩的头选项 。
IPComp头放置在IPv6数据报中采用与IPv6Fragment头一样的规则 。然而，假如IPv6数据报同时包含IPv6Fragment头和IPComp头，IPv6Fragment头必须在IPComp头之前 。
3.3.IPComp头结构
4字节的头结构如下：
0123
01234567890123456789012345678901
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NextHeaderFlagsCompressionParameterIndex
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NextHeader下一个头
8位选择子 。存储原始IP头中的IPv4协议字段或者IPv6NextHeader字段 。
Flags标志
8位字段，保留给将来使用 。必须设置为0，接收节点必须忽略它 。
CompressionParameterIndex(CPI)压缩参数索引
16位索引 。按网络字节序存储 。0-63定义了有名的压缩算法，这些算法不要求额外信息，用于手工设置 。这些值本身与[SECDOI]定义的OMP转换标识符相同 。参考[SECDOI]获取一组初始已定义的值，得到如何分配新值的指示 。64-255保留给将来使用 。256-61439在两个节点之间定义一个IPCA时协商 。注重：当协商有名的算法之一时，节点可能选择预定义的0-63之间的值作为CPI 。61440-65535主要是互相同意的各方私下使用 。两个参与的节点可以选择一个CPI值，彼此独立，两个选择的CPI之间没有关系 。出站IPComp头必须使用由解压缩节点选择的CPI值 。CPI和目的IP地址一起，唯一地标识数据报压缩算法的特征 。

推荐阅读


上一篇：如何清洗运动鞋的鞋垫和里面

下一篇：琦玉和龙卷是什么关系