ブロードバンド ケーブル : ケーブル モデム終端システム(CMTS)

Cisco uBR ケーブル モデム ターミネーション システム(CMTS)向けのアップストリーム スケジューラ モード設定

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

目次

概要
前提条件
      要件
      使用するコンポーネント
      表記法
背景説明
      DOCSIS でのアップストリーム スケジューリング
      ベスト エフォート
      帯域幅要求のバックオフおよびリトライ アルゴリズム
      バックオフおよびリトライ アルゴリズムの例
      トラフィック優先度
      最小予約レート
      帯域幅要求のピギーバック
      連結
      フラグメンテーション
Unsolicited Grant Service(UGS)
      Real Time Polling Service(RTPS)
Unsolicited Grant Service with Activity Detection(UGS-AD)
Non Real Time Polling Service(nRTPS)
スケジューリング アルゴリズム
      ジッタ
      アップストリームごとの UGS サービス フロー容量
DOCSIS 準拠スケジューラ
      設定方法
      アドミッション制御
      フラグメンテーションを使用するベスト エフォート トラフィックのスケジューリング
      優先度
      フラグメント化不能の DOCSIS 1.0 認可
      Cable default-phy-burst
      フラグメント化不能スロット ジッタ
      show コマンド出力
      DOCSIS 準拠スケジューラのメリットとデメリット
低遅延キューイング スケジューラ
      設定方法
      LLQ スケジューラの動作
      アドミッション制御
      show コマンド出力
      LLQ スケジューラのメリットとデメリット
結論
関連するシスコ サポート コミュニティ ディスカッション
関連情報

概要

このドキュメントでは、Cable Modem Termination System(CMTS; ケーブル モデム ターミネーション システム)の Cisco Universal Broadband Router(uBR; ユニバーサル ブロードバンド ルータ)シリーズに対する、アップストリーム スケジューラ モードの設定について説明します。

このドキュメントは、Voice over IP や Video over IP など、遅延やジッタの影響を受けやすいアップストリーム サービスを活用する高速データオーバーケーブル ネットワークの設計とメンテナンス作業を行う担当者を対象にしています。



前提条件

要件

次の項目に関する知識があることが推奨されます。

  • Data-over-Cable Service Interface Specification(DOCSIS; データオーバーケーブル サービス インターフェイス仕様)システム

  • CMTS の Cisco uBR シリーズ



使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づくものです。

  • Cisco uBR CMTS

  • Cisco IOS® ソフトウェア リリース トレイン 12.3(13a)BC および 12.3(17a)BC

注:Cisco IOS ソフトウェアのこれ以降のリリースにおける変更の詳細は、Cisco.com Web サイトで入手可能な該当のリリース ノートを参照してください。



表記法

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



背景説明

Data-over-Cable Service Interface Specification(DOCSIS; データオーバーケーブル サービス インターフェイス仕様)ネットワークでは、ケーブル モデムが生成するすべてのアップストリーム送信のタイミングとレートを CTMS が制御します。さまざまな遅延、ジッタ、およびスループット要件のある多くのさまざまなサービスは、現在の DOCSIS ネットワーク アップストリームで同時に稼働しています。そのため、これらのさまざまなタイプのサービスに代わってケーブル モデムがいつアップストリーム送信を作成できるかを CMTS が決定するしくみを理解する必要があります。

このホワイト ペーパーは次の内容を説明しています。

  • ベスト エフォート、Unsolicited Grant Service(UGS)、Real Time Polling Service(RTPS)など、DOCSIS におけるアップストリーム スケジューリング モードの概要

  • Cisco uBR CMTS 用の DOCSIS 準拠スケジューラの操作と設定

  • Cisco uBR CMTS 用の新しい低遅延キューイング スケジューラの操作と設定



DOCSIS でのアップストリーム スケジューリング

DOCSIS 準拠 CMTS は、サービス フローの概念によってさまざまなパケット ストリームやアプリケーションにさまざまなアップストリーム スケジューリング モードを提供できます。サービス フローは、データのアップストリーム フローまたはダウンストリーム フローのいずれかを表し、そのデータが Service Flow ID(SFID; サービス フロー ID)を一意に識別します。それぞれのサービス フローには、最大スループット、最小保証スループット、優先度など、独自の Quality of Srvice(QoS)パラメータを指定できます。アップストリーム サービス フローの場合は、スケジューリング モードも指定できます。

さまざまなタイプのアプリケーションに対応するために、1 つのケーブル モデムに複数のアップストリーム サービス フローを設定することができます。たとえば、Web と電子メールは 1 つのサービス フローを使用でき、Voice over IP(VoIP)は別のものを、そして、インターネット ゲームはまた別のサービス フローを使用することができます。これらのアプリケーションそれぞれに適切なタイプのサービスを提供できるようにするには、これらのサービス フローの特性を異なるものにする必要があります。

ケーブル モデムと CMTS は、正しいトラフィックのタイプを分類子を使用することで適切なサービス フローに向けることができます。分類子とは、アクセス リストのような特別なフィルタのことであり、UDP や TCP のポート番号などのパケット プロパティを照合して、パケットが通過するための適切なサービス フローを決定します。

図 1 では、ケーブル モデムに 3 つのアップストリーム サービス フローがあります。1 番目のサービス フローは音声トラフィックのために予約されています。このサービス フローは低い最大スループットですが、同時に、低遅延の保証も提供するように設定されています。2 番目のサービス フローは一般的な Web と電子メールのトラフィック用のものです。このサービス フローには高いスループットがあります。3 番目のサービス フローは peer-to-peer(P2P; ピアツーピア)トラフィック用に予約されています。このサービス フローの最大スループットには、このアプリケーションの速度を抑制するために、かなりの制限があります。

図 1:3 つのアップストリーム サービス フローがあるケーブル モデム

upstrm_sch_config_01.gif

サービス フローは、ケーブル モデムが最初にオンラインになるときに確立され、アクティブになります。ケーブル モデムを設定するために使用する DOCSIS コンフィギュレーション ファイルにサービス フローの詳細をプロビジョニングします。DOCSIS コンフィギュレーション ファイルには、少なくとも、アップストリーム トラフィックに 1 つのサービス フローと、ダウンストリーム トラフィックに別の 1 つのサービス フローをプロビジョニングします。DOCSIS コンフィギュレーション ファイルに指定する最初のアップストリームおよびダウンストリーム サービス フローは、プライマリ サービス フローと呼ばれます。

また、サービス フローは、ケーブル モデムがオンラインになった後で動的に作成してアクティブにすることもできます。一般に、このシナリオは 1 つのサービス フローに適用され、そのサービス フローが VoIP 通話に属しているデータに対応します。そのようなサービス フローは電話の会話が始まると作成され、アクティブになります。その後、このサービス フローは通話が終了したときに非アクティブになり、削除されます。サービス フローが必要なときにだけ存在するのであれば、アップストリーム帯域幅リソースとシステムの CPU 負荷とメモリを節約できます。

ケーブル モデムは、任意のタイミングでアップストリーム送信を作成できるわけではありません。一度にアップストリーム チャネルのデータを送信できるのは 1 つのケーブル モデムだけであるため、ケーブル モデムは CMTS からの指示を必ず待ってからデータを送信します。そのようにしないと、送信がオーバーランして、互いを破損することになります。ケーブル モデムが送信を作成できるタイミングの指示は、帯域幅割り当て MAP メッセージの形式で CMTS から入ってきます。Cisco CMTS は、任意の種類の送信を作成できるタイミングをケーブル モデムに通知するために、2 ミリ秒ごとに MAP メッセージを送信します。各 MAP メッセージには、送信を作成するタイミング、送信が存在できる時間、および送信できるデータのタイプをモデムに正確に指示する情報が含まれています。つまり、ケーブル モデム データ送信は、互いに衝突することはなく、データの破損を回避します。このセクションでは、アップストリームで送信を作成するケーブル モデム権限を付与するタイミングを CMTS が判断できるいくつかの方法について説明します。



ベスト エフォート

ベスト エフォート スケジューリングは、遅延やジッタに対する厳格な要件のない従来型のインターネット アプリケーションに適しています。このタイプのアプリケーションの例としては、電子メール、Web ブラウジング、ピアツーピア ファイル転送などがあります。ベスト エフォート スケジューリングは、Voice over IP や Video over IP など、保証遅延やジッタを必要とするアプリケーションには適していません。その理由は、輻輳した状況でそのような保証のないものがベスト エフォート モードで作成されるからです。DOCSIS 1.0 システムは、このタイプのスケジューリングだけを許可します。

ベスト エフォート サービス フローは、通常は、ケーブル モデムに関連付けられた DOCSIS コンフィギュレーション ファイルにプロビジョニングされます。そのため、ベスト エフォート サービス フローは、一般に、ケーブル モデムがオンラインになるとすぐにアクティブになります。DOCSIS コンフィギュレーション ファイルでプロビジョニングされる予定の最初のアップストリーム サービス フローであるプライマリ アップストリーム サービス フローは、ベスト エフォート形式のサービス フローにする必要があります。

次に示すのは、DOCSIS 1.1/2.0 モードでベスト エフォート サービス フローを定義するパラメータで最もよく使用されるパラメータです。

  • 最大持続トラフィック レート(R)

    最大持続トラフィック レートとは、このサービス フローでトラフィックが動作できる最大レートのことです。この値はビット/秒で表されます。

  • 最大トラフィック バースト(B)

    最大トラフィック バーストとは、アップストリーム スループット制限を強化するトークン バケット レート リミッタに適用するバイト単位のバースト サイズのことです。値が何も指定されない場合は、デフォルト値の 3044 が適用され、それが 2 つのフル イーサネット フレームのサイズになります。大きな最大持続トラフィック レートに対しては、この値を、少なくとも最大持続トラフィック レートを 64 で除算した値に設定します。

  • トラフィック優先度

    このパラメータは、0(最低)から 7(最大)までの範囲のサービス フローでのトラフィックの優先度のことです。アップストリームでは、高優先度サービス フロー用のすべての保留中のトラフィックが、低優先度のサービス フロー用のトラフィックの前に、送信のためにスケジュールされます。

  • 最小予約レート

    このパラメータは、サービス フロー用の最低保証スループット ビット/秒を示しており、Committed Information Rate(CIR; 認定情報レート)と似ています。あるチャネルにおけるすべてのサービス フロー用の統合最小予約レートは、そのチャネルで利用可能な帯域幅を超過してはなりません。超過すると、約束された最小予約レートを保証することが不可能になります。

  • 最大連結バースト

    最大連結バーストは、モデムがサービス フローの代わりに作成できる連結フレームの最大の送信をバイト単位のサイズにしたものです。このパラメータが示すように、モデムは 1 つの送信のバーストで複数のフレームを送信できます。この値が指定されていない場合、DOCSIS 1.0 ケーブル モデムと古い DOCSIS 1.1 モデムは、連結バースト サイズには明示的な制限は設定されていないと想定します。DOCSIS 1.1 以降の仕様の新しいリビジョンに準拠するモデムは、1522 バイトの値を使用します。

ケーブル モデムにアップストリーム ベスト エフォート サービス フローの代わりに送信するデータがある場合、そのモデムは遅延なしで DOCSIS ネットワークにデータを単に転送することはできません。モデムは、CMTS からの排他的なアップストリーム送信時間をモデムが要求するプロセスを経由する必要があります。この要求プロセスによって、データが、同一のアップストリーム チャネルに接続されている別のケーブル モデムの送信と衝突しなくなります。

ときには、CMTS は、帯域幅要求と呼ばれる特殊なメッセージを送信することを CMTS がケーブル モデムに許可する一定の期間をスケジュールすることがあります。帯域幅要求は、モデムが送信したいデータ量の詳細を含んでいる非常に小さなフレームと、データを送信する必要のあるアップストリーム サービス フローに対応する Service Identifier(SID; サービス識別子)で構成されます。CMTS は、アップストリーム サービス フローへの内部テーブル照合 SID 番号を維持します。

CMTS は、他のイベントがアップストリームに何もスケジュールされていないときに帯域幅要求機会をスケジュールします。つまり、スケジューラは、アップストリーム スケジューラがベスト エフォートの認可を計画していないとき、または UGS 認可または他のタイプの認可が特定の時点に配置されているときに帯域幅要求を提供します。そのため、アップストリーム チャネルが頻繁に使用されているときには、ケーブル モデムが帯域幅要求を送信する機会は少なくなります。

CMTS は、アップストリーム チャネルがどんなに輻輳するようになっても、少数の帯域幅要求機会が常に定期的に必ずスケジュールされるようにします。複数のケーブル モデムは、同時に帯域幅要求を送信し、互いの送信を破壊することができます。帯域幅要求を破壊できるコリジョンの可能性を減らすために、「バックオフおよびリトライ」アルゴリズムが実施されます。このドキュメントの残りのセクションでこのアルゴリズムについて説明します。

CMTS は、ケーブル モデムからの帯域幅要求を受け取ると、次のアクションを実行します。

  1. CMTS は、帯域幅要求が関連付けられているサービス フローを調べるために、帯域幅要求で受信される SID 番号を使用します。

  2. 次に、CMTS はトークン バケット アルゴリズムを使用します。このアルゴリズムによって、CMTS が要求された帯域幅を認可する場合に、サービス フローが指示された最大持続レートを超過するかどうかを CMTS は確認できます。次に示すのは、トークン バケット アルゴリズムの計算です。

    Max(T) = T * (R / 8) + B

    ここで、

    • Max(T) は、時間 T を超えてサービス フローで送信できる最大バイト数を示しています。

    • T は、秒単位の時間を表しています。

    • R は、ビット/秒のサービス フローに対する最大持続トラフィック レートを示しています。

    • B は、バイト単位のサービス フロー用最大トラフィック バーストです。

  3. 帯域幅要求がスループット制限内にあることを CMTS が突き止めると、CMTS は、アップストリーム スケジューラに帯域幅要求の詳細をキューイングします。アップストリーム スケジューラは、帯域幅要求をいつ認可するのかを決定します。

    Cisco uBR CMTS は、DOCSIS 準拠スケジューラと低遅延キューイング スケジューラという 2 つのアップストリーム スケジューラ アルゴリズムを実装しています。詳細は、このドキュメントの「DOCSIS 準拠スケジューラ」セクションと「低遅延キューイング スケジューラ」セクションを参照してください。

  4. CMTS は、次回の定期帯域幅割り当て MAP メッセージに次の詳細を含めます。

    • ケーブル モデムが送信できるタイミング。

    • ケーブル モデムが送信できる期間。



帯域幅要求のバックオフおよびリトライ アルゴリズム

