了解壓縮（包括cRTP）和服務品質

簡介

本文探討在同一路由器上啟用Cisco IOS^®軟體壓縮和服務品質(QoS)功能的已知問題。

Cisco IOS軟體提供了許多最佳化廣域網(WAN)鏈路的功能，以緩解廣域網頻寬瓶頸。壓縮是一種有效的最佳化方法，它分為兩類：

• 資料壓縮 — 為每端提供編碼方案，允許從鏈路傳送端的幀中刪除字元，然後在接收端正確替換字元。由於壓縮的幀佔用較少的頻寬，因此每單位時間可以傳輸較多的幀數。資料壓縮方案的示例包括STAC、Microsoft點對點壓縮(MPPC)和幀中繼論壇9(FRF.9)。

• 標頭壓縮 — 在開放系統互連(OSI)參考模型的不同層壓縮標頭。範例包括傳輸控制通訊協定(TCP)標頭壓縮、壓縮RTP(cRTP)和壓縮網際網路通訊協定/使用者資料包通訊協定(IP/UDP)。

必要條件

需求

本文件沒有特定需求。

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您在即時網路中工作，請確保在使用任何命令之前瞭解其潛在影響。

慣例

如需文件慣例的詳細資訊，請參閱思科技術提示慣例。

資料壓縮概述

資料壓縮的基本功能是減小通過網路鏈路傳輸的資料幀的大小。減小幀大小可以減少通過網路傳輸幀所需的時間。

網間裝置上最常用的兩種資料壓縮演算法是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

思科壓縮硬體

硬體輔助的資料壓縮實現了與基於軟體的資料壓縮相同的整體功能，但通過從主CPU中解除安裝該計算來加速壓縮速率。換句話說：

• 軟體壓縮 — 壓縮是在路由器主處理器中安裝的Cisco IOS軟體中實施的。

• 硬體壓縮 — 壓縮是在安裝在系統插槽中的壓縮硬體中實施的。硬體壓縮會刪除路由器中安裝的主處理器的壓縮和解壓縮責任。

  下表列出思科壓縮硬體和支援的平台：

在串列介面上使用compress stack等命令配置壓縮功能會自動啟用硬體壓縮（如果可用）。否則會啟用軟體壓縮。可以使用compress stac software命令強制使用軟體壓縮。

Fancy隊列和硬體壓縮

本節討論思科舊版優先順序佇列(PQ)功能和壓縮硬體的已解決問題。壓縮硬體最初從PQ主動出列資料包，有效地消除了PQ的優點。換句話說，PQ工作正常，但是排隊功能上移動到壓縮硬體自己的隊列（holdq、hw ring和compQ），嚴格來說這些隊列是先進先出(FIFO)。 此問題的症狀記錄在Cisco錯誤ID CSCdp33759(標籤為CSCdm91180的副本)中。

解析度將修改壓縮硬體的驅動程式。具體而言，它通過根據介面的頻寬減少硬體隊列的大小，來限制壓縮硬體將資料包出隊的速率。這種背壓機制可確保資料包留在花哨的隊列中，而不是保留在壓縮硬體的隊列中。如需詳細資訊，請參閱以下錯誤ID:

注意：使用Bug Toolkit（僅限註冊客戶）可以找到有關這些錯誤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從不支援CSA的平台上刪除CSCdm91180中實施的更改。

此外，在排解此問題的過程中，使用錯誤ID CSCdm11401解決了小資料包（約4位元組）和特定重複模式（如模式為0xABCD的Cisco ping）的資料包擴展問題。小資料包不太可能與流中的其他資料包相關，嘗試壓縮它們可能導致擴展的資料包，或導致字典重置。根本原因在於CSA上使用的晶片有問題。思科錯誤ID CSCdp64837通過更改FRF.9壓縮代碼來避免壓縮負載小於60位元組的資料包，從而解決了此問題。

花式佇列與軟體壓縮

與硬體壓縮不同，採用PPP封裝配置的介面不支援軟體壓縮和花式佇列（包括自定義、優先順序和加權公平佇列）。此限制已記錄在Bug IDs CSCdj45401和CSCdk86833中。

限制的原因是PPP壓縮不是無狀態的，它會在資料流上維護壓縮歷史記錄以最佳化壓縮比。必須保留壓縮的資料包，以便維護壓縮歷史記錄。如果在排隊之前壓縮資料包，則必須將它們放在單個隊列中。將資料包放入不同的隊列（如自定義隊列和優先順序隊列）時，可能導致資料包按順序到達，從而中斷壓縮。備選解決方案不是最好的，尚未實施。這些替代方案包括在資料包出隊時對其進行壓縮（由於效能原因不能接受），維護每個隊列的單獨壓縮歷史記錄（不受支援且涉及大量開銷），以及重置每個資料包的壓縮歷史記錄（顯著影響壓縮比率）。 作為解決方法，您可以配置高級資料鏈路控制(HDLC)封裝，但此配置可能影響系統效能，不建議使用。而是使用硬體壓縮。

RTP標頭壓縮和QoS

RFC 1889 ：指定RTP，它管理IP語音(VoIP)的音訊路徑傳輸。RTP提供諸如排序以識別丟失的資料包和32位值以識別和區分多播流中的多個傳送者的服務。重要的是，它不能提供或確保QoS。

VoIP資料包由一個或多個語音編解碼器樣本或封裝在40位元組的IP/UDP/RTP報頭中的幀組成。對於典型的20位元組VoIP負載而言，40位元組是相對較大的開銷，尤其是在低速鏈路上。RFC 2508 (RFC 2508)指定壓縮RTP(cRTP)，其設計用於在沒有傳送UDP校驗和的情況下，將大多數資料包的IP/UDP/RTP報頭減少為兩個位元組，或減少四個位元組的校驗和。本文檔中定義的壓縮演算法很大程度上依賴於RFC 1144 中所述的TCP/IP報頭壓縮設計。

RFC 2508實際上指定了cRTP的兩種格式：

• 壓縮RTP(CR) — 當IP、UDP和RTP標頭保持一致時使用。所有三個標頭都經過壓縮。

• 壓縮UDP(CU) — 在RTP時間戳發生重大變化或RTP負載型別發生變化時使用。IP和UDP報頭已壓縮，但RTP報頭未壓縮。

Cisco IOS軟體版本12.1(5)T針對在Cisco 2600、3600和7200系列路由器上的訊框中繼永久虛擬電路(PVC)進行壓縮引入了一些改進。這些改進包括：

已知的問題

下表列出了cRTP和Cisco IOS QoS功能的已知問題。此清單在發佈時是準確的。此外，請參閱適用於您的Cisco IOS軟體版本的發行說明，瞭解更多資訊。

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

相關資訊

• QoS支援頁面
• 技術支援 - Cisco Systems