QoS の導入によるマルチメディア ネットワークのパフォーマンス向上

Updated : 11月 30, 2004

Microsoft® Windows® 2000 Quality of Service (QoS) を使用すると、通信の遅延に大きな影響を受ける、あるいは優先順位を高くする必要があるビデオ会議などのネットワーク トラフィックに割り当てる帯域幅に優先的な順位を付け、その使用を保証することができます。

トピック

目的
設計のロジック
機能するしくみ
実装した方法
セットアップ手順
その他の参考資料

目的

このシナリオでは、Windows 2000 Quality of Service (QoS) 、QoS 受付制御サービス (QoS ACS) 、および リソース予約プロトコル (RSVP) を使用して、次の目的を達成します。

• 通信の遅延が問題になる、あるいは優先順位を高くする必要があるビデオ会議などのネットワーク トラフィックに割り当てる帯域幅に優先的な順位を付け、その使用を保証します。

• どのユーザーが QoS にアクセスでき、さらにそれらのユーザーがそれぞれの QoS セッションにどの程度の帯域幅を使用できるかを制御します。

• ネットワーク上のどのサブネットを QoS ACS によって管理するかを指定します。

• QoS 対応のアプリケーションにおけるネットワーク帯域幅の必要性を評価し、ネットワーク上のリソースを定期的に予約するユーザーの数を監視します。

次の「設計のロジック」では、上に指摘した目的を達成するための方法を紹介します。

設計のロジック

このシナリオの目的は、図 1 に示すインフラストラクチャによって達成します。

図 1: QoS のインフラストラクチャ

このシナリオでは、Seattle と Milan の両方のサイトに設置されているクライアント コンピュータで Microsoft® Windows® 2000 Professional を実行しています。そのために Windows 2000 QoS を完全にサポートすることが可能になっています。それに対して Microsoft® Windows® 98 を実行している場合は、QoS が部分的にしかサポートされません。Windows® 98 と Windows® 2000 Professional における QoS のサポートを比較した詳細なデータについては、『QoS テクニカル ホワイト ペーパー』を参照してください。Microsoft® Windows® 2000 Server を実行している Seattle と Milan のサーバーには、QoS 受付制御サービス (QoS ACS) がインストールされています。Seattle サイトの QoS ACS サーバー SEA-NA-FP-04 は、同じ共有ローカル エリア ネットワーク (LAN) のセグメント、つまり Noam ドメインのサブネット 172.16.20.0/22 に属している QoS ユーザーの帯域幅要求に対して制御ポイントを提供します。さらに、必要なネットワーク リソースが現在利用可能であるかどうか、およびユーザーがその容量の帯域幅を要求するために必要なアクセス許可を割り当てられているかどうかを判断します。また、Milan サイトの QoS ACS サーバー MIL-EU-FP-04 は、Eu ドメインのサブネット 172.16.132.0/22 に対して同じサービスを提供します。

QoS ACS では、Windows 2000 に組み込まれているディレクトリ サービスである Active Directory・をデータとポリシーの保存場所として使用します。また、QoS ACS は、ネットワークの帯域幅の監視、および予約された帯域幅を要求するユーザーの監視を行うために、アカウント管理とログ収集の機能も提供します。この情報は、さまざまなユーザーによるリソースの使用状況を監視するために使用できます。

クライアントには Microsoft® NetMeeting をインストールして、ビデオ会議用のアプリケーションとして使用します。これは、Microsoft® NetMeeting が QoS 対応のアプリケーションであり、Windows 2000 QoS の長所をシームレスに活用できるからです。

このシナリオの場合、QoS は、エンドツーエンド ソリューションとして実装されます。つまり、データの伝送パスに関連するすべてのエンティティにおいて、802.1p、Differentiated Class of Service (Diff-serv) 、および RSVP などの Windows 2000 でサポートされている QoS プロトコルのいずれか 1 つがサポートされます。このシナリオでは、Seattle と Milan のサイトを接続している 2 つのエッジ ルーターがネットワークのボトルネックになる可能性があります。そこで、これらの 2 つのエッジ ルーターに着目し、リソース予約プロトコル (RSVP) をサポートするように構成します。また、エンドツーエンド ソリューションの一部であるレイヤ 3 スイッチも RSVP をサポートするように構成します。これによって、Seattle サイトのクライアントと Milan サイトのクライアントの間で WAN リンクを介して通信するときに、レイヤ 3 において必要な帯域幅の予約を保証することが可能になります。