帯域幅要求メカニズムは、帯域幅要求を同時に送信する複数のケーブル モデム間のコリジョンの可能性を、完全に除去はしないものの低減するためのシンプルな「バックオフおよびリトライ」アルゴリズムを備えています。

帯域幅要求を送信すると決定するケーブル モデムは、まず帯域幅要求機会のランダム番号が渡されるのを待ってから、送信を作成します。この待機時間によって、帯域幅要求の同時送信によって発生するコリジョンの可能性が低くなります。

data backoff start および data backoff end という 2 つのパラメータは、ランダムな待機期間を決定します。ケーブル モデムは、定期的な Upstream Channel Descriptor(UCD; アップストリーム チャネル ディスクリプタ)メッセージの内容の一部としてこれらのパラメータを習得します。CMTS は、アクティブな各アップストリーム チャネルの代わりに UCD メッセージを 2 秒ごとに送信します。

これらのバックオフ パラメータは、「2 の累乗」の値として表されます。モデムは、これらのパラメータを 2 の乗数として使用し、帯域幅要求を送信するまでに待機する時間の長さを計算します。どちらの値も範囲は 0 から 15 までであり、data backoff end は、data backoff start 以上の値にする必要があります。

ケーブル モデムが特定の帯域幅要求の送信を初めて必要とするとき、ケーブル モデムは、0 から 2 に data backoff start を累乗したものから 1 を減算した値までのランダム番号を最初に選ぶ必要があります。たとえば、data backoff start が 3 に設定されている場合、モデムは 0 から (23 – 1) = (8 – 1) = 7 までのランダム番号を選択する必要があります。

その後、ケーブル モデムは、帯域幅要求伝送機会の選択済みのランダム番号が通過するのを待ってから、帯域幅要求を送信する必要があります。つまり、モデムがこの強制遅延のために次回の利用可能な機会に帯域幅要求を送信できないでいる間は、別のモデムの送信によるコリジョンの可能性は減少します。

data backoff start の値が大きくなればなるほど、帯域幅要求間のコリジョンの可能性が低くなるのは自然なことです。また、data backoff start 値が大きくなることは、モデムが帯域幅要求を送信するために待つ時間が長くなることになり、そのためにアップストリーム遅延が増えることも意味します。

CMTS には、次回の送信される帯域幅割り当て MAP メッセージでの確認応答が含まれます。この確認応答は、帯域幅要求の受信が成功したことをケーブル モデムに通知します。この確認応答で次のことができます。

  • モデムがいつ送信を実行できるかを正確に示す

    または

  • 帯域幅要求が受信されており、送信の時間は将来の MAP メッセージで決定されることだけを示す

CMTS が次回の MAP メッセージに帯域幅要求の確認応答を含まない場合、モデムは帯域幅要求が受信されなかったと結論づけることができます。この状況は、帯域幅要求が認可された場合、コリジョンやアップストリームのノイズのため、またはサービス フローが指示された最大スループット レートを超過するために発生する可能性があります。

どの場合でも、ケーブル モデムの次のステップはバックオフを行い、帯域幅要求をもう一度送信することです。モデムはランダム値が選択される範囲を拡大します。これを行うために、モデムは data backoff start 値に 1 を加算します。たとえば、data backoff start 値が 3 に設定され、CMTS が 1 つの帯域幅要求送信を受信できない場合、モデムは再送信の前に 0〜 15 の帯域幅要求機会内のランダム値を待機します。次に示すのがこの計算式です。 23+1 – 1 = 24 – 1 = 16 – 1 = 15

さらに大きな値にすると、別のコリジョンの機会が減少します。モデムがさらに帯域幅要求を失った場合、モデムは各再送信のために 2 の累乗として値を増分することを、値が data backoff end と同じになるまで続行します。2 の累乗は data backoff end 値よりも大きくなることはできません。

モデムは、最大 16 回まで帯域幅要求を再送信し、その後、モデムは帯域幅要求を廃棄します。この状況は、輻輳が非常に発生しやすい状況だけで発生します。

次のケーブル インターフェイス コマンドを使用すると、data backoff start 値と data backoff end 値を Cisco uBR CMTS でケーブル アップストリームごとに設定できます。

cable upstream upstream-port-id data-backoff data-backoff-start data-backoff-end

Cisco は、data-backoff-start パラメータと data-backoff-end パラメータにデフォルトの値、つまり、3 と 5 を維持することを推奨します。ベスト エフォート スケジューリング システムのコンテンションベースの特性として、ベスト エフォート サービス フローに、アップストリーム遅延またはジッタの確定的レベルまたは保証レベルを提供することはできません。さらに、輻輳した状況では、ベスト エフォート サービス フロー用のスループットの特定レベルを保証することが不可能になります。ただし、優先度や最小予約レートなどのサービス フロー プロパティを使用できます。これらのプロパティがあると、サービス フローは輻輳した状況で希望のスループット レベルを達成することができます。



バックオフおよびリトライ アルゴリズムの例

この例は、同じアップストリーム チャネルに接続されている A、B、C、D という 4 つのケーブル モデムで構成されています。t0 という同じ瞬間に、モデム A、B、および C が、アップストリームでいくつかのデータを送信すると決定します。

ここで、data backoff start は 2 に設定され、data backoff end は 4 に設定されます。モデムが最初に帯域幅要求を送信する前に選ぶ間隔の範囲は、0 〜 3 です。次に示すのがこの計算式です。

(22 – 1) = (4 – 1) = 3 間隔

次に示すのは、3 つのモデムが時間 t0 を待つために選ぶ帯域幅要求機会の番号です。

  • モデム A: 3

  • モデム B: 2

  • モデム C: 3

モデム A とモデム C が同じ番号の機会を選ぶために待機していることに注目してください。

モデム B は、t0 の後に現れる 2 つの帯域幅要求機会を待ちます。次に、モデム B は帯域幅要求を送信し、それを CMTS が受信します。モデム A とモデム C の両方が、t0 の後に 3 つの帯域幅要求機会が通過するのを待ちます。その後、モデム A と C は同時に帯域幅要求を送信します。これら 2 つの帯域幅要求は衝突し、破壊されます。その結果、どちらの要求も CMTS に正常に到達しません。図 2 は、このイベントのシーケンスを示します。

図 2:帯域幅要求の例、パート 1

upstrm_sch_config_02.gif

図の最上部にある灰色の帯は、時間 t0 が経過した後にケーブル モデムに対して利用可能になる一連の帯域幅要求機会を表します。色の付いた矢印は、ケーブル モデムが送信する帯域幅要求を表します。灰色の帯の中にある色付きの四角は、CMTS に正常に到達する 1 つの帯域幅要求を表しています。

CMTS からブロードキャストされる次の MAP メッセージには、モデム B の認可が含まれていますが、モデム A および C の指示は含まれません。これは、モデム A および C に対して帯域幅要求を再送信する必要があることを示します。

2 回目の試行時に、モデム A およびモデム C は、選択する間隔の範囲を計算するときに、使用する 2 の累乗を増分する必要があります。ここで、モデム A およびモデム C が、0 〜 7 の間隔のランダム番号を選びます。次に計算式を示します。

(22+1 -1) = (23 – 1) = (8 – 1) = 7 間隔

モデム A およびモデム C が再送信の必要性を認識する時間が t1 であると仮定します。また、モデム D という別のモデムが同じ瞬間 t1 にいくつかのアップストリーム データを送信することを決定していると仮定します。モデム D は、初めて帯域幅要求送信を行うところです。そのため、モデム D は、data backoff start と data backoff end のオリジナルの値、主に 0 〜 3 [(22 – 1) = (4 – 1) = 3 間隔] を使用します。

3 つのモデムは、これらの帯域幅要求機会のランダム番号を選び、時間 t1 から待機します。

  • モデム A: 5

  • モデム C: 2

  • モデム D: 2

モデム C と D は、どちらも時間 t1 の後に現れる 2 つの帯域幅要求機会を待ちます。次に、モデム C と D は同時に帯域幅要求を送信します。これらの帯域幅要求は衝突し、そのため、CMTS には到達しません。モデム A は、5 つの帯域幅要求機会が通過するのを許します。次に、モデム A は帯域幅要求を送信し、CMTS はそれを受信します。図 3 は、モデム C と D の送信の間のコリジョンと、モデム A の送信の正常な受信を示しています。この図の開始時間基準は t1 です。

図 3:帯域幅要求の例、パート 2

upstrm_sch_config_03.gif

CMTS からブロードキャストされる次の MAP メッセージには、モデム A の認可が含まれていますが、モデム C および D の指示は含まれません。モデム C および D は、帯域幅要求を再送信する必要があることを認識します。現在、モデム D は、2 回目の帯域幅要求を送信しようとしています。そのため、モデム D は、2 の累乗として data backoff start + 1 を、待機する間隔の範囲の計算で使用します。モデム D は、0 〜 7 の間隔を選択します。次に示すのがこの計算式です。

(22+1 – 1) = (23 – 1) = (8 – 1) = 7 間隔

モデム C は、3 回目の帯域幅要求を送信しようとしています。そのため、モデム C は、2 の累乗として data backoff start + 2 を、待機する間隔の範囲の計算で使用します。モデム C は、0 〜 15 の間隔を選択します。次に示すのがこの計算式です。

(22+2 – 1) = (24 – 1) = (16 – 1) = 15 間隔

ここでの 2 の累乗は data backoff end 値と同じ 4 であることに注目してください。これは、2 の累乗の値がこのアップストリーム チャネルのモデムに対してできる最も高い値です。次の帯域幅要求送信サイクルでは、2 つのモデムが待機するために次の帯域幅要求機会の番号を選びます。

  • モデム C: 9

  • モデム D: 4

モデム D は帯域幅要求を送信可能であり、これは、モデム D が 4 つの帯域幅要求機会が通過するのを待機するためです。さらに、モデム C も帯域幅要求を送信可能であり、これは、現在、モデム C が 9 つの帯域幅要求機会の送信を延期しているためです。

残念ながら、モデム C が送信を行おうとしたときに、入力ノイズの大量のバーストが送信を干渉し、CMTS が帯域幅要求を受信できなくなります(図 4 を参照)。その結果、再度、モデム C は CMTS が送信する次回の MAP メッセージで認可を確認できなくなります。これによってモデム C は、帯域幅要求の 4 番目の送信を行おうとします。

図 4:帯域幅要求の例、パート 3

upstrm_sch_config_04.gif

モデム C は、data backoff end の 4 の値にすでに到達しています。モデム C は、間隔のランダム番号を選ぶために使用する範囲を増やして待機することはできません。そのため、モデム C は、ここでも 2 の累乗の 4 を使用してランダムな範囲を計算します。モデム C は、この計算によって 0 〜 15 の範囲の間隔を引き続き使用します。

(24 – 1) = (16 – 1) = 15 間隔

4 番目の試行時に、モデム C はコンテンションまたはノイズがない状態で正常な帯域幅要求送信を行うことができます。

この例におけるモデム C の複数の帯域幅要求再送信は、輻輳しているアップストリーム チャネルで発生する可能性のあることを具体的に示しています。また、この例は、発生する可能性のあるベスト エフォート スケジューリング モードに含まれる問題と、ベスト エフォート スケジューリングが、パケット遅延とジッタの厳密に制御されたレベルを必要とするサービスには適していない理由を具体的に示します。



トラフィック優先度

CMTS に複数のサービス フローからの複数の保留中の帯域幅要求がある場合、CMTS はどのサービス フローに最初に帯域幅を付与するかを決定するために、それぞれのサービス フローのトラフィック優先度を確認します。

CMTS は、より高い優先度のサービス フローからの保留中の要求すべてに送信時間を付与してから、より低い優先度のサービス フローからの帯域幅要求を認可します。輻輳したアップストリーム状況において、これは、一般に、低い優先度のサービス フローと比較して、高い優先度のサービス フローにより高いスループットが提供されます。

注目すべき重要な事実は、高優先度のベスト エフォート サービス フローが帯域幅を即座に受信する傾向にある一方で、そのサービス フローは引き続き帯域幅要求コリジョンの可能性にさらされるということです。このため、トラフィック優先度はサービス フローのスループットと遅延特性を強化できますが、それを必要とするアプリケーションに対してサービス保証を提供するための適切な方法ではありません。



最小予約レート

ベスト エフォート サービス フローは、準拠する最小の予約レートを受信できます。CMTS は、指定された最小予約レートのサービス フローが、優先度に関係なく、他のすべてのベスト エフォート サービス フローよりも先に帯域幅を必ず受け取るようにします。

この方法は、フレームリレー ネットワークに類似している一種の Committed Information Rate(CIR; 認定情報レート)形式のサービスを提供する試みです。CMTS には、特定のアップストリーム上で、接続されたすべてのサービス スローの連結最小予約レートがアップストリーム チャネルの利用可能な帯域幅、またはそのパーセンテージを超過できなくするアドミッション制御メカニズムがあります。これらのメカニズムは、次のアップストリーム ポートごとのコマンドでアクティブにできます。

[no] cable upstream upstream-port-id admission-control max-reservation-limit

max-reservation-limit パラメータには 10 〜 1000% の範囲があり、これによって CIR 形式のサービスが消費できる未加工の利用可能なアップストリーム チャネル スループットと比較して、サブスクリプションのレベルを示すことができます。max-reservation-limit を 100 よりも上に設定した場合、アップストリームは、指定されたパーセンテージの制限によって CIR 形式のサービスをオーバーサブスクライブできます。

CMTS は、新しい最小予約レート サービス フローが、アップストリーム ポートが利用可能なアップストリーム チャネル帯域幅の設定済みの max-reservation-limit パーセンテージを超える原因となる場合、そのサービス フローを確立させません。最小予約レート サービス フローは、引き続き帯域幅要求のコリジョンの可能性にさらされます。そのように、最小予約レート サービス フローは、特に非常に輻輳している場合は、特定のスループットの真の保証は提供できません。いいかえると、CCMTS がケーブル モデムからの必要なすべての帯域幅要求を受信できる場合、CMTS は最小予約レート サービス フローが特定の保証アップストリーム スループットを達成できることを保証することだけができます。この要件は、サービス フローを、ベスト エフォート サービス フローではなく Real Time Polling Service(RTPS)サービス フローにする場合に達成できます。詳細は、「Real Time Polling Service(RTPS)」セクションを参照してください。



帯域幅要求のピギーバック

アップストリーム ベスト エフォート サービス フローが高いレートでフレームを送信するとき、帯域幅要求の独立した送信をするのではなく、アップストリーム データ フレームに帯域幅要求をピギーバックすることができます。帯域幅の次の要求の詳細は、アップストリーム内で CMTS に送信されるデータ パケットのヘッダーに追加されるだけです。

