Quality of Service ソリューション ガイド、 Cisco IOS Release 15.1S
シグナリングの概要
シグナリングの概要
発行日;2012/02/02 | 英語版ドキュメント(2011/05/06 版) | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 6MB) | フィードバック

目次

シグナリングの概要

IP Precedence

リソース予約プロトコル

機能のしくみ

RSVP 低遅延キューイングに対するサポート

制約事項

前提条件

RSVP フレームリレーに対するサポート

RSVP 帯域幅割り当てとモジュラ QoS コマンド ライン インターフェイス(CLI)

利点

制約事項

前提条件

RSVP-ATM QoS インターワーキング

機能のしくみ

サンプル シナリオ

COPS for RSVP

機能のしくみ

COPS for RSVP 機能の詳細

Subnetwork Bandwidth Manager

シグナリングの概要

最も一般的な意味で、QoS シグナリングは、エンド ステーションまたはネットワーク ノードからそのネイバーに通信または通知して、特定のトラフィック処理を要求できるようにするネットワーク通信の一形態です。QoS シグナリングは、他の QoS 機能で提供されるトラフィック処理テクニックの調整に役立ちます。また、ネットワーク全体でエンドツーエンドの QoS サービスを適切に設定するうえで重要な役割を果たします。

真のエンドツーエンド QoS では、ネットワーク パス内のすべての要素(スイッチ、ルータ、ファイアウォール、ホスト、クライアントなど)によってその QoS の一部が配信され、これらのエンティティのすべてが QoS シグナリングを使用して調整される必要があります。

実行可能な QoS シグナリング ソリューションの多くは、インフラストラクチャ内の特定の場所で QoS を提供しますが、ネットワーク全体ではその範囲が制限されます。エンドツーエンド QoS を実現するには、シグナリングでネットワーク全体をカバーする必要があります。

Cisco IOS QoS ソフトウェアは、IP を活用して、異種ネットワーク インフラストラクチャ上で動作可能な堅牢な QoS シグナリング ソリューションを発見する課題を解決します。このソフトウェアは、レイヤ 2 テクノロジー固有の QoS シグナリング ソリューションと、Resource Reservation Protocol(RSVP; リソース予約プロトコル)機能と IP Precedence 機能のレイヤ 3 IP QoS シグナリング方式をオーバーレイさせます。

IP ネットワークは、たとえば、IP パケット ヘッダーの一部を使用してプライオリティまたは時間依存のトラフィックの特殊な処理を要求することによって、エンドツーエンド QoS を実現できます。IP の普遍性を前提とすれば、IP を活用する QoS シグナリングは、強力なエンドツーエンド シグナリングを提供します。RSVP と IP Precedence の両方がこのカテゴリに含まれます。

特定の QoS が特定のトラフィック分類に必要なことを示すには、インバンド(IP Precedence、802.1p)シグナリングとアウトバンド(RSVP)シグナリングのどちらかを使用します。IP Precedence は区別された QoS を通知し、RSVP は保証された QoS を通知します。

IP Precedence

図 1 に示すように、IP Precedence 機能は、IP version 4(IPv4)ヘッダーの Type of Service(ToS; タイプ オブ サービス)フィールド内の優先順位ビットを使用して各パケットのサービス クラスを指定します。IP precedence を使用すれば、最大 6 つのサービス クラスにトラフィックを分類できます。ネットワーク経由のキューイング テクノロジーは、この信号を使用して、適切な優先処理を提供します。

図 1 IP Precedence ToS フィールド

Policy-Based Routing(PBR; ポリシーベース ルーティング)や Committed Access Rate(CAR; 専用アクセス レート)などの機能を使用して、拡張アクセス リスト分類に基づく優先順位を設定できます。これらの機能を使用すれば、アプリケーションまたはユーザ別の割り当てや宛先サブネットまたは送信元サブネット別の割り当てを含む、優先順位割り当ての柔軟性が大幅に向上します。一般的に、これらの機能は、ネットワーク エッジまたは管理ドメインのできるだけ近くに配置して、それ以降のネットワーク要素で、決定されたポリシーに基づくサービスが提供できるようにします。IP precedence は、ホストまたはネットワーク クライアント上で設定することもできますが、ネットワーク内のポリシーによってオーバーライドされる可能性があります。

IP precedence を使用すれば、既存のアプリケーションを変更したり、複雑なネットワーク要件を解決したりしなくても、Weighted Fair Queueing(WFQ; 重み付け均等化キューイング)や Weighted Random Early Detection(WRED; 重み付けランダム早期検出)などの既存のネットワーク キューイング メカニズムを使用してサービス クラスを設定できます。

リソース予約プロトコル

RSVP は、異種ネットワーク上でエンドツーエンド QoS を動的にセットアップする初めての重要な業界標準プロトコルです。IP 上で動作する RSVP を使用すれば、アプリケーションでネットワーク帯域を動的に予約できます。また、RSVP を使用すれば、アプリケーションで、ネットワーク上のデータ フローに対して一定レベルの QoS を要求できます。

Cisco IOS QoS 実装を使用すれば、設定されたプロキシ RSVP を使用して RSVP をネットワーク内で開始できます。この機能を使用すれば、RSVP に対応していないアプリケーションとホストからなるネットワークでも RSVP の利点を享受できます。RSVP は、IP ネットワークのエンドツーエンドでネットワーク帯域幅を保証する唯一の標準シグナリング プロトコルです。

RSVP は独自のルーティングを実行しません。その代わりに、基礎となるルーティング プロトコルを使用して、予約要求を伝送すべき場所を特定します。ルーティングによってトポロジ変更に適合するようにパスが変更されるため、RSVP がその予約を予約が設定される新しいパスに適合させます。このモジュール方式では、RSVP による他のルーティング サービスの使用が阻害されません。RSVP は、RSVP をサポートしていないルータ ノードを通した透過的処理を提供します。