メモ SEA-NA-CISCO-02 と SEA-NA-CISCO-03 という 2 つのレイヤ 3 スイッチの主要な目的は、Reskit ネットワーク内の Noam ドメインにおいて、異なるサブネットに対するスイッチング機能を提供することです。

Windows 2000 QoS は、レイヤ 3 デバイスの RSVP と Diff-serv に対する優先順位マーキングとレイヤ 2 デバイスの 802.1p に対する優先順位マーキングを実行します。ルーターが RSVP をサポートしていなく、Diff-serv だけをサポートしている場合は、Diff-serv 対応のレイヤ 3 デバイスがパケットを検出したときに、それらのパケットをキューの前方に格納することによって優先的な順位を設定することが、レイヤ 3 の優先順位マーキングによって保証されます。また、レイヤ 2 デバイスがネットワークのインフラストラクチャで使用されている場合、Windows 2000 QoS に組み込まれている 802.1p の優先順位マーキングによって、MIL-EU-CISCO-02 などの 802.1p 対応のレイヤ 2 デバイスをパケットが通過するときに優先的な順位が与えられることが保証されます。

重要 Seattle と Milan の両方のサイトに設置されている QoS ACS サーバーでは、ローカルなトラフィックとリモートな WAN のトラフィックを区別することができません。通常、 WAN リンクに比べると、LAN 上では大きな帯域幅を利用できるので、LAN 内に限定されているトラフィック用の帯域幅は比較的大きく割り当てて、 WAN リンク上で伝送されるトラフィック用の帯域幅は比較的小さく割り当てる必要があります。このような構成は、数とおりの方法で達成することが可能です。たとえば第 1 の方法としては、エッジ ルーターにルーター ベースの RSVP 受付制御エージェントを使用します。その場合の構成を図 2 に示します。

図 2: ルーター ベースの RSVP 受付制御エージェント

第 2 の方法としては、WAN リンクの内部に別のサブネットを追加作成し、その新しく作成したサブネット内に QoS ACS サーバーを配置します。その場合の構成を図 3 に示します。

図 3: WAN 内に設置した QoS ACS サーバー

第 3 の方法としては、WAN リンクの内部のルーターまたは QoS ACS サーバーをこのシナリオの説明に従って構成します。つまり、WAN リンクには比較的小さな帯域幅を割り当てて、その一方で LAN には比較的大きな帯域幅を割り当てるように QoS ACS サーバーを構成します。また、これらの方法以外に、WAN リンクを介した QoS のサポートを必要とする個々のユーザーやグループに、Windows ACS を通じて特定のポリシーを割り当てて、それと同時に LAN についてユーザーやグループにポリシーを割り当てるという方法も考えられます。

機能するしくみ

Windows 2000 QoS が動作して、ネットワーク上で高品質のエンドツーエンド通信を実現するプロセスを、手順に従って紹介します。

1. Seattle サイトのユーザーは NetMeeting セッションを開きます。NetMeeting は、QoS 対応のアプリケーションです。次に、Milan サイトのユーザーとの間で NetMeeting セッションを開始します。NetMeeting は、RSVP SP (RSVP サービス プロバイダ) を使用して QoS を要求します。

2. RSVP SP は RSVP サービスによって必要な帯域幅の要件を示す信号を送信することを要求し、RSVP サービスは RSVP PATH メッセージを送信します。これによって、送信者と受信者の間のルートに沿った RSVP の状態が確立されます。また、QoS がこのフロー用に要求したトラフィック制御を通知します。NetMeeting は、オーディオとビデオのトラフィックのストリーミングを開始します。このトラフィックは、予約が承認されるのを待機している間に、ベスト エフォートのサービスを割り当てられます。

3. RSVP RESV メッセージが QoS ACS サーバーに送信されて、予約が要求されます。ここで QoS ACS サーバーに渡されのは RSVP メッセージだけであり、データ パケットは渡されないことに注意してください。データ パケットは、送信者から受信者に直接伝送されます。

4. 要求された QoS のレベルを満たすだけの十分なネットワーク リソースが利用可能であること、および要求された容量の帯域幅の割り当てがユーザー ポリシーによって許可されていることが、QoS ACS サーバーによって検証されます。ローカル ポリシー モジュールでは、RSVP 要求の中で Kerberos V5 チケットを使用してユーザーの身元を認証し、さらにそのユーザーの身元を使用して Active Directory 内でユーザー ポリシーを検索します。この場合、QoS ACS では送信者、受信者、またはその両方に関するリソースを検証できる点に注意してください。

5. 検証が完了すると、QoS ACS サーバーは要求を承認し、帯域幅を論理的に割り当てます。次に、QoS ACS サーバーは、要求を Milan サイトの受信者に転送します。