これは、帯域幅要求がコンテンションにさらされず、そのため、要求が CMTS に到達するさらに高い機会があることを意味します。ピギーバック帯域幅要求の概念は、イーサネット フレームがアップストリーム送信で費やす時間が短縮されるので、イーサネット フレームがエンド ユーザの Customer Premise Equipment(CPE; 顧客宅内機器)に到達するためにかかる時間を短縮します。短縮できるのは、モデムが、遅延に陥りやすいバックオフおよびリトライ帯域幅要求送信プロセスを通過する必要がないためです。

帯域幅要求をピギーバックすることは、一般には次のようなシナリオで発生します。

ケーブル モデムはフレーム X の送信をアップストリームで待機しているときに、アップストリームに送信する別のフレーム Y を CPE から受信します。ケーブル モデムは新しいフレーム Y からのバイトを送信には追加できません。その理由は、それを行うと、モデムが付与されているアップストリーム時間よりも多くの時間を消費することになるためです。その代わりに、モデムはフレーム X の DOCSIS ヘッダーのフィールドに値を挿入して、フレーム Y に必要な送信時間の量を示します。

CMTS はフレーム X を受信し、また、Y の代わりに帯域幅要求の詳細も受信します。アベイラビリティを基準にして、CMTS は Y の代わりにモデムにさらに送信時間を付与します。

非常に控えめに時間を計算すると、帯域幅要求の送信と帯域幅割り当ての受信の間と、データ送信に時間を割り当てる MAP 確認応答も含めると、最短でも 5 ミリ秒が経過します。これは、ピギーバックが発生するには、ケーブル モデムは互いに 5 ミリ秒未満で CPE からのフレームを受信する必要があるということになります。

これは、G.711 のような典型的な VoIP コーデックが、一般に 10 ミリ秒または 20 ミリ秒のフレーム間期間を使用するため、注目に値します。ベスト エフォート サービス フローで動作する典型的な VoIP ストリームは、ピギーバックのメリットを活用できません。



連結

アップストリーム ベスト エフォート サービス フローがフレームを高いレートで送信するとき、ケーブル モデムはいくつかのフレームを 1 つにまとめてそのフレームのまとまりをすべて一度に送信する権限を要求します。これを連結といいます。ケーブル モデムは連結されたフレームのグループですべてのフレームの代わりに 1 つだけの帯域幅要求を送信する必要があり、これによって効率が高まります。

連結は、ケーブル モデムが帯域幅要求を送信すると決定したときに、連結がケーブル モデム内部で複数のフレームをキューイングするように要求する場合を除き、ピギーバックに似た環境で発生する傾向があります。これは、連結がピギーバックよりも平均的に高いフレーム レートで発生する傾向にあることを示しています。また、両方のメカニズムは、通常、ベスト エフォート トラフィックの効率を向上させるために連携しています。

サービス フローのために設定できる最大連結バースト フィールドは、サービス フローが送信できる連結フレームの最大サイズを制限します。また、連結されたフレームのサイズとアップストリーム チャネル変調プロファイルの最大バースト サイズを限定するために cable default-phy-burst コマンドを使用することもできます。

連結は、CMTS の Cisco uBR シリーズのアップストリーム ポートではデフォルトで有効になっています。ただし、[no] cable upstream upstream-port-id concatenation [docsis10] ケーブル インターフェイス コマンドによって、アップストリーム ポートごとに連結を制御することもできます。

docsis10 パラメータを設定した場合、コマンドは DOCSIS 1.0 モードで動作するケーブル モデムだけに適用されます。

このコマンドに変更を加えると、ケーブル モデムはその変更を有効にするために CMTS 上で再登録する必要があります。影響を受けたアップストリーム上にあるモデムはリセットされる必要があります。ケーブル モデムは、モデムがオンラインになる処理の一部として登録を実行する場所で、連結が許可されるかどうかを習得します。



フラグメンテーション

大きなフレームは、アップストリームで送信するのに長い時間がかかります。この送信時間はシリアライゼーション遅延と呼ばれています。特に大きなアップストリーム フレームは送信に非常に長い時間がかかることがあるので、VoIP など、時間の影響を受けやすいサービスに属しているパケットでは害を及ぼすかたちで遅延を引き起こす可能性があります。これは長く連結されたフレームで特に当てはまります。このため、DOCSIS 1.1 にフラグメンテーションが導入されました。大きなフレームをより小さなフレームに分割し、分解バーストで送信することで、それぞれの送信にかかる時間を短縮します。

フラグメンテーションでは、大きなフレーム全体の送信を待機するのではなく、大きなフレームのフラグメントの間で、時間の影響を受ける小さなフレームがインターリーブすることが許可されています。複数のフラグメントとしてフレームを送信すると、各フラグメントに余分な DOCSIS ヘッダー セットが付随されるので、1 つのバーストで 1 つのフレームを送信することよりも少しだけ効率が落ちます。しかし、フラグメンテーションによりアップストリーム チャネルに柔軟性が追加されるので、余分なオーバーヘッドも妥当と考えることができます。

DOCSIS 1.0 モードで動作するケーブル モデムはフラグメンテーションを実行できません。

フラグメンテーションは、CMTS の Cisco uBR シリーズのアップストリーム ポートでデフォルトで有効になります。ただし、[no] cable upstream upstream-port-id fragmentation ケーブル インターフェイス コマンドによって、アップストリーム ポートごとにフラグメンテーションを有効または無効にすることができます。

このコマンドを有効にするためにケーブル モデムをリセットする必要はありません。Cisco は、フラグメンテーションを常に有効にしておくことをお勧めします。通常、フラグメンテーションは、大きなデータ フレームが時間の影響を受けやすい小さなフレームの送信または特定の定期的な DOCSIS 管理イベントの送信を干渉する可能性があると CMTS が認識しているときに発生します。

DOCSIS 1.1/2.0 ケーブル モデムに対しては、[no] cable upstream upstream-port-id fragment-force [threshold number-of-fragments] ケーブル インターフェイス コマンドですべての大きなフレームをフラグメント化することを強制できます。

デフォルトで、この機能は無効になっています。設定で threshold と number-of-fragments に値を設定しない場合、しきい値は 2000 バイトに設定され、フラグメント数は 3 に設定されます。fragment-force コマンドは、サービス フローが指定されたしきい値パラメータで送信に要求するバイト数を比較します。要求サイズがしきい値よりも大きな場合、CMTS は「number-of-fragments」と同じサイズのパートでサービス フローに帯域幅を付与します。

たとえば、特定のアップストリームの fragment-force が、threshold には 2000 バイト、number-of-fragments には 3 の値を有効にしているとします。次に、3000 バイトのバーストを送信する要求が入ってきたとします。3000 バイトは 2000 バイトの threshold よりも大きいので、フラグメント化する必要があります。number-of-fragments が 3 に設定されているので、送信時間は 1000 バイトずつ等分に分けられた 3 つになります。

個別のフラグメントのサイズが使用中のケーブル ラインカード タイプの容量を上回らないように注意します。MC5x20S ラインカードの場合、最も大きな個別フラグメントを 2000 バイト以内にする必要があり、MC28U、MC5x20U、MC5x20H などのその他のラインカードの場合は、最も大きな個別フラグメントを 4000 バイト以内にする必要があります。



Unsolicited Grant Service(UGS)

Unsolicited Grant Service(UGS)は、ケーブル モデムが帯域幅要求を送信することなく、アップストリーム サービス フローに定期的な認可を提供します。このタイプのサービスは、定期的な間隔で固定サイズのフレームを生成し、パケットの損失に対応しないアプリケーションに適しています。Voice over IP は、その典型的な例です。

UGS スケジューリング システムを、T1 や E1 回線などの Time Division Multiplexing(TDM; 時分割多重)システムでのタイムスロットと比較します。UGS は保証スループットと遅延を提供します。これが、次に固定長定期間隔の継続的なストリームを提供し、クライアントが帯域幅に対して定期的に要求したり、競合したりする必要なく送信できます。このシステムは、音声トラフィックが一般に固定長の定期的データの継続ストリームとして送信されるため、VoIP にとって最適です。

UGS は、遅延の保証がないために、ベスト エフォート スケジューリング モードでジッタとスループットを生み出していました。ベスト エフォート スケジューリング モードは、特定のフレームを特定の時間に送信できるという保証を提供せず、輻輳したシステムでは、特定のフレームがすべて送信できるという保証もありません。

UGS 形式のサービス フローが VoIP ベアラ トラフィックを運ぶには最も適切なサービス フローのタイプであるにもかかわらず、Web、電子メール、P2P などの従来からのインターネット アプリケーションには適切なものと見なされていないことに注意してください。その理由は、従来からのインターネット アプリケーションは、固定長定期間隔でデータを生成せず、事実、データをまったく送信しない時間にかなりの期間を費やす可能性があるためです。UGS サービス フローが従来からのインターネット トラフィックを運ぶために使用された場合、そのサービス フローは、アプリケーションが一時的に送信を停止するときにかなりの期間使用されない状態になる可能性があります。これは、アップストリーム帯域幅リソースの浪費を示す未使用の UGS 認可になる可能性があり、これは好ましくありません。

UGS サービス フローは、通常、DOCSIS コンフィギュレーション ファイルでプロビジョニングされるよりも、必要とされるときに動的に確立されます。統合された VoIP ポートのあるケーブル モデムは、通常、モデムがその VoIP 通話が進行中であることを検出したときに適切な UGS サービス フローを作成することを CMTS に尋ねます。

Cisco は、DOCSIS コンフィギュレーション ファイルで UGS サービス フローを設定しないことをお勧めします。その理由は、ケーブル モデムがオンラインである限り、いずれのサービスがそれを使用するかどうかに関係なく、この設定が UGS サービス フローをアクティブなままにするためです。この設定は、UGS サービス フローがケーブル モデムの代わりにアップストリーム送信時間を絶えず予約するため、アップストリーム帯域幅を浪費することになります。UGS サービス フローを動的に作成または削除することを許可する方が、必要なときに UGS がアクティブになるので、はるかに適切です。

次に、UGS サービス フローを定義する、最も一般的に使用されるパラメータを示します。

  • 任意認可サイズ(G):それぞれの定期的な認可のバイト単位のサイズ。

  • 公称認可間隔(I):認可の間のマイクロ秒単位の間隔。

  • 許容認可ジッタ(J):正確に定期的な認可から許可されたマイクロ秒単位の変動。つまり、これは、CMTS が UGS 認可を時間どおりにスケジュールしようとするときに CMTS が持っている余地です。

UGS サービス フローがアクティブのときに、すべての(I)ミリ秒で、CMTS は(G)バイト(任意認可サイズ)で送信するようにサービス フローに機会を提供します。理想的には CMTS が正確に毎(I)ミリ秒の認可を提供するのですが、最大(J)ミリ秒まで遅延する可能性があります。

図 5 は、提供された認可サイズ、認可間隔、および許容ジッタで UGS 認可がどのように割り当てられるかを具体的に示すタイムラインを示しています。

図 5:定期的な UGS 認可を示すタイムライン

upstrm_sch_config_05.gif

緑の模様の四角は、CMTS が UGS サービス フローにだけアップストリーム送信時間を提供する時間を表しています。



Real Time Polling Service(RTPS)

Real Time Polling Service(RTPS)は、サービス フローが帯域幅要求の送信に専用の時間を持つように、非コンテンション ベースの帯域幅要求機会を提供します。このユニキャスト帯域幅要求機会の使用を許可されるのは、RTPS サービス フローだけです。他のケーブル モデムは、帯域幅要求コリジョンを引き起こすことはできません。

RTPS は、効果的に動作するように、半定期的に可変長フレームを生成し、最小保証スループットを必要とするアプリケーションに適しています。IP 上のビデオ テレフォニーや複数プレーヤーのオンライン ゲームなどは典型的な例です。

RTPS は VoIP シグナリング トラフィックにも使用されます。VoIP シグナリング トラフィックは極端な低遅延またはジッタで送信される必要はありませんが、VoIP は相当の時間で CMTS に到達できる可能性が高い必要があります。ベスト エフォート スケジューリングでなく RTPS を使用する場合、音声シグナリングは繰り返す帯域幅要求コリジョンのために大幅に遅延されたり廃棄されたりはしないと確信できます。

一般に、RTPS サービス フローは次の属性を処理します。

  • 公称ポーリング間隔:ユニキャスト帯域幅要求機会の間のマイクロ秒単位の間隔。

  • 許容ポール ジッタ:正確に定期的なポールから許可されたマイクロ秒単位の変動。いいかえると、これは、CMTS が RTPS ユニキャスト帯域幅要求機会を時間どおりにスケジュールしようとするときに CMTS が持っている余地です。

図 6 は、RTPS ポールが、提供された公称ポーリング間隔と許容ポール ジッタでどのように割り当てられるかを具体的に示すタイムラインです。

図 6:定期的な RTPS ポーリングを示すタイムライン

upstrm_sch_config_06.gif

緑の模様の四角は、CMTS が RTPS サービス フローにユニキャスト帯域幅要求機会を提供する時間を表しています。

CMTS が RTPS サービス フローの代わりに帯域幅要求を受信すると、CMTS は「ベスト エフォート」サービス フローからの要求と同じように帯域幅要求を処理します。これは、前述のパラメータに加えて、最大持続トラフィック レートやトラフィック優先度などのプロパティが、RTPS サービス フロー定義に含まれる必要があることを意味します。RTPS サービス フローは、通常、サービス フローに関連付けられているトラフィックが認定帯域幅保証を確実に受信できるように、最小予約トラフィック レートも含んでいます。



Unsolicited Grant Service with Activity Detection(UGS-AD)

Unsolicited Grant Service with Activity Detection(UGS-AS)は、UGS-AS が実際にパケットを送信する必要があるときにだけ、サービス フローに UGS 形式の送信時間を割り当てます。CMTS は、ケーブル モデムが特定の期間フレームを送信していないことを検出したときに、UGS 形式の認可ではなく RTPS 形式の帯域幅要求機会を提供します。その後にサービス フローが帯域幅要求を作ることを CMTS が検出した場合、CMTS は UGS 形式の認可を提供するためにサービス フローを戻して、RTPS 形式の帯域幅要求機会の提供を停止します。

