Comments
Description
Transcript
バックボーンネットワークにおける帯域制御効果の検証
特別研究報告 題目 バックボーンネットワークにおける 帯域制御効果の検証 Verification of band control effect in backbone networks 報告者 1135048 川崎 隆裕 指導教員 植田 和憲 講師 平成 23 年 2 月 7 日 高知工科大学 電子・光システム工学コース 目次 第 1 章 はじめに 1 第 2 章 帯域制御に関する方針 3 2.1 帯域制御の運用 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 インターネットサービスプロバイダ . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 利用者の公平性 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 第 3 章 トラヒック制御技術 7 3.1 DiffServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 IntServ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1 RSVP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 3.2.2 RSVP の流れ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 第 4 章 帯域制御におけるユーザ効用の変化 19 シミュレーション環境 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.1 バックボーンネットワーク . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1.2 トラヒックの分類 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1.3 帯域制御機構 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2 シミュレーション概要 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.3 ネットワークモデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.4 帯域制御モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.5 ユーザ効用モデル . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.6 シミュレーションによるユーザ効用の評価 . . . . . . . . . . . . . . . . . . . 23 4.7 考察 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.1 i 第 5 章 まとめ 28 謝辞 30 参考文献 31 ii 第 1 章 はじめに 近年、ネットワーク技術の発展により、誰でも簡単にインターネットを利用することがで きるようになった。また、リアルタイムの動画や音楽の視聴、P2P ファイル交換ソフトなど の高速なネットワークを前提とするようなアプリケーションも盛んに利用されている。中で も、P2P ファイル交換ソフトはバックボーン帯域の約 50 ％を消費しているという調査結果 もあり、一部のヘビーユーザ（頻繁にあるいは長時間アプリケーションを利用するユーザ） によるネットワーク帯域の占有の原因の一つになっていると考えられている [1]。また、近 年では「YouTube」や「ニコニコ動画」を代表とする動画視聴サイトの普及により動画デー タもネットワーク帯域の圧迫の原因になってきている。今日では動画視聴サイトの利用者が 増加し、P2P ファイル共有ソフトよりもネットワーク帯域を圧迫しており、ネットワーク帯 域の枯渇問題を更に加速させている [2]。リアルタイムの動画視聴や P2P ファイル交換ソフ トなどの大容量の通信を行うアプリケーションはネットワーク帯域を多く使うため、ネット ワーク回線上でふくそうが発生してしまう問題が起きている。 ふくそうはパケット転送速度の低下やパケット消失を引き起こす原因となる。その影響に よりダウンロードに要する時間が長くなる、音声の途切れ・映像上のブロックノイズが発生 するなどの場合がある。結果としてふくそうの発生はアプリケーションの品質を損なう。 ふくそうの発生によるアプリケーションの品質悪化に対する解決策として、ネットワーク 帯域の拡張が挙げられる。これは、通信に十分な帯域を確保することで、ふくそうの発生を 抑えることができるという考え方である。しかし、今後の利用者の増加や通信データの大容 量化に対する予想は難しく、拡張すべき帯域を算定するのは容易でない。帯域の拡張量に対 する判断を誤ると、短期間での更なる帯域の拡張を余儀なくされたり必要以上に高速なネッ トワークを整備してしまうことになり、無駄にコストが掛かってしまう。帯域の拡張に掛る コストは、ネットワークを利用するために求められる料金の高額化につながり、エンドユー ザの利益が損なわれる [2]。 1 そこで、帯域の拡張でない解決策としてネットワーク管理技術による帯域制御が考えられ る。ネットワーク帯域が不足するのは、ベストエフォートを前提とするネットワークにおい て前述したようなネットワークアプリケーションの利用が盛んになり、それら以外のネット ワークアプリケーションの通信に影響を与えているからである。そこで、特定の通信に対し てある程度のネットワーク帯域を割り当て、それらの通信のネットワーク品質をある程度保 てるようにすることを考える。この技術をリアルタイム性のある動画やストリーミング再生 の動画に適用すると、音声が途切れる現象やブロックノイズなどにより映像が乱れる現象を 抑えることが可能になり、快適にアプリケーションを利用することができる。 しかし、近年ネットワークサービスの充実によりネットワーク帯域の圧迫の原因が多様化 してきたため、通信事業者 (ISP) は帯域制御の方針決定が困難な状態である [3]。そこで、本 研究では帯域制御を行うことでバックボーンネットワークにおいてネットワーク資源を有効 活用できるか検証し、ネットワーク運用者の帯域制御の方針決定に参考になるデータの提供 を目指す。 2 第 2 章 帯域制御に関する方針 技術の進歩により高速大容量化技術や光回線・ブロードバンドが普及し、インターネット 利用者のインターネットの利用料金が安価になってきている。インターネットの利用料金が 安価になるにつれて利用者が年々増加し、ネットワーク上を流れるトラヒックは急速に増加 の一途をたどっている [2]。 通信事業者はこの問題をネットワーク機器の性能向上や高速大容量技術を用いて解決して きたが、今日ではこれらの方法では追いつかない状態になってきている。主な原因は P2P 技 術を利用したファイル共有ソフトによるネットワーク帯域の圧迫である。P2P ファイル共有 ソフトを利用することでネットワーク上のトラヒック量が急激に増加し、一部の P2P ファ イル共有ソフト利用者によってバックボーンネットワークの約 50 ％が占有されている状態 になり、一般ユーザが利用するアプリケーションの品質劣化が起こる [1]。一般ユーザが利用 するアプリケーションの品質を保証するために一部の通信事業者は P2P ファイル共有ソフ トの通信速度の低下や通信の遮断を行うことで解決した。通信事業者はパケットのヘッダ部 の情報を解析することで P2P ファイル共有ソフトを判別し、通信速度の低下や通信の遮断 を行った。しかし、パケットを解析することは「通信の秘密」を侵害する行為とされ総務省 から指摘を受けた。また通信速度の低下や通信の遮断は「利用の公平性」に欠けると指摘を 受け、現在では通信の遮断は禁止され、通信事業者は特定の条件下でのみ通信速度の規制を 許されている。このことから通信事業者は「通信の秘密」「利用の公平性」を守りつつ帯域 制御を行うことが課題になっている。 このような背景から総務省と通信事業者が協力して、ネットワーク運用者がどのように ネットワークを管理すればよいかを決めるための帯域制御に関するガイドラインを作成した [3]。 3 2.1 帯域制御の運用 序論でも述べた通り、近年急速にネットワーク技術が発展し、利用者も増え、ネットワー クサービスも充実してきている。P2P ファイル共有ソフト利用者の内の一部のヘビーユーザ によってバックボーンネットワークの約 50 ％もが占有されていると報告された [2]。 ガイドラインの取り決めでは基本的に通信事業者はネットワークの中立性を踏まえネット ワークの運用をしなければならないとされた。ネットワークの中立性とは「インターネット はどんなユーザやアプリケーションからでも平等に扱う利用の公平性という考え方に基づい ており、それを反することは許されない」という考え方である。 基本的に通信事業者等は急激に増加するトラヒックに対してバックボーンネットワーク等 のネットワーク設備の増強によって対処するべきであり、帯域制御はあくまでも例外的な状 況において実施すべきものであるとされている。そのため、帯域制御を行う上で必要最小限 のルールとして、関係事業者間において、帯域制御は一定の合理性がある場合のみ認められ る限定的な手法とされている。次の 2 つの場合のみ通信事業者は帯域制御を行うことが許さ れている。 • P2P ファイル交換ソフト等の特定のアプリケーションに対して、通信帯域の制御を行 う場合 • ユーザごとのデータ転送量の基準を設定し、それを超えたユーザについては通信帯域 の制限や契約の解除を行う場合 特定のアプリケーションに対して通信帯域の制御を行う場合には、バックボーン上を流れ る総トラヒックの大半を特定のトラヒックが占有している場合に適応される。特定のユーザ ごとに制御する場合は、他のユーザの利用に支障が現れる場合やネットワーク全体の通信に 影響がある場合に適応される。帯域制御を行う場合はこの 2 つの条件を満たした場合のみ実 行可能になる。 今後の検討課題として、利用者が急激に増加したことでネットワーク帯域の圧迫の主な 原因となりつつある動画提供サービスや動画配信サービスといったリッチコンテンツによる トラヒックの発生にどのように対処すべきか検討する必要がある。他には「アクセス網で帯 4 域制御が実施された場合の影響」、「関係事業者間の情報共有のあり方」、「諸外国の状況」、 「ネットワークのコスト負担の公平性」などの検討もしなけらばならない [3]。 2.2 インターネットサービスプロバイダ これまで通信事業者はネットワーク機器の性能向上を図ることでネットワーク品質の保証 を行ってきた。しかしネットワーク機器の性能向上だけで対処することが困難になり、一部 の通信事業者は現有の資源を活用できる帯域制御を行うことで対処してきた。帯域制御を行 う上で守らなければならないこととして「通信の秘密」と「利用の公平性」がある。 「通信の秘密」とは「個人間の通信の内容及びこれに関連した一切の事項に関して、公権 力がこれを把握する事及び知り得た事を第三者に漏らすことなどを禁止する事」であり「通 信の自由」と表裏一体の関係にある。これは機械が行った作業でも、通信の秘密の侵害にお いては人間が行ったものに違いないと考えられ、通信事業者が行うルーティングやメールの 配送などの行為も当てはまる。通信事業者はルーティングやメールの配送などは「通信の秘 密」を侵害する行為に当てはまるがこれらを禁止されるとネットワーク運用業務が困難にな ることから正当防衛とみなしている [3][4]。 「利用の公平性」とは、原則的にネットワークはだれもが平等に扱えるという考え方に基 づいている。 これまで通信事業者はネットワーク帯域の圧迫の主な原因となっていた P2P ファイル共 有ソフトや 一部のヘビーユーザに対してガイドラインに法り帯域制御を行うことが可能で あったが、今日急激に増加している動画配信サービスは不特定多数の一般ユーザが利用して いるため帯域制御を行うことが難しく問題視されている。 P2P ファイル共有ソフトは常時通信が行われるため一日単位でみたトラヒックの最高値と 最低値に大きな差はなかったが、動画配信サービスは一般のユーザの生活習慣に影響される ことから仕事や学校に通う朝方から正午にかけては利用者が少なく、仕事や学校から帰宅し た後の夕方から夜にかけて利用者が急激に増えるため、一日のトラヒックの最高値と最低値 に大きな差がみられる [5]。 ネットワーク機器は一日のトラヒックの最高値を基準として性能向上を図ってきたため、 常時通信を行っている場合が多い P2P ファイル共有ソフトに対してはネットワーク機器の 5 性能を無駄なく使用できたが、一日のトラヒックの最高値と最低値に大きな差がある動画視 聴サービスに関してはネットワーク機器の向上を図っても性能を最大限に利用することがで きず性能の多くを使用しない場合が多くなってしまうため、ネットワーク機器の増強も難し い状態である。 今後さらに動画視聴サービスの利用者が増加されると予想されるが現在通信事業者はこれ に対しての解決策に目処が立っていない [2]。 2.3 利用者の公平性 通信事業者は全ての利用者に一定水準以上のネットワーク品質を提供する必要がある。一 定水準のネットワーク品質を保つためにネットワークの性能向上と帯域制御があるがネット ワークの性能向上には限界があるため、帯域制御に頼る必要がある。帯域制御を行う上で全 てのユーザに公平でなければならない。 公平と平等とは異なった概念である。数量で表わされるものがあった場合、平等とは全体 の量を均等に配分するものだが、公平では均等に配分する必要はない。配分される側が公平 と感じられたら公平性が保たれていると見なされる [6]。 一般的に公平を決める方法は大きく分けて次の 2 つの方法に分けられるがこの 2 つの方 法は似て非なるものである。 • 完全なランダム性 • 選択の自由 例えば 1 つのケーキを A さん、B さんの 2 人で分ける場合に半分にできない場合がある。 この時にじゃんけん等をして勝った方がケーキを貰うと決めれば、どちらかが優遇されてい るわけではないので公平と考えられる。これは「完全なランダム性」を利用した方法になる。 「選択の自由」を利用した方法を利用する場合は、まず A さんが公平だと思う量にケー キを 2 つに切り分ける。その後、B さんが 2 つのうち好きな方を選択すれば公平な分け方 だと考えられる。 今回は A さん、B さんの 2 人だけの場合を例に出したが同じ方法で更に多くの人数でも 公平にわけることも可能である。 6 第 3 章 トラヒック制御技術 現在のネットワークで提供されるネットワークサービスの基本はベストエフォートサービ スである。 ベストエフォートとは、パケットの送信を最優先とした考えであるため、相手の通信状況 や通信状態を考慮しておらず、パケット送信中にパケットの破棄が発生した場合にも、送信 者はそのことを認知していない。 ネットワークはベストエフォート型のため、ネットワークを流れる各フローは平等で扱わ れるため優先順位はない。そのため、一部のユーザが P2P ファイル共有ソフトなどのアプ リケーションを利用することなどによって膨大なパケットが発生し、ネットワーク帯域が占 有されることで、パケットロスや通信遅延が頻繁に起こり得る状態になる。 上記のような状況下では優先したい通信が優先度の低い通信に妨げられたり、動画データ のようにリアルタイムが求められるデータ通信にブロックノイズや音飛びなどのサービス品 質の劣化が見られるといった問題が起こる そこで、ユーザが円滑に通信を行えるために、QoS (Quality of Service, サービス品質) 技 術が研究開発された。QoS とはサービス品質のことで、通信遅延、パケットロス、誤り率 などを抑えることでアプリケーションの品質を保つ技術のことである。近年、特定のアプリ ケーションによるネットワーク帯域の占有が原因となり、一般ユーザの通信品質を保つこと が困難な状態にある。そこで特定のアプリケーションやユーザに対してネットワーク帯域に 制限を加えることで一般ユーザの通信品質を保つことを行った。この QoS 技術には DiffServ と IntServ といわれる帯域制御技術がある [7]。 本章では、以下 DiffServ、IntServ 技術ならびに IntServ をつかさどる RSVP 技術につい てまとめておく。 7 3.1 DiffServ DiffServ (Differentiated Services) はインターネット・ユーザが送受信するトラヒックの種 類を識別し、その種類に応じて通信品質 (QoS) を提供する技術のことで差別化サービスと も呼ばれる。 QoS を提供する技術は他に、IntServ(Integrated Services) と呼ばれるものがある。この技 術については後に詳しく説明する。 DiffServ は、性能の完全保証を破棄し、複数の優先クラス間で相対的な転送性能に差をつ けることにより、トラヒックの優先制御を行う。インターネット上で IntServ を実現するには 動的資源準備のために考えられたプロトコルである RSVP(Resource reSerVation Protocol) を使用するが、複雑なため規模の拡張性に欠けている。そこで、インターネット上で実運用 できる機能拡張性を備えている DiffServ が提案された。 Diffserv は内部ゲートウェイがパケットヘッダの特定フィールドのみを見れば処理内容を 決定できることを基本とするサービスであるため性能向上が期待できる。IPv4 パケットの Type of Service フィールド、IPv6 パケットの Traffic Class フィールドの上位 6 ビットに DS (DiffServ) codepoint を記入しておき、ゲートウェイのトラヒック制御機構 (PHB:Per-Hop Behavior) の動作をこのコードだけで決定することが可能である。Type of Service は 8 ビッ トあるがそのうちの 2 ビットは将来のために予約してあり現在未使用の状態である。各内 部ゲートウェイには DS codepoint とパケットスケジューラの動作の対応表が配られており、 各ゲートウェイのトラヒック制御機構はその対応表のみを参照して動作する。 DiffServ では、各パケットの処理は DS codepoint で定まり、そのゲートウェイだけで完 結して以降のゲートウェイの動作とは無関係である。 DiffServ ではエンドツーエンドのサービスを既定することはせずに、 QoS を実現するフ レームワークとその構成部品の一部を既定するため、ユーザはそれらを組み合わせて適切な パラメータを設定して希望の QoS サービスを実現しなければならない。 DiffServ のサービスの一部として次の 4 つのサービスがある [図 3.1]。 • 急行転送型 PHB (expedited forwarding service) • 確実転送型 PHB (assured forwarding service) 8 • ベストエフォード型 PHB (best effort service) • クラス選択型 PHB (class selector) 送信ホスト 1 エッジ ルータ DiffServ ネットワーク エッジ ルータ 受信ホスト コア ルータ 送信ホスト 2 エッジ ルータ 図 3.1: DiffServ における PHB 動作 PHB (Per Hop Behavior) は各クラスのパケットをどのように扱うかを記述したもので、 ルータにおけるキュー管理、廃棄機構によって実現される。 急行転送型 PHB は専用線的サービスを実現するためのもので、各境界ルータでは、パケッ トの待ち時間や、ジッタ、パケット廃棄率をできるだけ減らすために、DS 動作集合に必ず 設定レート以上のサービスレートを割り当てる。設定レートは DS 動作集合ごとに管理者が 設定する。設定レートを、入力レートより大きく設定しておけばパケットはゲートウェイで ほとんど待たされることがないため他の PHB に比べてもジッタ、パケットの廃棄率を減ら すことができる。 9 確実転送型 PHB はパケットに 3 種類の優先度のマークをつけておき、ネットワークに輻 輳が発生したなら優先度が低いパケットから順に廃棄して、最優先のパケットはできるだけ そのまま伝送することを狙う PHB である。そのためパケットの優先度を区別する手段とし てそれぞれに異なる DS codepoint を与え、3 個の DS 動作集合を使用する。3 個の DS 動 作集合を優先度の大きい順にレベル 1,2,3 と呼ぶ。3 個の DS 動作集合全体をクラスと呼ぶ。 ベストエフォート型 PHB はそれぞれのゲートウェイのデフォルト動作を行う PHB であ るため、QoS 保証が行われていない。急行転送型 PHB や確実転送型 PHB も DiffServ の使 用するための必須条件ではないが、ベストエフォート型 PHB は DiffServ の使用するために は必須条件となる。 クラス選択型 PHB での DS codepoint は IPv4 では IP ヘッダの Type of Service フィール ドに収容される。このフィールド内の優先されるフィールドは既に多く使われているため従来 の使用法と互換性を保つ目的で、クラス選択 PHB が定義されている。PHB と DS codepoint の対応は DS ドメインごとに定義することが可能で、パケットがある DS ドメインから他の DS ドメインにパケットが流れる際にトラヒック調整機構内のマーカが DS codepoint を付 け替える必要がある [7]。 3.2 IntServ IntServ (Integrated Service) はフローを単位にネットワーク帯域などのネットワーク資源 を確保することで QoS を確保しようとする QoS 保証通信サービスである。 IntServ では RSVP (Resource reSerVation Protocol) を使用して通信帯域などのネット ワーク資源を確保している。 RSVP の特徴の一部として以下のようなものがある。この他の特徴や詳しいことについて は後に述べる [7][8]。 • 一方向のデータフローに対する資源予約をおこなう • 予約の起動は送信者ではなく受信者がおこなう • ルーティングプロトコルから分離しているため、ルーティングプロトコルが確立した パスの上に、独立して資源を予約していくシステム 10 IntServ には、ベストエフォート型以外に帯域と最大遅延を保障する「Guaranteed Service」(GS:保障型) と、パケットの流量を自ら制御する抵抗型アプリケーションを想定した 「Controlled Load Services」(CS:負荷制御型) の 2 つがある。 保障型 (GS) IntServ は経路上で各ルータが該当フローに提供すべきサービスレートと遅 延余裕で定まる。遅延余裕は通常アプリケーションが許容できる遅延値から経路の最大遅延 値との差で表現される。パケット損失を許容しないリアルタイム型のアプリケーションであ るため回線シミュレーションなどに使用される。 負荷制御型 (CS) IntServ はネットワークの負荷にかかわらず、このサービスを受けるフ ローのパケットは低負荷時のネットワークのベストエフォートサービスと同等の品質サービ スを受けるためパケット損失を許容する再生型アプリケーションや非リアルタイムアプリ ケーションに適している。このためビデオストリームなどの伝送には好適といえる。 これらの機能を実現するために必要な IntServ を提供するゲートウェイの主要 QoS アー キテクチャの構成要素は次の 5 つである。 • パケットスケジューラ (packet scheduler) • パケット分類機構 (packet classifier) • トラヒック調整機構 • 受付制御機構 (admission control) • RSVP の処理機構 – 予約の集約と実行 – Path, Resv 状態の設定 – ゲートウェイ QoS 情報の輸出 – メッセージ中継 図 3.2 に上記を備えたコアゲートウェイアーキテクチャを示す。新規予約フローが現れた 場合、ゲートウェイの資源が新規フローを受け入れる余裕があるか判断する。 11 データ面 入力ドライバ フォワーディング機構 フォワー ディング 機構 トラヒック 調整機構 出力ドライバ 保証型キュー パケット 分類機構 パケット スケジューラー 負荷制御型キュー ベストエフォートキュー フロー制御表 スケジュール表 構成制御機構 ＲＳＶＰ 処理機構 オペレータ コントロール面 図 3.2: IntServ ゲートウェイアーキテクチャ 12 3.2.1 RSVP RSVP (Resource reSserVation Protocol) は動的資源の準備のために考えられたプロトコ ルである。 フローごとの QoS サービスを提供するためには、フローの継続中や経路上のネットワー ク資源を確実に保持する必要がある。ネットワーク資源を確実に確保するためには次の 2 つ の条件を満たさなけらばならない。 • あらかじめ十分なネットワーク資源を準備する • コネクション設定のたびに必要な資源を予約しコネクション継続中その資源を確保する この 2 つはそれぞれ静的な資源準備と RSVP と呼ばれ、RSVP の方が資源の利用効率が 高いと言われている [7]。送信アプリケーションが QoS を確保する必要があると判断した場 合に、RSVP コマンドを起動し、通信経路上のネットワーク資源を確保する。 RSVP の特徴は次の通りである。 • 動的な資源準備 • 汎用性 • マルチキャスト通信 • 障害対策 動的な資源の準備は予約型の信号方式で、送信ホスト上にあるアプリケーションによって 起動される。また必要になった時点で動的な資源を確保することができる。 汎用性は、スケジューリングアルゴリズムやルーティングアルゴリズムなどの特定のアル ゴリズムに依存することなく、全てのアルゴリズムに対応できるようにすることでできるだ け多くの QoS サービスに使用できるように設計をしている。RSVP 自体はサービスの実行 機能は持たず、必要な情報を伝搬するだけに限定され、情報の内容の解釈はゲートウェイに 任せている。 RSVP ではマルチキャスト通信のサポートも可能である。マルチキャスト通信の場合は送 信者が受信者の情報を知ることが少ないため、送信者から受信者に対してトラヒックの QoS 13 サービスを決めることが難しい。このためトラヒックの QoS サービスに関しては受信者側 が行う必要がある。また動的なマルチキャストメンバの変更も可能である。フローの送信者 の定義とフローの定義を分類することにより、通信中の送受信者の変更が簡単になる。 障害対策については、ゲートウェイの状態を定期的にリセット、リフレッシュする方式を とっている。ゲートウェイの状態をリセット、リフレッシュすることで障害が発生した場合 にも自動的に状態を回復し、重要障害には発展しないようにしている。また、軽度の障害が 生じた場合にも QoS サービスの継続は可能である。 RSVP の主な動作として次の 3 つがある。 • QoS 予測情報の収集 • 予約情報の配布 • 関連動作 3.2.2 RSVP の流れ 図 3.3 は RSVP の予約情報の収集から配布の流れを簡単に書いたものである。QoS 予測 情報の収集は、送信アプリケーションが送信ホストに RSVP コマンドを送信し予約を依頼 し、送信ホストは Path メッセージを受信ホストに送信する。 Path メッセージの内容には次の 6 つが書かれている。 • 経路の遅延誤差 • 経路の最大パケット長 • 経路のデータレート • 経路上の IntServ ゲートウェイの個数 • 経路のサポートできる QoS サービス • その他 14 Path メッセージの送信はまず、送信アプリケーションがフロー情報や QoS 種別を送信ホ ストに知らせる。この時フロー情報には宛先情報、送信元情報、送信フローのトラヒック特 性などが含まれる。フロー情報を基に送信ホストは作成した Path メッセージをルーティン グ動作によって決定された経路の下流次ホップのゲートウェイに伝搬し、設定した時間が経 過すれば Path メッセージは自動的に消滅する。送信ホストは定期的に Path メッセージを 再送することでゲートウェイ内の Path メッセージをリフレッシュさせる。Path メッセージ を受け取ったゲートウェイはその情報からゲートウェイ内に各種情報を設定する。受信ホス トは、送信アプリケーションからの Path メッセージと経路上のゲートウェイから送られて きた情報を受信アプリケーションに伝える。予約情報の配布では Path メッセージの内容か ら受信アプリケーションは要求する QoS サービスを決定し、受信ホストに予約実行を依頼 する。その後受信ホストは Resv メッセージを Path メッセージと逆方向に経路を通り、経 路上の各ゲートウェイに必要な情報を送信する。Resv メッセージの送信はまず、受信アプリ ケーションが Path メッセージを参照して QoS サービス種別とサービスパラメータを決定 し予約要求を作成し、受信ホストに送信する。ゲートウェイから送信されてきた Path メッ セージのパラメータから保証型サービス、負荷制御型サービスの各サービスが経路上の全て のゲートウェイでサポートされているかどうか判断し、使用するサービスを決定する。サー ビスの決定後に予約要求から Resv メッセージを作成し、上流次ホップに送信する。この時 作成された予約内容はスタイルオブジェクトに格納され、設定した時間が経過すれば Resv メッセージは自動的に消滅する。受信ホストは、定期的に Resv メッセージを再送すること でゲートウェイ内の Resv メッセージの状態をリフレッシュさせる。送信ホストでは経路上 のゲートウェイと同じように、資源の予約や Resv の状態設定を行い、送信アプリケーショ ンに Resv メッセージの内容を報告する。各ゲートウェイは予約受付ができない場合にはエ ラーメッセージを返し、受付可能な場合には必要なサービスレートやバッファを確保する。関 連動作では Resv メッセージに基づきゲートウェイは必要な動作を行う。予約動作は RSVP の範囲外の仕事であるためゲートウェイで行う。 RSVP は rawIP データグラムで、IP ヘッダの直後に RSVP メッセージを付加した形式 を所持している。また、RSVP メッセージは共通ヘッダの後に、パラメータとして各種の可 変長オブジェクトが続く形式を所持している [図 3.4]。RSVP メッセージの先頭に置かれる 15 共通ヘッダには以下の内容が含まれる。 • メッセージ種別 – Path – Resv – PathErr – ResvErr – PathTear – ResvTear – ResvConf • メッセージ長 • メッセージの残存期間 (TTL) • チェック • その他 RSVP はオブジェクトを区別するためにクラス番号と c-タイプを使用している。クラス番 号は 14 個のオブジェクトクラスを区別するのに使用し、c-タイプは IPv4 と IPv6 の区別に 使用する。クラス番号では Path メッセージを下流次ホップに送信し、c-タイプでは Resv メッセージを上流次ホップに送信する [7]。 16 上流 Path メッセージ 送信アプリケーション Resv メッセージ Resv の設定情報 フロー情報 QoS 種別 送信ホスト Path メッセージ 資源予約 Resv の設定 ホップ Path メッセージ から各種情報を 設定 ホップ Resvメッセージ ゲートウェイの情報 受信ホスト Resvメッセージ 要求する QoS 予約実行 Path メッセージ ゲートウェイ情報 受信アプリケーション 下流 図 3.3: RSVP の動作 17 0 1 送信残存 時間 版 フラッグ 2 3 4 byte メッセージ 種別 RSVP チェックサム (予備) RSVP 長さ 共通ヘッダ オブジェクト値 長さ (byte) クラス番号 オブジェクト 図 3.4: RSVP メッセージ形式 18 C-タイプ 第 4 章 帯域制御におけるユーザ効用の 変化 これまで述べたように、近年ネットワーク機器の発展と普及に伴い、光通信やブロードバ ンドなどの高速大容量転送技術などを利用した多種多様なネットワークサービスやソフト ウェアが登場し、ネットワーク資源の枯渇問題が進んでいる。この問題に対し、通信事業者 はネットワーク機器の性能向上だけではコスト面・技術面の問題から対処することが難しく なった。そこで現有の資源を有効活用できる帯域制御に注目が集まった。 本研究では、帯域制御技術を使用し、特定の通信に対して帯域制御をかけることで現有資 源であるバックボーンネットワークを有効活用できるか検証する。 4.1 シミュレーション環境 本研究では、実際のネットワークでの帯域制御効果を知るために現実に則したネットワー クモデルでシミュレーションを行う必要がある。現実に即したネットワークモデルの実現の ためのバックボーンネットワーク、トラヒックの種別、帯域制御機構について述べる。 4.1.1 バックボーンネットワーク バックボーンネットワーク上には多数のルータが配置し、ルータ同士が連結することで広 域ネットワークを構築。連結するルータの端にあるものをエッジルータと呼び、通信事業者 側にあるルータをコアルータと呼ぶ。エッジルータはユーザのネットワークを WAN 回線に 繋ぎ、バックボーンネットワークにアクセスする役割を持っている。コアルータは通信事業 者のネットワークを相互接続させるために使用される。また、他のプロバイダのネットワー クと繋ぐためにも使用される。 19 本研究ではユーザの回線を収容するエッジルータで帯域制御のポリシーを導入し、コア ルータで帯域制御を行う。 4.1.2 トラヒックの分類 バックボーンネットワーク上には不特定多数のユーザが様々なソフトウェアやアプリケー ションを利用することで、多種多様なトラヒックが流れている。それぞれ異なるトラヒック のため保障すべきネットワーク品質が異なるため、特定のトラヒックに対してネットワーク 品質を確保しても他のトラヒックの通信品質の向上にはつながらない。このため異なるトラ ヒックの通信品質の確保を効果的に行うためにはトラヒックを特徴ごとに分類し帯域制御を 行う必要がある。 現在ネットワーク上には様々なトラヒックが流れているが大きく分けると、ネットワーク 帯域の枯渇問題の主な原因になっている P2P ファイル共有トラヒック、近年急激に増加し ている YouTube やニコニコ動画等の動画トラヒック、主に HTTP データなどの Web トラ ヒックの 3 つに分類される。3 つに分類されているが現在のネットワークの総トラヒックは P2P ファイル共有トラヒックと動画トラヒックが大部分を占めていて、Web トラヒックは 少ない状態である。Web トラヒックもオンデマンドな通信が大多数を占めるため、オンデマ ンドなトラヒックやソフトウェアが自動で通信を行うトラヒックのネットワーク品質を効果 的に上げることができれば有効とされている。 4.1.3 帯域制御機構 現有のネットワーク資源を有効利用するためには可能な限り、インターネット利用者が快 適に利用できる環境を提供する必要がある。そのためにはインターネット利用者が使用する インターネットサービスやアプリケーションの品質を一定に保ちながら、それぞれのサービ スやアプリケーションに合った帯域制御を行うことが重要になる。バックボーンネットワー ク上を流れるトラヒックの傾向は時間帯、曜日、トラヒック種別などの状況により常に変化 する。状況に合わせた帯域制御を行うことがネットワーク資源の有効活用につながるといえ る。例えば動画トラヒックの場合は朝方から正午にかけては利用者が少なく夕方から夜方に 20 かけて利用者が増加する傾向にある。このことから動画トラヒックの帯域制御に関しては朝 方から正午にかけては与える帯域を少なくし、利用者が増える夕方から夜間にかけて与える 帯域を増やすことによりインターネット利用者が快適に利用できる環境を提供できると考え られる。これらのことを考慮して帯域制御を行わなければならない。 4.2 シミュレーション概要 今回のシミュレーションではネットワークシミュレータである「NS2」を使用した [9][10]。 使用した「NS2」のバージョンは 2.33 を採用した。OS は「NS2」を利用するために Linax OS を採用した。今回使用した Linax OS は単体では利用することができないため、必要な ツール類や設定をひとまとまりにしてインストールすることが可能な デストリビューション である ubuntu9.04 を使用した。 現在、近い将来のネットワークを有効利用するための帯域制御の使用法については定まっ ていないため、本研究では近い将来を想定したネットワークモデルを考慮したシミュレーショ ンを行う。シミュレーションでは現実のネットワークに則したネットワークモデルを基準に 構築する。具体的には、近い将来のネットワークモデルを構築するために CISCO 社が 2013 年までバックボーントラヒックがどのように変化するか予測したデータを用いる [11]。ネッ トワークトポロジー (network topology) はユーザがローカルネットワーク間のコアルータと エッジルータを介して P2P ファイル共有トラヒック、動画トラヒック、Web トラヒックの 3 つのデータを通信している状況を想定する。 ネットワークモデルごとに全体のユーザの満足度を算出し、どのような帯域制御が有効 か検証する。ユーザ満足度の算出にはユーザ効用モデルを考え、トラヒックの種類ごとにス ループットを用いてユーザ効用に変換する。シミュレーション結果を出力し、グラフ化する ために gnuplot4.5 を使用する。 4.3 ネットワークモデル 今回本研究で使用するネットワークモデルは CISCO 社が 2013 年のバックボーントラヒッ クを予想したものを想定して、ネットワーク帯域に余裕がないバックボーンネットワークを 21 構築する [11]。CISCO 社の予想データ [11] では動画トラヒック 60 ％, P2P トラヒック 25 ％, Web トラヒック 15 ％と予想されていたため、本研究でもこの値を参考にした。この条 件を満たすために今回使用するトラヒックは以下の 3 つになる。 • 動画配信サービストラヒック • P2P ファイル共有ソフトのトラヒック • Web のトラヒック Web トラヒックには動画配信サービストラヒックと P2P ファイル共有ソフトのトラヒッ ク以外のものが含まれる。 上記のデータがエッジルータ、コアルータを介して、別のローカルネットワークと通信を 行う状況を構築し、送受信のホスト数やトラヒック種別ごとの比率を変化させることでネッ トワークモデルを変動させる。具体的には Web トラヒックの本数を 3 本、P2P トラヒック の本数を 5 本、動画トラヒックの本数を 2 本から 20 本まで変化させることでネットワーク モデルを変動させた。動画トラヒックの本数が 12 本を超えた時点で予想の 60 ％を超える が今後動画トラヒックは増加し続けると予想されるため今回の検証では 20 本まで増加させ た。今日では動画配信サービスなどのストリーミングを利用したサービスの利用者が急激に 増加しているため、動画配信サービストラヒックの送受信数を変動させ、トラヒックごとに 帯域制御を行うとどのような変化があるか検証する。 4.4 帯域制御モデル 今回の実験では P2P ファイル共有ソフトのトラヒックのネットワークに帯域に制限を加 えた。動画配信サービストラヒックにネットワーク帯域を与えすぎてもあまり効果が見られ ない。反対に P2P ファイル共有ソフトのトラヒックや Web トラヒックはトラヒックの転送 レートが高ければ高いほど通信速度が向上するためネットワーク帯域を与えるほどコンテン ツの取得が早くなる。そのためコンテンツ取得時間が短くなりユーザ効用が高くなる [12]。 このことから、今回は Web トラヒックにネットワーク帯域を多めに割り当てるような帯域 制御を行った。 22 また、帯域制御を行う上で「通信の秘密」を侵害しないように気をつけて帯域制御を行わ なければならない。 4.5 ユーザ効用モデル 実験の評価基準であるユーザ効用モデルはネットワーク資源の公平性を考慮する必要があ る。本研究では評価基準のパラメータはユーザ満足度をトラヒック種別の特徴ごとに決定す る。動画配信サービストラヒックにネットワーク帯域を割り当てすぎても効果が薄いことが 分かっている [13]。反対に P2P ファイル共有ソフトのトラヒックや Web トラヒックに帯域 を多めに割り当てると通信速度が向上し、コンテンツの取得が早くなる。このことからファ イル共有ソフトのトラヒックや Web トラヒックにネットワーク帯域を多めに割り当てた方 がユーザの満足度が高くなることがわかる [12]。 4.6 シミュレーションによるユーザ効用の評価 先ほど述べたユーザ効用モデルに則り、P2P ファイル共有トラヒック、動画トラヒック、 Web トラヒックをそれぞれのトラヒックごとにスループットを用いて算出する。動画データ は人間の視覚を考慮しなければならないため、急激にユーザ効用が伸び、一定の値に達する と以降はあまり変化が現れないものとする。このことから動画トラヒックのユーザ効用の算 出としてスループットを基に対数関数を用いた。P2P ファイル共有トラヒックと Web トラ ヒックに関しては平均スループットを用いてユーザ効用の算出をした [12]。今回のシミュレー ションではネットワークモデルと帯域制御モデルを変化させることでトラヒック種別ごとの ユーザ効用を算出し、算出された値を加えることで全体のユーザ効用とした。ネットワーク モデルと帯域制御モデルを変動させるごとにユーザ効用を算出し、帯域制御モデルごとにど のような変化があるかどうか検証した。 23 バックボーンネットワーク 多数のルータが配置され、 ルータ同士が結合することで広域ネットワークを構築 受信ホスト 1 送信ホスト1 コアルータで帯域制御を実行 Web 15% P2P 25% VoD 10 ~60% エッジルータ コアルータ エッジルータ 送信ホストN ユーザ回線を収容する エッジルータで 帯域制御ポリシーを導入 図 4.1: 使用したパラメータの値 24 受信ホスト N 4.7 考察 図 4.2 と図 4.3 を用いて今回行ったシミュレーションの考察を行う。ここでは横軸に動画 トラヒックの本数をとってユーザ効用の値を比較する。図 4.2 では 帯域制御を行っていない 場合 (Best Effort) と Web トラヒックの帯域割り当て率を 30 ％から 10 ％ずつ増加させて いき動画トラヒックと P2P ファイル共有トラヒックに割り当てた帯域がそれぞれ 10 ％に なるまでデータを取得し全体のユーザ効用度を比較した。全てのトラヒックに 30 ％ずつ帯 域を与えた場合に余る 10 ％分の帯域はどのトラヒックも自由に使ってよいものとする。帯 域制御を行っていない場合は全体のユーザ効用が低く、帯域制御を行った場合は帯域制御を 行っていない場合と比べ全体のユーザ効用が高くなることがわかる。また帯域制御を行った 場合を比較しても Web トラヒックに帯域を多めに割り当てた方が全体のユーザ効用が高く なることがわかる。 図 4.3 では図 4.2 と同様に帯域制御を行っていない場合 (Best Effort) と 動画トラヒック の帯域割り当て率を 30 ％から 10 ％ずつ増加させていき Web トラヒックと P2P ファイル 共有トラヒックに割り当てた帯域がそれぞれ 10 ％になるまでデータを取得し全体のユーザ 効用度を比較した。動画トラヒックの帯域割り当て率が増加していくに連れて全体のユーザ 効用が低くなることがわかる。 このことから今回の検証で採用した帯域制御モデルでは Web トラヒックに帯域を割り当 てた方が全体のユーザ効用が高まることがわかった。また動画視聴トラヒックが増加してく る過度期では帯域制御による効果に差があることがわかったが、想定する最大値に近づくに つれて帯域制御の効果に差があまり出なくなることがわかった。 これらのデータは本研究のシミュレーション条件上での結果であるため、現段階では通信 事業者に提供できる指針になるとは言えない。しかし、これも 1 つの帯域制御によるユーザ 効用の変化であるため Web トラヒック、P2P ファイル共有トラヒック、動画トラヒックの 3 つのトラヒックに対して帯域制御が全体のユーザ効用に同様な効果を与える傾向にあるこ とがわかる。 25 1 Web 30% P2P 30% VoD 30% Web 40% P2P 30% VoD 30% Web 50% P2P 20% VoD 30% Web 60% P2P 10% VoD 30% Web 70% P2P 10% VoD 20% Web 80% P2P 10% VoD 10% 0.95 Average of Utility 0.9 Best Effort 0.85 0.8 0.75 0.7 0.65 2 4 6 8 10 12 14 Number of VoD Flow 16 18 20 図 4.2: Web トラヒックに帯域を多めに割り当てた場合のユーザ効用の変化 26 1 Best Effort VoD 30% P2P 30% Web 30% VoD 40% P2P 30% Web 30% VoD 50% P2P 20% Web 30% 0.95 Average of Utility 0.9 VoD 60% P2P 10% Web 30% VoD 70% P2P 10% Web 20% VoD 80% P2P 10% Web 10% 0.85 0.8 0.75 0.7 0.65 2 4 6 8 10 12 14 Number of VoD Flow 16 18 20 図 4.3: VoD トラヒックに帯域を多めに割り当てた場合のユーザ効用の変化 27 第 5 章 まとめ ネットワーク技術の発展に伴い、ネットワークの利用やサービスも変化してきている。中 でも P2P ファイル共有ソフトの利用や YouTube などを代表とする動画共有サイトの利用が 広まるにつれ、帯域の枯渇が問題視されるようになった。これらのアプリケーションは今後 も増加すると予想され、ネットワークの増強あるいは有効活用が論議されるようになった。 しかし、ネットワークの増強にはコスト面や技術面の問題から困難になり、現有のネットワー ク資源を有効活用できる帯域制御技術に注目があつまった。これまでの帯域制御ではバック ボーンネットワークの約 50 ％を占有する P2P ファイル共有ソフトに対して帯域制御を行っ てきたが今日では急激に増加し続ける動画共有トラヒックに対しても考えなければならない 状態にある。しかし、通信事業者は動画共有トラヒックに対してどのような帯域制御をする のか判断が難しい状態にある。以上の解決策を得るため本研究では Web トラヒック、P2P ファイル共有トラヒック、動画共有トラヒックが混雑した環境において、様々な帯域制御モ デルを採用した場合の帯域制御効果について考察を行った。実際のトラヒック比率に基づい たシミュレーションを行いスループットから求められるユーザ効用に対して帯域制御の効果 を検証した。 検証の結果、今回採用した帯域制御モデルにおいては動画トラヒックに多く帯域を割り当 てるよりも Web トラヒックに帯域を多めに割り当てた方が全体のユーザ効用値が高くなる ことがわかった。また、動画トラヒックが増加してくる過度期では帯域制御による効果に差 があるが、想定する最大値に近づくにつれて効果に差があまり出なくなることもわかった。 この結果から Web トラヒック、P2P ファイル共有トラヒック、動画トラヒックの 3 つのトラ ヒックに対して帯域制御が全体のユーザ効用に同様な効果を与える傾向にあることがわかる。 今後の課題として、より現実のネットワークに適応しやすい帯域制御モデルでの検証を行 う必要がある。今回の検証ではユーザ効用モデルを変動させず固定して検証を行ったが、今 日急激に増加している動画共有サイトのトラヒックは動画再生までの待機時間が存在するた 28 め、待機時間を考慮したユーザ効用モデルでの検証を行う必要がある。 29 謝辞 本研究を行うにあたり、多大な御指導賜りました高知工科大学 電子・光システム工学科植 田和憲講師に心より感謝致します。また、岩下克教授、山本真行准教授には研究について貴 重な意見を頂いたこと、お礼を申し上げます。研究全般においてご助力をいただきました植 田研究室の江波友則氏、大久保拓哉氏に深くお礼申し上げます。研究について貴重御意見頂 いた、赤瀬隼一氏、福見和彦氏、丸岡優大氏、山本敬典氏に感謝致します。実験を手伝って 下さった、大西直弥氏、西峯誠志氏、檜垣智也氏、政岡佑太郎氏に感謝致します。最後に 6 年間お世話になった電子・光システム工学科の教職員の方々に感謝致します。 30 参考文献 [1] “帯 域 の 戦 い は ま だ ま だ 続 く， ” available at http://www.atmarkit.co.jp/news/ analysis/200706/11/network.html. [2] “イ ン タ ー ネット 政 策 懇 談 会 報 告 書 ， ” available at http://www.soumu.go.jp/ maincontent/000009979.pdf. [3] “帯域制御の運用基準に関するガイドライン， ” available at http://www.jaipa.or.jp/ other/bandwidth/guidelines.pdf. [4] “情報通信政策 watch， ” available at http://ict.cocolog-nifty.com/ict/2007/06/ post_e999.html. [5] H. K.Cho, K.Fukuda, and A.Kato, “The MPEG-4 observing slow crustal movement in residential user traffic IP,” Madrid, Spain,, 2008. [6] “小島寛之の「環境と経済と幸福の関係」公平とは何か∼「選択の自由」と「公平性」， ” available at http://wiredvision.jp/blog/kojima/200803/200803061103.html. [7] 戸田巌，ネットワーク QoS 技術，株式会社オーム社（編），株式会社オーム社，東京， 2001. [8] “Intserv と rsvp， ” available at http://www.kanadas.com/investigation-j/2007/04/ rsvp_intserv.html. [9] 銭飛，実験で学ぶ QoS ネットワーク技術 NS2 によるネットワークシミュレーション，森 北肇（編），森北出版株式会社，東京，2006. [10] “The network simulator - ns-2,” available at http://www.isi.edu/nsnam/ns/. 31 [11] “ハイパーコネクティビティとゼタバイト時代の到来， ” available at http://www.cisco. com/web/JP/solution/isp/ipngn/literature/VNIHyperconnectivityWP.html. [12] 矢守恭子，野村一智，宮田健，田中良明，“配信待ち時間と効用の関係におけるコンテン ツ属性の主要因分析， ” 電子情報通信学会論文誌，vol.102，no.452，pp.pp.49–52，Nov. 2002. [13] 福田健太郎，若宮直紀，村田正幸，宮原秀夫，“帯域予約型ネットワークに適した mpeg2 動画像における品質と帯域の関係， ” 電子情報通信学会論文誌，vol.J82-B，no.3， pp.pp.358–367，1999. 32