Header Compression<?XML:NAMESPACE PREFIX = O />

Case Study:Overview

header compression通过压缩packet和segment的headers来减少消耗.

header compression对于低速链路上的交互式或对延迟敏感的数据很有效.

 

主要有两种header compression:

tcp header compression压缩IP和TCP headers

rtp header compression压缩IP,UDP和RTP headers

 

 

Case Study:Header Compression Basics

1>header compression是通过去除header中的静态和可预料的信息.

2>header compression中使用会话索引

3>只有header中的变化的参数被发送

4>header compression必须在链路双方同时启用

5>ip和高层header都被压缩

5>payload不被改变

 

 

 

Case Study:Header Compression Algorithms

TCP Header Compression(RFC1144)

1>用于减少TCP segment的消耗

2>对于承载许多小负载TCP会话的低速链路非常有效.

(负载小,TCP会话多,低速链路)

 

RTP header compression(RFC 1889)

1>用于减少Real Time Transport Protocol(RTP)的延迟及吞吐量

2>增加语音质量

3>在低速链路上非常有效

 

 

 

Case Study:TCP Header Compression

1>大部分的internet上的应用都是TCP流量

2>大部分的IP和TCP头部信息在整个会话中都是静态的或是可预测的

3>IP(20 bytes)和TCP(20 bytes) headers共占:40 bytes

4>TCP Header compression可以将这两个头压缩至3~5 bytes

 

 

TCP Header Compression Example:

1>link bandwidth=64 kbps

2>链路用来传输大量的交互式TCP会话流

3>使用PPP封装

4>平均packet大小为5 bytes

5>每个segment有46 bytes的消耗(ppp,ip及tcp headers)

压缩前:

Overhead = 46/(46+5)

Overhead = 90%

Delay = (46+5)/64 kbps

Delay = 6 ms

 

压缩后:

Overhead = 10/(10+5)

Overhead = 67%

Delay = (10+5)/64 kbps

Delay = 2 ms
TCP Header Compression Configuration:

router(config-if)#ip tcp header-compression [passive]

在ppp或hdlc封装的接口上启用TCP header compression

使用passive参数,则只在接收到对端tcp header compression才会开启本地的tcp header compression

 

router(config-if)#frame-relay ip tcp header-compression [passive]

在frame relay封装的接口上启用tcp header compression

使用passive参数,则只在接收到对端tcp header compression才会开启本地的tcp header compression

 

show ip tcp header-compression [interface] 显示tcp header compression统计信息

show frame-relay ip tcp header-compression [interface]

显示frame relay (子)接口的统计信息

 

Case Study:RTP Header Compression

1>语音会话都使用Real-Time Transport Protocol(RTP)

2>RTP使用UDP传输

3>headers(IP,UDP及RTP)中的大部分信息在整个会话中都是静态的

4>IP(20 bytes),UDP(8 bytes),RTP(12 bytes) 共占:40 bytes

5>RTP header compression可以压缩上述三个headers到3~5 bytes

 

RTP Header Compression Example:

1>link bandwidth=64 kbps

2>link用于VOIP

3>使用PPP封装

4>G.729 codec被使用(8 kbps的语音数据,50秒一次实例,每个实例20 bytes)

5>每个segment有46 bytes的消耗(PPP,IP,UDP,RTP headers)
压缩前:

Overhead = 46/(46+20)=70%

Delay = (46+20)/64 kbps=8 ms

BW = (46+20)*50*8=26 kbps

--------------------------

 2 voice session/64 kbps

 

压缩后:

Overhead = 10/(10+20)=33%

Delay = (10+20)/64 kbps=4 ms

BW = (10+20)*50*8=12 kbps

--------------------------

 5 voice session/64 kbps
RTP Header Compression Configuration:

router(config-if)#ip rtp header-compression [passive]

在ppp或hdlc封装的接口上启用RTP header compression

使用passive参数,则只在接收到对端rtp header compression才会开启本地的rtp header compression

 

router(config-if)#frame-relay ip rtp header-compression [passive]

在frame relay封装的接口上启用rtp header compression

使用passive参数,则只在接收到对端rtp header compression才会开启本地的rtp header compression

 

show ip rtp header-compression [interface]

显示RTP header compression的统计信息

show frame-relay ip rtp header-compression [interface] 

显示frame relay(子)接口上的RTP header compression的统计信息

 