UGS-AD は、通常、Voice Activity Detection(VAD; 音声アクティビティ検出)を使った VoIP トラフィックが伝達された状況で使用されます。音声アクティビティ検出は、UGS-AD がユーザの音声で一時停止を検出した場合、VoIP エンド ポイントが VoIP フレームの送信を停止する原因になります。この動作は帯域幅を節約できますが、終端パーティが発話の再開を開始した少し後に、VAD または UGS-AD アクティビティ検出メカニズムがアクティブになる場合は特に、音声品質の問題を引き起こす可能性があります。これで、ユーザが静寂の後に発話を再開すると、ポンやカチッという音が鳴ることがあります。この理由があるため、UGS-AD は広く展開されていません。

cable service flow inactivity-threshold threshold-in-seconds グローバル CMTS 設定コマンドを発行して期間を設定すると、その後に CMTS がアクティブではない UGS-AD サービス フローを UGS モードから RTPS モードに切り替えます。

threshold-in-seconds パラメータのデフォルト値は 10 秒です。UGS-AD サービス フローは、一般に、UGS サービス フローと公称ポーリング間隔の属性、RTPS サービス フローに関連付けられた許容ポール ジッタ属性を持っています。



Non Real Time Polling Service(nRTPS)

Non Real Time Polling Service(nRTPS)スケジューリング モードは、nRTPS がファイル転送などの非対話型サービスに一般に関連付けられること以外は、RTPS と基本的に同じです。非リアルタイム コンポーネントは、ユニキャスト帯域幅要求機会用の公称ポーリング間隔が正確に定期的ではないか、1 秒ごとよりも遅いレートで発生する可能性があると示すことがあります。

ケーブル ネットワークのオペレータの中には、音声シグナリング トラフィックを運ぶのに RTPS サービス フローではなく nRTPS を使用する傾向にあるものもあります。



スケジューリング アルゴリズム

DOCSIS 準拠スケジューラと低遅延キューイング スケジューラの詳細を説明する前に、アップストリーム スケジューラの特性を判断するために、必要なトレードオフを理解する必要があります。スケジューラ アルゴリズムの説明は、主に、UGS スケジューリング モードについてですが、この説明は RTPS 形式についても同じように当てはまります。

UGS サービス フローをスケジュールする方法を決定するときに、柔軟なオプションはそれほど多くは存在しません。スケジューラに対して認可サイズを変更することや、UGS サービス フローの認可間隔を変更することはできません。その理由は、そのような変更を行うと、VoIP コールが完全に失敗するからです。ただし、ジッタを変更した場合、コールで遅延が増加する可能性があるにもかかわらず、コールは動作します。さらに、アップストリームで許可されているコールの最大数の変更は、個別のコールの品質には影響を与えません。そのため、多数の UGS サービス フローをスケジュールするときには、次の 2 つの主な要因を考慮します。

  • ジッタ

  • アップストリームごとの UGS サービス フロー容量



ジッタ

許容認可ジッタは、UGS または RTPS サービス フローの属性の 1 つとして指定されます。ただし、非常に低い許容ジッタを伴ういくつかのサービス フローと、非常に大量のジッタを伴うその他のサービス フローの同時サポートは、効率的ではない可能性があります。一般に、サービス フローがアップストリームで遭遇するジッタのタイプには、一貫した選択を行う必要があります。

低いレベルのジッタが必要とされる場合、スケジューラは、スケジュールが認可されたときには柔軟性のない、固定のものにする必要があります。結果として、スケジューラは、アップストリームでサポートされる UGS サービス フローの数に制限を設ける必要があります。

ジッタ レベルは通常のコンシューマ VoIP のために必ずしも極端に低くする必要はなく、その理由は、ジッタ バッファ テクノロジーが高いレベルのジッタに補正できるためです。現在の適応型 VoIP ジッタ バッファは、150 ミリ秒のジッタよりも多くを補正することができます。ただし、VoIP ネットワークは、パケットの遅延に対して発生するバッファリングの量を追加します。高いレベルの遅延は、VoIP の遭遇がより貧弱になる一因になります。



アップストリームごとの UGS サービス フロー容量

チャネル幅、変調方式、誤り訂正強度などの物理層属性は、アップストリームの物理容量を決定します。ただし、アップストリームがサポートできる同時 UGS サービス フローの数は、スケジューラ アルゴリズムにも依存します。

非常に低いジッタ レベルが必須ではない場合は、スケジューラの厳密さを緩めて、アップストリームが同時にサポートできる UGS サービスフローの数を増やすように便宜を図ることができます。ジッタ要件を緩めた場合、アップストリームでの非音声トラフィックの効率性を高めることができます。

注:さまざまなスケジューリング アルゴリズムは、特定のアップストリーム チャネルで UGS および RTPS サービス フローのさまざまな数をサポートするようにできます。ただし、そのようなサービスは DOCSIS システムでは 100% のアップストリーム容量を利用できません。これは、ケーブル モデムが CMTS との最初のやり取りを行うときに使用する初期メンテナンス メッセージや、ケーブル モデムが CMTS への接続性を確実に維持できるために使用するステーション メンテナンス キープアライブ トラフィックなどの DOCSIS 管理トラフィックにある部分を専用に使用する必要があるためです。



DOCSIS 準拠スケジューラ

DOCSIS 準拠スケジューラは、Cisco uBR CMTS におけるスケジューリング アップストリーム サービス用のデフォルト システムです。このスケジューラは、UGS および RTPS サービス フローが遭遇するジッタを最小化するように設計されました。ただし、このスケジューラでは、アップストリームごとの同時 UGS コールの数を最適化するために、ある程度の柔軟性を引き続き維持できます。

DOCSIS 準拠スケジューラは、UGS サービス フローより先にアップストリーム時間を事前に割り当てます。他のいずれかの帯域幅割り当てがスケジュールされる前に、CMTS はアクティブな UGS サービス フローに属している認可に対する将来の時間を取りおいておき、他のタイプのサービス フローまたはトラフィックが UGS 認可を取り換えることのないように、また、大きなジッタの原因にならないようにします。

CMTS がベスト エフォート形式サービス フローの代わりに帯域幅要求を受信した場合、CMTS は各 UGS 認可のタイムリーなスケジューリングに影響を与えないように、事前に割り当てられた UGS 認可の周りにベスト エフォート サービス フローの送信時間をスケジュールする必要があります。



設定方法

DOCSIS 準拠スケジューラは、Cisco IOS ソフトウェア リリース 12.3(9a)BCx およびそれ以前でだけ利用できるアップストリーム スケジューラ アルゴリズムです。そのため、このスケジューラには、アクティブにするために必要な設定コマンドがありません。

Cisco IOS ソフトウェア リリース 12.3(13a)BC およびそれ以降の場合、DOCSIS 準拠スケジューラは、2 つの代替スケジューラ アルゴリズムの 1 つですが、デフォルト スケジューラとして設定されます。DOCSIS 準拠スケジューラは、次のスケジューリング タイプのうち、1 つ、いくつか、すべてに対して有効にできます。

  • UGS

  • RTPS

  • NRTPS

cable upstream upstream-port scheduling type [nrtps | rtps | ugs] mode docsis ケーブル インターフェイス コマンドを使用すると、これらのスケジューリング タイプそれぞれに対して DOCSIS 準拠スケジューラを明示的に有効にできます。

DOCSIS 準拠スケジューラの使用は、デフォルト設定の一部です。そのため、非デフォルト低遅延キューイング スケジューラ アルゴリズムから戻して変更する場合にだけ、このコマンドを実行する必要があります。詳細は、「低遅延キューイング スケジューラ」セクションを参照してください。



アドミッション制御

DOCSIS 準拠スケジューラの大きなメリットは、このスケジューラにより UGS サービス フローがアップストリームをオーバーサブスクライブしないことです。新しい UGS サービス フローを確立する必要があり、余裕がないためにスケジューラが認可の事前スケジュールが不可能であることを発見した場合、CMTS は新しい UGS サービス フローを拒否します。VoIP トラフィックを運ぶ UGS サービス フローがアップストリーム チャネルをオーバーサブスクライブすることを許可された場合、すべての VoIP コールの品質は大きく低下します。

UGS サービス フローがアップストリームをオーバーサブスクライブすることはないと DOCSIS 準拠スケジューラが確約する方法を示すには、このセクションの図を参照してください。図 7、8、9 は、帯域幅割り当てタイムラインを示しています。

これらのすべての図で、色付きの模様の部分は、ケーブル モデムがその UGS サービス フローの代わりに認可を受信する場所の時間を示します。他のケーブル モデムからの他のアップストリーム送信はその時間には発生しません。タイムラインの灰色の部分は、まだ割り当てられていない帯域幅です。ケーブル モデムはこの時間を使用して帯域幅要求を送信します。CMTS は、この時間を後で使用して、他のタイプのサービスをスケジュールします。

図 7:DOCSIS 準拠スケジューラが 3 つの UGS サービス フローを事前にスケジュールする

upstrm_sch_config_07.gif

同一の認可サイズと認可間隔でさらに 2 つの UGS サービス フローを追加します。ここでも、スケジューラは問題なくそれらを事前にスケジュールします。

図 8:DOCSIS 準拠スケジューラが 5 つの UGS サービス フローを事前にスケジュールする

upstrm_sch_config_08.gif

先に進み、さらに 2 つの UGS サービス フローを追加すると、利用できるすべてのアップストリーム帯域幅を使い切ることになります。

図 9:UGS サービス フローは利用可能なすべてのアップストリーム帯域幅を消費する

upstrm_sch_config_09.gif

明らかに、スケジューラは、ここでさらに UGS サービス フローを許可することはできません。そのため、別の UGS サービス フローがアクティブになろうとすると、DOCSIS 準拠スケジューラは、さらに認可を行う余裕がないことを認識し、そのサービス フローの確立を妨げます。

注:この一連の図でわかるように、1 つのアップストリームを UGS サービス フローで全面的に満たすことは不可能です。スケジューラは、ステーション メンテナンス キープアライブやベスト エフォート データ トラフィックなどの、他の重要なタイプのトラフィックに対応する必要があります。また、DOCSIS 準拠スケジューラでオーバーサブスクリプションを回避することの保証は、すべてのサービス フロー スケジューリング モード、主に UGS、RTPS、nRTPS が DOCSIS 準拠スケジューラを使用する場合にだけ当てはまります。

DOCSIS 準拠スケジューラを使用するときに明示的なアドミッション制御設定は必要ありませんが、Cisco はアップストリーム チャネル使用率がベスト エフォート トラフィックに悪い影響を与えるようなレベルまで確実に上がらないようにすることをお勧めします。また、Cisco は、アップストリーム チャネル使用率の合計が、重要な時間の 75% を上回らないようにすることをお勧めします。これは、ベスト エフォート サービスがより高い遅延とよりゆっくりとしたスループットに遭遇し始めるレベルのアップストリーム使用率です。UGS サービスは、アップストリーム使用率に関係なく引き続き動作します。

特定のアップストリームで許可されるトラフィックの量を制限する場合は、UGS、RTPS、NRTPS、UGS-AD、またはベスト エフォート サービス フローに対して、グローバルなケーブル インターフェイスごとまたはアップストリーム コマンドごとにアドミッション制御を設定します。最も重要なパラメータは、exclusive-threshold-percent フィールドです。

cable [upstream upstream-number] admission-control us-bandwidth
scheduling-type UGS|AD-UGS|RTPS|NRTPS|BE minor minor-threshold-percent 
major major-threshold-percent exclusive exclusive-threshold-percent
[non-exclusive non-excl-threshold-percent]

次にパラメータを説明します。

  • [upstream <upstream-number>]:コマンドをケーブル インターフェイスやグローバルに適用するのではなく、特定のアップストリームに適用する場合、このパラメータを指定します。

  • <UGS|AD-UGS|RTPS|NRTPS|BE>:このパラメータは、アドミッション制御を適用するサービス フローのスケジューリング モードを指定します。

  • <minor-threshold-percent>:このパラメータは、マイナー アラームがネットワーク管理ステーションに送信される設定済みのスケジューリング タイプによってアップストリーム使用率のパーセンテージを示します。

  • <major-threshold-percent>:このパラメータは、メジャー アラームがネットワーク管理ステーションに送信される設定済みのスケジューリング タイプによってアップストリーム使用率のパーセンテージを指定します。この値は <minor-threshold-percent> パラメータに設定する値よりも高くする必要があります。

  • <exclusive-threshold-percent>:このパラメータは、指定された scheduling-type に排他的に予約されたアップストリーム使用率のパーセンテージを表します。<non-excl-threshold-percent> の値を指定しない場合、この値はこのタイプのサービス フローの使用率に対する最大の制限を表します。この値は <major-threshold-percent> 値よりも大きくする必要があります。

  • <non-excl-threshold-percent>:このパラメータは、別のスケジューリング タイプがまた使用していない限り、このスケジューリング タイプが利用できる <exclusive-threshold-percent> よりも上のアップストリーム使用率のパーセンテージを表します。

たとえば、UGS サービス フローを利用可能なアップストリーム帯域幅合計の 60% に限定すると仮定します。また、UGS サービス フローによるアップストリーム使用率のパーセンテージが 40% を超えるとネットワーク管理ステーションが通知されると仮定すると、マイナー アラームは 50% を超えて送信する必要があり、メジャー アラームを送信する必要があります。次のコマンドを発行します。

cable admission-control us-bandwidth scheduling-type UGS minor 40 major 50 exclusive 60



フラグメンテーションを使用するベスト エフォート トラフィックのスケジューリング

DOCSIS 準拠スケジューラは、事前に割り当てられた UGS 認可や RTPS 認可の周りにベスト エフォート トラフィックを単にスケジュールします。このセクションの図で、この動作を具体的に示します。

図 10:保留中のベスト エフォートの認可のスケジューリング

upstrm_sch_config_10.gif

図 10 は、アップストリームに同じ認可サイズと認可間隔が事前にスケジュールされた 3 つの UGS サービス フローがあることを示しています。アップストリームは、3 つの独立したサービス フローである A、B、C の代わりに帯域幅要求を受け取ります。サービス フロー A は中程度の量の送信時間を、サービス フロー B は小さな量の送信時間を要求し、サービス フロー C は大量の送信時間を要求しています。

ベスト エフォート サービス フローそれぞれに同じ優先度を与えます。また、CMTS が A から B、C の順にこれらの認可それぞれに対して帯域幅要求を受信すると仮定します。CMTS は、最初に同じ順序の認可に送信時間を割り当てます。図 11 は、DOCSIS 準拠スケジューラがそれらの認可を割り当てる方法を示します。

図 11:固定 USG サービス フローの認可の周りにスケジュールされたベスト エフォートの認可

upstrm_sch_config_11.gif

