Loading article…
サービス品質( QoS ) は、電話やコンピュータ ネットワーク、クラウド コンピューティングサービスなどのサービスの全体的なパフォーマンス、特にネットワーク ユーザーから見たパフォーマンスを説明または測定するものです。サービス品質を定量的に測定するには、パケット損失、ビット レート、スループット、伝送遅延、可用性、ジッターなど、ネットワーク サービスの関連するいくつかの側面を考慮することがよくあります。
コンピュータ ネットワーキングやその他のパケット交換通信ネットワークの分野では、サービス品質は、達成されるサービス品質ではなく、トラフィックの優先順位付けとリソース予約制御メカニズムを指します。サービス品質とは、さまざまなアプリケーション、ユーザー、またはデータフローに異なる優先順位を提供したり、データ フローに一定レベルのパフォーマンスを保証したりする機能です。
サービス品質は、特別な要件のあるトラフィックの転送において特に重要です。特に、開発者はVoice over IPテクノロジを導入して、コンピュータ ネットワークを電話ネットワークと同様に音声会話に使用できるようにし、さらに厳しいネットワーク パフォーマンス要件を持つ新しいアプリケーションをサポートできるようにしました。
定義
電話の分野では、サービス品質は1994年にITUによって定義されました。 [1]サービス品質は、サービス応答時間、損失、信号対雑音比、クロストーク、エコー、割り込み、周波数応答、音量レベルなど、接続のあらゆる側面に関する要件で構成されています。電話QoSのサブセットは、サービスグレード（GoS）要件であり、保証された最大ブロッキング確率や停止確率など、ネットワークの容量とカバレッジに関連する接続の側面で構成されています。[2]
コンピュータ ネットワーキングやその他のパケット交換通信ネットワークの分野では、テレトラフィック エンジニアリングは、達成されるサービス品質ではなく、トラフィックの優先順位付けとリソース予約制御メカニズムを指します。サービス品質とは、さまざまなアプリケーション、ユーザー、またはデータ フローに異なる優先順位を提供したり、データ フローに一定レベルのパフォーマンスを保証したりする機能です。たとえば、必要なビット レート、遅延、遅延変動、パケット損失、またはビット エラー レートが保証される場合があります。サービス品質は、Voice over IP、マルチプレイヤー オンライン ゲーム、IPTVなどのリアルタイムストリーミング マルチメディアアプリケーションにとって重要です。これらのアプリケーションでは、固定ビット レートが必要になることが多く、遅延の影響を受けやすいためです。サービス品質は、セルラー データ通信など、容量が限られたリソースであるネットワークでは特に重要です。
QoS をサポートするネットワークまたはプロトコルは、アプリケーション ソフトウェアとトラフィック契約を結び、セッション確立フェーズなどでネットワーク ノードの容量を予約することがあります。セッション中は、データ レートや遅延などの達成されたパフォーマンス レベルを監視し、ネットワーク ノードのスケジュール優先順位を動的に制御します。ティアダウン フェーズでは、予約された容量を解放することがあります。
ベストエフォート ネットワークまたはサービスでは、サービス品質はサポートされません。複雑な QoS 制御メカニズムの代替手段は、予想されるピーク トラフィック負荷に十分対応できるように容量を過剰にプロビジョニングすることで、ベスト エフォート ネットワーク上で高品質の通信を提供することです。その結果、ネットワークの輻輳がなくなり、QoS メカニズムの必要性が軽減または排除されます。
QoSは、リソースを予約する能力を指すのではなく、多くの代替定義を持つ品質の尺度として使用されることがあります。サービス品質は、サービス品質のレベル、つまり保証されたサービス品質を指すこともあります。[3]高いQoSは、高ビットレート、低レイテンシ、低ビットエラー率などの高レベルのパフォーマンスと混同されることがよくあります。
QoS は、電話やストリーミング ビデオなどのアプリケーション層サービスで、主観的に体験される品質を反映または予測するメトリックを表すために使用されることがあります。このコンテキストでは、QoS は、サービスに影響を与えるすべての欠陥が加入者の満足度に与える許容可能な累積効果です。同様の意味を持つ他の用語には、体感品質(QoE)、平均オピニオン スコア(MOS)、知覚音声品質測定(PSQM)、およびビデオ品質の知覚評価(PEVQ) があります。
歴史
過去には、データに QoS タグを追加するレイヤー 2テクノロジの試みが数多く行われ、人気を博しました。例としては、フレーム リレー、非同期転送モード(ATM)、マルチプロトコル ラベル スイッチング(MPLS) (レイヤー 2 と 3 の中間のテクノロジ) などがあります。これらのネットワーク テクノロジは現在でも使用されていますが、イーサネットネットワークの出現以降、この種のネットワークは注目されなくなりました。今日では、イーサネットが圧倒的に最も人気のあるレイヤー 2 テクノロジです。従来のインターネット ルーターとネットワーク スイッチは、ベスト エフォート方式で動作します。この機器は、QoS メカニズムを提供する以前のより複雑なテクノロジよりも安価で、複雑ではなく、高速であるため、人気があります。
イーサネットはオプションで802.1p を使用してフレームの優先度を通知します。
各IP パケット ヘッダーには、当初4 つのサービス タイプビットと 3 つの優先順位ビットが提供されていましたが、これらは一般には考慮されませんでした。これらのビットは、後に差別化サービス コード ポイント(DSCP) として再定義されました。
IPTVとIP テレフォニーの登場により、エンド ユーザーが QoS メカニズムを利用できる機会が増えています。
トラフィックの品質
パケット交換ネットワークでは、サービス品質はさまざまな要因によって左右されますが、これらは人的要因と技術的要因に分けられます。人的要因には、サービス品質の安定性、サービスの可用性、待ち時間、ユーザー情報などがあります。技術的要因には、信頼性、拡張性、有効性、保守性、ネットワーク輻輳などがあります。[4]
パケットが送信元から送信先まで移動する間にさまざまなことが発生する可能性があり、送信者と受信者の観点から見ると次のような問題が発生します。
- グッドプット
- 同じネットワーク リソースを共有するさまざまなユーザーからの負荷が変化するため、特定のデータ ストリームに提供できる最大スループットは、リアルタイムのマルチメディア サービスには低すぎる可能性があります。
- パケット損失
- ネットワークの輻輳により、一部のパケットが配信されない (ドロップされる) 場合があります。受信側アプリケーションがこの情報の再送信を要求する場合があり、その結果、輻輳による崩壊や全体的な送信の許容できない遅延が発生する可能性があります。
- エラー
- 特に無線通信や長い銅線では、ノイズや干渉によってビット エラーが発生し、パケットが破損することがあります。受信側はこれを検出し、パケットがドロップされた場合と同様に、この情報の再送信を要求する場合があります。
- レイテンシー
- 各パケットが長いキューで待機したり、混雑を避けるために間接的なルートを取ったりするため、宛先に到達するまでに長い時間がかかることがあります。場合によっては、遅延が長すぎると、VoIP やオンライン ゲームなどのアプリケーションが使用できなくなることがあります。
- パケット遅延変動
- 送信元からのパケットは、さまざまな遅延を伴って送信先に到達します。パケットの遅延は、送信元と送信先の間のパスにあるルーターのキュー内の位置によって異なり、この位置は予測できないほど変化する可能性があります。遅延の変化は受信側で吸収できますが、その場合、ストリームの全体的な遅延が増加します。
- 順序外配送
- 関連するパケットの集合がネットワークを介してルーティングされる場合、異なるパケットが異なるルートを取る可能性があり、それぞれ異なる遅延が発生します。その結果、パケットは送信された順序とは異なる順序で到着します。この問題には、順序が乱れたパケットを並べ替えるための特別な追加プロトコルが必要です。並べ替えプロセスには、受信側で追加のバッファリングが必要になり、パケット遅延の変動と同様に、ストリームの全体的な遅延が増加します。
アプリケーション
特定の種類のネットワーク トラフィックでは、定義されたサービス品質が望まれるか、または必要になる場合があります。次に例を示します。
- ストリーミングメディア
- ボイスオーバーIP (VoIP)
- ビデオ電話
- テレプレゼンス
- iSCSIやFibre Channel over Ethernetなどのストレージアプリケーション
- 回路エミュレーションサービス
- 可用性の問題が危険となる遠隔手術などの安全性が重要なアプリケーション
- ネットワーク自体または顧客のビジネスクリティカルなニーズに対応するネットワーク運用サポートシステム
- リアルタイムラグが要因となるオンラインゲーム
- 機械のリアルタイム制御に使用されるEtherNet/IPなどの産業用制御システムプロトコル
これらのタイプのサービスは非弾性と呼ばれ、機能するには一定の最小ビット レートと一定の最大遅延が必要です。対照的に、弾性アプリケーションは、利用可能な帯域幅が多かれ少なかれ、それを活用できます。TCPに依存するバルク ファイル転送アプリケーションは、一般的に弾性です。
メカニズム
回線交換ネットワーク、特に ATM やGSMなどの音声伝送を目的としたネットワークでは、コア プロトコルに QoS が備わっており、ネットワークの各ステップで通話のセットアップ時にリソースが予約されるため、必要なパフォーマンスを達成するために追加の手順は必要ありません。データ ユニットが短く、QoS が組み込まれていることは、ビデオ オン デマンドなどのアプリケーションにとって ATM のユニークなセールス ポイントの一部でした。
QoS を提供するためのメカニズムの費用が正当化される場合、ネットワークの顧客とプロバイダーは、相互に合意された基準に基づいてスループットまたは遅延に関して保証されたパフォーマンスを提供する接続の能力に対する保証を指定する、 サービス レベル契約(SLA) と呼ばれる契約上の合意を締結できます。
過剰プロビジョニング
複雑な QoS 制御メカニズムの代替案としては、ネットワークを余裕を持ってオーバープロビジョニングし、容量がピーク時のトラフィック負荷の推定値に基づいて決定されるようにすることで、高品質の通信を提供するという方法があります。このアプローチは、ピーク負荷が予測可能なネットワークでは簡単です。この計算では、帯域幅の変化や遅延を大きな受信バッファで補正できる要求の厳しいアプリケーションを評価する必要がある場合があります。これは、ビデオ ストリーミングなどでよく発生します。
オーバープロビジョニングは、時間の経過とともにネットワーク上に配置されるデータの量が増加し、使用可能な帯域幅がすべて消費されてパケットがドロップされるトランスポート プロトコル ( TCPなど) の場合、あまり効果がありません。このような貪欲なプロトコルは、すべてのユーザーの待ち時間とパケット損失を増加させる傾向があります。
QoS を置き換えるために必要な内部リンクのオーバープロビジョニングの量は、ユーザー数とトラフィック需要によって異なります。これにより、オーバープロビジョニングの有用性が制限されます。帯域幅を大量に消費する新しいアプリケーションや、ユーザーの追加により、オーバープロビジョニングされたネットワークが失われます。この場合、関連するネットワーク リンクの物理的な更新が必要になりますが、これはコストのかかるプロセスです。したがって、インターネットではオーバープロビジョニングを盲目的に想定することはできません。
商用 VoIP サービスは、ユーザーの ISP への接続や VoIP プロバイダーの別の ISP への接続で QoS メカニズムが使用されていない場合でも、通話品質の点で従来の電話サービスと競合することがよくあります。ただし、高負荷状態では、VoIP は携帯電話の品質以下に低下する可能性があります。パケット トラフィックの計算によると、控えめな仮定の下では、ネットワークには 60% 以上の生の容量が必要です。[5]
IPとイーサネットの取り組み
単一所有者のネットワークとは異なり、インターネットはプライベートネットワークを相互接続する一連の交換ポイントです。[6]そのため、インターネットの中核は単一のエンティティではなく、さまざまなネットワークサービスプロバイダーによって所有および管理されています。その動作ははるかに予測不可能です。
現代のパケット交換 IP ネットワークにおける QoS には、ネットワークとのアプリケーション要件の交換に基づくパラメータ化システムと、各パケットがネットワークに対して必要なサービス レベルを識別する優先順位付けシステムという 2 つの主要なアプローチがあります。
- 統合サービス(「IntServ」) は、パラメータ化されたアプローチを実装します。このモデルでは、アプリケーションはリソース予約プロトコル(RSVP) を使用して、ネットワーク経由でリソースを要求および予約します。
- 差別化サービス(「DiffServ」) は、優先順位付けモデルを実装します。DiffServ は、必要なサービスの種類に応じてパケットをマークします。これらのマークに応じて、ルータとスイッチはさまざまなスケジューリング戦略を使用して、期待どおりにパフォーマンスを調整します。差別化サービス コード ポイント (DSCP) マークは、 IP(v4) パケット ヘッダーのToSフィールド (現在は DS フィールドに名前が変更されています)の最初の 6 ビットを使用します。
初期の研究では、ネットワーク リソースを予約する統合サービス (IntServ) の考え方が採用されていました。このモデルでは、アプリケーションは RSVP を使用してネットワーク経由でリソースを要求および予約していました。IntServ メカニズムは機能しますが、大規模なサービス プロバイダーに典型的なブロードバンド ネットワークでは、コア ルーターが数千または数万の予約を受け入れ、維持し、破棄する必要があることが認識されました。このアプローチはインターネットの成長に合わせて拡張できないと考えられており、[ 7]いずれにしても、コア ルーターがパケットを可能な限り高速に切り替える以上のことはほとんど行わないようにネットワークを設計するというエンドツーエンドの原則に反していました。
DiffServ では、パケットはトラフィック ソース自体によって、またはトラフィックがネットワークに入るエッジ デバイスによってマークされます。これらのマークに応じて、ルータとスイッチはさまざまなキューイング戦略を使用して、要件に合わせてパフォーマンスを調整します。IP 層では、DSCP マークは IP パケット ヘッダーの 6 ビット DS フィールドを使用します。MAC 層では、VLAN IEEE 802.1Q を使用して、基本的に同じ 3 ビットの情報を伝送できます。DiffServ をサポートするルータとスイッチは、帯域幅が制限された (ワイド エリアなど) インターフェイスからの送信を待機しているパケットに複数のキューを使用するようにネットワーク スケジューラを構成します。ルータ ベンダーは、サポートされるキューの数、キューの相対的な優先順位、および各キューに予約される帯域幅など、この動作を構成するためのさまざまな機能を提供します。
実際には、キューイングのあるインターフェイスからパケットを転送する必要がある場合、低ジッタを必要とするパケット ( VoIPやビデオ会議など) は、他のキューのパケットよりも優先されます。通常、ネットワーク制御パケット (インターネット制御メッセージ プロトコルやルーティング プロトコルなど) には、デフォルトでいくらかの帯域幅が割り当てられますが、ベスト エフォート トラフィックには、残った帯域幅がそのまま割り当てられることがあります。
メディアアクセス制御（MAC）層では、VLAN IEEE 802.1QおよびIEEE 802.1pを使用してイーサネットフレームを区別し、分類することができます。MAC層プロトコルのパフォーマンス分析とQoSに関するキューイング理論モデルが開発されています。[8] [9]
Cisco IOS NetFlowとCisco Class Based QoS（CBQoS）管理情報ベース（MIB）は、シスコシステムズによって販売されています。 [10]
インターネットで QoS が必要であることを示す説得力のある例の 1 つは、輻輳崩壊に関連しています。インターネットは、輻輳崩壊につながるような状況下でトラフィックを削減するために、主に伝送制御プロトコル (TCP) に組み込まれている輻輳回避プロトコルに依存しています。VoIP や IPTV などの QoS アプリケーションは、ほぼ一定のビットレートと低遅延を必要とするため、TCP を使用できず、輻輳を防ぐためにトラフィック レートを削減することもできません。サービス レベル契約は、インターネットに提供できるトラフィックを制限し、それによってインターネットが過負荷になるのを防ぐトラフィック シェーピングを実施します。したがって、サービス レベル契約は、リアルタイム トラフィックと非リアルタイム トラフィックの混合を崩壊なく処理するインターネットの機能に不可欠な要素です。
プロトコル
IP ネットワーキングにはいくつかの QoS メカニズムとスキームが存在します。
- IPv4 ヘッダーのサービスタイプ( ToS) フィールド(現在はDiffServに置き換えられています)
- 差別化サービス(DiffServ)
- 統合サービス(IntServ)
- リソース予約プロトコル(RSVP)
- 返信-TE
QoS 機能は、次のネットワーク テクノロジーで利用できます。
- マルチプロトコルラベルスイッチング（MPLS）は8つのQoSクラスを提供する[11]
- フレームリレー
- X.25
- 一部のDSLモデム
- ATM
- オーディオビデオブリッジングとタイムセンシティブネットワーキングを備えたIEEE 802.1Qをサポートするイーサネット
- IEEE 802.11e をサポートするWi-Fi
- HomePNA同軸ケーブルと電話線を介したホームネットワーク
- G.hnホーム ネットワーキング標準は、QoS を必要とし、ネットワーク コントローラと契約をネゴシエートしたフローに割り当てられる競合のない送信機会(CFTXOP)によって QoS を提供します。G.hn は、競合ベースのタイム スロットによって非 QoS 操作もサポートします。
エンドツーエンドのサービス品質
エンドツーエンドのサービス品質には、ある自律システムと別の自律システム間のリソース割り当てを調整する方法が必要になる場合があります。インターネット技術特別調査委員会(IETF) は、 1997 年に帯域幅予約用のリソース予約プロトコル(RSVP) を標準提案として定義しました。 [12] RSVP は、エンドツーエンドの帯域幅予約およびアドミッション制御プロトコルです。RSVP は、スケーラビリティの制限により広く採用されませんでした。[13]よりスケーラブルなトラフィックエンジニアリングバージョンであるRSVP-TEは、多くのネットワークで、トラフィックエンジニアリングされたマルチプロトコルラベルスイッチング(MPLS) ラベルスイッチパスを確立するために使用されます。 [14] IETF は、 QoS シグナリングをターゲットとしたNext Steps in Signaling (NSIS) [15]も定義しました。NSIS は、RSVP を開発および簡素化したものです。
「異種ネットワークにおけるエンドツーエンドのサービス品質サポート」（EuQoS、2004年から2007年）[16]などの研究コンソーシアムやIPsphere Forum [17]などのフォーラムでは、ドメイン間でQoS呼び出しをハンドシェイクするためのメカニズムがさらに開発されました。IPsphereは、ネットワークサービスを確立、呼び出し、および（試行）保証するためのサービス構造化層（SSS）シグナリングバスを定義しました。EuQoSは、セッション開始プロトコル、シグナリングの次のステップ、およびIPsphereのSSSを統合する実験を約1560万ユーロの費用で実施し、書籍を出版しました。[18] [19]
研究プロジェクト Multi Service Access Everywhere (MUSE) は、2004 年 1 月から 2006 年 2 月までの第 1 フェーズと、2006 年 1 月から 2007 年までの第 2 フェーズで、別の QoS 概念を定義しました。 [20] [21] [22] PlaNetS という別の研究プロジェクトは、2005 年頃に欧州の資金提供を受けるために提案されました。[23] 4WARD として知られる「将来のインターネットのアーキテクチャと設計」と呼ばれるより広範な欧州プロジェクトは、2,340 万ユーロの予算が見積もられ、2008 年 1 月から 2010 年 6 月まで資金提供されました。[24] このプロジェクトには「サービス品質のテーマ」が含まれており、書籍も出版されています。[25] [26] WIDENS (Wireless Deployable Network System) と呼ばれる別の欧州プロジェクト[27]は、モバイル無線マルチレート アドホック ネットワーク用の帯域幅予約アプローチを提案しました。[28]
制限事項
Secure Sockets Layer、I2P、仮想プライベート ネットワークなどの強力な暗号化ネットワーク プロトコルは、それらを使用して転送されるデータを隠します。インターネット上のすべての電子商取引では、このような強力な暗号化プロトコルの使用が求められるため、暗号化されたトラフィックのパフォーマンスを一方的に低下させると、顧客にとって受け入れがたい危険が生じます。ただし、暗号化されたトラフィックは、 QoS のディープ パケット インスペクションを受けることができません。
ICAやRDPなどのプロトコルは、さまざまな要件を持つ他のトラフィック (印刷、ビデオ ストリーミングなど) をカプセル化することがあり、最適化が困難になる可能性があります。
Internet2プロジェクトは 2001 年に、当時の機器では QoS プロトコルを Abilene ネットワーク内に導入できない可能性が高いことを発見しました。[ 29 ] [a]このグループは、QoS を目的としたプロトコルの変更によって「ロジスティック、財務、組織上の障壁が帯域幅の保証への道を阻む」と予測しました。[30] 彼らは、経済的な理由から、ネットワーク プロバイダーはベスト エフォート トラフィックの品質を意図的に低下させ、顧客を高額な QoS サービスに誘導するだろうと考えました。代わりに、当時は容量のオーバープロビジョニングの方がコスト効率が高いと提案しました。[29] [30]
アビリーンのネットワーク研究は、2006 年初頭に米国上院商務委員会のネットワーク中立性に関する公聴会でゲイリー バチュラが証言した根拠となった。バチュラは、帯域幅を増やすことは、検討されたさまざまな QoS 達成方式のどれよりも効果的であるという意見を表明した。 [31]バチュラの証言は、サービス品質を禁止する法律の支持者によって、そのようなサービスでは正当な目的が果たされないことの証拠として引用されている。この議論は、過剰プロビジョニングは QoS の一形態ではなく、常に可能であるという仮定に依存している。コストやその他の要因は、通信事業者が恒久的に過剰プロビジョニングされたネットワークを構築および維持する能力に影響を与える。[要出典]
モバイル（セルラー）QoS
有線公衆交換電話網サービス プロバイダーやインターネット サービス プロバイダーがQoS を提供するのと同様に、モバイル セルラー サービス プロバイダーも顧客にモバイル QoS を提供できます。QoS メカニズムは回線交換サービスには常に提供されており、ストリーミング マルチメディアなどの非弾性サービスには不可欠です。
モビリティにより、QoS メカニズムが複雑になります。新しい基地局が過負荷になると、ハンドオーバー後に通話やその他のセッションが中断される可能性があります。予測不可能なハンドオーバーにより、セッション開始フェーズ中に絶対的な QoS を保証することが不可能になります。
標準
電話分野におけるサービス品質は、1994 年にITU-T勧告 E.800 で初めて定義されました。この定義は非常に広範で、サポート、操作性、アクセス性、保持性、整合性、セキュリティという 6 つの主要コンポーネントが挙げられています。[1] 1998 年に ITU はデータ ネットワーキング分野における QoS について議論した文書を公開しました。X.641 は、QoS に関連する標準を開発または強化する手段を提供し、関連する標準の一貫性を維持するのに役立つ概念と用語を提供します。[32]
QoS 関連の IETF のRequest for Comments (RFC) には、Baker, Fred、Black, David L.、Nichols, Kathleen、Blake, Steven L. (1998 年 12 月)、「IPv4 および IPv6 ヘッダーの Differentiated services フィールド (DS フィールド) の定義」、doi : 10.17487/RFC2474、RFC 2474などがあります。、およびBraden, Robert T.、Zhang, Lixia、Berson, Steven、Herzog, Shai、Jamin, Sugih (1997 年 9 月)、Braden, R. (ed.)、Resource ReSerVation Protocol (RSVP)、doi : 10.17487/RFC2205、RFC 2205 ; これらについては上で説明しました。IETF は QoS の背景を説明する 2 つの RFC も発行しています: Huston, Geoff (2000 年 11 月)、Next Steps for the IP QoS Architecture、doi :10.17487/RFC2990、RFC 2990 、およびFloyd、S.、Kempf、J. (2004)、Kempf、J. (ed.)、インターネットにおける音声トラフィックの輻輳制御に関する IAB の懸念、doi :10.17487/RFC3714、RFC 3714 。
IETFは、Baker, Fred、Babiarz, Jozef、Chan, Kwok Ho (2006年8月)、DiffServサービスクラスの構成ガイドライン、doi : 10.17487/RFC4594、RFC 4594も公開しています。 DiffServネットワークの QoS ソリューションを設計する際の実際的な側面について、参考資料またはベスト プラクティスドキュメントとして提供します。このドキュメントでは、IP ネットワーク上で一般的に実行されるアプリケーションを識別し、それらをトラフィック クラスにグループ化し、ネットワークからこれらのクラスに必要な処理を調査し、それらの処理を実装するためにルーターで一般的に使用できる QoS メカニズムのどれを使用できるかを提案します。
参照
注記
- ^ 当時利用可能だった機器は、QoS を実装するためにソフトウェアに依存していました。
参考文献
- ^ ab 「E.800: 信頼性を含むサービス品質とネットワークパフォーマンスに関する用語と定義」ITU-T 勧告1994 年 8 月2011 年10 月 14 日閲覧。2008年9月にサービス品質に関連する用語の定義として更新されました
- ^ Teletraffic Engineering Handbook Archived January 11, at the Wayback Machine ITU-T Study Group 2 (350 ページ、2.69 MB)(QoS の代わりに略語 GoS を使用しています)
- ^ Menychtas Andreas (2009). 「グリッド環境での QoS プロビジョニング レベルを保証するためのリアルタイム再構成」. Future Generation Computer Systems . 25 (7): 779–784. doi :10.1016/j.future.2008.11.001.
- ^ Peuhkuri M. (1999-05-10). 「IP サービス品質」。ヘルシンキ工科大学、電気通信技術研究所。
- ^ Yuksel, M.; Ramakrishnan, KK; Kalyanaraman, S.; Houle, JD; Sadhvani, R. (2007). 「IP バックボーンにおけるサービス クラスのサポートの価値」。2007 年 15 回 IEEE 国際サービス品質ワークショップ(PDF) 。エバンストン、イリノイ州、米国。pp . 109–112。CiteSeerX 10.1.1.108.3494。doi : 10.1109 / IWQOS.2007.376555。ISBN 978-1-4244-1185-6. S2CID 10365270. 2012年4月30日時点の オリジナル（PDF）からアーカイブ。2009年1月24日閲覧。
{{cite book}}: CS1 メンテナンス: 日付と年 (リンク) CS1 メンテナンス: 場所の発行元がありません (リンク) - ^ 「ロバート・カーンとの夕べ」。コンピュータ歴史博物館。2007年1月9日。2008年12月19日時点のオリジナルよりアーカイブ。
- ^ 「4.9」。画像およびビデオ処理ハンドブック（第2版）。2005年。ISBN 978-0-12-119792-6
しかし、ルートに沿ってフローベースのリソース予約を設定するには膨大な労力が必要です。さらに、必要な制御シグナリングとルータでの状態維持により、このアプローチのスケーラビリティが制限されます
。 - ^ Bianchi, Giuseppe (2000). 「IEEE 802.11 分散調整機能のパフォーマンス分析」. IEEE Journal on Selected Areas in Communications . 18 (3): 535–547. CiteSeerX 10.1.1.464.2640 . doi :10.1109/49.840210.
- ^ Shi, Zhefu; Beard, Cory; Mitchell, Ken (2009). 「CSMA ネットワークにおける不正行為と MAC フレンドリネスを理解するための分析モデル」.パフォーマンス評価. 66 (9–10): 469. CiteSeerX 10.1.1.333.3990 . doi :10.1016/j.peva.2009.02.002.
- ^ Ben Erwin (2008 年 12 月 16 日)。「How To Manage QoS In Your Environment, Part 1 of 3」。Network Performance Daily ビデオ。NetQoS。2011年 9 月 29 日時点のオリジナルよりアーカイブ。2011 年10 月 15 日閲覧。
- ^ 「VoIP on MPLS」。Unified Communications を検索。2012年3 月 12 日閲覧。
- ^ Bob Braden編、L. Zhang、S. Berson、S. Herzog、S. Jamin (1997 年 9 月)。リソース予約プロトコル (RSVP )。IETF。doi : 10.17487 / RFC2205。RFC 2205 。
{{citation}}: CS1 maint: 複数の名前: 著者リスト (リンク) - ^ Pana, Flavius; Put, Ferdi (2014 年 12 月)、「OPNET Modeler を使用した RSVP のパフォーマンス評価」、シミュレーション モデリングの実践と理論、49 : 85–97、doi :10.1016/j.simpat.2014.08.005
- ^ MPLSセグメントルーティング、Arista、2019年12月10日、 2020年4月16日取得
- ^ 「「シグナリングにおける次のステップ」憲章」
- ^ 「EuQoS - 異機種ネットワーク上でのエンドツーエンドのサービス品質サポート」。プロジェクト Web サイト。2004–2006 年。2007 年 4 月 30 日時点のオリジナルからアーカイブ。2011年10 月 12 日閲覧。
- ^ IPSphere: 高度なサービス提供の実現 2011年1月13日アーカイブ、Wayback Machine
- ^ 「異機種ネットワーク上のエンドツーエンドのサービス品質サポート」。プロジェクトの説明。欧州共同体研究開発情報サービス。2011年10 月 12 日閲覧。
- ^ Torsten Braun、Thomas Staub (2008)。異機種ネットワーク上のエンドツーエンドのサービス品質。Springer。ISBN 978-3-540-79119-5。
- ^ 「Multi Service Access Everywhere (MUSE)」。プロジェクトのウェブサイト。 2011年10月12日閲覧。
- ^ 「Multi Service Access Everywhere」。プロジェクトの説明。欧州共同体研究開発情報サービス。 2011年10月12日閲覧。
- ^ 「Multi Service Access Everywhere」。プロジェクトの説明。欧州共同体研究開発情報サービス。 2011年10月12日閲覧。
- ^ 「PlaNetS QoS ソリューション」。プロジェクト Web サイト。2017 年 7 月 28 日。2009 年 11 月 12 日時点のオリジナルよりアーカイブ。2011年10 月 12 日閲覧。
- ^ 「4WARD: 将来のインターネットのためのアーキテクチャとデザイン」。プロジェクトの説明。欧州共同体研究開発情報サービス。2011年10 月 15 日閲覧。
- ^ 「Going 4WARD」。プロジェクトニュースレター。2010年6月。 2013年5月9日時点のオリジナル（PDF）からアーカイブ。2011年10月15日閲覧。
- ^ ルイス・M・コレイア;ジョアン・シュワルツ (FRW) ダ・シルバ (2011 年 1 月 30 日)。未来のインターネットのためのアーキテクチャとデザイン: 4WARD EU プロジェクト。スプリンガー。ISBN 978-90-481-9345-5。
- ^ 「ワイヤレス展開可能ネットワークシステム」。プロジェクトの説明。欧州連合。 2012年5月23日閲覧。
- ^ R. Guimaraes、L. Cerdà、JM Barcelo-Ordinas、J. Garcia-Vidal、M. Voorhaen、C. Blondia (2009 年 3 月)。「マルチレート Ad-doc ワイヤレス ネットワークでの帯域幅予約によるサービス品質」。Ad Hoc Networks。7 ( 2 ): 388–400。doi :10.1016/j.adhoc.2008.04.002。
- ^ ab Benjamin Teitelbaum、Stanislav Shalunov (2002 年 5 月 3 日)。「プレミアム IP サービスが展開されていない理由 (そしておそらく今後も展開されない理由)」。ドラフト情報文書。Internet2 QoS ワーキング グループ。2002 年 8 月 30 日時点のオリジナルからアーカイブ。2011年10 月 15 日閲覧。
- ^ ab Andy Oram (2002 年 6 月 11 日)。「ネットワークのサービス品質を高める優れた方法?」。プラットフォームに依存しないコラム。O'Reilly。2002 年 8 月 5 日時点のオリジナルよりアーカイブ。2011 年10 月 15 日閲覧。
- ^ Gary Bachula (2006年2月7日). 「Internet2副社長、Gary R. Bachulaの証言」(PDF) . pp. 2–3. 2010年1月7日時点のオリジナル(PDF)からアーカイブ。 2011年10月15日閲覧。
- ^ 「X.641: 情報技術 - サービス品質: フレームワーク」。ITU -T 勧告。1997 年 12 月。
さらに読む
- マルチサービス ネットワーク向け IP および MPLS QoS の導入: 理論と実践、 John Evans、Clarence Filsfils 著 (Morgan Kaufmann、2007 年、ISBN 0-12-370549-5 )
- Lelli、F. Maron、G. Orlando、S. リモート サービス実行のクライアント側推定。第 15 回コンピュータおよび通信システムのモデリング、分析、シミュレーションに関する国際シンポジウム、2007 年。MASCOTS '07。
- Mario Marchese 著「QoS Over Heterogeneous Networks」 (Wiley、2007 年、 ISBN 978-0-470-01752-4 )
- XiPeng Xiao (2008 年 9 月 8 日)。QoS の技術的、商業的、および規制上の課題: インターネット サービス モデルの観点。Morgan Kaufmann。ISBN 978-0-12-373693-2。
- Braden, Robert T.; Clark, David D.; Shenker, Scott (1994 年 6 月)、「インターネット アーキテクチャにおける統合サービス: 概要」、doi :10.17487/RFC1633、RFC 1633
- Black, David L.; Wang, Zheng; Carlson, Mark A.; Weiss, Walter; Davies, Elwyn B.; Blake, Steven L. (1998 年 12 月)、差別化サービスのためのアーキテクチャ、doi :10.17487/RFC2475、RFC 2475
- Awduche, Daniel O.; Berger, Lou; Gan, Der-Hwa; Li, Tony; Srinivasan, Vijay; Swallow, George (2001 年 12 月)、RSVP-TE: LSP トンネル用 RSVP の拡張、doi : 10.17487/RFC3209、RFC 3209
外部リンク
- Nate Hoy、「QoS の実装」。Vonageフォーラム。2011年10 月 14 日閲覧。
- Cisco のインターネットワーキング テクノロジー ハンドブックは、2015 年 9 月 6 日にWayback Machineにアーカイブされました。
- Henning Schulzrinne (2008 年 1 月 9 日)。「ネットワーク サービス品質」。コロンビア大学教員ウェブサイト。2011年10 月 14 日閲覧。
- 「サービス品質 (QoS) の概要」。Microsoft TechNet。2011年 3 月 31 日。2011 年10 月 14 日に取得。
- 「高優先度アプリケーションにおけるサービス品質 (QoS)」(PDF)。Transition Networks。2003 年 2 月。2017 年2 月 16 日に閲覧。
- 「ネットワークトラフィックの優先順位付けのためのサービス品質の実装」。EtherWAN 。 2022年12月15日閲覧。