サービス品質(QoS) : QoS リンク効率性メカニズム

圧縮(cRTP を含む)および QoS について

2005 年 8 月 10 日 - ライター翻訳版
その他のバージョン: PDFpdf | 機械翻訳版 (2013 年 8 月 21 日) | 英語版 (2008 年 2 月 15 日) | フィードバック

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
データ圧縮の概要
シスコの圧縮ハードウェア
高度なキューイングとハードウェア圧縮
高度なキューイングとソフトウェア圧縮
RTP ヘッダー圧縮と QoS
既知の問題
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

このドキュメントでは、Cisco IOS(R) ソフトウェアの圧縮機能と QoS(Quality of Service)機能を、1 台のルータで有効にした場合の既知の問題について説明します。

Cisco IOS ソフトウェアでは、ワイドエリア ネットワーク(WAN)リンクを最適化して、WAN 帯域幅のボトルネックを緩和する機能を多数用意しています。 圧縮は効果的な最適化手法で、次の 2 種類があります。

  • データ圧縮:リンクの送信側でフレームから文字を削除し、受信側で削除した文字を正しく復元する符号化方式を各端に提供します。 圧縮フレームでは、占有する帯域幅が減少するため、単位時間あたりに送信できるフレーム数が増加します。 データ圧縮方式の例には、STAC、Microsoft Point-to-Point Compression(MPPC)、Frame Relay Forum 9(FRF.9; フレームリレー フォーラム 9)などがあります。

  • ヘッダー圧縮:OSI(Open System Interconnection; オープン システム インターコネクション)参照モデルの各レイヤで、ヘッダーを圧縮します。 例としては、Transmission Control Protocol(TCP)ヘッダー圧縮、compressed RTP(cRTP)、compressed Internet Protocol/User Datagram Protocol(IP/UDP)などがあります。

前提条件

要件

このドキュメントに関する特別な要件はありません。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されています。このドキュメント内で使用されているデバイスではすべて、クリアな(デフォルト)設定で作業を開始しています。実稼動中のネットワークで作業する場合は、コマンドの実行によって生じる影響について、事前に理解しておいてください。

表記法

ドキュメント表記の詳細は、『シスコ テクニカル ティップスの表記法』を参照してください。

データ圧縮の概要

データ圧縮の基本的な機能は、ネットワーク リンクで送信するデータ フレームのサイズを小さくすることです。 フレームのサイズを小さくすると、ネットワークでフレームの送信にかかる時間が短縮されます。

インターネットワーキング デバイスで最も一般的に使用されているデータ圧縮アルゴリズムは、Stacker と Predictor の 2 つです。

次の設定例では、フレームリレーのインターフェイスとサブインターフェイスで、ペイロード圧縮を有効にする 2 つの方法を示しています。

 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 ソフトウェアに実装されています。

  • ハードウェア圧縮:圧縮機能は、システム スロットに取り付けられている圧縮ハードウェアに実装されています。 ハードウェア圧縮を使用すると、ルータに搭載されているメイン プロセッサに、圧縮および圧縮解除の処理の負担がかからなくなります。

    次の表に、シスコの圧縮ハードウェアとサポートするプラットフォームを示します。

圧縮ハードウェア サポートするプラットフォーム 備考

SA-Comp/1 および SA-Comp/4 サービス アダプタ(CSA)

Cisco 7200 シリーズ ルータおよび、Cisco 7000 と 7500 シリーズ ルータの Second-generation Versatile Interface Processor(VIP2)

Point-to-Point Protocol(PPP; ポイントツーポイント プロトコル)またはフレームリレーのカプセル化が設定されているシリアル インターフェイスで、Stacker アルゴリズムをサポートします。

NM-COMPR

Cisco 3600 シリーズ ルータ

FRF.9 圧縮アルゴリズムを使用する PPP リンクおよびフレームリレー リンクで、Stacker アルゴリズムをサポートします。

AIM-COMPR4

Cisco 3660 シリーズ ルータのみ

Lempel-Ziv Standard(LZS)および MPPC アルゴリズムをサポートします。

シリアル インターフェイスで compress stac などのコマンドを使用して圧縮を設定すると、ハードウェア圧縮が使用可能な場合は、自動的にハードウェア圧縮が有効になります。 そうでない場合は、ソフトウェア圧縮が有効になります。 compress stac software コマンドを使用すると、強制的にソフトウェア圧縮を有効にできます。

高度なキューイングとハードウェア圧縮

