この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。
このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。
ビデオ ストリームを構成するデータ パケットは、ネットワークを介して送信されます。パケットは、キューに入れられた順に宛先に到着します。シンプルなネットワークの動作では、最初にキューに入れられたパケットが最初に到着するパケットになります。単一の LAN スイッチでは、このプロセスはかなりシンプルになります。スイッチに、メディアを送信するポートと受信するポートがあるためです。ネットワークが増大するとともに、シナリオは、順序付けされたパケットの理想的世界から、順序付けされていないパケットの集まりに変わります。つまり、負荷を処理する十分なキャパシティがないネットワーク リンクを介して送信し切れない数のパケットが、同時に生成されます。このような現実的なシナリオでは、ネットワーク リンク間のパケット フローを制御するために、いくつかの方法が必要になります。
Quality of Service(QoS)を使用して、他のパケットより先に処理できる特定タイプのパケットを識別できます。異なるプライオリティを必要とするパケットに QoS 情報が挿入されます。
QoS は、高速道路とそれを利用する車に例えることができます。高速道路に例えられるのはネットワークです。ネットワークは、出発地から目的地まで移動する方法を車(QoS の場合はデータ パケット)に提供するからです。高速道路に十分な車線があり、事故がない場合、通常交通はスムーズに流れるので、移動時間は大部分のユーザに受け入れ可能な長さになります。しかし、交通量がピークのときは、事態はそれほどよくない場合があります。相乗り車線が役に立ちます。特定の基準を満たす車が、相乗り車線を利用し、交通渋滞をう回する特典を持ちます。また、救急車などの緊急公務には、他の交通量をう回できるさらに高いプライオリティが与えられます。一方、大型車や重い荷を積んだ車は、車線を余計に利用するため、交通を渋滞させる可能性があります。以上と QoS が似ているのは、QoS では特定のパケットがネットワークに優先的にアクセスし、キュー内の他のパケットより先に送信できるためです。
従来、IP パケットでは、3 ビットを使用して、IP Precedence またはタイプ オブ サービス(ToS)(RFC 791)が指定されていました。Differentiated Services(DiffServ)(RFC 2474 および RFC 2475)モデルでは、6 ビットを使用して、IP Precedence の値も保持されます。DiffServ モデルは、確認転送(RFC 2597)を使用してドロップ確率でさまざまなトラフィック クラスを定義するとともに、緊急転送(RFC 2598)を使用して低損失、低遅延、および低ジッター サービスを実現します。確認転送のクラスはさまざまなタイプのトラフィックをグループ化するのに使用され、ドロップ確率はパケットがドロップされ続けるトラフィックをグループ化するのに使用されます。緊急転送は、パケットのドロップと遅延による影響を受けやすい音声などのトラフィックに使用されます。
各トラフィック タイプには異なる QoS 値を設定できるため、ネットワークでは、高い QoS 値を持つと識別されたパケットは先に送信されます。 表 5-1 に、さまざまな音声とビデオ トラフィックのタイプで使用される標準的な値をいくつか示します。
|
|
|
|
---|---|---|---|
ボイスコールには、1 つのパケット ストリームしかありません。ビデオ コールにはビデオのストリームと音声のストリームの 2 つのストリームがあり、コールの両方のストリームに同じ QoS マーキングを設定する必要があります。
Cisco Unified Communications Manager(Unified CM)は、メディア パケット用に QoS をマーキングするエンドポイントをサポートします。音声パケットが EF(DSCP 値 46)としてマーキングされるのに対し、メディア パケットはビデオ デバイスにより AF41(DSCP 値 34)としてマーキングされ、TelePresence エンドポイントのトラフィックは CS4(DSCP 値 32)としてマーキングされます。すべてのコール シグナリングは CS3(DSCP 値 24)としてマーキングされます。
QoS は Cisco TelePresence Video Communication Server(VCS)で設定します。VCS がメディアおよびコール シグナリングを処理するからです。VCS に登録するエンドポイント(Cisco TelePresence System EX Series、C Series、Cisco IP Video Phone E20 など)は、そのエンドポイントのメディアを DSCP AF41 としてマーキングし、コール シグナリングが DSCP CS3 を使用するように設定する必要があります。
ネットワークのトラフィックは、ネットワークがそれを信頼できるようにするため、マーキングする必要があります。パケットを信頼するスイッチなどのネットワーク要素を信頼境界にすることができます。信頼境界を設定することは重要です。ネットワークの他の要素が QoS のためにパケットをあらためてマーキングしないで済むからです。アクセス スイッチは、IP Phone をそれとのアソシエーションに基づいて信頼することができます。Cisco のスイッチは、自身と Phone を関連付けるためにレイヤ 2 プロトコル、Cisco Discovery Protocol(CDP)を使用します。これらのスイッチは、CDP を使用して IP Phone を個々の音声 VLAN に配置します。これにより、アクセス スイッチはこれらの Phone を信頼して適切な QoS によりパケットをマーキングできるので、信頼境界を設定することができます。IP Phone がスイッチと関連付けできないか、あるいは信頼境界がアクセス スイッチまたはディストリビューション スイッチである必要がある場合、スイッチは、デバイスの IP アドレスあるいは、コールのためにシグナリングまたはメディアで使用される共通のポートなどの基準に基づいてパケットのマーキングを実施することで、信頼境界を作成することができます。
ネットワークは、QoS を使用してさまざまなトラフィック タイプを識別し、プライオリティを設定する一方で、キューイング メカニズムを使用して順序に従ってパケットを転送し、フローを制御します。キューイングは、MAN ネットワークや WAN ネットワークなど、相互間のリンクが低キャパシティであるネットワークで広く使用されています。
ネットワークでよく使用されるキューイング メカニズムは次のとおりです。
このタイプのキューイングはシンプルで、同じ時間にキューに入れられたパケットはすべて同時に送信されます。パケットは、キューに入れられた順序で、スイッチまたはネットワークを介して送信されます。このタイプのキューイングは、パケット量の大きな変動がないネットワークで使用できます。
このタイプのキューイングでは、プライオリティが高いパケットが、プライオリティが低いパケットより先に送信されます。プライオリティ キューは、ボイスコールなど、遅延の影響を非常に受けやすい低帯域幅のトラフィックでよく使用されます。
このタイプのキューイングでは、プライオリティ トラフィックおよび非プライオリティ トラフィックに対して複数のキューを使用します。これは、プライオリティの低いトラフィックがスタベーション状態にならないプライオリティ トラフィックを実現します。このメカニズムが使用されるのは、ネットワークで、プライオリティを必要とするトラフィック(音声トラフィックなど)や、ドロップできないビジネス アプリケーションなどの重要なトラフィックがある場合です。
このタイプのキューイングは、トラフィックをグループ化する複数のクラスと WFQ メカニズムを使用する一方で、カスタム キュー専用の帯域幅を用意します。このタイプのメカニズムは、ビジネス アプリケーションと結びついたインタラクティブな音声トラフィックおよびビデオ トラフィックで広く使用されています。このメカニズムには、さまざまなタイプの企業向けの導入に対して柔軟性があるというメリットがあります。
キューイング メカニズムは、組織のパケットでサービス クラス(CoS)を実現します。サービス クラスはレイテンシ、ジッター、および遅延の要件を保証するのに使用されます。また、それはリンクの帯域幅を効率的に使用して、組織が WAN リンクを介して送信できるトラフィックを見積もったり、目的のトラフィックをサポートできるようリンクを計画したりできるようにもします。
特定のキューがすべての帯域幅を使用しないように、トラフィックをポリシングすることが重要です。ポリシングは、特定タイプのトラフィックがリンクにおいて設定された使用制限を超えないようにします。ポリシングは、トラフィック シェーピングとともに、パケットのドロップを防止するほか non-critical トラフィックの処理を可能にするために必要です。
ビデオ コールでは、リップシンクの問題が発生しないよう、コールのビデオ ストリームと音声ストリームの両方を同じキューから送信することが重要です。ビデオ ストリームと音声ストリームで異なるキューを使用する場合、一方のストリームが他方のストリームより遅く到着するため、音声が遅延している間にその音声に関連するビデオが表示されたり、またはこの逆が起きたりします。
音声トラフィックとビデオ トラフィックがリンクの全帯域幅を使用せず、ビジネス アプリケーションなどの他の重要データのパケットがドロップしないようにするために、組織ではコール アドミッション制御を使用することができます。コール アドミッション制御は、サイト間の特定のリンクで使用可能なコール数を制限します。
• コールのカウント:この方法では、コール制御エージェントがロケーション間で使用可能なコール数をカウントします。同じタイプのコール別にのみカウントが行われるので、そのようなコールは、設定された音声コーデックおよび設定されたビデオ コーデックでは容易にカウントできます。
• 帯域幅:この方法はコールのカウントと基本的には同じですが、コールで使用される帯域幅の量をカウントする点が異なります。帯域幅のカウントには、音声コーデックのタイプとビデオ コールの帯域幅のタイプが使用されます。
コール品質を維持することが重要です。コールが WAN リンクを通過するときにリンクをオーバーサブスクライブすると、コール品質が低下する可能性があります。コール アドミッション制御は、リンクがコールでいっぱいにならないようにするために重要です。コール制御エージェントは、コールをルーティングする際に、コールを許可できるか、またはリンクがコールを処理できないかを判別します。これにより、ユーザは一貫したコール体験が可能になります。
Cisco Unified CM は、コール アドミッション制御を帯域幅方式でサポートします。これにより、さまざまなコーデック タイプおよびビデオ帯域幅タイプを含むコールが企業ネットワークでサポートできます。Unified CM は、地域のメカニズムを使用して、コーデックとビデオ帯域幅にコールごとのパラメータを指定します。また、Unified CM は、ロケーションのメカニズムを使用して、特定サイトの音声およびビデオ コールを制限するための帯域幅値を指定します。Cisco TelePresence VCS が使用する類似のメカニズムでは、リンクでコールごとの帯域幅を設定し、パイプでサイトに対して全コールの帯域幅を設定します。
コール アカウンティングのコール カウントおよび帯域幅方式では静的な設定値を使用しますが、実際のコールで使用される帯域幅はこの値より大きかったり小さかったりします。コールで使用される実際の帯域幅を特定するには、Resource Reservation Protocol(RSVP)が使用されます。このプロトコルは、メディアで使用されている実際のパスを確認して、コールに十分な帯域幅が使用可能かどうかを判定します。コールを処理できる帯域幅がパスのデバイスにない場合は、その状態が RSVP を介してレポートされ、コールが許可されない可能性があります。
Cisco Unified CM は、Cisco RSVP Agent という別個のメディア デバイスを使用し、ビデオ エンドポイントの代わりに RSVP を使用して、ネットワーク帯域幅についてネゴシエーションします。これにより、それを介した正確なアカウンティングが可能になります。
TelePresence コールでは、これらの技術によってユーザ エクスペリエンスを保証するためのトラフィックを可能にするようネットワークが設計されているため、コール アドミッション制御を使用しません。TelePresence のトラフィックは音声およびビデオとは異なる方法でマーキングされる、つまり別のキューに入れられるため、レイテンシと遅延が低く、ユーザ エクスペリエンスを保証することができます。
組織に複数のコール制御エージェントがある場合は、各エージェントが独自のコール アドミッション制御を行います。これらは、同時に動作しますが、相手の中を通過しているコールを認識できません。同じサイト内の 2 つの異なるコール制御エージェント間でコールが行われる場合、このコールの帯域幅を両方のエージェントがカウントします。これが WAN 帯域幅を使用しない場合でも、そうです。このため、組織内では、デバイスのコール アドミッション制御は、ただ 1 つのコール制御エージェントで行うことが重要です。