RSVP は、既存のキューイング メカニズムを置き換えるのではなく、それと一緒に機能します。また、RSVP は特定の QoS を要求しますが、予約の実装は WFQ や WRED などの特定のインターフェイス キューイング メカニズムに任されます。

RSVP を使用すれば、負荷制御サービスとレート保証サービスの 2 種類の動的予約を作成できます。この両方の簡単な説明がこのマニュアルの「 Quality of Service(QoS)の概要 」にあります。

RSVP の主な特徴はそのスケーラビリティです。RSVP は、マルチキャストが本来備えているスケーラビリティを利用してうまくスケールします。また、RSVP は、マルチキャスト ツリーを遡るときにマージされるレシーバー指向の予約要求を使用するため、大規模なマルチキャスト グループにスケールします。RSVP はマルチキャスト アプリケーション専用に設計されていますが、ユニキャスト予約も作成できます。ただし、大量のユニキャスト予約のようにはスケールしません。

RSVP は、重要な QoS 機能ですが、QoS で解決されるすべての問題が解決されるわけではなく、エンドツーエンド予約のセットアップに要する時間などのいくつかの欠点があります。

機能のしくみ

ホストとルータは、RSVP を使用して、データ ストリームのパスに沿って QoS 要求をルータに配信したり、ルータとホストの状態を維持して要求されたサービス(その多くは帯域幅や遅延)を提供したりします。RSVP は、中間データ レート(ルータがキュー内に保持するデータの最大量)と最小 QoS(つまり、RSVP を使用して予約されたときに指定された要求帯域幅の保証)を使用して、帯域幅予約を決定します。

ホストは、RSVP を使用して、アプリケーション データ ストリームの代わりに、ネットワークから特定の QoS サービスを要求します。RSVP は、特定の QoS を要求しますが、予約の実装はインターフェイス キューイング メカニズムに任されます。また、RSVP は、ネットワーク経由で要求を伝送しながら、ネットワークがストリームの伝送に使用している各ノードを訪問します。各ノードでは、RSVP が、ノードに要求された QoS を満たすだけの十分なリソースが存在するかどうかを判断する専用のアドミッション コントロール モジュールを使用して、ストリームのリソース予約を作成しようとします。


) RSVP によって、アプリケーションは、要求された QoS よりも高いレートでトラフィックを送信できますが、最小要求レートしか保証されません。帯域幅に余裕がある場合は、要求されたレートを上回るトラフィックが通過します。帯域幅に余裕がない場合は、超過トラフィックが破棄されます。


必要なリソースが使用可能で、ユーザに管理アクセス権が付与されている場合は、RSVP デーモンがパケット分類機能とパケット スケジューラ内の引数を設定して必要な QoS を実現します。分類機能がパケットごとの QoS クラスを決定し、スケジューラがパケット送信を指示してストリームごとに約束された QoS を実現します。リソースが使用できないか、ユーザが管理権限を拒否された場合は、RSVP プログラムがエラー通知を要求元のアプリケーション プロセスに戻します。

WFQ または WRED が、パケット分類と予約されたフローに必要なスケジューリングをセットアップします。WFQ を使用した場合は、RSVP で統合されたサービスのレート保証サービスを配信できます。WRED を使用した場合は、負荷制御サービスを配信できます。

RSVP の設定方法については、このマニュアルの 「Configuring RSVP」 を参照してください。

RSVP 低遅延キューイングに対するサポート

RSVP は、ネットワーク上のエンドツーエンド送信アプリケーションによって必要な QoS が実現されることを保証するためのネットワーク リソース(主に帯域幅)を予約する手段を提供するネットワーク制御プロトコルです。

RSVP を使用すれば、リアルタイム トラフィック(音声フローを含む)で低遅延と帯域幅の保証に必要なリソースを予約できます。

音声トラフィックには、厳格な遅延要件とジッタ要件が伴います。エンドツーエンド QoS の低下を避けるために、ホップごとに超低遅延と最小ジッタが要求されます。この要件を満たすには、遅延とジッタを最小化するためにほぼ最優先で音声トラフィックを転送可能な Low Latency Queueing(LLQ; 低遅延キューイング)などの効率的なキューイング実装が必要です。

RSVP は、WFQ を使用して、フロー間の公平性を提供し、パケットに低い重みを割り当ててプライオリティを確保します。ただし、RSVP によって提供される優遇措置では、キューイング アルゴリズムそのものの特性が原因でジッタを最小化するまでには至りません。したがって、前述の RSVP と WFQ の実装では、音声フローの低遅延要件とジッタ要件を満たせない可能性があります。

RSVP はアドミッション コントロールを提供します。ただし、音声トラフィックに対する帯域幅と遅延の保証を提供し、アドミッション コントロールを獲得するには、RSVP が LLQ と連動する必要があります。RSVP LLQ に対するサポート機能を使用すれば、RSVP で音声フローを分類して、それらを LLQ システム内のプライオリティ キューに配置しながら、同時に、予約されたキューを獲得することによって非音声フローの予約を実現できます。

図 2 は、RSVP が同じキューイング メカニズムの LLQ を使用して、どのように ip rtp priority などの他の Voice over IP(VoIP)機能と連動するかを示しています。

図 2 RSVP LLQ に対するサポート

 

RSVP は、帯域幅などのネットワーク リソースの可用性に基づいてアドミッション コントロールを提供する唯一のプロトコルです。LLQ は、音声トラフィックを他のデータ トラフィックより優先して転送する手段を提供します。組み合せた場合、RSVP LLQ に対するサポートが、アドミッション コントロールを提供し、実現可能な最低の遅延とジッタで音声フローを転送します。