スケジューラは、UGS 認可の最初の 2 つのブロックの間のギャップで A および B のためにまとめて認可を押し込むことができます。ただし、C の認可は利用可能なギャップよりも大きいものです。そのため、DOCSIS 準拠スケジューラは、UGS 認可の 3 番目のブロックの周りに C の認可を、C1 と C2 という 2 つの小さな認可にフラグメント化します。フラグメンテーションは UGS 認可の遅延を防止し、これらの認可をベスト エフォート トラフィックが引き起こすジッタの影響を受けないようにします。

フラグメンテーションは、データ送信に関連付けられた DOCSIS プロトコル オーバーヘッドを少しだけ増やします。余分なフラグメントがそれぞれ送信されると、DOCSIS ヘッダーの余分なセットも送信される必要があります。ただし、フラグメンテーションがないと、スケジューラは固定の UGS 認可との間にベスト エフォートの認可を効率的にインターリーブすることができません。フラグメンテーションは、DOCSIS 1.0 モードで動作するケーブル モデムに対しては発生できません。



優先度

DOCSIS 準拠スケジューラは、認可が属しているサービス フローの優先度を基準にして割り当てを待っている認可をキューに配置します。DOCSIS の優先度は 8 つあり、0 が最低で、7 が最高です。これらの優先度は、それぞれに関連付けられたキューがあります。

DOCSIS 準拠スケジューラは、異なる優先度の認可が送信時間にいつ割り当てられるかを判断するために、厳格な優先度キューイング メカニズムを使用します。いいかえると、高優先度キューに格納されたすべての認可は、低い優先度のキューにある認可よりも前にサービスを受ける必要があります。

たとえば、DOCSIS 準拠スケジューラは、A、B、C、D、E、F の順序で短い期間に 5 つの認可を受信します。スケジューラは、認可のサービス フローの優先度に対応するキューに認可それぞれをキューイングします。

図 12:優先度が異なる認可

upstrm_sch_config_12.gif

DOCSIS 準拠スケジューラは、図 12 に模様付きブロックとして表示される事前にスケジュールされた UGS 認可の周りにベスト エフォートの認可をスケジュールします。DOCSIS 準拠スケジューラが行う最初のアクションは、最上の優先度キューをチェックすることです。この場合、優先度 7 のキューには、スケジュールを準備できる認可があります。スケジューラは、先に進み、認可 B および E の送信時間を割り当てます。事前に割り当てられた UGS 認可のタイミングと干渉しないように、認可 E がフラグメンテーションを必要とすることに注目してください。

図 13:優先度 7 の認可のスケジューリング

upstrm_sch_config_13.gif

スケジューラは、すべての優先度 7 の認可が送信時間を受信することを確認します。次に、スケジューラは優先度 6 のキューをチェックします。この場合、優先度 6 のキューは空なので、スケジューラは、認可 C を含む優先度 5 のキューに移行します。

図 14:優先度 5 の認可のスケジューリング

upstrm_sch_config_14.gif

次に、スケジューラは、すべてのキューが空になるまで、より低い優先度のキューに移動して同じ形式で処理を進めていきます。スケジュールが必要な認可が多数ある場合、新しい帯域幅要求は CMTS に到達でき、その後で DOCSIS 準拠スケジューラが保留中の認可すべてへの送信時間の割り当てを終了します。例では、この時点で CMTS が優先度 6 の帯域幅要求 G を受信すると仮定します。

図 15:優先度 6 の認可がキューイングされる

upstrm_sch_config_15.gif

認可 A、F、D が新しくキューイングされた認可 G よりも長く待機しているにもかかわらず、DOCSIS 準拠スケジューラは、G がより高い優先度であるため、G への送信時間を次に割り当てる必要があります。これは、DOCSIS 準拠スケジューラの次の帯域幅割り当てが、G、A、D の順になることを意味します(図 16 を参照)。

図 16:優先度 6 および優先度 2 の認可のスケジューリング

upstrm_sch_config_16.gif

より高い優先度の認可が途中でキューイング システムには入らないと仮定すると、スケジュールされる予定の次の認可は F です。

DOCSIS 準拠スケジューラには、例で記述されていない 2 つ以上のキューがあります。最初のキューは、ケーブル モデムをオンラインのままにするために、定期的ステーション メンテナンス キープアライブ トラフィックをスケジュールするために使用するキューです。このキューは、CMTS 定期キープアライブ トラフィックを送信するために、ケーブル モデムに対する機会をスケジュールするために使用されます。DOCSIS 準拠スケジュールがアクティブになると、このキューは他のすべてのキューよりも前に最初に提供されます。2 番目は、指定された最小の予約レート(CIR)でサービス フローに割り当てられる認可に対するキューです。スケジューラは、認定レートを伴うサービス フローが必要な最小スループットを確実に受信するように、優先度 8 のキューとしてこの CIR キューを扱います。



フラグメント化不能の DOCSIS 1.0 認可

前のセクションの例から、ジッタが事前に割り当てられた UGS 認可で誘導されないことを確実にするために、認可は、複数の部分にフラグメント化する必要があることがあります。これは、UGS トラフィックの重要な部分でアップストリーム セグメントに DOCSIS 1.0 モードで動作するケーブル モデムの問題になることがあります。その理由は、DOCSIS 1.0 ケーブル モデムが次の利用可能な送信機会に収まるには大きすぎるフレームに送信することを依頼できるためです。

ここに次の例があります。スケジューラはその順序で新しい認可 A および B を受信すると仮定します。また、両方の認可が同じ優先度を持っているものの、認可 B が DOCSIS 1.0 モードで動作するケーブル モデム用であると仮定します。

図 17:保留中の DOCSIS 1.1 および DOCSIS 1.0 認可

upstrm_sch_config_17.gif

スケジューラは、認可 A に最初に時間を割り当てようとします。次に、スケジューラは次に利用可能な送信機会を認可 B に割り当てようとします。ただし、A と UGS 認可の次のブロックの間には認可 B をフラグメント化されないままにする余裕は存在しません(図 18 を参照)。

図 18:延期された DOCSIS 1.0 認可 B

upstrm_sch_config_18.gif

この理由で、認可 B が収まる余裕がある UGS 認可の 2 番目のブロックの後まで、認可 B が遅延されます。UGS 認可の 2 番目のブロックの前に未使用の領域ができたことに注目してください。ケーブル モデムは、今回は、CMTS に帯域幅要求を送信する時間を使用しますが、これは、帯域幅の非効率的な使用を表します。

この例を再考します。スケジューラに別の 2 つの UGS サービス フローを追加します。認可 A がフラグメント化できる一方で、認可 B は UGS 認可のブロック間に収まるには大きすぎるため、フラグメント化不能な認可 B をスケジュールする機会は存在しません。この状況によって、認可 B に関連付けられたケーブル モデムは、アップストリームで大きなフレームを送信できないままになります。

図 19:DOCSIS 1.0 認可 B をスケジュールできない

upstrm_sch_config_19.gif

認可 B のための余地を作成するために、スケジューラに単にプッシュアウトを許可できたり、UGS 認可のブロックを少し遅延させることができますが、このアクションは、UGS サービス フローにジッタを引き起こします。当分の間、ジッタを最小限にすると仮定した場合、これは受け入れがたい解決策になります。

サイズが大きく、フラグメント化不能な DOCSIS 1.0 認可の問題を解決するために、DOCSIS 準拠スケジューラは、定期的にアップストリーム時間のブロックを、DOCSIS 1.0 ケーブル モデムが送信できる最も大きなフレームと同じだけの大きさになるよう事前にスケジュールします。スケジューラは、UGS サービス フローがスケジュールされる前にこれを行います。この時間は、通常、アップストリーム送信の約 2000 バイトと同等であり、「フラグメント化不能ブロック」または「UGS 空きブロック」とも呼ばれています。

DOCSIS 準拠スケジューラは、サイズの大きな DOCSIS 1.0 認可の機会が常に確実にスケジュールされるように、フラグメント化不能トラフィックに割り当てられる場合は UGS または RTPS 形式の認可を配置しません。このシステムで、フラグメント化不能 DOCSIS 1.0 トラフィック用の予約の時間は、アップストリームが同時にサポートできる UGS サービス フローの数を削減します。

図 20 は、フラグメント化不能ブロックを青い色で示し、同じ認可サイズと認可間隔の 4 つの UGS サービス フローを示しています。同じ認可サイズと認可間隔の別の UGS サービス フローをこのアップストリームに追加することはできません。その理由は、UGS 認可は、青色のフラグメント化不能ブロック領域にスケジュールすることが許可されていないためです。

図 20:フラグメント化不能ブロック:さらなる UGS 認可は許可されない

upstrm_sch_config_20.gif

フラグメント化不能ブロックが UGS 認可の期間よりも少ない頻度でスケジュールされているとしても、このブロックは、UGS 認可のすべてのブロック間でそれ自体と同じ大きさの割り当てられていない帯域幅の領域を発生させる傾向にあります。これは、大きなフラグメント化されていない認可をスケジュールする十分な機会を提供します。

認可 A と DOCSIS 1.0 の認可 B の例に戻ると、フラグメント化不能ブロックを配置した状態で、DOCSIS 準拠スケジューラは、UGS 認可の最初のブロックの後で正常に認可 B をスケジュールできることがわかります。

図 21:フラグメント化不能ブロックを使用する認可のスケジューリング

upstrm_sch_config_21.gif

DOCSIS 1.0 の認可 B は正常にスケジュールされているにもかかわらず、認可 A と UGS 認可の最初のブロックの間には未使用の領域の小さなギャップが引き続き存在します。このギャップは、帯域幅の次善の利用を表し、UGS サービスを展開するときに DOCSIS 1.1 モードのケーブル モデムを使用する必要がある理由を示します。



Cable default-phy-burst

Cisco uBR CMTS のデフォルトでは、ケーブル モデムが送信できる最大のバーストは 2000 バイトです。この値は最大のアップストリーム バースト サイズであり、DOCSIS 準拠スケジューラが使用するものとしてフラグメント化不能ブロックのサイズを計算するために使用されます。

最大バースト サイズは、cable default-phy-burst max-bytes-allowed-in-burst ケーブルごとのインターフェイス コマンドで変更できます。

<max-bytes-allowed-in-burst> パラメータの範囲は 0 〜 4096 バイトで、デフォルト値は 2000 バイトです。デフォルト値を変更する場合、この値を設定する必要のある方法について、いくつかの重要な制限事項があります。

MC5x20S ラインカードのケーブル インターフェイスの場合、このパラメータをデフォルトの 2000 バイトより上には設定しないでください。MC28U、MC5x20U、MC5x20H などのラインカードを含め、他のすべてのラインカード タイプに対して、4000 バイトでこのパラメータを設定できます。

<max-bytes-allowed-in-burst> パラメータを、ケーブル モデムが DOCSIS や 802.1q オーバーヘッドなどを送信するために必要とする最大の単一イーサネット フレームのサイズよりも低くは設定しないでください。これは、この値を約 1540 バイトよりも低く設定してはならないことを意味しています。

<max-bytes-allowed-in-burst> を特殊な値 0 に設定した場合、CMTS はアップストリーム バーストのサイズを制限するためにはこのパラメータを使用しません。その場合、DOCSIS コンフィギュレーション ファイルまたは cable upstream fragment-force コマンドで、最大連結バースト設定などのアップストリーム バースト サイズを妥当な限度に制限するために、他の変数を設定する必要があります。

最大アップストリーム バースト サイズを変更するために cable default-phy-burst を変更すると、UGS 空きブロックのサイズもそれに従って変更されます。図 22 は、cable default-phy-burst 設定を低くした場合、UGS 空きブロックのサイズが減少し、それに従って DOCSIS 準拠スケジューラがアップストリームでより多くの UGS コールを許可できることを示しています。この例では、cable default-phy-burst をデフォルト設定の 2000 からより低い値の 1600 に設定し、1 つ以上の UGS サービス フローがアクティブになる余裕を生み出しています。

図 22:削減された Default-phy-burst がフラグメント化不能ブロック サイズを減らす

upstrm_sch_config_22.gif

cable default-phy-burst コマンドによるバースト サイズの最大許容値の削減は、このコマンドにより 1 つのバースト内に連結できるフレームの数が減るため、ベスト エフォート トラフィックのアップストリームの効率を少し下げる可能性があります。また、この削減により、アップストリームでより多くの数の UGS サービス フローがアクティブになっているときに、フラグメンテーションの増大につながる可能性があります。

削減した連結バースト サイズは、ベスト エフォート サービス フローでアップロードしたデータの速度に影響を与える可能性があります。その理由は、複数のフレームの一度の送信が、各フレームに対する帯域幅要求の送信よりも速いためです。連結レベルを減らすことは、アップストリーム方向に運ばれる大量の TCP ACK パケットを連結するための減衰されたケーブル モデム能力のために、ダウンロードの速度に影響を与える可能性もあります。

ときには、アップストリームに適用される cable modulation-profile の「長い」IUC で設定される最大バースト サイズが、最大アップストリーム バースト サイズを決定する可能性があります。これは、変調プロファイル内の最大バースト サイズが cable default-phy-burst のバイト単位のサイズよりも少ないために発生することがあります。これは稀なシナリオです。ただし、cable default-phy-burst パラメータの値をデフォルトの 2000 バイトから増やした場合は、バーストを制限しないことを確認するために「長い」IUC の設定の最大バースト サイズを確認します。

アップストリーム バースト サイズのその他の制限事項は、最大の 255 ミニスロットが 1 回のバーストで送信できることです。ミニスロット サイズが最小の 8 バイトに設定された場合は、倍数になります。ミニスロットは、DOCSIS ネットワークにおけるアップストリーム送信の最も小さい単位であり、通常は 8 バイトまたは 16 バイトになります。



フラグメント化不能スロット ジッタ

アップストリームでより多くの同時 UGS フローを許可するために、DOCSIS 準拠スケジューラを微調整するもう 1 つの方法は、スケジューラに対して、フラグメント化不能のベスト エフォート トラフィックの大量のバーストで少量のジッタを UGS サービス フローに導入できるようにすることです。これは、cable upstream upstream-number unfrag-slot-jitter limit val ケーブル インターフェイス コマンドで実行できます。

このコマンドで、<val> はマイクロ秒単位で指定され、デフォルトの値は 0 です。DOCSIS 準拠スケジューラのデフォルトの動作では、UGS および RTPS のサービス フローにジッタを引き起こす原因となるフラグメント化不能の認可を許可していません。正のフラグメント化不能スロット ジッタが指定されると、DOCSIS 準拠スケジューラは、UGS 認可が理想的にスケジュールされたときから最大 <val> マイクロ秒分 UGS 認可を遅延させることができ、それによってジッタが引き起こされます。