このセクションでは、シスコの従来の Priority Queueing(PQ; プライオリティ キューイング)機能と圧縮ハードウェアに関する解決済みの問題について説明します。 当初の圧縮ハードウェアは、PQ からパケットを強制的に取り出していたため、事実上 PQ の利点を損なっていました。 つまり PQ は正常に機能していたものの、キューイング機能は、First-In, First-Out(FIFO; ファーストイン ファーストアウト)を原則とする圧縮ハードウェアのキュー(holdq、hw リングおよび compQ)で行われていました。 この問題の症状は、Cisco Bug ID CSCdp33759 に記載されています(CSCdm91180 の複製としてマークされています)。

この解決策では、圧縮ハードウェアのドライバを変更します。 具体的には、インターフェイスの帯域幅に応じてハードウェア キューのサイズを小さくすることで、圧縮ハードウェアがパケットを取り出す率を制限します。 このバック プレッシャ メカニズムにより、パケットが圧縮ハードウェアのキューで待機せず、高度なキューで待機するようになります。 詳細については、次の Bug ID を参照してください。

注:これらの Bug ID の詳細を参照するには、Bug Toolkit を使用してください。(登録ユーザ専用) 

  • CSCdm91180:フレームリレーのカプセル化および Compression Service Adapter(CSA)に適用されます。

  • CSCdp33759(および CSCdr18251):PPP カプセル化および CSA に適用されます。

  • CSCdr18251:PPP カプセル化および Asynchronous Interface Module-Compression(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 で実装した変更内容を取り除いています。 

また、この問題のトラブルシューティングとは別に、小さいパケット(4 バイト前後)や特定の反復パターン(0xABCDABCD のパターンを使用するシスコの ping など)に伴うパケット拡大の問題が、Bug ID CSCdm11401 で解決されています。 小さいパケットは、ストリームの他のパケットに関係する可能性が低く、このようなパケットを圧縮しようとすると、パケットが拡大したり、ディクショナリのリセットが引き起こされる場合があります。 根本原因は、CSA で使用しているチップに伴う問題です。 Cisco Bug ID CSCdp64837 では、60 バイト未満のペイロードのパケットの圧縮は回避するように FRF.9 圧縮コードを変更することで、この問題を解決しています。

高度なキューイングとソフトウェア圧縮

ハードウェア圧縮とは異なり、ソフトウェア圧縮と高度なキューイング(カスタム、プライオリティ、均等化などのキューイング)は、PPP カプセル化が設定されているインターフェイスでは、サポートされません。 この制限事項については、Bug ID CSCdj45401 および CSCdk86833 に記載されています。

この制限がある理由は、PPP 圧縮がステートレスではなく、データ ストリームの圧縮履歴を維持更新することにより圧縮比を最適化するためです。 圧縮履歴を維持更新するには、圧縮パケットを保持する必要があります。 パケットがキューイングの前に圧縮される場合は、単一のキューに入れる必要があります。 カスタム キューイングやプライオリティ キューイングで行われるように、パケットを異なる複数のキューに入れると、パケットの到着順序が前後してしまい、圧縮が損なわれる場合があります。 代替ソリューションは最適とはいえないため、実装されていません。 このような代替ソリューションには、パケットを取り出すときに圧縮する(パフォーマンス上の理由から望ましくない)、各キューごとに圧縮履歴を維持更新する(サポートされておらず、相当量のオーバーヘッドが発生する)、パケット単位で圧縮履歴をリセットする(圧縮比に大きな影響を与える)、などがあります。 回避策として、High-level Data Link Control(HDLC; ハイレベル データリンク コントロール)カプセル化を設定することもできますが、この設定はシステムのパフォーマンスに影響を及ぼす可能性があるため、推奨しません。 代わりに、ハードウェア圧縮を使用してください。

RTP ヘッダー圧縮と QoS

RFC 1889 leavingcisco.com では、RTP を規定しています。RTP は、Voice over IP(VoIP)の音声パス転送を管理します。 RTP では、損失パケットを識別するために順番付けを行うサービスや、マルチキャスト ストリームで複数の送信元を識別して区別するための 32 ビット値が提供されます。 重要なのは、RTP では、QoS が提供および保証されない点です。

VoIP パケットは、40 バイトの IP/UDP/RTP ヘッダーにカプセル化された 1 つ以上の音声コーデック サンプルまたはフレームで構成されています。 一般的な 20 バイトの VoIP ペイロードにとって、特に低速リンクでは、40 バイトは比較的大きなオーバーヘッドです。 RFC 2508 leavingcisco.com では、compressed RTP(cRTP)を規定しています。cRTP はほとんどのパケットの IP/UDP/RTP ヘッダーを、UDP チェックサムが送信されなかった場合は 2 バイトに、チェックサムがある場合は 4 バイトに縮小する設計になっています。 このドキュメントに記載されている圧縮アルゴリズムは、RFC 1144 leavingcisco.com に記載されている TCP/IP ヘッダー圧縮の設計を引用しています。

RFC 2508 では次の 2 つの cRTP のフォーマットを規定しています。

  • Compressed RTP(CR):IP、UDP および RTP ヘッダーの整合性を維持できる場合に使用されます。 3 つのヘッダーは、すべて圧縮されます。

  • Compressed UDP(CU):RTP タイムスタンプに大きな変更がある場合や、RTP ペイロード タイプが変わる場合に使用されます。 IP および UDP ヘッダーは圧縮されますが、RTP ヘッダーは圧縮されません。

Cisco IOS ソフトウェア リリース 12.1(5)T では、Cisco 2600、3600 および 7200 シリーズ ルータでのフレームリレー Permanent Virtual Circuit(PVC; 相手先固定接続)の圧縮処理が、いくつか改善されています。 改善内容は、次のとおりです。

Cisco IOS リリース 12.1(5)T より前のリリース Cisco IOS リリース 12.1(5)T および 12.2

音声品質の保証に必要な低速 WAN エッジのフラグメンテーション方式が、ハードウェア圧縮を使用するインターフェイスで機能していなかった。 これらのフラグメンテーション方式(MLPPP/LFI、FRF.11 Annex C、FRF.12 など)は、ソフトウェアベースの圧縮では機能する。

フラグメンテーション(FRF.12 または Link Fragmentation and Interleaving(LFI))は両方、ハードウェア圧縮でサポートされている。 さらに、FRF.12 および FRF.11 Annex-C フラグメンテーションが、同じ PVC 上の FRF.9 ハードウェア圧縮でサポートされている。 Low Latency Queueing(LLQ; 低遅延キューイング)を使用しているプライオリティ キューの音声パケットは、FRF.9 圧縮エンジンをバイパスする。 データ パケットは圧縮される。

FRF.9 圧縮は、IETF-encap PVC でのみサポートされている。

cRTP および FRF.9 圧縮は、同じ PVC 上でサポートされている。 FRF.9 圧縮は、シスコおよび Internet Engineering Task Force(IETF; インターネット技術特別調査委員会)のカプセル化が設定されている PVC 上でサポートされる。

cRTP は、シスコのカプセル化が設定されているフレームリレー PVC でのみサポートされている。

cRTP は引き続き、シスコのカプセル化が設定されている PVC でのみサポートされている。


既知の問題

次の表に、cRTP および Cisco IOS の QoS 機能に関する既知の問題を示します。 この表は、このドキュメントの発行時点の内容です。 詳細については、ご使用のバージョンの Cisco IOS ソフトウェアのリリース ノートを参照してください。

Bug ID 説明

CSCdv73543

モジュラ QoS CLI のコマンドを使用する階層型 QoS ポリシーが、発信インターフェイスに適用され、2 レベルのポリサーを指定している場合に、トラフィックの適合レートが予想より低くなることがあります。 この問題は、第 1 レベルのパケットで実行する処理と、第 2 レベルのパケットで実行する処理が異なる場合に発生します。 たとえば、レートが第 1 レベルに適合して、第 2 レベルで超過する場合があります。 次に、ポリシーの例を示します。

 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

フレームリレーで Low Latency Queueing(LLQ)を使用している場合に、予期しないパケットの廃棄が発生することがあります。 この問題は、cRTP の帯域幅のゲインを考慮していないキューイング システムが原因で発生していました。

CSCds43465

当初、cRTP はキューイングの後に行われていました。 そのため場合によっては、キューイングでは、パケットを実際に回線上に送信されるよりもかなり大きいサイズであると認識していました。 この不具合に伴って動作が変更されています。 現在は、キューイングで圧縮パケットを考慮しています。 この変更により、bandwidth 文を使用して、圧縮データ レートに基づく CBWFQ を設定できます。



関連するシスコ サポート コミュニティ ディスカッション

シスコ サポート コミュニティは、どなたでも投稿や回答ができる情報交換スペースです。


関連情報


Document ID: 22308