音声トラフィックの悪影響を受けることなく、ミッションクリティカルなアプリケーションからの高優先度非音声トラフィックの送信を継続できます。

非整合トラフィックはベストエフォート扱いを受けるため、そうでない場合にすべてのトラフィックに対して発生する可能性のある低下が回避されます。

RSVP LLQ に対するサポート機能は、次の RFC をサポートしています。

RFC 2205、『 Resource Reservation Protocol

RFC 2210、『 RSVP with IETF Integrated Services

RFC 2211、『 Controlled-Load Network Element Service

RFC 2212、『 Specification of Guaranteed Quality of Service

RFC 2215、『 General Characterization Parameters for Integrated Service Network Elements

図 3 は、各インターフェイス上で実行している LLQ を使用したサンプル ネットワーク トポロジを示しています。この設定では、音声トラフィックの QoS が保証されます。


) 送信元で RSVP をサポートできない場合は、送信元の代わりにルータでプロキシできます。


図 3 各インターフェイス上の LLQ を示すトポロジ

 

RSVP LLQ に対するサポート機能の設定方法については、『 Configuring RSVP Support for LLQ 』モジュールを参照してください。

制約事項

RSVP LLQ に対するサポート機能には、次の制約事項が適用されます。

LLQ はトンネル上でサポートされません。

RSVP LLQ に対するサポートはプライオリティ キューに依存します。LLQ がどのインターフェイスまたはプラットフォーム上でも使用できない場合は、RSVP LLQ に対するサポートが使用できません。

前提条件

RSVP LLQ に対するサポートをイネーブルにするには、ネットワーク上で次の Cisco IOS 機能をサポートする必要があります。

RSVP

WFQ または LLQ(プライオリティ キューがサポートされた WFQ)

RSVP フレームリレーに対するサポート

ネットワーク管理者は、キューイングを使用して、ルータ インターフェイスまたは Virtual Circuit(VC; 仮想回線)上の輻輳を管理します。フレームリレー環境では、輻輳点がインターフェイスそのものになることはありませんが、Committed Information Rate(CIR; 認定情報レート)が原因で VC になることがあります。迅速に送信する必要のあるリアルタイム トラフィック(音声フロー)の場合は、データ レートが CIR を超えないようにしなければ、パケットが破棄され、音声品質が低下する可能性があります。Frame Relay Traffic Shaping(FRTS; フレームリレー トラフィック シェーピング)は、インターフェイス上でルータが CIR を超えないように、アウトバウンド トラフィック レートを制御するように設定されます。この種の設定は、Class-Based WFQ(CBWFQ; クラスベース均等化キューイング)、LLQ、WFQ などのファンシー キューイングを VC 上で実行して、トラフィックに対する QoS 保証が提供できることを意味します。

以前は、RSVP 予約がフローのアウトバウンド VC の CIR によって制限されませんでした。そのため、RSVP トラフィックとその他のトラフィックの合計が CIR を上回ったときにオーバーサブスクリプションが発生する可能性がありました。

RSVP フレームリレーに対するサポート機能を使用すれば、音声のようなフローに対して RSVP と VC 単位( Data-Link Connection Identifier( DLCI; データリンク接続識別子))キューイングを連動させることができます。輻輳点、つまり、VC 自体で正確なリソース(帯域幅やキュー)の制御を実現するには、フレームリレー環境でトラフィック シェアリングをイネーブルにする必要があります。特に、RSVP は、インターフェイスまたはサブインターフェイス レベルで定義された VC と連動できます。インターフェイスまたはサブインターフェイス単位で設定可能な VC の数に制限はありません。

RSVP 帯域幅割り当てとモジュラ QoS コマンド ライン インターフェイス(CLI)

RSVP は、WFQ などのインターフェイス(または PVC)キューイング アルゴリズムを使用して、そのデータ フローの QoS を保証できます。

アドミッション コントロール

WFQ が実行中は、RSVP と他の QoS 機能をインターフェイス(または PVC)上で共存させ、帯域幅を予約し、QoS を強制できます。複数の帯域幅予約機能(RSVP、LLQ、CB-WFQ、 ip rtp priority など)を設定している場合は、インターフェイス(または PVC)上で使用可能な帯域幅の一部をこれらの機能のそれぞれに割り当てて、分類されたフローに使用できます。

内部のインターフェイスベース(または PVC ベース)の帯域幅マネージャが、これらの機能によって予約されたトラフィック量がインターフェイス(または PVC)容量を超過しないようにします。この使用可能な帯域幅のプールは show queue コマンドで確認できます。

LLQ や CB-WFQ などの機能を設定している合は、帯域幅が割り当てられるすべてのクラスによって、設定時点で帯域幅が予約され、帯域幅マネージャからその帯域幅が差し引かれます。設定された帯域幅がインターフェイスの容量を超えている場合は、設定が拒否されます。

RSVP の設定時は、帯域幅が予約されません( ip rsvp bandwidth コマンドで指定された帯域幅が厳密な上限として機能し、すべてのフローの許可が 保証されません )。RSVP 予約が到着した場合にのみ、RSVP が使用可能な帯域幅の残りのプール(つまり、他の機能によって処理されるトラフィック用以外の帯域幅)から帯域幅を予約しようとします。

データ パケット分類

デフォルトで、RSVP は、効率的なフローベースのデータ パケット分類を実行して、その予約されたトラフィックの QoS を保証します。この分類は、 ip rtp priority または CB-WFQ によるキューイング考慮よりも優先して実行されます。つまり、RSVP データ フローに QoS を付与するために、CB-WFQ クラスまたは ip rtp priority コマンドを使用する 必要がありません 。どの ip rtp priority 設定または CB-WFQ 設定も RSVP フローと一致しませんが、それらの分類機能と一致する可能性のある非 RSVP フロー用の追加の帯域幅が予約されます。

