了解压缩(包括RTP)和服务质量
前言
此 关于启用压缩和服务质量（QoS）® Cisco IOS软件功 能的本文探讨了已知问题在同一个路由器。
Cisco IOS软件提供优化方便的广域网的许多功能(广 域网)链路广域网带宽瓶颈。 压缩是一个有效最优化方法并 且包括二个类型：
-
数据压缩 - 提供每个末端以允许字符从帧被删除 在链路的发送端的编码方案，正确地然后替换他们在接收端。 因为压缩帧占用较少带宽，更加了不起的编号可以每时间单 位传输。数据压缩机制示例包括STAC、微软点到点压缩 (MPPC)和帧中继论坛9 (FRF.9)。
-
报 头压缩 - 压缩头在开放式系统互联(OSI) 参考模型的多种层。 示例包括传输控制协议（TCP）报头压 缩、压缩RTP (RTP)和被压缩互联网协议/用户数据报协议(IP/UDP) 。
数据压缩概要
数据压缩的基本功能将 减少在网络链路被传输的数据帧的大小。减少帧的大小减少 需时传输帧横跨网络。
二种最常用的 数据压缩算法在互联网设备是堆货机和预报器。
以下示例配置在帧中继接口或子接口显示启用有效载 荷压缩二种方式。
interface Serial0/5
ip address 10.0.0.1 255.255.255.0
no ip directed-broadcast
encapsulation frame-relay IETF
clockrate 1300000
frame-relay map ip 10.0.0.2 16 broadcast IETF payload-compression FRF9 stac
interface Serial0/0.105 point-to-point
ip address 192.168.162.1 255.255.255.0
no ip directed-broadcast
frame-relay interface-dlci 105 IETF
class 128k
frame-relay payload-compression FRF9 stac
Cisco压缩硬件
硬件支持的数据压缩达到整体功能和基于软件的数据 压缩一样，但通过计算卸载此加速压缩费率从主CPU。换句话 说：
-
软件压缩- 压缩在在路 由器的主处理器安装的Cisco IOS软件实现。
-
硬件压缩- 压缩在在系统插槽上安装压缩硬件 实现。硬件压缩从在您的路由器安装的主处理器取消压缩和 解压责任。
下面的表列出Cisco压缩 硬件和支持的平台：
|
压缩硬件 |
支持的平台 |
注意 |
|---|---|---|
|
支持在用点对点协议(PPP)或帧中继封装配置串行接 口的栈式算法。 | ||
|
支持在PPP链接和帧中继链路的栈式算法带有FRF.9压 缩算法。 | ||
|
支持 Lempel-ziv标准(LZS)和MPPC算法。 |
如果是可用的，配置压缩在一个串行接口 用一 个 命令例如 压缩stac 自动地启 用硬件压缩。 否则，软件compresion启用。您能使用 compress stac software命令强 制使用软件压缩。
理想的排队机制和硬件压缩
此部分与Cisco传统优先级排队功能 和压缩硬件讨论一个解决的问题。压缩硬件从PQs进取地最初 离队了信息包，有效去除PQ的好处。换句话说，PQ适当地运 作，但功能排队移动了向压缩硬件的自己的队列(holdq、hw 环和 compQ)，严格是先入先出（FIFO）。此问题症状在 Cisco Bug ID CSCdp33759提供(被标记作为CSCdm91180重复项)。
解决方法修改压缩硬件的驱动器。 特定地，它节流压缩硬件通过减少根据接口带宽的硬件队列 的大小离队信息包的费率。此反向压力机制保证信息包在花 梢队列在压缩硬件的队列停留而不是被暂挂。 参见以下 Bug ID欲知更多信息：
注意： 更多信息关于这些Bug ID可以通过使用 Bug Toolkit 查找 (注册的用户)。
CSCdm91180 - 适用于帧中继封装和压缩服务 适配器(CSA)。
CSCdp33759 (和 CSCdr18251) - 适用于PPP封装和CSA。
CSCdr18251 - 适用于PPP封装和异步接口模块 压缩(AIM-COMPR)。
Cisco 3660压缩 的硬件级别队列在show pas caim stats命令的以下示例输出能被 看见 。如果硬件压缩队 列存储许多信息包，信息包从PQ等待离队了在此队列的尾端，并且 经验因而延迟。
Router> show pas caim stats 0
CompressionAim0
ds:0x80F56A44 idb:0x80F50DB8
422074 uncomp paks in --> 422076 comp paks out
422071 comp paks in --> 422075 uncomp paks out
633912308 uncomp bytes in --> 22791798 comp bytes out
27433911 comp bytes in --> 633911762 uncomp bytes out
974 uncomp paks/sec in --> 974 comp paks/sec out
974 comp paks/sec in --> 974 uncomp paks/sec out
11739116 uncomp bits/sec in --> 422070 comp bits/sec out
508035 comp bits/sec in --> 11739106 uncomp bits/sec out
433 seconds since last clear
holdq: 0 hw_enable: 1 src_limited: 0 num cnxts: 4
no data: 0 drops: 0 nobuffers: 0 enc adj errs: 0 fallbacks: 0
no Replace: 0 num seq errs: 0 num desc errs: 0 cmds complete: 844151
Bad reqs: 0 Dead cnxts: 0 No Paks: 0 enq errs: 0
rx pkt drops: 0 tx pkt drops: 0 >dequeues: 0 requeues: 0
drops disabled: 0 clears: 0 ints: 844314 purges: 0
no cnxts: 0 bad algos: 0 no crams: 0 bad paks: 0
# opens: 0 # closes: 0 # hangs: 0
注意： CSCdr86700从平台取消实现的变化在 CSCdm91180上不支持CSA。
另外，当排除此问题故障，信息包扩展问题与小的信 息包(时大约4个字节)和特定的重复模式，例如Cisco连接与 0xABCDABCD的模式，在流被解决了与Bug ID CSCdm11401.小的信息 包是较不可能与其他信息包有关，并且尝试压缩他们可能导致膨胀 信息包，或者引起词典重置。根本原因是在CSA使用的芯片的 一个问题。Cisco Bug ID CSCdp64837通过更改FRF.9压缩代 码解决此问题避免压缩信息包有少于60个有效载荷字节。
理想的排队 机制和软件压缩
与硬 件压缩对比，软件压缩和理想的排队机制，包括自定义、优先级和 加权公平排队，用PPP封装配置接口不支持。此限制在 Bug ID CSCdj45401和CSCdk86833提供。
限制的原因是PPP压缩不是无状态的并且维护在数据 流的压缩历史记录优化压缩速率。必须保持压缩的信息包为 了维护压缩历史记录。如果信息包在排队之前是被压缩，在 单个队列必须放置他们。放置他们用不同的队列，作为自定 义和优先级队列，可能导致到达在顺序的外面信息包，中断压缩。 其它方案是不最理想的和未实现。这样选择包括他们 离队(不可接受为性能原因)，维护分开的压缩历史记录为每个队列( 不支持和介入重大的开销)和重置压缩历史记录为每个信息包的压缩 的信息包(大量影响压缩速率)。作为解决方法，您能配置高 级数据链路控制（HDLC）封装，但此配置可能影响系统性能并且不 推荐。反而，使用硬件压缩。
RTP报头压缩与 QoS
RFC 1889 
指定RTP，管理音 频路径传输为VocIp。RTP提供作为程序化识别丢失的信息包 和32位值识别和区分在多发送器之间在组播流的这样服务。重要地，它不提供也不保证QoS。
VOIP信息包由一个或更多语音编解码器示例在40字节或帧组 成封装的IP/UDP/RTP头。40 个字节是一笔相对很多笔开销 为典型的20 字节VoIP有效载荷，特别在低速链路。 RFC 2508 指定压缩RTP (RTP) ，设计减少IP/UDP/RTP头到二个字节为多数信息包在没有发送情况 下UDP检查和，或者四个字节带有检查和。在本文定义的压缩 算法在 RFC 1144 大量画在TCP/IP报头压缩设计如所 描述 。
RFC 2508 实际上指定RTP二种格式：
-
压缩RTP (CR) - 使用当 IP 、UDP和RTP头保持一致。全部三个头被压缩。
-
压缩 UDP (CU) - 使用当有在RTP时间戳的上 一个大变化或当RTP有效载荷类型更改。IP和UDP头被压缩， 但RTP 头不是。
Cisco IOS软件版 本12.1(5)T引入几改进为在帧中继永久虚拟电路(PVC的)压缩在 Cisco 2600、3600 及7200系列路由器。这些改进包括以下 ：
|
在Cisco IOS版本12.1(5)T之前 |
Cisco IOS版本12.1(5)T和 12.2 |
|---|---|
|
必要的慢速广域网边缘分段方 法保证语音质量在接口没有工作带有硬件压缩。 这些分段方 法，包括MLPPP/LFI，FRF 11 Annex C和FRF.12，与基于软件的压缩 一起使用。 |
分段(FRF.12或 Link Fragmentation and Interleaving (LFI))与硬件压缩一起支 持。另外，FRF.12和FRF 11附录C分段在同样PVC支持带有 FRF.9硬件压缩。语音信息包从优先级队列带有低延时排队 (LLQ)绕过FRF.9压缩机引擎。 数据包被压缩。 |
|
FRF.9压缩IETF encap PVC仅支持 |
RTP和FRF.9压缩同样PVC支持。 FRF.9 压缩用Cisco和互联网工程任务小组(IETF)封装配置 PVC支持。 |
|
RTP用仅Cisco封装配置帧 中继PVC支持。 |
RTP继续Cisco封装 的PVC仅支持。 |
已知问题
下面的表列出RTP和Cisco IOS QoS功能的已知问题。 此列表在发布之时是准确的。并且参见您的Cisco IOS 软件的版本的版本说明欲知更多信息。
|
Bug ID |
说明 |
|---|---|
|
CSCdv73543 |
当层次化QoS策略，使用模块化QoS CLI的命令，被运 用于一个出局接口并且指定一个两层策略时，一致的数据流速率比 预计可能是。当在信息包采取的行动在一个级别是与那不同 在第二个层次，问题发生。例如，一致在第一个级别并且超 出在第二个层次。示例策略如下说明： policy-map test-policer
class class-default
police 10000 1500 1500 conform-action
transmit exceed-action transmit
service-policy inner-police
!
policy-map inner-police
class prec5
police 20000 1500 1500 conform-action
transmit exceed-action transmit
|
|
CSCdt52094 |
意外的信 息包丢弃可能看当使用低延时排队(时LLQ)在帧中继。问题是 causd 由排队系统不考虑到RTP带宽增益。 |
|
CSCds43465 |
最初，在 排队以后，RTP发生。 结果是排队的(潜在)锯一个更更加大 量的信息包比什么在金属丝实际上传输了。此工作情况更改 与此Bug。现在排队凝视压缩的信息包。与此更改，您 能配置 带宽说明与根据压缩 的数据费率的CBWFQ。 |