これは、指定されたマイクロ秒数と同じ長さだけ、フラグメント化不能ブロック サイズを削減するのと同じ効果を持ちます。たとえば、default-phy-burst(2000 バイト)のデフォルト値を維持する場合、また、フラグメント化不能スロット ジッタの値を 1000 マイクロ秒に指定する場合、フラグメント化不能ブロックは削減されます(図 23 を参照)。

図 23:ゼロではないフラグメント化不能スロット ジッタがフラグメント化不能ブロック サイズを減らす

upstrm_sch_config_23.gif

注:1000 マイクロ秒時間が対応するバイト数は、チャネル幅と変調方式の設定によって動作するようにアップストリーム チャネルがどのように設定されているのかによって異なります。

注:ゼロではないフラグメント化不能スロット ジッタがあると、DOCSIS 準拠スケジューラは UGS 認可の数を増加できます。アップストリームでは default-phy-burst を削減したのと同じとして対応します。

注:サイズの大きな DOCSIS 1.1 認可 A の後にサイズの大きなフラグメント化不能の DOCSIS 1.0 認可 B が続いてアップストリームをスケジュールする例に戻ります。フラグメント化不能スロット ジッタを 1000 マイクロ秒に設定します。DOCSIS 準拠スケジューラは、このセクションの図に示すように動作します。

注:まず、スケジューラは認可 A に送信時間を割り当てます。これを行うため、UGS 認可の最初のブロックの前と後に収まるように、スケジューラは、認可を A1 と A2 にフラグメント化します。認可 B をスケジュールするために、スケジューラは、設定した 1000 マイクロ秒のフラグメント化不能スロット ジッタよりも大きくなり、UGS 認可の次のブロックへの遅延がないように、認可 A2 の後の空き領域にフラグメント化不能ブロックを収めることができるかどうかを判断する必要があります。次の図は、スケジューラが認可 A 2 の次に認可 B を配置した場合、1500 マイクロ秒を越え、UGS トラフィックの次のブロックが遅延するか、プッシュバックされることを示しています。そのため、スケジューラは、認可 A2 の直後には認可 B を配置できません。

図 24:認可 B は認可 A2 の次にはスケジュールできない

upstrm_sch_config_24.gif

DOCSIS 準拠スケジューラの次のステップは、次に利用可能なギャップが認可 B を収容できるかどうかを確認することです。図 25 は、UGS 認可の 2 番目のブロックの後に認可 B を配置する場合、3 番目のブロックは、設定した 1000 マイクロ秒のフラグメント化不能スロット ジッタよりは遅延されないことを示します。

図 25:認可 B は UGS 認可の 2 番目のブロックの後にスケジュールされる

upstrm_sch_config_25.gif

この位置に認可 B を挿入すると、UGS 認可で受け入れ不能なジッタが発生しないと認識されると、DOCSIS 準拠スケジューラは、認可 B を挿入し、UGS 認可の後に続くブロックで少しだけ遅延を発生させます。

図 26:フラグメント化不能の認可 B がスケジュールされ、UGS 認可で遅延が発生する

upstrm_sch_config_26.gif



show コマンド出力

show interface cable interface-number mac-scheduler upstream-number コマンドを使用すると、DOCSIS 準拠スケジューラの現在のステータスを測定できます。ここでは、MC28U ラインカード付きの Cisco uBR7200VXR で見られる、このコマンドの出力例を示します。

uBR7200VXR# show interface cable 3/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable3/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 0
     Queue[BE(7) Grants] 1/64, 0 drops, max 2
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 0
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 1/64, 0 drops, max 1
     Req Slots 36356057, Req/Data Slots 185165
     Init Mtn Slots 514263, Stn Mtn Slots 314793
     Short Grant Slots 12256, Long Grant Slots 4691
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 277629
     Fragmentation count 41
     Fragmentation test disabled
     Avg upstream channel utilization : 26%
     Avg percent contention slots : 73%
     Avg percent initial ranging slots : 2%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 6, Reqpolls 0, Util 27%
     UGS    : 6 SIDs, Reservation-level in bps 556800
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 35 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 0 SIDs, Reservation-level in bps 0

このセクションでは、このコマンドの出力の各行について説明します。このセクションでは、読者が一般的な DOCSIS アップストリーム スケジューリングの概念にすでに精通していることを前提としています。

  • DOCSIS 1.1 MAC scheduler for Cable3/0/U0

    コマンド出力の最初の行は、データに関連するアップストリーム ポートを示しています。

  • Queue[Rng Polls] 0/128, 0 drops, max 1

    この行は、ステーション メンテナンス キープアライブまたは DOCSIS 準拠スケジューラへのレンジング機会に供給するキューの状態を示しています。0/128 は、キュー内の最大 128 個の保留中のレンジング機会のうち現在 0 個があることを示しています。

    ドロップ(drops)カウンタは、レンジング機会の回数がこれ以上キューイングされないことを示しており、これは、このキューがすでにいっぱいであった(つまり、保留中レンジング機会が 128 個)ためです。ここでのドロップは、非常にたくさんの数のケーブル モデムがオンラインであるアップストリーム上でだけ、またはたくさんの数の UGS または RTPS サービス フローがアクティブであった場合、発生する可能性があります。このキューは、DOCSIS 準拠スケジューラが稼働するときに最も高い優先度でサービスを提供します。そのため、このキュー内でのドロップはほとんど起こりませんが、アップストリーム チャネルの深刻なオーバーサブスクリプションを示す可能性が高くなります。

    最大(max)カウンタは、show interface cable mac-scheduler コマンドが最後に実行されたときからこのキュー内にある要素の最大数を示します。これができるだけ 0 に近くなることが理想的です。

  • Queue[CIR Grants] 0/64, 0 drops, max 0

    この行は、指定された最小予約トラフィック レートでサービス フローの認可を管理するキューの状態を示します。いいかえると、このキューは、Committed Information Rate(CIR; 認定情報レート)サービス フローの認可にサービスを提供します。0/64 は、キュー内の最大 64 個の保留中の認可のうち現在 0 個があることを示しています。

    ドロップ(drops)カウンタは、CIR 認可の回数がこれ以上キューイングされないことを示しており、これは、このキューがすでにいっぱいであった(つまり、キュー内に認可が 64 個)ためです。ドロップは、UGS、RTPS、CIR 形式のサービス フローがアップストリームをオーバーサブスクライブした場合にここに累積する可能性があり、より厳密なアドミッション制御が必要であると示す可能性があります。

    最大(max)カウンタは、show interface cable mac-scheduler コマンドが最後に実行されたときからこのキュー内にある認可の最大数を示します。このキューには 2 番目に高い優先度が設定されているので、DOCSIS 準拠スケジューラは、スケジューラがベスト エフォート キューにサービスを提供する前にこのキューの要素に時間を割り当てます。

  • Queue[BE(w) Grants] x/64, y drops, max z

    次の 8 つのエントリは、優先度 7 から 0 のサービス フローの認可を管理するキューの状態を示しています。これらのエントリのフィールドは CIR キュー エントリのフィールドと同じ意味を持ちます。このグループでサービスを受ける最初のキューは、BE (7) キューであり、最後にサービスを受けるキューは BE (0) キューです。

    ドロップは、より高い優先度レベルのトラフィックがアップストリーム帯域幅すべてを消費する場合、または UGS、RTPS、CIR 形式のサービス フローのあるアップストリームのオーバーサブスクリプションが発生する場合に、これらのキューで発生することがあります。これは、大量のサービス フローの DOCSIS 優先度を再評価する必要性、またはアップストリームにより厳密なアドミッション制御を行う必要性を示しています。

  • Req Slots 36356057

    この行は、アップストリームがアクティブ化されてからアドバタイズされている帯域幅要求機会の数を示しています。この数は継続して増加する必要があります。

  • Req/Data Slots 185165

    このフィールドがアップストリームでアドバタイズされた要求またはデータ機会の数を示すことをその名前が示唆しているにもかかわらず、実際には、このフィールドは、高度なスペクトル管理機能を促進するために CMTS がアドバタイズする期間の数を示しています。このカウンタは、MC28U および MC520 形式のラインカードでアップストリーム用に増分することが予想されています。

    要求/データ機会は、ケーブル モデムがこれらの期間にデータの小さなバーストも送信できること以外は、帯域幅要求機会と同じです。Cisco uBR シリーズ CMTS は、現在は実際の要求/データ機会をスケジュールしていません。

  • Init Mtn Slots 514263

    この行は、アップストリームがアクティブ化されてからアドバタイズされている初期メンテナンス機会の数を表しています。この数は継続して上昇する必要があります。CMTS への接続を確立する初期試行を行うケーブル モデムは、初期メンテナンス機会を使用します。

  • Stn Mtn Slots 314793

    この行は、ステーション メンテナンス キープアライブまたはアップストリームで提供されるレンジング機会の数を示しています。アップストリームにケーブル モデムがオンラインで存在する場合、この数は継続的に上昇する必要があります。

  • Short Grant Slots 12256, Long Grant Slots 4691

    この行は、アップストリームで提供されるデータ認可の数を示しています。アップストリーム データを送信するケーブル モデムが存在する場合、これらの数は継続的に上昇する必要があります。

  • ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0, ATDMA UGS Grant Slots 0

    この行は、アップストリームで Advanced Time Division Multiple Access(ATDMA)モードに提供されるデータ認可の数を表します。DOCSIS 2.0 モードで動作し、アップストリーム データを送信するケーブル モデムが存在する場合、これらの数は継続的に上昇する必要があります。ATDMA は個別に UGS トラフィックを説明しています。

  • Awacs Slots 277629

    この行は、高度なスペクトル管理専用の期間数を表示します。高度なスペクトル管理が発生するためには、CMTS は、内部スペクトル分析機能が各ケーブル モデムからの信号品質を評価できるように、各ケーブル モデムが短い送信を作成する必要のある時間を定期的にスケジュールする必要があります。

  • Fragmentation count 41

    この行は、アップストリーム ポートが受信するためにスケジュールされるフラグメントの合計数を示します。たとえば、3 つの部分にフラグメント化されたフレームは、このカウンタを 3 つ増分させます。

  • Fragmentation test disabled

    この行は、test cable fragmentation コマンドが起動されていないことを示しています。このコマンドは本番ネットワークでは使用しないでください。

  • Avg upstream channel utilization: 26%

    この行は、アップストリーム送信による現在のアップストリーム チャネルの使用率を示しています。これは、ショート、ロング、ATDMA ショート、ATDMA ロング、ATDMA UGS 認可によって作成された送信を含んでいます。この値は、ローリング平均として毎秒計算されます。Cisco は、ピーク使用時間中の拡張基準に基づいて、この値が 75% を超えないようにすることを推奨します。それ以外の場合、エンド ユーザは、ベスト エフォート トラフィックでパフォーマンス問題の通知を開始できます。

  • Avg percent contention slots: 73%

    この行は、帯域幅要求専用のアップストリーム時間のパーセンテージを示します。これは、アップストリームの空き時間の量と同じであり、そのため、Avg upstream channel utilization のパーセンテージが増えると減ります。

  • Avg percent initial ranging slots: 2%

    この行は、ケーブル モデムが CMTS との初期接続を確立しようとするときに使用する初期レンジング機会専用に使用されるアップストリーム時間のパーセンテージを示します。この値は、常に合計使用率の低いパーセンテージのままである必要があります。

  • Avg percent minislots lost on late MAPs: 0%

    この行は、CMTS が帯域幅割り当て MAP メッセージを時間内にケーブル モデムに送信できなかったため、スケジュールされていなかったアップストリーム時間のパーセンテージを示しています。このパラメータは、常に 0 に近い値にする必要がありますが、過剰に高い CPU 負荷のあるシステムではより大きな値で始まる可能性があります。

  • Sched Table Rsv-state:Grants 0, Reqpolls 0

    この行は、DOCSIS 準拠スケジューラ内でサービス フローに対して事前に割り当てられた認可を持っているものの、まだアクティブ化されていない UGS 形式のサービス フロー(Grants)または RTPS 形式のサービス フロー(Reqpolls)の数を示しています。これは、既存の UGS または RTPS サービス フローのあるケーブル モデムを、あるアップストリームから別のアップストリームへ、ロード バランシングによって移動するときに発生します。この値は、DOCSIS 準拠スケジューラを使用する認可に対してのみ当てはまり、LLQ スケジューラを使用するものには当てはまらないことに注目してください。

  • Sched Table Adm-State:Grants 6, Reqpolls 0, Util 27%

    この行は、このアップストリームに対して DOCSIS 準拠スケジューラ内でサービス フローに対して事前に割り当てられた認可を持っている、UGS 形式のサービス フロー(Grants)または RTPS 形式のサービス フロー(Reqpolls)の数を示しています。Util は、これらのサービス フローによる利用可能な合計アップストリーム帯域幅の予想使用率です。この値は、DOCSIS 準拠スケジューラを使用する認可に対してのみ当てはまり、LLQ スケジューラを使用するものには当てはまらないことに注目してください。

  • <Scheduling-type> :x SIDs, Reservation-level in bps y

    この行は、アップストリームに提示される <Scheduling-type> サービス フローまたは SID の数、およびこれらのサービス フローが予約されているビット/秒単位の帯域幅の量を示します。ベスト エフォートと RTPS 形式のサービス フローに対して、帯域幅は、サービス フローが設定されている最小の予約レートである場合にだけ予約されます。



DOCSIS 準拠スケジューラのメリットとデメリット

DOCSIS 準拠スケジューラの目標は、UGS および RTPS 形式のサービス フローに対するジッタを最小化することであり、また、フラグメント化不能な DOCSIS 1.0 バーストに対応することです。DOCSIS 準拠スケジューラが、これらの目標を達成するために行うトレードオフは、アップストリームごとにサポートされる UGS サービス フローの最大数が、DOCSIS アップストリームが物理的にサポートでき、また、ベスト エフォート トラフィックがフラグメンテーションの程度に従うことのできる理論的な最大値よりも少ないことです。

DOCSIS 準拠スケジューラがアップストリーム上の同時 UGS サービス フローの理論的な最大数よりも少し少ない数をサポートし、また、他のいくつかのスケジューリング実装がアップストリームごとの UGS サービス フローよりも多くをサポートできる一方で、トレードオフには集中する必要があります。