利点

この機能の利点は次のとおりです。

現在の RSVP は、インターフェイス上で使用可能な帯域幅の代わりに、定義された VC 最小許容可能発信(minCIR)値に基づいて、アドミッション コントロールを提供します。

RSVP は、輻輳点、つまり、インターフェイスではなく、フレームリレー VC 上でリソースを予約することによって、高優先度トラフィックに対する QoS 保証を提供します。

RSVP は、ポイントツーポイントおよびマルチポイント インターフェイス設定に対するサポートを提供します。つまり、QoS が保証されたフレームリレー環境内の VoIP などのサービス展開が可能になります。

RSVP、CBWFQ、および ip rtp priority コマンドは、同時に実行している場合でも、インターフェイスまたは VC 上で使用可能な帯域幅を超えません。予約を許可する前に、これらの機能(および ip rtp priority コマンド)が内部の帯域幅マネージャと連携してオーバーサブスクリプションを回避します。

現在の IP QoS 機能は、VC(DLCI)単位でアドミッション コントロールを提供する RSVP を使用して、IP 環境からフレームリレー環境にシームレスに統合できます。

RSVP フレームリレーに対するサポート機能は、次の MIB と RFC をサポートしています。

RFC 2206、『 RSVP Management Information Base using SMIv2

RFC 220、『 Resource Reservation Protocol

RFC 2210、『 RSVP with IETF Integrated Services

RFC 221、『 Controlled-Load Network Element Service

RFC 2212、『 Specification of Guaranteed Quality of Service

RFC 2215、『 General Characterization Parameters for Integrated Service Network Elements

RVSP フレームリレーに対するサポートの設定方法については、『 Configuring RSVP Support for Frame Relay 』モジュールを参照してください。

制約事項

RSVP フレームリレーに対するサポート機能には、次の制約事項が適用されます。

インターフェイスレベル Generic Traffic Shaping(GTS; 汎用トラフィック シェーピング)はサポートされません。

同じインターフェイス上での VC レベル キューイングとインターフェイスレベル キューイングはサポートされません。

非音声 RSVP フローはサポートされません。

マルチキャスト フローはサポートされません。

前提条件

RSVP フレームリレーに対するサポートをイネーブルにするには、ネットワーク上で次の Cisco IOS 機能をサポートする必要があります。

RSVP

VC 上の WFQ

LLQ

インターフェイス上の Frame Relay Forum(FRF; フレームリレー フォーラム)12

RSVP-ATM QoS インターワーキング

RSVP-ATM QoS インターワーキング機能は、ATM コア ネットワーク上の RSVP を使用した負荷制御サービスに対するサポートを提供します。この機能を使用するには、RSVP 予約要求メッセージに対する応答で、ATM クラウド上の Switched Virtual Circuit(SVC; 相手先選択接続)の確立を通知できる必要があります。この要件を満たすために、RSVP over ATM は ATM SVC に対する RSVP セッションのマッピングをサポートしています。

RSVP-ATM QoS インターワーキング機能を使用すれば、次のタスクを実行できます。

RSVP 予約要求メッセージに対する応答で、SVC を動的に作成するようにインターフェイスまたはサブインターフェイスを設定します。定義された QoS を保証するために、これらの SVC は QoS プロファイルとマップされた RSVP フロー仕様(flowspec)が一致するように設定されます。

Distributed Weighted Random Early Detection(DWRED)グループ定義を拡張 ATM ポート アダプタ(PA-A3)インターフェイスに対応付けて VC 単位 DWRED 破棄ポリシーをサポートします。VC 単位 DWRED を使用すれば、パケットを破棄する必要がある場合は、ベストエフォート パケットが最初に破棄され、RSVP のトークン バケットで特定された QoS に適合するパケットは破棄されないことが保証されます。

IP Precedence 値と ToS 値を QoS プロファイルに適合するパケットまたは QoS プロファイルを超えているパケットに対して使用するために設定します。RSVP では、その入力処理の一部として、着信パケット内の ToS ビットと IP Precedence ビットをセットするために指定された値が使用されます。VC 単位 DWRED が設定されている場合は、同じルータの出力インターフェイス上で ToS ビットと IP Precedence ビットの設定値を使用して、破棄するパケットが決定されます。また、下流ルータのインターフェイス上のパケット処理にもこれらの設定値が使用されます。

この機能は、VIP2-50 および拡張 ATM ポート アダプタ(PA-A3)が搭載された Cisco 7500 シリーズ ルータ上でサポートされます。ハードウェアから、この機能に必要なトラフィック シェーピングが提供され、OC-3 レート性能要件が満たされます。

機能のしくみ

従来は、RSVP と WFQ が一体化されていました。WFQ が RSVP に帯域幅保証を提供し、RSVP ですべてのパケットが認識できるようにします。この可視性によって、RSVP では、それに関するパケットを特定してマークを付けることができます。

RSVP-ATM QoS インターワーキング機能を使用すれば、RSVP を WFQ から切り離す代わりに、ATM SVC に関連付けて予約要求メッセージを処理(および帯域幅保証を提供)し、NetFlow に関連付けて RSVP によるパケット認識を可能にできます。

RSVP-ATM QoS インターワーキング機能を使用するようにインターフェイスまたはサブインターフェイスを設定するには、 ip rsvp svc-required コマンドを使用します。新しい RSVP 予約が要求されると、ルータ ソフトウェアで新しい ATM SVC が確立され、予約が提供されます。

RSVP 値と ATM SVC 値の一致を保証するために、ソフトウェアのアルゴリズムによって、RSVP flowspec 内のレート パラメータとバースト サイズ パラメータが ATM Sustained Cell Rate(SCR; 平均セルレート)と Maximum Burst Size(MBS; 最大バースト サイズ)にマップされます。Peak Cell Rate(PCR; ピーク セル レート)の場合は、設定された値が使用されるか、デフォルトの回線レートに設定されます。RSVP-ATM QoS インターワーキングには、OC-3 速度の拡張 ATM ポート アダプタ(PA-A3)が必要です。