6. RSVP 要求が Seattle と Milan のレイヤ 3 スイッチとエッジ ルーターを通過するときに、レイヤ 3 スイッチとエッジ ルーターは、要求されるリソース (帯域幅) を追跡します。Milan サイトの QoS ACS サーバーが要求を受け取ると、受信者として指定されているユーザーの身元と受付制御ポリシーを検証して、要求された帯域幅の容量とサービスのレベルに対する権利をそのユーザーが割り当てられていることを確認します。QoS ACS サーバーは要求を承認し、その要求を Milan サイトの受信側クライアントに転送します。

7. このようにしてデータ パスに沿ったすべてのネットワーク デバイスを通過した後で、要求が受信者に到達します。Milan サイトの受信側クライアントは、データの受信を希望することを示し、予約を要求する RSVP RESV メッセージを送り返します。

8. 帯域幅に対する受信者の要求が Milan サイトのエッジ ルーターを通過する時点では、要求された帯域幅に関する情報が (Seattle サイトの送信者の要求に基づいて) 既にそのルーターのキャッシュに格納されています。ルーターでは受信者の要求を送信者の要求と一致させ、帯域幅を割り当てることによって予約をインストールします。同じプロセスが、Seattle サイトのエッジ ルーターとレイヤ 3 スイッチでも繰り返されます。

9. 予約が送信者に送り返されます。RSVP 対応のレイヤ 3 ネットワーク デバイス (レイヤ 3 スイッチとエッジ ルーター) には、物理的な帯域幅を承認して割り当てる機能が組み込まれています。また、2 台の QoS ACS サーバーでは、RSVP RESV メッセージに対するポリシーのチェックも行われます。すべてのレイヤ 2 ネットワーク デバイス (ブリッジとレイヤ 2 スイッチ) については、予約は単に通過するだけです。

10. 予約のセットアップ プロセスの間に、送信者側のトラフィック制御によってトラフィックがベスト エフォートの基準に基づいて送信されます。送信側クライアントのトラフィック制御は、予約メッセージを受け取るとすぐに、パケットのマーキングを行うプロセスを開始します。マーキングは、レイヤ 2 とレイヤ 3 のどちらのデバイスに対しても QoS パケット スケジューラ が実行します。つまり、レイヤ 2 デバイスの優先順位の設定については、802.1p マーキングを実行し、このシナリオでレイヤ 3 スイッチとエッジ ルーターとして示したレイヤ 3 デバイスの優先順位の設定については、Diff-serv マーキングを実行します。NetMeeting パケットには、スイッチとルーターのキューにおける優先的な順位が割り当てられます。したがって、これらのパケットは、遅延を生じることなく受信者に到達するようになります。予約のセットアップが終了すると、ビデオとオーディオの品質が改善されます。

実装した方法

このシナリオにおいてコンピュータおよびデバイスを構成するために使用した手続きは、サンプルとして示したものです。実際の各ネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、そのシナリオの機能を実現するために必要な手順だけを示しています。運用ネットワークにおいて必要になるその他の手順については取り上げていません。

このセットアップ手順では、以下の構成を仮定しています。

• 各コンピュータには、適切なオペレーティング システムをインストールしてあります。

• Windows 2000 Professional を実行している各クライアントには、NetMeeting をインストールしてあります。

• Windows 2000 Professional と NetMeeting を実行している各クライアントには、ビデオ カード、PC ビデオ カメラ、およびサウンド カードもインストールしてあります。

• QoS ACS サーバーとして構成する各コンピュータは、それぞれに対応するドメインのメンバとして既に追加されています。

• Seattle と Milan の両方のサイトには、冗長性を確保する目的で、さらにもう 1 台ずつの QoS ACS サーバーがインストールされています。

  注意
  このシナリオで使用している IP アドレスは、プライベート ネットワーク用に予約された IP アドレス範囲内のアドレスです。テスト環境内やファイアウォールの背後ではこれらの IP アドレスを使用することはできますが、インターネット上では使用できません。詳細については、RFC 1918 を参照してください。

表 1 に、このシナリオのために使用したハードウェアおよびソフトウェアの一覧を示します。

表 1 このシナリオで QoS の導入に使用したハードウェアおよびソフトウェア

セットアップ手順

このシナリオでは、Seattle のクライアントから Milan のクライアントに至るエンドツーエンドの QoS ソリューションを導入するために、以下の作業を実施しました。

1. QoS パケット スケジューラのインストール

2. QoS 受付制御サービスのインストール