たとえば、アップストリーム チャネルの 100% の帯域幅に近い値を消費し、同時に DOCSIS 1.0 モデムからのフラグメント不能な大量の連結フレームを同時にサポートする、ジッタのない UGS サービス フローをサポートできるスケジューラは存在しません。DOCSIS 準拠スケジューラの設計を考慮すれば、理解すべき重要な点が 2 つあります。

  • 75% は、望ましい最大アップストリーム使用率です。

    Cisco は、UGS サービス フローによる使用率を含め、アップストリームが 75% の使用率を超えて動作すると、ベスト エフォート トラフィック パフォーマンスが著しく影響を受けることがわかりました。これは、UGS と VoIP のシグナリングが 75% より多くのアップストリームを消費している場合、ベスト エフォート サービス フローによって運ばれる通常の IP トラフィックが著しく低いスループットと応答時間を引き起こす付加遅延の影響を受け始めるということです。このより高い使用率レベルのパフォーマンスの低下は、イーサネットやワイヤレス LAN などの現在のほとんどのマルチアクセス ネットワーク システムが共有しているプロパティです。

  • 3.2MHz の一般的に展開されたアップストリーム チャネルが使用された場合、DOCSIS 準拠スケジューラは、UGS サービス フローがアップストリーム チャネルの約 75% まで使用することを許可します。これらのサービス フローは G.711 VoIP コールを運びます。

これらの 2 つのポイントは、DOCSIS 準拠スケジューラが構築されたときの設計上の考慮事項の参考になります。DOCSIS 準拠スケジューラは、一般的な UGS サービス フロー(G.711)のためと、最も一般的に展開された 3.2MHz のチャネル幅で設計されており、アップストリーム制限ごとのコールは、75% の使用率マークで適用を開始します。これは、スケジューラがジッタを正常に最小化していることと、アップストリームに妥当な数の UGS サービス フローも許可していることを意味しています。

いいかえると、DOCSIS 準拠スケジューラは、実稼働 DOCSIS ネットワークで適切に動作するように設計されており、UGS サービス フローが非現実なほど高いアップストリーム帯域幅のパーセンテージを使用し尽くすことは許可しないように設計されています。このシナリオは、人為的な実験テスト シナリオで発生させることができます。

DOCSIS 準拠スケジューラを微調整すると、UGS ジッタとベスト エフォート トラフィック効率の損失にもかかわらず、アップストリームごとの UGS コールの増分する数に対応できます。このため、cable default-phy-burst パラメータを推奨最小設定の 1540 バイトに減らす必要があります。さらにコール密度が必要な場合は、cable upstream unfrag-slot-jitter を 2000 マイクロ秒などの値に設定します。ただし、Cisco は実稼働ネットワークにこのような設定を一般に行うことは推奨しません。

DOCSIS 準拠スケジューラの別のメリットは、CMTS オペレータが UGS や RTPS 形式のサービス フロー用にアドミッション制御を明示的に設定する強制的な要件が存在しないことです。これは、事前割り当てスケジュール方式によって、偶然のオーバーサブスクリプションの可能性が削減されるためです。これが当てはまる場合であっても、Cisco は、オペレータがアップストリーム使用率の合計がピーク時間の拡張期間に 75% を上回らないように注意するよう、引き続き提案します。そのため、Cisco はベスト プラクティスとしてアドミッション制御の設定を推奨します。

DOCSIS 準拠スケジューラの 1 つの障害は、UGS 認可の固定の位置は、UGS 使用率が高いときにベスト エフォートの認可のフラグメンテーションを要求できることです。一般に、フラグメンテーションは、著しいパフォーマンスの問題を発生させませんが、ベスト エフォート トラフィックへの遅延が少し上昇し、アップストリーム チャネルに提示されるプロトコル オーバーヘッドが増加します。

もう 1 つの障害は、DOCSIS 1.0 ケーブル モデムが大規模なフラグメント化不能なアップストリーム送信を作成する必要があるとき、事前にスケジュールされた UGS 認可のブロック間に適切なギャップが現れる前に遅延が存在する可能性があることです。また、これは、DOCSIS 1.0 アップストリーム トラフィックの遅延が増加することと、利用可能なアップストリーム送信時間が最適よりも下回って使用されることにもつながります。

最後に、DOCSIS 準拠スケジューラは、すべての UGS サービス フローが同一の認可サイズと認可間隔を共有する環境で最適に動作するように設計されます。つまり、すべての VoIP コールは、典型的な Packetcable 1.0 ベースのシステムで発生するような 10 ミリ秒または 20 ミリ秒のパケット化 G.711 など、同一のコーデックを共有します。まったく異なる認可間隔とサイズが提示されると、大量の UGS サービス フローをサポートする DOCSIS 準拠スケジューラの容量がアップストリームで減少します。さらに、スケジューラが異なる期間とサイズで UGS サービス フローをインターリーブしようとするときに非常に少ないジッタ(2 ミリ秒未満)がいくつかの認可で発生する可能性があります。

PacketCable MultiMedia(PCMM)ネットワークが広く普及し始めると、さまざまなパケット化間隔のあるさまざまな VoIP コーデックが同時操作に存在することがさらに一般的になる可能性があります。この種の環境は、それ自体が低遅延キューイング スケジューラに役立つ可能性があります。



低遅延キューイング スケジューラ

Low Latency Queueing(LLQ; 低遅延キューイング)スケジューラは、Cisco IOS ソフトウェア リリース 12.3(13a)BC で導入されました。LLQ は、Cisco uBR CMTS でアップストリーム サービスをスケジュールする代替方法です。このスケジューラは、アップストリームが同時にサポートでき、また、UGS サービス フローが存在するときにベスト エフォート トラフィックの効率を強化する UGS および RTPS 形式のサービス フローの数を最大化するように設計されました。トレードオフは、LLQ スケジューラが UGS および RTPS サービス フロー用のジッタを考慮した保証を行わないことです。

DOCSIS 準拠スケジューラ」で説明したように、DOCSIS 準拠スケジューラは、UGS および RTPS 形式のサービス フローに対して事前に送信時間を割り当てます。これは、遅延 Time Division Multiplexing(TDM; 時分割多重)システムが、特定の遅延とジッタ レベルを保証するために帯域幅をサービスに割り当てる方式に似ています。

現在のパケット ベースのネットワークでは、低遅延キューイングは、高い優先度サービスに関連付けられたパケット、たとえば、音声やビデオなどが他のより低い優先度のパケットよりも前にネットワークに確実に配信できるようにルータが使用する方法です。また、これは、遅延とジッタが重要なトラフィック用に確実に最小化されるために現在のルータが使用する方法でもあります。

TDM ベースのシステムに対する「保証」という単語と LLQ ベースのシステムに対する「最小化する」という単語は、ジッタと遅延に関連して使用されます。ゼロ遅延とジッタの保証が望ましいことの一方で、そのトレードオフは、そのようなシステムが、通常は柔軟性がなく、再設定が難しく、ネットワーク状態の変更を簡単に適応することが一般にできないことです。

厳密な保証を提供することよりも、遅延とジッタを最小化するシステムは、ネットワーク状態の変更に直面すると、継続的にそれ自体を最適化するために柔軟性を発揮できます。低遅延キューイング スケジューラは、パケット/ルータ ベースの LLQ システムと類似した方式で動作します。UGS 認可に対し、事前に割り当てをスケジュールするシステムとは異なり、このシステムは、スケジュールされる必要のあるポイントで「できるだけすぐに」認可をスケジュールします。

UGS サービス フローに対して認可するアプローチはできるだけ早く割り当てる必要がありますが、完全な周期性を持つ必要はなく、このシステムは、増加した UGS 容量とより少ないベスト エフォート データ フラグメンテーションに対して厳密なジッタ保証のトレードオフになります。



設定方法

Cisco IOS ソフトウェア リリース 12.3(13a)BC 以降では、LLQ スケジューラは 2 つの代替スケジューラ アルゴリズムの 1 つです。次のスケジューリング モードの 1 つ、すべて、またはいくつかに対して LLQ を有効にできます。

  • UGS

  • RTPS

  • NRTPS

LLQ スケジューラはデフォルトでは有効にはされません。必要なアップストリーム スケジューリング タイプに対して LLQ スケジューラを明示的にオンにする必要があります。cable upstream upstream-port scheduling type [nrtps | rtps | ugs] mode llq ケーブル インターフェイス コマンドを使用します。

一般に、これが希望するスケジューリング モードである場合、リストされているすべてのスケジューリング モードに対して LLQ スケジューラを有効にできます。次に示すのは、1 つのタイプのスケジューリング モードだけに LLQ スケジューリングを有効にし、他に対しては DOCSIS 準拠スケジューラを維持する状況の例です。

RTPS サービス フローには、ジッタ用の厳密な要件はありませんが、UGS サービス フローにはあります。この場合、RTPS サービス フローに LLQ スケジューラを有効にして、UGS に DOCSIS 準拠スケジューラを維持することができます。



LLQ スケジューラの動作

LLQ スケジューラは、他のすべてのキューよりも優先される特別な Low Latency Queue(LLQ; 低遅延キュー)に加えて、DOCSIS 準拠スケジューラの優先度キューイング機能と同じように動作します。

LLQ スケジューラは、アクティブなすべての UGS(および RTPS)形式のサービス フローの代わりにタイマーを開始します。タイマーは、すべての「認可間隔」がオフになるように設定されます。タイマーが時間切れになると、いつでも、UGS 認可が LLQ キューにキューイングされます。この認可が最高の優先度のある LLQ キューに配置されると、認可は、空き領域のある次の可能な瞬間にスケジュールされます。

このセクションの図では、同一の認可間隔のある 3 つのアクティブな UGS サービス フローのシステム例を示しています。図 27 は、左側に UGS-1 から UGS-3 までのラベルの付いた UGS サービス フローのタイマーを示しています。黄色の針は時計回りに動きます。黄色の針が赤の点に向かって上方に移動すると、UGS 認可が LLQ キューに追加されます。また、0 から 7 までの 8 つのおなじみの優先度キューと、これらすべてよりも優先される新しい LLQ キューがあります。最後に、右側にあるのは、認可がアップストリームでスケジュールされる方法を説明する帯域幅割り当てタイムラインです。追加した説明をわかりやすくするため、帯域幅割り当てタイムラインには、「現在の時間」ポインタが含まれます。このポインタは、例が進むにつれ、タイムラインに従って前に移動します。

図 27:低遅延キューイング システム

upstrm_sch_config_27.gif

最初に発生するイベントは、左上にある UGS-1 タイマーが時間切れになることです。対応する認可は LLQ キューにキューイングされます。同時に、優先度 2 の A というベスト エフォートの認可がキューイングされます。

図 28:UGS-1 の認可と優先度 2 の認可 A がキューイングされる

upstrm_sch_config_28.gif

LLQ スケジューラは、現在、優先度の順序で保留中の認可に送信時間を割り当てています。送信時間を受信する最初の認可は、LLQ キューで待機する UGS-1 の認可です。認可 A が続きます。

図 29:認可 UGS-1 および認可 A には送信時間が割り当てられる

upstrm_sch_config_29.gif

次に発生するイベントは、UGS-2 タイマーが時間切れであり、UGS-2 サービス フローの認可が LLQ キューでキューングされるようになります。同時に、優先度 0 の認可 B がキューイングされ、優先度 6 の認可 C がキューイングされます。

図 30:UGS-2 タイマーが時間切れになり、認可 B と C がキューイングされる

upstrm_sch_config_30.gif

LLQ スケジューラは、もう一度、優先度の順序に従って送信時間を割り当てます。ここでは、まず、UGS-2 認可、次に認可 C、最後に認可 B への順序で時間を割り当てます。

図 31:認可 UGS-2、C、および B は送信時間を割り当てられる

upstrm_sch_config_31.gif

ベスト エフォートの認可が一時的にスケジューラに入らないと仮定します。UGS タイマーそれぞれはさらに 2、3 回時間切れになります。これで、スケジューラが UGS サービス フローに認可を割り当てる期間の種類を確認できます。これらは等間隔で現れます。認可が帯域幅割り当てタイムライン上で互いに関連してこのように表示されるときに、大きなジッタは発生しないと仮定します。

図 32:UGS-1、UGS-2、UGS-3 が多数の認可を受け取り、認可 D がキューイングされる

upstrm_sch_config_32.gif

図 32 は、次の UGS-2 認可の理想的な位置を示しています。UGS-2 の認可がこの位置に配置された場合、UGS-2 のこの認可に対するジッタは発生しません。次の UGS-2 認可を LLQ キュー内にキューイングする時間がまだあることに注意してください。

図 32 は、また、非常に大きな優先度 0 の認可 D が優先度 0 のキューにちょうど入ったばかりであることも示しています。LLQ スケジューラが次に行うアクションは、認可 D の送信時間をスケジュールすることです。

図 33 はこのシナリオを表示しています。次の UGS-2 の認可がキューイングされる時点に少しだけ時計を進めます。

図 33:認可 D は送信時間を受け取り、UGS-2 の認可がキューイングされる

upstrm_sch_config_33.gif

認可 D は、次の UGS-2 認可がゼロ ジッタ用にスケジュールされる必要があるときにスケジュールされるようです。ここで、問題になるのは、なぜ LLQ スケジューラは認可 D をその時点でスケジュールされるようにし、UGS-2 の認可の後まで認可 D を遅延しないのか、また、なぜ D がフラグメント化されないのかです。その答えは、LLQ スケジューラが UGS サービス フローの送信時間を事前に割り当てないからです。そのため、LLQ スケジューラは、UGS 認可が帯域幅割り当てタイムライン上に配置される場所を事前にはわかりません。LLQ スケジューラは、LLQ キューでキューイングされるまで、UGS 認可を認識しません。この例では、UGS-2 の認可がキューに入るときには、認可 D はすでにスケジュールされています。

LLQ スケジューラは、次の利用可能な機会で UGS-2 の認可をスケジュールしますが、この認可は理想的な位置からは少し遅れることになります。定義によると、この特定の認可でいくらかのジッタが発生したことになります。

図 34:UGS-2 の認可は遅延され、ジッタが発生する

upstrm_sch_config_34.gif

DOCSIS 準拠スケジューラがこのジッタを回避できる一方で、LLQ スケジューラは、少量のジッタを犠牲にしただけで認可 D の遅延またはフラグメンテーションを回避します。VoIP エンドポイントのジッタ バッファは、このジッタを簡単に相殺できます。

複数のサービス フローの LLQ タイマーが同時に時間切れになり、UGS 認可が LLQ キュー内にキューイングされた他の UGS 認可の後ろで待機している場合にも、ジッタが発生する可能性があります。LLQ スケジューラは、この発生の可能性を最小にするために設計されてきました。スケジューラは、サービス フロー タイマーの有効期限を自動的に広げます。