予約されたフローに属しているパケットがインターフェイスまたはサブインターフェイスに到着すると、RSVP-ATM QoS インターワーキング ソフトウェアがトークン バケットを使用して帯域幅保証を管理します。また、予約 flowspec に照らして実際のトラフィック レートを測定し、パケットが flowspec に準拠しているか、flowspec を超えているかを判断します。準拠トラフィックまたは超過トラフィックとして設定された値を使用して、パケット ヘッダーの ToS バイト内の IP Precedence ビットと ToS ビットがセットされ、パケットが該当する VC に配信され、転送されます。RSVP-ATM QoS インターワーキング機能では、パケットが ATM SVC 上で送信される前にシェーピングされます。シェーピングは、かかる負荷がレートを超えていた場合に、Versatile Interface Processor(VIP)の負担になります。

RSVP-ATM QoS インターワーキング ソフトウェアは、SVC 単位 DWRED を使用して、シェーピングによって VIP 上にキューが構築された場合にパケットを破棄します。SVC 単位 DWRED を使用すれば、RSVP で負荷制御サービス クラスを配信して、予約されたパケットの性能が無負荷ネットワーク(超低損失で中程度の遅延)上の性能と等価になるようにできます。RSVP-ATM QoS インターワーキング機能の動作の詳細については、次のサンプル シナリオを参照してください。

サンプル シナリオ

RSVP-ATM QoS インターワーキング機能の動作を理解するために、VIP 入出力インターフェイスと RSVP 入力機能が Route Switch Processor(RSP)上に実装された Cisco 7500 ルータを使用する次の例を参照してください。図 4 はこの例を示しています。ATM クラウド上で通信するルータのペアが表示されています。この例では、単一の PVC が RSVP 要求メッセージに使用され、ATM SVC が新しい予約要求メッセージを処理するように設定されます。

図 4 ATM コア ネットワーク上で接続された 2 つのルータ

 

ルータ A の上流にあるホスト X は、FDDI を使用してルータ A に直接接続されています。ルータ B の下流にあるホスト Y は、FDDI を使用してルータ B に直接接続されています(代替設定では、これらのホスト/ルータ接続で ATM VC が使用できます)。

RSVP-ATM QoS インターワーキング機能では、主に、ATM バックボーン ネットワーク上のルータ同士の予約が必要です。予約が成立する場所の数を制限するために、ATM バックボーン ネットワーク上のルータ間接続に対応しているサブインターフェイス上でのみ RSVP を選択的にイネーブルにできます。ホストとルータ間での予約の成立を禁止することによって、VC の使用が制限され、ルータ上の負荷が軽減されます。

RSVP RESV メッセージは、受信ホストから送信ホストに流れます。この例では、ホスト Y が送信ホストでホスト X が受信ホストです(ホスト Y からホスト X に RESV メッセージが送信されます)。ATM クラウドの端にあるルータ B が RESV メッセージを受信して、PVC 上のルータ A に転送され、制御メッセージとして使用されます。図 4 に示すサンプル設定では、1 つの PVC を使用して RSVP 要求が伝送されます。

ルータ A 上の入力インターフェイスが RSVP-ATM 用に設定されます。これによって、要求ごとに SVC を確立してインターフェイス上で成立した新しい RSVP RESV 予約を提供できます。予約要求が受信されると、ルータ A のインターフェイス上で適切な QoS 特性を持つ新しい nonReal-Time Variable Bit Rate(nRTVBR)SVC が作成されます。SVC の確立に使用される QoS 特性は、RSVP RESV メッセージ内の flowspec と ATM シグナリング パラメータの該当するセットとのアルゴリズムによるマッピングから生成されます。

この例では、QoS クラスとして負荷制御サービスが使用されます。ATM PCR パラメータが回線レートに設定されます。インターフェイス上で ip rsvp atm-peak-rate-limit コマンドを使用してレート リミッタを設定した場合は、PCR がピーク レート リミッタに設定されます。ATM SCR パラメータが RSVP flowspec レートに設定され、ATM MBS が RSVP flowspec バースト サイズに設定されます。パケットは、ATM SVC 上に送信される前にシェーピングされます。シェーピングは、かかる負荷がレートを超えた場合に、VIP の負担になります。

予約要求を処理するために新しい SVC がセットアップされた場合は、パケットの送信元アドレス、宛先アドレス、およポート番号を使用してそのパケットが属している予約(もしあれば)を特定する分類機能の状態などの別の状態もセットアップされます。また、トークン バケットは、送信元からその flowspec のデータ レートと MBS パラメータを上回るデータが送信された場合に、超過トラフィックが他の予約を妨害しないことを保証するようにセットアップされます。

次の項では、パスに沿ったデータの移動について、より具体的に説明します。

ルータ B 宛てのデータ パケットがルータ A に到着すると、ATM クラウドに出力される前に、そのパケットの送信元アドレス、宛先アドレス、およびポート番号が、RSVP フィルタ仕様(filterspec)に照らしてチェックされ、予約と一致するかどうかが判断されます。

パケットが予約と一致しなかった場合は、ベストエフォート PVC からルータ B に送信されます。パケットが予約と一致した場合は、RSVP によってさらに処理されます。パケットは、予約のトークン バケットに対してチェックされ、トークン バケット パラメータに準拠しているか、そのパラメータを超過しているかが判断されます(予約と一致するすべてのパケットが予約の SVC 上に送信され、パケットの順序ミスが回避されます)。

