服务质量 (QoS) : QoS 链路有效性机制

了解压缩(包括RTP)和服务质量

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 22 日) | 反馈


目录


简介

此关于启用压缩和服务质量(QoS) Cisco IOS 软件功能的本文探讨了已知问题在同一路由器。

Cisco IOS软件提供优化广域网(WAN)链路缓和WAN带宽瓶颈的许多功能。压缩是一个有效优化方法并且包括两个类型:

  • 数据压缩-提供每个末端允许从帧将删除的字符在链路的发送端的编码方案,正确地然后替换他们在接收端。因为压缩帧占用较少带宽,更加了不起的编号可以每时间单位传送。数据压缩机制示例包括STAC、Microsoft点对点压缩(MPPC)和帧中继论坛9 (FRF.9)。

  • 报头压缩-压缩报头在开放式系统互联(OSI)参考模型的多种层。示例包括传输控制协议(TCP)报头压缩、压缩RTP (cRTP)和被压缩互联网协议/用户数据报协议(IP/UDP)。

先决条件

要求

本文档没有任何特定的要求。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备创建的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您是在真实网络上操作,请确保您在使用任何命令前已经了解其潜在影响。

规则

有关文档规则的详细信息,请参阅 Cisco 技术提示规则

数据压缩概述

数据压缩基本功能将减少在网络链路传送的数据帧的大小。减少帧的大小减少所需的时间传输在间网络的帧。

在网间设备的两种最常用的数据压缩算法是Stacker和Predictor。

以下配置示例显示启用在帧中继接口或子接口的有效载荷压缩两种方式。

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软件里实现。

  • 硬件压缩-压缩在系统插槽安装的压缩硬件里实现。硬件压缩从在您的路由器安装的主处理器取消压缩和解压责任。

    下表列出思科压缩硬件和支持的平台:

压缩硬件 支持的平台 备注
A-COMP/1和A-COMP/4服务适配器(CSA) 思科7200系列路由器和第二代多功能接口处理器(VIP2)在Cisco 7000及7500系列路由器 支持在配置的serial interfaces的栈式算法与点对点协议(PPP)或帧中继封装。
NM-COMPR Cisco 3600 系列路由器 支持在PPP链路和帧中继链路的栈式算法与FRF.9压缩算法。
AIM-COMPR4 仅Cisco 3660系列路由器 支持Lempel-Ziv Standard (LZS)和MPPC算法。

如果是可用的,配置在一serial interfaces的压缩用一命令例如压缩stac自动地启用硬件压缩。否则,软件压缩启用。您能使用compress stac software命令强制使用软件压缩。

花样排队与硬件压缩

此部分与思科传统优先权队列(PQ)功能和压缩硬件讨论解决的问题。压缩硬件从PQs积极地最初离队了数据包,有效删除PQ的好处。换句话说,适当地工作的PQ,但是功能上排队移动向压缩硬件的自己的队列(holdq、hw环和compQ),严格是先入先出(FIFO)。此问题症状在Cisco Bug ID CSCdp33759描述(被标记作为CSCdm91180重复项)。

解决方法修改压缩硬件的驱动程序。特别地,它节流压缩硬件通过减少根据接口带宽的硬件队列大小离队数据包的速率。此背压机制保证数据包在花梢队列在压缩硬件的队列停留而不是保持。参考以下Bug ID欲知更多信息:

注意: 通过使用Bug Toolkit (仅限注册用户),关于这些Bug ID的更多信息可以被找到。

  • 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个字节)时和特定的重复模式,例如思科ping与0xABCDABCD模式,用Bug ID CSCdm11401解决。小数据包是不太可能涉及到在数据流的其他数据包,并且尝试压缩他们可能导致展开的数据包,或者请引起词典重置。根本原因是与在CSA使用的芯片的一问题。Cisco Bug ID CSCdp64837通过更改FRF.9压缩代码避免解决此问题压缩有的数据包少于60有效载荷字节。

花样排队与软件压缩

与硬件压缩、软件压缩和理想的排队机制对比,包括自定义,接口不支持优先级和加权公平排队配置与PPP封装。此限制在Bug ID CSCdj45401和CSCdk86833描述。

限制的原因是PPP压缩不是无状态的并且维护在数据流的压缩历史记录优化压缩速率。必须保持压缩的信息包为了维护压缩历史记录。如果数据包在排队前是被压缩的,在单个队列必须放置他们。放置他们用不同的队列,作为自定义和优先级队列,可以导致到达数据包失序,中断压缩。其它方案不理想的和未实现。这样选择包括,他们离队(不可接受由于性能上的原因),维护每个队列的分开的压缩历史记录(不支持的和介入重大的开销)和重置每数据包的(充分地影响压缩速率)的压缩的数据包压缩历史记录。作为应急方案,您能配置高级数据链路控制(HDLC)封装,但是此配置可能影响系统性能和没有推荐。反而,请使用硬件压缩。

RTP 包头压缩与 QoS

RFC 1889leavingcisco.com 指定RTP,管理VoIP的音频路径传输。RTP提供这样服务象定序识别丢失的数据包和32位值识别和区分在组播流的多发送方之间。重要地,它不提供也不保证QoS。

VoIP信息包在40字节或帧封装的撰写一个或更多语音编解码器示例的IP/UDP/RTP报头。40个字节是典型的20字节VoIP有效载荷的一笔相对很多开销,特别在低速链路。RFC 2508leavingcisco.com 指定压缩RTP (cRTP),设计减少IP/UDP/RTP报头到多数数据包的两个字节在案件UDP校验和没有发送,或者与校验和的四个字节。在本文定义的压缩算法大量地画在TCP/IP报头压缩设计正如RFC 1144所描述leavingcisco.com

RFC 2508实际上指定cRTP两个格式:

  • 压缩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或链路分段和交织(LFI))与硬件压缩一起支持。另外, FRF.12和FRF.11附录C分段支持与在同样PVC的FRF.9硬件压缩。从优先级队列的语音数据包与低延迟队列(LLQ)绕过FRF.9压缩物引擎。数据包是被压缩的。
IETF encap PVC仅支持FRF.9压缩 同样PVC支持cRTP和FRF.9压缩。PVC支持FRF.9压缩配置与思科和互联网工程任务组(IETF)封装。
帧中继PVC支持cRTP配置与仅思科封装。 继续Cisco封装的PVC仅支持cRTP。

已知问题

下表列出与cRTP和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)时在帧中继。问题是由不考虑到的排队系统引起的cRTP带宽增益。
CSCds43465 最初, cRTP在排队以后发生。结果是排队(潜在)看到了一更更加大量的数据包比什么在电线实际上传送。此行为更改与此bug。当前排队凝视压缩的信息包。使用此更改,您能配置与根据压缩数据数据传输比的CBWFQ的带宽说明

相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


相关信息


Document ID: 22308