DOCSIS 準拠スケジューラによると、LLQ スケジューラには、例で説明されていないさらに 2 つのキューがあります。次にキューを示します。

  1. 最初のキューは、ケーブル モデムをオンラインに維持するために定期的なステーション メンテナンス キープアライブ トラフィックをスケジュールするために使用します。このキューは、LLQ キューのすぐ後にサービスされます。

  2. 2 番目は、最小の予約レートを伴うサービス フロー(CIR サービス フロー)に割り当てられた認可のためのキューです。この CIR キューは、認定レートを伴うサービス フローが必要な最小のスループットを確実に受信するために、「優先度 8」キューとして扱われます。



アドミッション制御

DOCSIS 準拠スケジューラとは異なり、LLQ スケジューラは UGS および RTPS サービス フローを伴うアップストリームの偶発的なオーバーサブスクリプションを停止する事前にスケジュールされるシステムを使用しません。このため、LLQ スケジューラを使用するアップストリームに対してアップストリーム アドミッション制御を明示的に設定する必要があります。この設定は、UGS サービス フローの合計アップストリーム帯域幅が制限を超過しないようにします。

一般に、Cisco はアップストリーム チャネルの使用率が、ピーク使用期間中に長期間 75% を超過することを許可しないように提案しています。たとえば、UGS トラフィックがアップストリーム帯域幅の 75% 以上を消費した場合、ベスト エフォート データは過剰な遅延とスループット パフォーマンスの問題にさらされ始めます。

CMTS オペレータがベスト エフォート トラフィックのマイナスの結果を受け付けられる場合、UGS サービス フローが利用可能なアップストリーム帯域幅の 75% よりも多く消費させることができます。ただし、アップストリーム チャネルでレイヤ 2 管理トラフィックへの影響も検討する必要もあります。初期およびステーション メンテナンス メッセージング(ケーブル モデム キープアライブ)の時間を考慮する必要があります。これを考慮しない場合、また、UGS トラフィックが 100% に近い帯域幅を消費する場合、ケーブル モデムはオンラインになれないかオフラインになる可能性があります。

次に示すのはアドミッション制御の設定例です。この例は、アップストリームの利用可能な帯域幅の 50% に特定のアップストリームの UGS サービス フローを制限します。このコマンドの形式も、また、30% と 40% の使用率のマイナーとメジャーのしきい値に到達するときに、SNMP トラップを設定済みのネットワーク管理ステーションに送信します。コマンドは次のとおりです。

cable upstream upstream-number admission-control us-bandwidth scheduling-type UGS minor 30 major 40 exclusive 50

アドミッション制御の設定方法について、このドキュメントの「DOCSIS 準拠スケジューラ」の「アドミッション制御」を参照してください。



show コマンド出力

show interface cable interface-number mac-scheduler upstream-number コマンドを発行すると、LLQ スケジューラの現在のステータスを測定できます。

このコマンドの出力例を次に示します。DOCSIS 準拠スケジューラが動作しているときと異なる部分は太字で示します。

uBR7200VXR# show interface cable 5/0 mac-scheduler 0
     DOCSIS 1.1 MAC scheduler for Cable5/0/U0
     Queue[Rng Polls] 0/128, 0 drops, max 1
     Queue[CIR Grants] 0/64, 0 drops, max 2
     Queue[BE(7) Grants] 0/64, 0 drops, max 0
     Queue[BE(6) Grants] 0/64, 0 drops, max 0
     Queue[BE(5) Grants] 0/64, 0 drops, max 0
     Queue[BE(4) Grants] 0/64, 0 drops, max 0
     Queue[BE(3) Grants] 0/64, 0 drops, max 2
     Queue[BE(2) Grants] 0/64, 0 drops, max 0
     Queue[BE(1) Grants] 0/64, 0 drops, max 0
     Queue[BE(0) Grants] 0/64, 0 drops, max 5
     Queue[LLQ Grants] 0/64, 0 drops, max 3
     Req Slots 165488850, Req/Data Slots 871206
     Init Mtn Slots 1727283, Stn Mtn Slots 1478295
     Short Grant Slots 105668683, Long Grant Slots 52721
     ATDMA Short Grant Slots 0, ATDMA Long Grant Slots 0
     ATDMA UGS Grant Slots 0
     Awacs Slots 1303668
     Fragmentation count 11215
     Fragmentation test disabled
     Avg upstream channel utilization : 6%
     Avg percent contention slots : 91%
     Avg percent initial ranging slots : 3%
     Avg percent minislots lost on late MAPs : 0%
     Sched Table Rsv-state: Grants 0, Reqpolls 0
     Sched Table Adm-State: Grants 0, Reqpolls 0, Util 1%
     UGS    : 3 SIDs, Reservation-level in bps 278400
     UGS-AD : 0 SIDs, Reservation-level in bps 0
     RTPS   : 0 SIDs, Reservation-level in bps 0
     NRTPS  : 0 SIDs, Reservation-level in bps 0
     BE     : 14 SIDs, Reservation-level in bps 0
     r4k ticks in 1ms 600000
     Total scheduling events 5009
     No search was needed 5009
     Previous entry free 0
     Next entry free 0
     Could not schedule 0
     Recovery failed 0
Curr time 1341 entry 61
Entry 188, Bin 13
    SID: 416 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 13
Entry 188, Bin 14
    SID: 414 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 188, skew from ref 0, priority 10
    position 188, bin 14
Entry 192, Bin 12
    SID: 415 IUC: 5, size_ms: 17 size_byte: 232 Frag: N Inval: 20
    type 8, perfect time ref 192, skew from ref 0, priority 10
    position 192, bin 12

この出力にある標準文字の行の説明については、DOCSIS 準拠スケジューラの「show コマンド出力」セクションを参照してください。

show コマンド出力の太字で示した行について説明します。

  • Queue[LLQ Grants] 0/64, 0 drops, max 3

    この行は LLQ キューの状態を示し、それは、cable upstream scheduling type [nrtps | rtps | ugs] mode llq コマンドで指定されたサービス フロー タイプの認可を管理します。0/64 は、キュー内の最大 64 個の保留中の認可のうち現在 0 個があることを示しています。

    ドロップ(drops)カウンタは、このキューがすでにいっぱいであった(64 個の認可がキュー内にある)ため、UGS 認可または RTPS ポールをキューイングすることができなかったスケジューラの回数を示しています。このキューでドロップが発生する場合、最も適切な説明として、アップストリームが UGS または RTPS のサービス フローでオーバーサブスクライブされており、より厳密なアドミッション制御を適用する必要があります。

    最大(max)カウンタは、show interface cable mac-scheduler コマンドが最後に実行されたときからこのキュー内にある認可の最大数を示します。存在するときに、このキューにはリストされたすべてのキューの最も高い優先度があります。

  • r4k ticks in 1ms 600000

    このフィールドは、認可が高い精度で LLQ キューに配置されるようにするために LLQ スケジューラが使用する内部タイミング変数を表します。

  • Total scheduling events 5009

    この行は、show interface cable mac-scheduler コマンドがこのアップストリームで最後に実行されたときから、LLQ スケジューラが認可をキューイングしようとする回数を示します。このカウンタは、show コマンドが実行されるたびにリセットされます。

  • No search was needed 5009

    LLQ スケジューラは、認可をキューイングした後、次回のキューイングを準備するためにサービス フロー タイマーをリセットしようとします。タイマーのリセットで問題がない場合、このカウンタは増分します。このカウンタは、理想的には Total scheduling events カウンタと同じ値を持つ必要があります。

  • Previous entry free 0, Next entry free 0

    これらのカウンタはどちらも Cisco IOS ソフトウェアの現在のリリースで増分されます。これらのカウンタは常に 0 のままになります。

  • Could not schedule 0, Recovery failed 0

    この行は、LLQ スケジューラが適切に設定されるサービス フローの認可タイマーの調整ができなかった回数を示します。これは、LLQ スケジューラが非常に短い認可間隔で極端に大きな認可を処理する場合にのみ発生する必要があります。これらのカウンタが実稼働ネットワークで増分されることはほとんどありません。これらのカウンタの増分は、UGS および RTPS サービス フローがアップストリームで物理的に利用可能な帯域幅を超えて消費することを示す可能性があります。その場合、適切なアドミッション制御コマンドを実行する必要があります。

  • Curr time 1341 entry 61

    この行は、ミリ秒単位で計測された LLQ スケジューラの内部タイマーを示しています。この「entry」がサービス フロー統計における「Entry」フィールドと同じである場合、認可が LLQ キューにキューイングされています。

これらの統計は、LLQ スケジューラが処理するサービス フローそれぞれで繰り返されます。この例では、そのようなサービス フローが 3 つあります。

  • Entry 188, Bin 13

    「Entry」値が前述の「entry」フィールドと同じであると、このサービス フローのタイマーは時間切れになり、認可は LLQ キューに移動します。このフィールドは、サービス フローが認可をキューイングするたびにリセットされます。

  • SID: 416

    LLQ スケジューラがスケジュールする認可のサービス フロー向けの Service Identifier(SID)です。

  • IUC: 5

    このサービス フローに属している認可の MAP メッセージ内でアドバタイズされる間隔用法コードです。UGS 形式のサービス フローが使用中であるとき、通常「Short data」に対しては 5、「Long Data」に対しては 6、「Advanced PHY UGS」に対しては 11 です。RTPS 形式のサービス フローの場合、この値は「Request」に対して常に 1 です。

  • size_ms:17 size_byte: 232

    ミニスロット単位の認可のサイズであり、その後ろにバイト単位の認可のサイズが続きます。ミニスロットは、DOCSIS ネットワークにおけるアップストリーム送信の最も小さい単位であり、通常は 8 バイトまたは 16 バイトになります。

  • Frag:N

    認可がフラグメント化可能かどうかを示します。現在この値はいつも N に設定されています。

  • Inval: 20

    ミリ秒単位の認可またはポーリング間隔です。

  • type 8

    8 は、このサービス フローが UGS であることを示し、10 は RTPS を示し、11 は NRTPS を示します。

  • perfect time ref 188

    この認可がスケジュールされるにあたっての理想な時間です。これは、通常は先頭にある「Entry」と同じです。違う場合は、より厳密なアドミッション制御を必要とする非常に輻輳したアップストリームが示されます。

  • skew from ref 0

    この認可がスケジュールされた時間と、この認可がスケジュールされるにあたっての理想の時間の差です。これは、「Entry」と「perfect time ref」の差です。そのため、この値は通常は 0 になる必要があります。

  • priority 10

    Cisco IOS ソフトウェアの現在のリリースでは、この値は常に 10 に設定されますが、将来は変わる可能性があります。

  • position 188, bin 13

    これらのフィールドは、このリストの最初にある「Entry, Bin」と同じである必要があります。



LLQ スケジューラのメリットとデメリット

LLQ スケジューラの目標は、アップストリーム チャネルの UGS と RTPS の容量を増やすことと、ベスト エフォート トラフィックの効率を上げることです。LLQ スケジューラがこれらの目標を達成するために行うトレードオフは、このスケジューラが UGS および RTPS サービス フロー ジッタに保証を明示的に提供しないことです。それよりも、LLQ スケジューラは、ジッタを最小化するためにできるだけ表示付きで理想的な時間に近くするように UGS 認可と RTPS ポールをスケジュールします。

また、LLQ スケジューラは、OCSIS 準拠スケジューラよりも、異なる認可間隔と認可サイズの複数の UGS サービス フローをよりよく処理することもできます。この機能は、異なるタイプの VoIP コールが存在する PCMM 環境で役に立つ可能性があり、また、他のアプリケーションは、1 つのアップストリーム チャネルですべて同時にサービスを提供される可能性があります。

LLQ スケジューラは認可のフラグメンテーションの可能性を削減するので、LLQ スケジューラはより効率的にベスト エフォート トラフィックをスケジュールします。フラグメント化不能な DOCSIS 1.0 バーストがスケジュールされると、LLQ スケジューラは DOCSIS 準拠スケジューラがときおり行うような UGS 認可または RTPS ポールの前に未使用の帯域幅ギャップの作成は行いません。これは利用可能なアップストリーム時間のより良い使用法につながります。

典型的な DOCSIS または PacketCable ベースのネットワークにおいては、LLQ スケジューラを使用するときよりも DOCSIS 準拠スケジューラを使用するときの方が、UGS ジッタが一般に高いのですが、LLQ スケジューラのジッタ レベルは十分に VoIP エンドポイント ジッタ バッファ テクノロジーの容量内にあります。これは、適切に設計された VoIP ネットワーク内で LLQ スケジューラを使用するときに、VoIP コール品質への著しい影響は存在しないことを示しています。

大規模なアップストリーム バーストから発生するジッタには制限を設けることができます。このため、cable default-phy-burst パラメータは、デフォルト値の 2000 バイトかそれ以下に必ず維持する必要があります。システムが特別に低速なアップストリーム チャネルを使用する場合、たとえば、800 kHz やそれよりも低いチャネル幅である場合、大規模バーストを cable upstream fragment-force コマンドによって小さいバーストに強制的にフラグメント化すると、更なる削減を達成できます。

LLQ スケジューラが使用中であるとき、アップストリーム チャネルのオーバーサブスクリプションの可能性を防止するために、ケーブル アドミッション制御を設定する必要があります。アップストリームよりもアクティブな UGS サービス フローは、物理的に処理でき、アップストリーム上のすべての UGS サービス フローにわたって貧弱な音声品質をもたらします。極端な場合では、これも、ケーブル モデムがオフラインになり、新しいケーブル モデムがオンラインになれないことも意味します。Cisco は、アップストリーム ポート上の合計アップストリーム使用率が長期間 75% を上回らないなど、CMTS オペレータがアドミッション制御を設定することを推奨します。



結論

DOCSIS CMTS 製品の Cisco uBR シリーズは、2 つの代替アップストリーム スケジューリング アルゴリズムを提供するので、さまざまなネットワーク条件に応じることができます。

DOCSIS 準拠スケジューラは低ジッタ用に最適化されているものであり、一定の VoIP コーデックが適切に配置され、UGS サービス フローによってアップストリーム チャネル使用率の標準レベルが望まれる場所で典型的な Packetcable 1.x 音声システムに最も適しています。

低遅延キューイング スケジューラは、UGS サービス フローによるアップストリーム使用率の通常よりも高いレベル、増分されるベスト エフォート トラフィック効率、およびさまざまな認可間隔と認可サイズを備えた UGS および RTPS サービス フローを使用するシステムをサポートするために設計されています。




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

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


関連情報


Document ID: 69704