flowspec 準拠パケットと flowspec 超過パケットの区別を導入するために、パケットの IP Precedence ビットと ToS ビットのセット時に使用する RSVP-ATM の値を指定できます。これらの値を指定するには、 ip rsvp precedence コマンドと ip rsvp tos コマンドを使用します。準拠パケットと超過パケットで異なる優先順位値を設定して、DWRED などの優先破棄ポリシーを使用する場合は、RSVP-ATM によって、VC が輻輳した場合に flowspec 超過パケットの方が flowspec 準拠パケットよりも先に破棄されることが保証されます。

RSVP-ATM QoS インターワーキング機能の設定方法については、『 Configuring RSVP-ATM QoS Interworking 』モジュールを参照してください。

COPS for RSVP

Common Open Policy Service(COPS; 共通オープン ポリシー サービス)は、ネットワーク トラフィック ポリシー情報をネットワーク装置に伝達するためのプロトコルです。RSVP は、ネットワーク リソース(主に帯域幅)を予約して、インターネット上をエンドツーエンドで送信するアプリケーションが必要な速度と品質で動作することを保証するための手段です。

COPS と RSVP を組み合せることによって、次の能力を含む、RSVP の集中モニタリングおよび管理がネットワーク マネージャに提供されます。

音声伝送などの時間依存トラフィックに対して、適切な帯域幅、ジッタ、および遅延限界を保証します。

ビデオ会議や遠隔学習などのマルチメディア アプリケーションに対して、適切な帯域幅を保証します。

帯域幅を大量に消費するアプリケーションが、最優先フローを遅延させたり、同じネットワーク上で定期的に動作する他のアプリケーションの性能に悪影響を与えたりできないようにします。

その際、COPS for RSVP は次の重要な RSVP 機能をサポートします。

アドミッション コントロール。RSVP 予約が、エンドツーエンド で使用可能なネットワーク リソースに基づいて、許可または拒否されます。

帯域幅保証。RSVP 予約が許可された場合は、予約が有効なかぎり、予約されたリソースの可用性が保証されます。

メディアに依存しない予約。エンドツーエンド RSVP 予約は、任意の下位レイヤ メディア タイプをカバーできます。

データ分類。予約の有効期間に、その RSVP フローに属しているデータ パケットが他のパケットから分離され、予約フローの一部として転送されます。

データ ポリシング。予約された帯域幅サイズを上回る RSVP フローに属しているデータ パケットは、より低いパケット優先順位にマークされます。


) COPS for RSVP 機能を使用するには、ネットワーク上で Cisco IOS 12.1(1)T 以降のリリースが動作している必要があります。さらに、Cisco COPS QoS Policy Manager などの互換性のあるポリシー サーバをネットワークに接続する必要があります。



) Cisco IOS 12.1(2)T リリースの COPS for RSVP では、RSVP+ がサポートされません。


COPS for RSVP は次のインターフェイス上で動作します。

イーサネット

ファスト イーサネット

High-Speed Serial Interface(HSSI):V.35、EIA/TIA-232

T1

COPS for RSVP 機能は、次の RFC をサポートしています。

RFC 2749、『 COPS Usage for RSVP

RFC 2205、『Resource ReSerVation Protocol (RSVP) 』

RFC 2748、『The COPS (Common Open Policy Service) Protocol』

機能のしくみ

この項では、COPS for RSVP 機能のネットワーク上での動作に関する概要を示し、COPS for RSVP 機能を設定する一般的な手順を紹介します。

図 5 は、RSVP を伴う COPS のサンプル配置です。

図 5 RSVP を伴う COPS のサンプル配置

 

特定のポリシー サーバ(Policy Decision Point(PDP; ポリシー デシジョン ポイント)と呼ばれている)上に保存されたポリシーに従って、到着したすべての RSVP メッセージを処理するようにルータを設定するには、次の手順を実行します。

1. PDP サーバで、Cisco COPS QoS Policy Manager または互換性のあるポリシー マネージャ アプリケーションを使用して、ポリシーを入力します。

2. RSVP メッセージに関する決定をサーバに要求するようにルータを設定(コマンド ライン インターフェイス経由)します。

この設定以降は、次のように、ネットワーク フローが Policy Enforcement Point(PEP)として指定されたルータによって処理されます。

a. RSVP シグナリング メッセージがルータに到着すると、ルータが PDP サーバにメッセージの処理方法(許可、拒否、転送、または設定)を問い合せます。

b. PDP サーバは、その決定をルータに送信し、ルータが指示どおりにメッセージを処理します。

3. または、このような決定を PDP サーバに問い合せることなくルータ自体で(ローカルに)処理するようにルータを設定できます(ローカル機能は、このリリースでサポートされませんが、今後のリリースでサポートされる予定です)。

COPS for RSVP 機能の詳細

図 6 に、RSVP メッセージ フローのポリシー管理で使用可能なオプションを示します。オプションごとに、その設定に使用されるルータ コンフィギュレーション コマンドの例がカッコ内に太字で示されています。

網掛けの領域は、ローカル ポリシー処理を示しています。図の残りの部分は、リモート ポリシー処理を示しています(ローカル ポリシーの設定は今後のリリースで使用可能になる予定です)。

図 6 RSVP PATH メッセージと RESV メッセージの処理手順

 

図の補足説明を次に示します。

a. ルータが PATH メッセージまたは RESV メッセージを受信すると、まずは、ローカルで(つまり、ポリシー サーバを参照することなく)メッセージを判定しようとします。ルータがローカルで特定の Access Control List(ACL; アクセス コントロール リスト)を判定するように設定されており、メッセージがそのリストのいずれかと一致した場合(a-1)は、ルータのポリシー モジュールが設定されていた演算子を適用します。そうでない場合は、ポリシー処理が継続されます(a-2)。