3. Seattle サイトの QoS 受付制御サービスの構成

4. Milan サイトの QoS 受付制御サービスの構成

5. Seattle サイトの Cisco 製レイヤ 3 スイッチ SEA-NA-CISCO-02 の構成

6. Seattle サイトの Cisco 製レイヤ 3 スイッチ SEA-NA-CISCO-03 の構成

7. Seattle サイトの Cisco 製ルーター SEA-NA-CISCO-01 の構成

8. Milan サイトの Cisco 製ルーター MIL-EU-CISCO-01 の構成

9. QoS RSVP の動作の検証

10. QoS RSVP のトラブルシューティング

図 4 は、このシナリオの作業の対象として検討するネットワークの部分を示しています。

図 4: このシナリオの QoS の構成

その他の参考資料

このシナリオについてさらに詳しく調べたい方は、以下の資料を参考にしてください。

Windows 2000 リソース キット
以下は、『Microsoft Windows 2000 Professional リソース キット』および『Microsoft Windows 2000 Server リソース キット』の参考資料です。オンラインで概要を参照できる章もあります。

• QoS について詳しくは、『Microsoft Windows 2000 Server リソース キット 6 TCP/IP ガイド』の「第 9 章 サービス品質」を参照してください。

• Active Directory と OU について詳しくは、『Microsoft Windows 2000 Server リソース キット 3 分散システム ガイド 上』の「第 1 章 Active Directory の論理構造」を参照してください。

ツール
QoS のトラブルシューティングに使用するツールについて詳しくは、『Microsoft Windows 2000 Server リソース キット 6 TCP/IP ガイド』の「第 9 章 サービス品質」を参照してください。

Requests for Comments (RFC)

Quality of Service の詳細については、RFC Editor Web サイト (英語) で以下の文書を参照してください。

• RFC 2205: 「Resource Reservation Protocol (RSVP) Version 1 Functional Specification」

• RFC 2207: 「RSVP Extensions for IPSec Data Flows」

• RFC 2208: 「Resource Reservation Protocol (RSVP) — Version 1 Applicability Statement: Some Guidelines on Deployment」

• RFC 2209: 「Resource Reservation Protocol (RSVP) — Version 1 Message Processing Rules」

• RFC 2210: 「The Use of RSVP with IETF Integrated Services」

• RFC 2211: 「Specification of the Controlled-Load Network Element Service」

• RFC 2212: 「Specification of Guaranteed Quality of Service」

• RFC 2688: 「Integrated Services Mappings for Low Speed Networks」

• RFC 2689: 「Providing Integrated Services over Low-bitrate Links」

• RFC 2747: 「RSVP Cryptographic Authentication」

• RFC 2814: 「SBM (Subnet Bandwidth Manager) : A Protocol for RSVP-based Admission Control Over IEEE 802-style Networks」

• RFC 2816: 「A Framework for Integrated Services Over Shared and Switched IEEE 802 LAN Technologies」

• RFC 2750: 「RSVP Extensions for Policy Control」

ホワイト ペーパー
QoS の詳細については、『QoS テクニカル ホワイト ペーパー』を参照してください。

導入実験の詳細と協力企業について

• 導入実験、および導入実験に提供されたハードウェアに関する情報については、『導入実験のハードウェア仕様』を参照してください。

リソース キット導入実験シナリオの凡例

• Microsoft Windows 2000 リソース キット導入実験シナリオのネットワーク図で使用されている略語や記号について詳しくは、『導入実験シナリオの凡例』を参照してください。

リソース キット導入実験のネットワーク図

• ネットワークの設計、ネットワーク ルーティング設計、ドメイン ネーム システム (DNS) 設計、および Active Directory 階層の高水準の編成については、『導入実験のネットワーク図』を参照してください。

関連資料

• Windows 2000 Server リソース キット 購入ページ

• Windows 2000 Professional リソース キット 購入ページ

• Windows 2000 リソース キットの詳細については、こちらを参照してください。

注意
このシナリオにおいて、コンピュータおよびデバイスを構成するために使用した手続きは、サンプルとして紹介したものです。実際のネットワークでは、類似したコンピュータおよびデバイスを構成する場合でも、必要になる手順はそれぞれのケースで異なります。さらに各シナリオでは、目的とする機能を実現するために必要な手順だけを示しています。運用ネットワークにおいて必要になる、その他の手順については取り上げていません。すべてのシナリオは、特に表記しない限り Windows 2000 を使用してテストされています。また、ブラウザとして Microsoft Internet Explorer 5 以上を推奨します。