payload compression:

 

Case Study:Overview

对于当然对带宽的大量的需求,qos不能创建bandwidth,payload compression通过压缩第二层帧的负载可以变向的实现bandwidth的增加。

compression是一个cpu-intensive的工作，它增加了IP包的经过设备的延迟。

 

Case Study:Compression Building Blocks
Case Study:Compression Results

Compression增加了吞吐量,也有可能会增加延迟.

 

 

Case Study:Compression Algorithms

1>stacker or STAC(STAC Electronics,or Hi/fn,Inc.)

2>MPPC(Microsoft Point-to-Point Compression)

3>predictor(public domain algorithm)

这些算法在压缩性能和CPU/MEMORY的消耗上都是不同的。

 

 

Stacker and MPPC Compression:

1>stacker使用Lempel-Ziv(LZ)算法，这个算法查找冗余字符并用一个短的代替，进而实现压缩。

LZ算法建立一个dictionary，用于对应不同的替代字符映射。

2>mppc由Microsoft开发，它也使用LZ算法。

 

Stacker/MPPC vs. Predictor:

Stacker and MPPC是CPU-intensive的：

1>它有一个好的平均压缩率

2>速度慢

3>产生许多延迟

4>不应该配置与低速链路上

5>stacker有更高的可调性,可定制性

 

 

Predictor需要更多的memory:

1>不如stacker和MPPC效率高

2>速度快,占用CPU时间少

3>产生少许延迟

4>可以被应用于高速链路上

 

Compression and Layer2 Encapsulation:
 
硬件压缩模块也支持使用Stacker算法的PPP及Frame Relay

 

 

Case Study:performance

compression性能依赖于以下因素:

1>router platform(cpu power)

2>compression algorithm(Stacker,MPPC,or Predictor)

3>hardware compression support

 

 

Case Study:Stacker with PPP encapsulation configuration

router(config-if)#compress stac

router(config-if)#compress stac distributed

将压缩任务分给接口卡上的每个vip(通用接口处理器)来处理,即分布式,类似于CEF

支持VIP2-40或更新的

router(config-if)#compress stac ratio {high | low | medium}

可以实现吞吐量与延迟的一个平衡,因为压缩比越高,延迟越大

默认为low

 

 

Case Study:Stacker with Frame Relay encapsulation configuration:

router(config-if)#frame-relay payload-compression FRF9 stac

router(config-if)#frame-relay payload-compression FRF9 stac distributed

将压缩任务分给接口卡上的每个vip(通用接口处理器)来处理,即分布式,类似于CEF

支持VIP2-40或更新的

router(config-if)#frame-relay payload-compression FRF9 stac ratio {high | low}

可以实现吞吐量与延迟的一个平衡,因为压缩比越高,延迟越大

默认为low

 

 

Case Study:MPPC or Predictor configuration

因为它们没有微调的能力,即没有可定制性,所以它们配置相对比较简单

router(config-if)#compress mppc [ignore-pfc]

使用ignore-pfc参数用来忽略协议号的协商

router(config-if)#compress predictor

配置使用predictor compression

 

 

Case Study:Hardware Compression

可以使用以下模块实现硬件压缩:

1>Compression Advanced Interface Module(CAIM):Cisco 2600系列路由的子模块卡

2>Compression service adapter(CSA) module:Cisco 7x00系列路由的模块

3>Compression Network Module(NM-COMPR):Cisco 3620/3640系列路由模块

4>AIM-COMPR4:Cisco 3660系列路由的压缩子模块卡

 

Case Study:Compression Configuration Example

!

interface s1/0

 encapsulation ppp

 compress stac

使用stacker算法配置软件压缩

!

interface s1/1

 encapsulation ppp

 compress stac caim 0

使用Stacker算法在Cisco 2600路由器的CAIM模块上实现硬件压缩

!

interface s1/2

 encapsulation ppp

 compress predictor

使用predictor算法配置软件压缩

!

interface s1/2

 encapsulation frame-relay

 frame-relay map ip 1.1.1.1 102 broadcast ietf payload-compress frf9 stac

!

interface s1/2.1 point-to-point

 frame-relay interface-dlci 101 ietf

 frame-relay payload-comp frf9 stac

!

使用stacker算法配置FR软件压缩

注意:子接口与一般接口的配置区别

 

show compression  查看压缩统计信息