b. 演算子によってメッセージが拒否されるたびに、ルータは、エラー メッセージを送信側に送信して、データベースから PATH メッセージまたは RESV メッセージを削除します(b-1)。メッセージが拒否されなかった場合は、ポリシー処理が継続されます(b-2)。

c. このエントリに対してローカル オーバーライド フラグがセットされていた場合は、指定されたポリシー演算子を使用して直ちにメッセージが許可されます(c-1)。そうでない場合は、ポリシー処理が継続されます(c-2)。

d. メッセージがローカル ポリシー用に設定されたどの ACL とも一致しなかった場合(a-2)は、ルータがデフォルト ローカル ポリシーを適用します(d-1)。ただし、デフォルト ローカル ポリシーが設定されていなかった場合は、メッセージがリモート ポリシー 処理に送られます(d-2)。

e. ルータが特定のポリシー サーバ(PDP)に対する特定の ACL を使用して設定されており、メッセージがその ACL のいずれかと一致した場合は、ルータがメッセージを PDP に送信して処理を依頼します(e-1)。そうでない場合は、ポリシー処理が継続されます(e-2)。

f. PDP が「拒否」決定を下した場合(f-1)は、メッセージが破棄され、その状態を示すエラー メッセージが送信側に送り返されます。PDP が「許可」決定を下した場合(f-2)は、メッセージが許可され、通常の RSVP 処理ルールに従って処理されます。

g. メッセージが特定の PDP 用に設定されたどの ACL とも一致しなかった場合(e-2)は、ルータが デフォルト PDP 設定を適用します。デフォルト COPS 設定が入力されていた場合は、ポリシー処理が継続されます(g-1)。そうでない場合は、メッセージが不一致と見なされます(g-2)。

不一致メッセージに対するデフォルト ポリシー決定が拒否の場合(h-1)は、直ちにメッセージが破棄され、その状態を示す ERROR メッセージが送信側に送信されます。そうでない場合は、メッセージが許可され、通常の RSVP 処理ルールに従って処理されます(h-2)。

PDP-PEP の通信と処理の詳細を次に示します。

ポリシー要求タイマー。処理要求(任意の種類)が PDP に送信されると、PATH メッセージまたは RESV メッセージに関連付けられた 30 秒タイマーが始動します。PDP が要求に応答する前にタイマーが切れた場合は、PDP がダウンしていると見なされ、その要求がデフォルト ポリシーに渡されます(図 6 のステップ g-2)。

PEP 予約の PDP トラッキング。PDP で予約が設定可能と判断された場合は、その予約をルータ上で設定する必要があります。帯域幅容量が割り当てられており、予約が設定されている場合は、PEP のポリシー モジュールが COMMIT メッセージを PDP に送信します。ただし、リソース不足で予約を設定できなかった場合は、予約が非設定状態に戻され、NO-COMMIT メッセージが PDP に送信されます。予約が新規(以前の状態なし)でもあった場合は、代わりに、DELETE REQUEST メッセージが PDP に送信されます。このような方法で、PDP は PEP 上の予約を追跡できます。

再同期化。PDP が SYNCHRONIZE-REQUEST メッセージを PEP に送信した場合は、PEP のポリシー モジュールが、そのデータベースで、過去にその PDP によって判定されたすべてのパスと予約をスキャンして、それらの要求を再送信します。過去に判定されたポリシー情報は、新しい決定が受信されるまで保存されます。すべての PATH 状態または RESV 状態が PDP に報告されたら、SYNCHRONIZE-COMPLETE メッセージがポリシー モジュールから PDP に送信されます。PEP は、PDP がダウンしている間にローカルに判定されたすべてのフローに関する問い合せも送信します。

再判定。

RSVP セッションで管理されたフローが PEP ルータ経由で転送されているかぎり、PDP は一方的にそのセッションのすべての COPS 決定を判定し直すことができます。たとえば、PDP は、過去に許可された特定のフローを今回は拒否する必要がある(突然のプリエンプションまたはタイムアウトが原因)と判断する場合があります。このような場合は、PDP が新しい決定メッセージを PEP に送信し、それに従ってその動作が調整されます。

PEP ルータが、オブジェクトが変更された RESV メッセージを受信した場合は、ポリシー決定を再判定する必要があります。たとえば、送信側で帯域幅予約を増加または削減したい場合は、新しいポリシー判定を下す必要があります。このような場合は、過去にこのセッションに適用されたポリシー フラグが保存され、セッションが再判定されます。

取り消し。PEP のポリシー モジュールは、過去にポリシー経由で設定された予約またはパスが何らかの理由で取り消された場合は PDP に通知する責任があります。PEP は、DELETE REQUEST メッセージを送信することによって、PDP に通知します。

接続管理:

PDP への接続が閉じられた場合(PDP が接続を閉じたか、TCP/IP エラーが発生したか、キープアライブが失敗したか)は、PEP が CLIENT-CLOSE メッセージを発行して、同じ PDP への再接続を試みます。PEP が PDP リダイレクト アドレスを含む CLIENT-CLOSE メッセージを受信した場合は、リダイレクト先の PDP への接続を試みます。

どちらかの試みが失敗した場合は、PEP が過去に ip rsvp policy cops servers 設定コマンドで指定された PDP への接続を試みます。接続は、そのコマンドで指定されたサーバのシーケンスに従って、必ず、そのリストで最初のサーバから開始されます。

PEP がサーバのリストの最後に到達しても接続できなかった場合は、特定の時間(「再接続遅延」と呼ばれている)を置いて、リスト内で最初のサーバへの接続を再度試みます。この再接続遅延の初期値は 30 秒で、PEP が接続できないままリストの最後に到達するたびに 2 倍されます。最大値は 30 分です。接続が確立されると直ちに、遅延が 30 秒にリセットされます。

置換オブジェクト: 表 1 は、PEP 経由で渡される RSVP メッセージ内で PDP による置換が可能なオブジェクトを示しています。列に「○」が記入されたオブジェクトは、RSVP メッセージ内で PDP による置換が可能です。

表 1 RSVP メッセージ内で PDP による置換が可能なオブジェクトの一覧

メッセージ コンテキスト
オブジェクト
影響を受ける項目
ポリシー
TSpec
Flowspec
Errorspec
Path In
x
x

•--

•--

設定された PATH 状態

この PATH に関するすべてのアウトバウンド PATH メッセージ

Path Out
x
x

•--

•--

この PATH のリフレッシュ(ただし、設定された PATH 状態ではない)

Resv In
x

•--

x

•--

設定された RESV 状態(着信およびトラフィック制御設定)

この RESV に関するすべてのアウトバウンド RESV メッセージ

Resv Alloc

•--

•--

x

•--

このセッションに対して設定されたリソース

Resv Out
x

•--

x

•--

この RESV メッセージの特定のリフレッシュ(ただし、設定された RESV 状態でも、トラフィック制御割り当てでもない)

PathError In
x

•--

•--

x

転送された PATHERROR メッセージ

PathError Out
x

•--

•--

x

転送された PATHERROR メッセージ

ResvError In
x

•--

•--

x

このルータによって転送されたすべての RESVERROR メッセージ

ResvError Out
x

•--

•--

x

この特定の転送された RESVERROR メッセージ

オブジェクトが置換された RSVP メッセージが遅れて上流からリフレッシュされた場合は、PEP が古いバージョンと新しいバージョンの両方のオブジェクトを追跡して、そのリフレッシュを PATH 状態または RESV 状態の変化と間違えないようにします。

COPS for RSVP の設定方法については、このマニュアルの「 Configuring COPS for RSVP 」を参照してください。

Subnetwork Bandwidth Manager

RSVP とそのサービス クラス定義は、基礎となるネットワーク テクノロジーにほとんど依存しません。この非依存性を確保するために、ユーザが RSVP とサブネットワーク テクノロジーのマッピングを定義する必要があります。

Subnetwork Bandwidth Manager(SBM)機能が、IEEE 802 ベースのネットワークに関するこの RSVP の要件を満たします。SBM は、RSVP フローに対する LAN ベースのアドミッション コントロールに関するシグナリング方式とプロトコルを指定します。SBM を使用すれば、RSVP 対応ルータ、レイヤ 2 装置、およびレイヤ 3 装置は、RSVP 対応データ フローに対する LAN リソースの予約を支援できます。SBM シグナリング方式は、RSVP 自体の方式と似ています。SBM プロトコル エンティティには次のような特徴があります。

レイヤ 2 装置またはレイヤ 3 装置内に存在する。

セグメント単位でリソースを管理できる。セグメントは、共有イーサネット回線や共有トークン リング回線などの 1 つ以上の送信側によって共有されたレイヤ 2 物理セグメントです。

1 つの SBM をセグメント マネージャとして指名する動的選出プロセスの候補になれる。選出された候補は、Designated Subnetwork Bandwidth Manager(DSBM)と呼ばれています。選出された DSBM は、管理対象セグメント上のリソース予約要求に対してアドミッション コントロールを実行する責任があります。

管理対象セグメントには、DSBM によって分離されない共有 LAN の相互接続部分が含まれます。DSBM の優先順位によって、そのセグメントが管理対象セグメントになります。SBM は 1 つの管理対象セグメントに 1 つ以上存在させることができますが、DSBM は 1 つの管理対象セグメントに 1 しか存在させることができません。

セグメントに接続されたルータ上のインターフェイスを DSBM 選定プロセスに参加するように設定できます。最高優先順位に設定された候補が、管理対象セグメントの DSBM になります。

ルータが DSBM 候補として設定されておらず、RSVP がイネーブルになっている場合は、セグメント上に存在する DSBM とシステムがデータをやり取りします。実際には、それなりの特徴を有する DSBM がセグメント上に存在する場合に、そのセグメントが管理対象セグメントと見なされ、すべての RSVP メッセージの転送が SBM メッセージ転送ルールに基づきます。この動作は、管理対象セグメント インターフェイスに接続されたルータ上の RSVP 対応インターフェイスを DSBM にしたくないが、そのインターフェイスを使用してセグメントを管理している DSBM とデータをやり取りしたいケースに対応するために存在します。


SBM は、現在、トークン リング LAN 上でサポートされません。


図 7 は、ホストとルータのセットを相互接続しているレイヤ 2 ドメイン内の管理対象セグメントを示しています。

図 7 DSBM 管理対象セグメント

 

DSBM クライアントが、管理対象セグメントに接続されたインターフェイス上で RSVP PATH メッセージを送信または転送する場合は、PATH メッセージが、従来の RSVP 処理で実施されていたように、RSVP セッション宛先アドレスに送信されるのではなく、セグメントの DSBM に送信されます。メッセージ処理手順の一部として、DSBM がセッションの PATH 状態を構築して維持し、PATH メッセージを受信した 1 つ前のレイヤ 2 またはレイヤ 3 ホップを記録します。処理された PATH メッセージは、DSBM がその宛先アドレスに転送します。

DSBM は、RSVP RESV メッセージを受信すると、使用可能な帯域幅によって結果が異なる RSVP による予約要求処理と同様の方法で処理します。手順は次のとおりです。

リソース不足が原因で要求に応じることができなかった場合は、DSBM が RESVERROR メッセージを要求側に返します。

十分なリソースが使用可能で、DSBM が予約要求に応じることができた場合は、セッションのローカル PATH 状態を含む RESV メッセージが 1 つ前のホップに転送されます。

SBM の設定方法については、『 Configuring Subnetwork Bandwidth Manager 』モジュールを参照してください。