Comments
Description
Transcript
統合的なQoS 保証ネットワークアーキテクチャの設計
統合的な QoS 保証ネットワークアーキテクチャの設計 Design of integrated QoS guarantee network architecture 彌冨 輝彦 † 寺岡 文男 ‡ † 慶應義塾大学大学院 理工学研究科 ‡ 慶應義塾大学 理工学部 E-mail: † [email protected] ‡ [email protected] Abstract: 近年，IPv6 の導入を開始した携帯電話事業者が出てきた．そのため，音声通話のような QoS (Quality of Service) 保証通信も IPv6 上で実現する必要がでてくると考えられる．また，スマートフォンのような高機能な携帯 機器も普及し，音声通話だけでなく QoS 保証を必要とするさまざまなアプリケーションが携帯機器上で実行され るようになると思われる．そこで本論文では，個々に研究されることが多い QoS 技術や AAA 機能などの全体を統 合し，IPv6 を利用した単一管理ドメインにおいて多数の携帯機器に QoS 保証通信を実現する IQSAME (Integrated QoS Architecture for Mobility Environment) を提案する．IQSAME は QoS 保証経路の設定には OpenFlow を，AAA (Authentication, Authorization and Accounting) に関しては Diameter を，モビリティサポートには PMIPv6 (Proxy Mobile IPv6) を用いる．IQSAME における QoS 保証通信では，(1) 高価だがフローごとの厳密な QoS 保証 (2) 安価 だが複数のフローを束ねたクラスごとの相対的な QoS 保証のような運用を想定している．そのため，(1) を利用す るフローは比較的少なく，(2) を利用するフローは比較的多くなると想定している．また QoS 保証通信を継続しな がらのスムーズなハンドオーバも実現する． keyword: OpenFlow, PMIPv6, Diameter, IntServ, DiffServ 1 はじめに グローバル IPv6インターネット 近年，IPv6 の導入を開始した携帯電話事業者が出 てきた．そのため，音声通話のような QoS (Quality of グローバル インターネットと 複数個所で接続 サーバ (e.g., WWW) Service) 保証通信も IPv6 上で実現する必要がでてくる ターゲットドメイン(IPv6) と考えられる．また，スマートフォンのような高機能 な携帯機器も普及し，音声通話だけでなく QoS 保証を AAA サーバ 認証・権限確認・ 課金を行う access point 必要とするさまざまなアプリケーションが携帯機器上 best-effort 通信 で実行されるようになると思われる． ドメイン内で QoS保証通信 多数の 移動機器に QoS通信を提供 QoS 保証を必要とするアプリケーションは，実行に 当たって十分な動作を保証するための帯域・遅延・パ 図 1: 本研究の想定環境 ケットロス率といった通信品質の保証を要求する．実 際に，実環境で要求に応じた通信品質を確保するため には，通信品質を保証する経路の計算，その経路に沿っ チャIQSAME (Integrated QoS Architecture for Mobility た End-to-End での資源予約，通信品質に応じたパケッ Environment) の詳細設計を提案する． トスケジューリングなどのさまざまな技術が必要とな る．さらに現実のシステムで QoS 保証通信を提供する 1.1 には，ユーザの認証処理や課金処理などのための AAA (Authentication, Authorization, and Accounting) 機能も 必要となる．これらの技術は個々に研究されることが 想定する環境 図 1 に本研究が想定する環境を示す．IPv6 を使用し ている 1 つの管理ドメイン (対象ドメインと呼ぶ) にお 多くその一部は標準化されているが，QoS 技術や AAA いて，正当な権限を有するユーザ (移動機器) にスケー 機能などの全体を統合した実用的なシステムは存在し ラブルな QoS 保証通信の提供を可能にし，ユーザが移 ない．このような背景を踏まえ，本論文は移動機器に 動しても QoS 保証通信を継続させることが本研究の目 QoS 保証通信を提供するための統合的なアーキテク 1 的である．対象ドメインは 1 つまたは複数の経路でグ するため，フロー数に対してスケーラブルな QoS 保証 ローバルな IPv6 インターネットと接続するものとする． が必要となる． 対象ドメインには無線基地局が設置され，多数の移動 QoS 保証の実現手法には大きく分けて Integrated Services (IntServ)[1] と Differentiated Services (DiffServ)[2, 機器が接続する．移動機器は移動しながら IPv6 を利用 して対象ドメイン内外の機器とベストエフォート通信 保証通信の提供は対象ドメイン内 (intra-domain) に限る 3] の 2 種類がある．IntServ とは，個別の通信フローご とに通信帯域などのネットワーク資源を確保すること によって通信品質を保証する資源管理方式である．そ ものとし，複数の管理ドメインにおける (inter-domain) のため，IntServ は通信フローごとの厳密な QoS 保証 QoS 保証通信の実現は今後の課題とする． が可能な反面，ルータが保持する状態数が膨大になり もしくは QoS 保証通信を行う．また本研究では，QoS やすくスケーラビリティに乏しい．一方 DiffServ は同 1.2 じクラスに属するフローを束ねてクラスごとに優先度 想定される使用例とシステムの処理 を与えることにより，CoS (Class of Service) を実現す 図 1 に示した環境において，想定されるユーザの る．このためルータはクラスごとの状態を保持すれば 使用例とその際にシステムで行われる処理について述 良く，スケーラビリティに優れている反面，1 つ 1 つ べる． のフローには厳密な QoS 保証はできない． そこで，本研究では QoS 保証を 2 つのサービスク (1) ユーザが対象ドメイン内で移動機器の電源を入 れる．あるいは移動機器を携帯したユーザが対象ドメ イン内に移動してくる．(2) 対象ドメインはユーザを認 に厳密な QoS 保証を提供するが，料金は高価であると 証し，ネットワーク接続の権限を有するかを確認する する．2 つ目は DiffServ を適用してフローごとには厳 (Authentication and Authorization)．正当な場合は携帯 密な QoS 保証は提供できないがスケーラビリティに富 機器は対象ドメインに接続し，ベストエフォートでの み，前者に比べて料金は安価であるとする．事業社は 通信が可能になる．さらに，システムはユーザのネット このようなサービスクラスを設けて実際には，緊急・ ワークアクセス状況を記録する (Accounting)．(3) ユー どうしても必要なサービスを IntServ に，それ以外の ザが VoIP などの QoS 保証通信を開始しようとする． ほとんどのサービスで DiffServ を用いるようにする． (4) システムはユーザを認証し，QoS 保証通信を行う 権限を有するかを確認する．正当な場合，システムは QoS 保証通信を実システムで提供するにはこのように 相手機器への経路を計算し，QoS 保証のためのシグナ 次に，1.2 節 (2) (4) (5) では AAA (Authentication, リングを実行する．以上の処理が正常に実行された場 する (Accounting)．(5) システムは携帯機器の移動に合 Authorization, and Accounting) 処理を行っている．Authentication (認証) とはユーザの真正性を確認するこ とである．Authorization (権限委譲) とはユーザが要求 わせてパケットの配送経路を変更し，また QoS 保証通 するサービスを受ける権利があるかを確認し，権限を 信の場合は QoS 保証経路を変更する．この時，処理の 委譲することである．Accounting (利用状況記録) とは たびにユーザの認証・権限移譲・利用状況記録を行う ユーザが使用したサービスに関する利用情報などを記 (AAA)．これにより，ユーザの対象ドメイン内の移動 に関して，ベストエフォート通信および QoS 保証通信 は継続される． 録することであり，accounting を基に課金を行うこと ラスに分ける．1 つ目は IntServ を適用してフローごと 課金についてもある程度考慮する必要がある． 合，システムはユーザの QoS 保証通信利用状況を記録 ができる．実運用を考慮すると AAA は必要不可欠で あり，想定する環境下では以下の 2 場面の処理パター ンが考えられる． 1.3 • 移動機器がネットワークに接続したとき，および 必要要件 移動機器がネットワーク内を移動 (ハンドオーバ) 1.2 節で述べた使用例を基に，本研究における必要 要件について議論する． まず，1.2 節 (3) (4) では QoS 保証を行っている．ま したとき • 移動機器が QoS 保証を要求したとき た，本研究が想定する環境では多数の移動機器が接続 前者はネットワークアクセスのための AAA で，ベス 2 トエフォート通信を行う際に必要となる．後者は資源 1.4 予約のための AAA で，QoS 保証通信を行う際に必要 本論文の構成 本論文の構成は以下のとおりである．2 章では関連 となる．なお，ハンドオーバとは移動機器が現在の基 研究として，Mobility Management，QoS Provisioning， 地局から切断し新しい基地局に接続することであるた IntQoS (Integrated QoS，Security and Mobility Frame- め，ハンドオーバ時にもネットワークアクセスのため work) の概要とその問題点を述べる．3 章では提案手法 の設計概要について述べ，4 章でその詳細を述べる．最 後に 5 章で提案手法をまとめ，今後の計画を述べる． の AAA が必要となる．ただし本研究では，課金モデ ルは各ベンダーの運用ポリシーに従って設定できるも のと想定している． さらに，1.2 節 (1) (5) では移動機器のモビリティサ ポートが行われている．モビリティプロトコルには，機 2 器移動時のシグナリングを移動機器が行う host-based mobility management protocol と，ネットワーク側が行 関連研究 本章では，モビリティ環境下における QoS 保証につ う network-based localized mobility management proto- いての関連研究を挙げる． col という 2 つのカテゴリがある．前者は管理ドメイ ンを越えた移動が可能であるという汎用性を持つ反面， 2.1 MM (Mobility Management) 移動機器にモビリティプロトコルを実装する必要があ る．後者は移動機器にはモビリティプロトコルを実装 する必要はないが，移動できる範囲が 1 つの管理ド MM [6] は IP ベースの携帯電話網において音声通話 のような real-time アプリケーションが必須であるこ メイン内に限られるという制限がある．前者の例とし とを背景に，ハンドオーバ前後の通信切断による遅延 ては Mobile IPv6 (MIPv6)[4] があり，後者の例として が real-time アプリケーションの要求を満足しないこ は Proxy Mobile IPv6 (PMIPv6)[5] がある．本研究は単 とを解決しようとしている．MM は PMIPv6 ドメイン 一管理ドメインを想定しているので移動機器へのモビ を対象としている．PMIPv6 では LMA (Local Mobility リティプロトコルの実装が不要である PMIPv6 を採用 Anchor)，MAG (Mobile Access Gateway) が定義されて する． おり，これが協調することでネットワーク側のモビリ また，ハンドオーバ前後で QoS 保証通信を途切れる ティサポートを行う．そこで MM は，PMIPv6 ドメイ ことなく継続させる必要もある．そこで本研究では，移 ンのハンドオーバ時において通信再開前にネットワー 動機器の移動を事前に検知することで，移動後の AAA ク側で移動後通信経路を事前設定することで通信再開 処理の高速化を図ったり変更後の QoS 保証通信経路を までの遅延を小さくしている． 前もって設定しておくという方法をとる． 具体的には以下のようになる．MM は Proxy Infor- 以上をまとめると，本研究における必要要件は以下 mation Server (PIS) と呼ばれるネットワーク全体を管 の 4 点にまとめられる． 理するサーバをドメイン中に持つ．PIS はネットワーク 全体の情報からドメイン中の全 MAG の情報を把握し， • 比較的少数のフローへの Intserv による厳密な通 それぞれの MAG と Neighbor な関係にある MAG を把 信品質保証の提供 握している．ハンドオーバ時に移動機器が MAG から • 比較的多数のフローへの Diffserv によるスケーラ ブルな通信品質保証の提供 切断されると，LMA は MAG からその旨を通知され， PIS へその MAG と Neighbor な関係にある MAG を聞 きにいく．LMA は Neighbor な関係にある全 MAG に ハンドオーバ情報を通知する．移動機器がハンドオー • ネットワークへの接続時/ハンドオーバ時および資 源予約時におけるユーザの認証・権限委譲 バして新しい MAG へ接続すると，MAG は LMA に • PMIPv6 によるモビリティサポートおよび事前移 動検知によるスムーズなハンドオーバ PBA (Proxy Binding Acknowledgement) メッセージを 送るだけで移動機器の通信が再開される． しかし MM が行う QoS 保証は，SLA (Service Level Agreement) のみである．SLA はプロバイダと顧客間 3 で事前に契約を行い，その契約内容に基づいてサービ Correspondent Node Future Internet ス品質を保証する方式のことである．1.1 節の本研究 Correspondent Node が想定する環境では，SLA のような事前に契約を行う Gateways もの以外に移動機器が必要に応じて自由にサービスを AAA Server 求められるメカニズムが必要であると考えられる． AAA Server Enhanced Nodes 2.2 QSP (QoS Provisioning) Enhanced Nodes Enhanced Nodes Access Network1 Access Network2 Mobile Nodes QSP [7] は，PMIPv6 ドメインにおいて Flow-state routing という QoS 保証メカニズムを使いシームレス なモビリティと QoS 保証を実現している． 図 2: IntQoS におけるネットワークアーキテクチャ例 モビリティ環境での QoS 保証は，新規フローとハ ンドオーバ後のフローの区別が難しい．そのため QSP 2.3 IntQoS (Integrated QoS，Security and Mobility Framework) では，PMIPv6 ドメインのホームアドレスと呼ばれる， 移動に関係なく移動機器に割り当てられるアドレスを 用いて，ルータに転送されてきたフローを各ルータが 識別できるようにしている．そのため QSP における IntQoS [9] は，inter-domain のような QoS 環境が違 各ルータは，各フローごとに状態を保持している．ハ う中で QoS 保証を含むさまざまなサービスをユビキタ ンドオーバ時には，ハンドオーバ後に移動機器が PBU スに提供することを目指している．サポートする機能 (Proxy Binding Update) メッセージを送るだけで各ルー タが自律的に，そのフローが新規に Flow State Table に として QoS 保証，AAA，モビリティサポートが考え 登録するものなのか，既存の Flow State Table 情報を チャの例を図 2 に示す． 変更し Forwarding Table や Classification Table を更新 するものなのかを判断する．もし，ハンドオーバ前後 図 2 に示すように各ドメインには複数台の EN (Enhanced Node) が設置され，MN (Mobile Node) との間 で経路に変更がなければルータは特に処理を行うこと でトンネルが張られて通信が行われる．EN はドメイ はない． ン中の自 Node 以下の各ルータを管理し，管理下の各 QSP はハンドオーバ時に経路変更が生じるルータだ けが処理を行うため，RSVP(Resource reSerVation Protocol) [8] のような End-to-End での処理を必要としな ルータから QoS ，Security，モビリティ情報を集める． られている．IntQoS におけるネットワークアーキテク そして EN は Signaling を通して EN 間で情報を共有 し，Security，MM (Mobility Management)，QoS 保証， Radio 資源管理のサービスを提供する．Radio 資源管 理とは，ハンドオーバ時に移動機器が適切な無線基地 局を見つけるためのサポート機能のことである．また， い．このように QSP はハンドオーバ後の処理を減らす ことで通信再開までの遅延を小さくしているが実装は されておらず，実際に real-time アプリケーションの通 のような移動後通信経路を事前に設定する場合との比 IntQoS では inter-domain でのハンドオーバ時に QoS 保証情報を EN 間で転送することでスムーズなハンド 較もないが，通信再開までの遅延は事前に設定する場 オーバを提供している． 合の方が小さいと思われる．また，QSP には AAA に ついて一切考慮されていないが，ネットワークアクセ IntQoS はハンドオーバやスケーラビリティなどが適 切に考えられているが，QoS 保証については PerFlow スのための AAA と資源予約のための AAA は実運用 の IntServ 型の QoS 保証のみしか考えられておらず， 上必要不可欠であると考えられる． AAA については Accounting や QoS 保証に対する Au- 信品質を保持できるレベルなのか不明である．2.1 節 thentication，Authorization が考えられていない．しか し QoS 保証サービスを提供する場合，QoS 保証通信は ベストエフォート通信より優先される．そのため QoS 保証を行う場合には，ユーザが正当な権利を保持して 4 いるかや課金について考慮されなければならないと思 LMA: Local Mobility Anchor (& Diameter Client) MAG: Mobile Access Gateway (& Diameter Client) RMOC: Resource Manager & OpenFlow Controller われる． LMA target domain (PMIP domain) to global IPv6 Internet [Backbone Area] RMOC-0 2.4 3GPP (Third Generation Partnership Project) area border router-1 [sub-Area-1] MAG-11 MAG-12 mobile node (MN-1) Multimedia Subsystem) をもつ網とバックボーン網など の外部ネットワークと接続するときの協調動作を規定 している．また，QoS 保証についても規定しており， [sub-Area-2] area border router-2 RMOC-2 RMOC-1 3GPP [10] は，第 3 世代 (3G) 移動体通信システム の標準化プロジェクトである．3GPP では，IMS (IP Diameter server MAG-21 MAG-22 MN-2 図 3: ターゲットドメインの構成例 UMTS (Universal Mobile Telecommunications System) や GPRS (General Packet Radio Service) の技術環境に 考慮すれば複数) の資源管理サーバを設置し，資源管 おいて IntServ/DiffServ/SLA 通信を保証する．3GPP で 理サーバがドメイン全体のネットワーク資源とその利 は，QoS 保証のシグナリングについて RSVP (Resource 用状況を一元管理する．QoS 保証要求のたびに資源管 reSerVation Protocol) を用いており，DiffServ におい 理サーバが経路を計算するため，適切な経路計算が可 ても RSVP Aggregation [11] を用いている．RSVP は 能である反面負荷が資源管理サーバに集中してしまう． Path/Resv メッセージを用いて，QoS 保証通信に先だっ 分散管理では，ドメイン内の各ルータが自身のネット て End-to-End での通信経路の資源予約を行うプロトコ ワーク資源を管理する．QoS 保証要求時は要求元から ルである． 要求先までの経路上にある各ルータがそれぞれ処理し 3GPP によって規定された技術は，様々な技術環境 て適切な経路を選択していく．1 つの機器に負荷が集 下における協調動作について考えられている．そのた 中することはないが，必ずしも最適な経路が選択され め本研究を行ううえで大変参考になったが，本研究で るとは限らず，場合によっては途中で要求を満たせる 対象とする環境はシングルドメインであり 3GPP のよ 経路が見つけられなくなり，後戻りをして再度別経路 うに複数の技術環境について考える必要はない．また， を探す (crank back) という処理が生じる可能性もある． RSVP は通信に先だって End-to-End でパケットを送り 通信経路を設定する必要がある．そのため，通信開始 そこで本研究では，1.1 節のような事業者でのネッ までのオーバヘッドが大きくなりがちである． トワークを想定し，図 3 に示すように対象ドメインを 本研究では，これらの欠点を補い処理負荷が軽くな 複数の “エリア” に分割する方式にする．各エリア内 る方式を提案する． は集中管理方式を採用し，1 つ (あるいは複数) の資 源管理サーバ (RMOC: Resource Manager & OpenFlow Controller) がエリア内のネットワーク資源を集中管理 提案アーキテクチャ 3 する．そして各エリアの RMOC が協調してドメイン 本章では，関連研究を踏まえて提案する IQSAME の 全体の資源を分散管理する．ドメインのエリア分割に 全体像を示す． 3.1 ついては効率を踏まえて，OSPF (Open Shortest Path First) [12] にならって “バックボーンエリア” を 1 つ設 置してその下に “サブエリア” が接続するという 2 階 資源管理方法 層構造をとる．図 3 は 1 つのバックボーンエリアに 2 要求された QoS を満たす経路を計算するには対象 つのサブエリアが接続し，各エリアにそれぞれ RMOC ドメイン内のネットワーク資源を管理する必要がある． (RMOC-0∼2) が設置されている例である．各エリア間 に存在する ABR (Area Border Router) は耐障害性のた めに複数設置されることもある． 資源の管理方法には大きく分けて集中管理と分散管理 がある．集中管理では，ドメイン内に 1 つ (耐故障性を 5 OpenFlow Controller topology & resource info. OpenFlow Controller (manage one or more switches) topology & resource info. reservation reservation OpenFlow Protocol (control switch behavior) intserv (1 for each flow) class-1 (aggregated) class-1 (aggregated) best effort OpenFlow Switch class-2 (aggregated) class-2 (aggregated) OpenFlow Switch OpenFlow Switch best effort OpenFlow Switch packet flow packet forwarding specified by controller 図 4: 資源割当ての例 図 5: OpenFlow の概念 3.2 資源割当て方法 唱した技術であり，現在，仕様書 ver.1.1.0[14] が公開 IQSAME では 1.3 節で述べたように，厳密な QoS 保 されている． 証を要求する通信には IntServ を適用し，スケーラブ 現在のルータやスイッチは，パケットの転送機能 ルだが厳密な QoS 保証を要求しない通信には DiffServ 割当てを行う． (データパス) と高機能な経路選択 (制御パス) が同一 のデバイスに組み込まれている．OpenFlow はこの制 御パスの部分をスイッチから分離し，OpenFlow コント IntServ の通信には，要求に応じて End-to-End で連 続した QoS パスを確立したり解放したりするものとす る．一方 DiffServ の通信の場合は，予め隣接するルー ローラに組み込む．OpenFlow コントローラは，OpenFlow スイッチと OpenFlow プロトコルで通信し，管 理下の複数の OpenFlow スイッチを制御する．つまり タ間にクラスごとの QoS パスを確立しておき，ルータ 間 QoS パスを連結して End-to-End の QoS パスを形成 OpenFlow は，外部からスイッチやルータのフォワー ディングテーブルを操作する技術である (図 5 参照)． するものとする．ルータ間 QoS パスに割り当てられる 本研究では，利便性のため OpenFlow コントローラは 資源は，QoS を要求する通信の増減に応じて動的に調 RMOC に組み込まれるものとする．このように OpenFlow はスイッチとコントローラを分離するため新しい を適用する．そこで本研究では図 4 に示すような資源 節する．このようにすることで，ルータ間のリンクで DiffServ のクラスが同じフローは終点アドレスなどに 関係なく集約することができ，ルータはリンクを通る 機能はコントローラのみに実装すれば良い．すなわち， フローに応じて動的にクラス帯域を調節できるように した経路へのフローのマッピング機能はコントローラ なる． のみに実装すれば良く，開発の効率や拡張性にとても 本研究で提案するシグナリングプロトコルや資源予約 図 4 は，対象ドメイン内の隣接する 3 台のルータの 優れている．また，OpenFlow は各ベンダーで仕様の異 例を示したものである．図 4 では End-to-End で連続し なるスイッチをコントローラで一元して管理すること た IntServ の QoS パスが 1 本通っている．また隣接ルー ができ，各ベンダーもスイッチ内部の仕様を開示せず タ間には 2 つのクラス (class-1 と class-2) の DiffServ に QoS 保証を実現できるため実用性にも優れている． のルータ間 QoS パスが確立され，残りの資源をベスト エフォートが使用している．以上のように，IntServ に おいては QoS パスは End-to-End の連続したパスにな 3.4 QoS パス確立方法 り，DiffServ においては複数のルータ間 QoS パスが連 結されて End-to-End の QoS パスとなる． 3.3 QoS パスの確立は以下のように行われる．まず始め に，図 4 に示すように各ルータはトポロジー情報や 資源情報 (リンク容量など) を自身が属するエリアの QoS 経路へのマッピング: OpenFlow IQSAME では，計算された QoS 経路への各ルータ RMOC に通知する．これにより RMOC は自身が管理 するエリア全体のトポロジーおよびネットワーク資源 のマッピングに OpenFlow [13] を用いる．OpenFlow は を知ることができる．次に，たとえば図 3 において移 2008 年にスタンフォード大学の Nick McKeown が提 動機器 MN-1 から MN-2 に QoS パス確立要求があった 6 とする．すると MAG-11 はこの要求を受け取り，QoS LMA: Local Mobility Anchor MAG: Mobile Access Gateway PBU: Proxy Binding Update PBA: Proxy Binding Ack MNP: Mobile Network Prefix パス確立要求を RMOC-1 に送信する．RMOC-1 はこ の要求を受け取ると，MN-2 は別のエリアに存在する global Internet のでバックボーンエリアの RMOC である RMOC-0 に LMA Sub-Area-1 外の経路計算を依頼する．依頼後，RMOC1 は Sub-Area-1 内の要求を満たす経路を計算し，経路 上の各ルータへ図 4 に示すように設定を行って QoS パ (3) assign MNP & create entry (10) modify entry (2) PBU(MN-ID) (9) PBU & PBA (4) PBA(MNP) スを確立する．RMOC-0 でも同様に RMOC-2 に sub- (8) PBU & PBA (dereg) Area-2 内での経路計算と QoS パス確立を要求し，バッ MAG-1 クボーンエリア内での資源予約を行う．RMOC-2 でも (1) attach 同様に処理を行うことで，End-to-End の QoS パスが MAG-2 (12) RA (6) RA (7) handover 確立される． 3.5 図 6: PMIPv6 の動作例 シグナリングプロトコル 3.4 節で述べたように，QoS パス確立のためのシグナ 制御には IEEE802.1X が広く使用されている．また， リングメッセージはまず移動機器から MAG に送信さ Diameter Base Protocol はメッセージの信頼性やセキュ リティを保証しているためプロトコルが複雑であり， 移動機器に実装するには適していない．そこで，移動 れ，次に MAG からその MAG が属するエリアの RMOC に送信され，次に RMOC 間で送信される．本研究で は，シグナリングメッセージを MAG と RMOC 間およ 機器と MAG 間は QoS パス確立のためのフロントエ び RMOC 同士で転送するプロトコルとして，Diameter ンドプロトコルとして独自のものを定義し，MAG と QoS Signaling Application を新たに定義する．これは， RFC 5624[15]，5777[16] では Diameter を QoS シグナ リングのプロトコルとして利用するためのデータ構造 RMOC 間，RMOC 同士はバックエンドプロトコルと して Diameter Base Protocol を使用するものとする． は定義されているが具体的なプロトコルはまだ定義さ 3.6 れていないためである． Diameter QoS Signaling Application では以下の 4 つ 1.3 節で述べたようにモビリティ管理には PMIPv6 のメッセージを定義する． • Diameter QoS Reserve を利用する．図 3 に示すように，対象ドメインが 1 つ の PMIPv6 ドメインとなり，グローバルな IPv6 イン Request/Answer (RVR/RVA): QoS パス確立要求/応答メッセージ • Diameter QoS Release モビリティ管理 ターネットとの境界にローカルな Home Agent として LMA (Local Mobility Anchor) が配置される．図 3 では Request/Answer LMA は 1 台しか配置されていないが，耐障害性を考 慮した場合は複数台の LMA を配置する．また，対象 (RLR/RLA): QoS パ ス の 解 放 要 求/応 答 メッ セージ ドメインの有線通信部分と無線通信部分の境界に位置 一方，移動機器と MAG でのシグナリングには Di- するアクセスルータは MAG (Mobile Access Gateway) ameter 以外の独自プロトコルを定義することとする． 理由は以下のとおりである．Diameter Base Protocol は として動作する (図 6 参照)．PMIPv6 は以下のように 動作する． (1) 移動ノード (MN) が MAG-1 に接続する．PMIPv6 AAA システムにおけるバックエンドプロトコルとして 設計された．バックエンドプロトコルとは AAA サー バ間で使用されるプロトコルである．一方，ユーザ機 では MAG はリンク層技術により MN の接続を検知 器と AAA サーバ間で使用されるプロトコルはフロン 別子である MN-ID を含む PBU (Proxy Bind Update) トエンドプロトコルと呼ばれ，ネットワークアクセス メッセージを送信する．(3) LMA は MN-ID に対応し できるとしている．(2) MAG-1 は LMA に MN の識 7 た HNP (Home Network Prefix: 64 ビットのプレフィッ EAP methods クス) を割当て，BCE (Binding Cache Entry) を作成す TLS る．(4) LMA は MAG-1 に HNP を含む PBA (Proxy Diameter Applications Binding Acknowledgement) を送信する．(5) 以上の処理 TTLS ... Diameter EAP Application の結果，LMA と MAG-1 の間にトンネルが確立される． Diameter QoS Application Diameter SIP Application ... Diameter Base Protocol (6) MAG-1 は HNP を含む RA (Router Advertisement) を MN に送信する．MN は RA を受信すると IPv6 ア 図 7: Diameter Base Protocol と Diameter Applications ドレスを生成し，通信可能となる．MN へのパケット はまず LMA に到達する．LMA はこのパケットをトン ネリングで MAG-1 に転送する．MAG-1 は元のパケッ び LMA と Diameter Server 間で Diameter for PMIPv6 トを取り出し，MN へ転送する．MN からのパケット [19] が動作するものとする．また，QoS パス要求時には MAG と Diameter Server 間で Diameter QoS Application はこの逆の処理で送信される．(7) MN が MAG-2 の エリアにハンドオーバする．(8) MAG-1 は MN が切 [20] が動作するものとする． 断したことを検知し，LMA に de-registration のための PBU を送信し，LMA は PBA を返信する．この処理に より，LMA と MAG-1 間のトンネルは削除される．(9) MAG-2 は MN の接続を検知し，LMA に PBU を送信 3.7.1 Diameter Base Protocol と Diameter Applications する．(10) LMA は BCE を更新し，先ほどと同じ HNP Diameter Base Protocol は基本的には AAA 情報を Diameter ノード間で転送するためのプロトコルであ り，AAA 機能を必要とするそれぞれの利用形態に応じ を含む PBA を返信する．(11) 以上の処理により LMA と MAG-2 間にトンネルが確立される．(12) MAG-2 は MN に HNP を含む RA を送信する．HNP はハンドオー バの前後で変化しないので，MN はハンドオーバには て Diameter Base Protocol の上に Diameter Application が定義されている (図 7 参照)．たとえばネットワークア 気付かずに通信を継続できる． クセスの AAA のためには Diameter EAP Application が た だ し (7)∼(12) に お け る ハ ン ド オ ー バ 手 順 は 定義されており，さらにこれは PMIPv6 利用時の AAA PMIPv6 [5] に述べられた手順であり，3.8 節で本方式 処理のために拡張されている．また QoS 保証通信の のハンドオーバ手順を述べる． 資源予約の AAA のためには Diameter QoS Application が定義されている． 1.3 節で述べたように，移動機器が対象ドメインに Diameter Base Protocol は Diameter ノードが他の Diameter ノードに Request メッセージを送り，Request を 受信したノードはそれに対して Answer を返すという 接続したり対象ドメイン内を移動したとき，および移 プロトコルである．Diameter Base Protocol および Di- 動機器が QoS パスの確立を要求したときに AAA 処理 ameter Application が定義する主なコマンドを表 1 に を行う必要がある．AAA のためのプロトコルとして 示す． 3.7 AAA 処理 は現在は RADIUS (Remote Authentication Dial-In User Service)[17] が広く利用されているが，メッセージの 信頼性，セキュリティ，拡張性などで問題があるため， RADIUS の後継プロトコルとして 2003 年に Diameter 3.8 ハンドオーバ処理 Base Protocol[18] が標準化された．そのため本研究で は AAA 処理のため Diameter Base Protocol を用いる． の接続処理を行う必要がある．また，AAA についても 図 3 に示すように，対象ドメインには 1 つ (耐障害性を 再度 Diameter for PMIPv6 を動作させる必要がある．こ 考慮すると複数) の Diameter server が存在し，MAG と れではハンドオーバ時間が長くなってしまう．そこで LMA は Diameter client の役割も果たすこととする．移 本研究ではハンドオーバ時に移動元の MAG (pMAG: 動機器の接続時およびハンドオーバ時には MAG およ previous MAG) と移動先の MAG (nMAG: new MAG) 3.6 節 (7)∼(12) はハンドオーバの際に再度 PMIPv6 8 LMA: Local Mobility Anchor (& Diameter Client) MAG: Mobile Access Gateway (& Diameter Client) RMOC: Resource Manager & OpenFlow Controller 表 1: Diameter の主なコマンド ACR Accounting-Request ACA Accounting-Answer CER Capabilities-Exchange-Request CEA Capabilities-Exchange-Answer STR Session-Termination-Request STA Session-Termination-Answer [Backbone Area] Diameter-EAP-Request DEA Diameter-EAP-Answer Diameter server RMOC-0 area border router-1 [sub-Area-1] [sub-Area-2] area border router-2 RMOC-2 RMOC-1 MAG-11 MAG-12 MAG-21 mobile node (MN-1) Diameter EAP Application DER LMA target domain (PMIP domain) Diameter Base Protocol PMIPv6 OpenFlow Context Transfer Diameter PMIPv6/QoS Application Diameter QoS Reserve Application to global IPv6 Internet MAG-22 MN-2 図 8: IQSAME の動作まとめ Diameter QoS Application QAR QoS-Authorization-Request QAA QoS-Authorization-Answer 約を行う．MAG-12 が移動機器の接続を確認し，上記 間でコンテキスト転送を行う．Diameter for PMIPv6 で の手順で認証・権限が確認されると MAG-12 は MAG11 にコンテキスト転送の確認応答を送信する．さらに MAG-12 は RMOC-1 に最終的な QoS パスの変更要求 は，移動機器の認証・権限が確認されると移動機器と を送信する．すると RMOC-1 は OpenFlow の制御メッ MAG の間で MSK (Master Session Key) が共有される． セージを MAG-11 に送信し，MAG-11 を QoS パスか そこで pMAG が移動機器のハンドオーバを事前に検 ら削除する． 知し，コンテキスト転送によって pMAG から nMAG pMAG が予め nMAG を知ることができるかはリン ク層技術に依存しており，たとえば IEEE802.11 のよ に MSK を転送しておく．nMAG に接続した移動機器 は nMAG とメッセージを交換するだけで認証・権限 うな無線 LAN を使用している場合は pMAG は nMAG 確認が済むことになり，ハンドオーバ時間の AAA 処 を事前に知ることはできないと思われる．そこで本研 理時間が短縮される．コンテキスト転送のメッセージ 究では，pMAG は移動機器のハンドオーバを事前に検 フォーマットは，CXTP (Context Transfer Protocol)[21] 知すると移動先となる可能性のある複数の MAG にコ に準拠することとする． ンテキスト転送を行うこととする．移動機器が接続し PMIPv6 では pMAG は移動機器のハンドオーバを検 知し，移動先である nMAG を知ることができるという 前提になっている．このような場合，移動機器が QoS nMAG となった MAG は pMAG にコンテキスト転送 の確認応答を送信する．コンテキスト転送を受信した が移動機器がタイムアウト内に接続しなかった MAG パスを使用したままハンドオーバする場合の処理は以 は受信したコンテキストを廃棄することとする． 下のようになる．図 3 において移動機器が MAG-11 か ら MAG-12 にハンドオーバするものとする．pMAG 3.9 IQSAME のまとめ (MAG-11) は移動機器のハンドオーバを事前に検知し， 図 3 に示す構成を例として，図 8 に IQSAME の動 nMAG (MAG-12) を特定する．MAG-11 は上記のよう に MAG-12 にコンテキスト転送するとともに QoS パ スの事前確立を要求する．MAG-12 は RMOC-1 に QoS 作のまとめを示す． MAG-11 が MN-1 の接続を検知すると，Diameter for の変化は自エリア内のみであることを検知し，QoS パ PMIPv6 Application により Diameter Server と通信して ネットワークアクセスに関するユーザの認証・権限確 スの変化部分 (この例では MAG-12 とその上流のルー 認を行う．次に MAG-11 は PBU メッセージを LMA に タ) に OpenFlow の制御メッセージを送信し，資源予 送信する．LMA は Diameter PMIPv6 Application によ パスの事前確立要求を送信する．RMOC-1 は QoS パス 9 LMA: Local Mobility Anchor (& Diameter Client) MAG: Mobile Access Gateway (& Diameter Client) RMOC: Resource Manager & OpenFlow Controller LMA target domain (PMIP domain) MN Class-1 path between routers Class-2 path between routers best effort path between routers to global IPv6 Internet EAP/res-identity Diameter server DEA (EAP request #1) EAP/res #2 DER (EAP response #2) EAP/res #N DER (EAP response #N) EAP/success DEA (EAP success) + MAG-to-HAAA AVPs (1) … [sub-Area-2] DER + MAG-to-HAAA AVPs EAP/req #1 … area border router-1 [sub-Area-1] Diameter EAP/req-identity [Backbone Area] RMOC-0 LMA MAG MN L2 attach area border router-2 PMIPv6 PBU AAR + LMA-to-HAAA AVPs RMOC-2 RMOC-1 AAA + LMA-to-HAAA AVPs (2) PMIPv6 PBA RA MAG-11 MAG-12 MAG-21 mobile node (MN-1) MAG-22 IP Connectivity PMIPv6 tunnel up MN-2 図 10: 端末接続時のメッセージシーケンス 図 9: 確立された QoS パス 処理後の QoS パスの様子を図 9 に示す．ここでは 元々各ルータ間には Class-1, Class-2, およびベストエ り Diameter Server と通信して PMIPv6 の使用に関する フォートのためのルータ間 QoS パスが用意されている ユーザの認証・権限確認を行う． とする．この状態で，MN-1 は MN-2 との間に Class-1 MAG-11 は MN-1 から QoS パス確立要求を受信する の QoS パスを確立したとする．この QoS パス確立要 と，Diameter QoS Application により Diameter Server 求により，必要に応じて各ルータ間パスの帯域が調整 と通信して資源予約に関するユーザの権限確認を行 される．そして各ルータ間の class-1 のパスを連結する う．次に MAG-11 は RMOC-1 に Diameter QoS Sig- ことで MN-1 と MN-2 間の QoS パスが構成される． naling Application により QoS パスの確立を要求する． RMOC-1 は MN-2 が自エリアに存在しないことが分 かるので，RMOC-0 に QoS パス確立要求を転送する． RMOC-0 はさらに RMOC-2 に QoS パス確立要求を転 送する． 提案アーキテクチャの詳細 4 本章では，前章で述べた IQSAME のメッセージシー RMOC-1 は RMOC-0 に QoS パス確立要求を転送後， sub-Area-1 内の経路を計算し経路上にある各ルータに ケンスについて述べる． OpenFlow の制御メッセージを送信し，QoS パスを確 立する．RMOC-0，RMOC-2 も同様である． MAG-11 が，MN-1 が MAG-12 にハンドオーバする 4.1 ことを事前に検知すると，MAG-11 と MAG-12 間でコ メッセージシーケンスを示す．ここに示すメッセージ ンテキスト転送が行われる．このとき同時に MAG-11 シーケンスとメッセージフォーマットは，EAP [22]， 端末接続時 図 10 に移動機器がネットワークに接続したときの は QoS パスの事前確立要求を MAG-12 に送信する． PMIPv6 [5]，Diameter for PMIPv6 [19] に準拠してい MAG-12 は QoS パスの事前確立要求を RMOC-1 に送 信する．RMOC-1 は MN-1 がハンドオーバしたあと る．図中の (1) は移動機器 (MN ) のネットワーク接 の QoS パスを計算し，QoS パスの変化部分 (この例で メッセージを送信する．MN-1 が MAG-12 に接続する Application と同様のシーケンスとなっている．まず MAG (Mobile Access Gateway) は MN の接続を検知し， MN と EAP Request と EAP Response の交換をして MN と，MAG-12 は RMOC-1 にその旨を通知する．すると の識別子を得る．MN の識別子は最終的に Diameter RMOC-1 は MAG-11 とその上流のルータに OpenFlow Server 内で NAI (Network Access Identifier) [23] の表 の制御メッセージを送信し，MAG-11 を QoS パスから 記にマッピングされる．次に MAG は Diameter Server 削除する． に DER (Diameter EAP Request) を送信し，Diameter 続のための認証・権限確認処理であり，Diameter EAP は MAG-12 とその上流のルータ) に OpenFlow の制御 for PMIPv6 の開始を通知する．その後は実際に使用 10 MAC header MN Protocol packet type length version (a) EAPOL (EAP over LAN) frame format MAG EAP packet Diameter Server own Area RMOC other Area RMOC other Area RMOC CN QoS Reserve QAR QAA 0 8 16 Code(1 or 2) Identifier Type Type Data 0 8 Code(3 or 4) 24 QoS Reserve Request 31 Length 16 24 Identifier 31 Length QoS Reserve Response QoS Reserve Request QoS Reserve Answer QoS Reserve Request QoS Reserve Answer ・・・ QoS Response Code 1 : Request 2 : Response 3 : Success 4 : Failure Type 1 : Identity 2 : Notification 3 : Nak 4 : MD5-Challenge 5 : One-Time Password 6 : Generic Token Card 13 : TLS 図 13: QoS 通信開始時のメッセージシーケンス (b) EAP packet format 図 11: EAP のパケットフォーマット 可変長の Data を格納し，AVP 中に他の AVP を含むこ ともある．本提案で用いられる Diameter のメッセージ 0 8 16 24 Version Message Length Command Flags Command Code 32 は全てこれに準拠する．Diameter-EAP-Request/Answer は RFC 4072 (Diameter EAP Application) に準拠して Application ID いる．また，AA-Request/Answer + LMA-to-HAAA は Hop-by-Hop Identifier End-to-End Identifier RFC 4005 (Diameter NASREQ)， RFC 5779 (Diameter for PMIPv6) に準拠している． AVPs ・・・ (a) Diameter packet format 0 8 16 24 32 AVP Code AVP Flags 4.2 QoS 保証通信開始時 AVP Length Vendor-ID(optional) Data ・・・ 図 13 に QoS 保証通信開始時のメッセージシーケン (b) AVP format スを示す．まず MN は MAG に QoS Reserve メッセー 図 12: Diameter のフォーマット ジを送信する．すると MAG は Diameter QoS Applica- される認証方式に従って DER と DEA (Diameter EAP tion [20] にしたがって Diameter Server と QAR (QoS Authorization Request) と QAA (QoS Authorization Answer) の交換を行い，MN が資源予約を行う際の権限 Answer) が何度かやりとりされ，認証処理が終了する． 図中の (2) は移動機器が PMIPv6 を利用するための認 確認処理を行う．次に MAG は自エリアの RMOC に 証・権限確認処理である．MAG は MN の認証が成功す のメッセージは本方式で定義した Diameter QoS Signal- ると，PMIPv6 の PBU (Proxy Binding Update) を LMA ing Application のメッセージである．このメッセージ を受信した RMOC は経路を計算し，その結果に基づ (Local Mobility Anchor) に送信する．LMA は Diameter RVR (Diameter QoS Reserve Request) を送信する．こ Server と AA-Request/AA-Answer の交換をする．これ が成功すると移動機器は PMIPv6 を利用して通信可能 となる． 経路上の RMOC に順々に転送されていき，通信相手 移動機器と MAG 間で交換される EAP メッセージの アの RMOC は 1 つ前の RMOC に RVA (Diameter QoS フォーマットを図 11 に示す．これは RFC 3748 (EAP) に Reserve Answer) を返す．最終的に RVA は MAG に返 準拠している．次に Diameter メッセージのフォーマット る．最後に MAG は MN に QoS Response を返す．上 いて他エリアの RMOC に RVR を送信する．RVR は が存在するエリアで資源予約が成功すると，そのエリ を図 12 に示す．Diameter メッセージには図 12 (a) で示 記の動作と同時に各 RMOC は QoS 保証通信の経路と すようにヘッダおよび 1 つ以上の AVP (Attribute-Value なる OpenFlow スイッチに ofp queue set config パケッ Pairs) が含まれており，各メッセージ内の AVP のコレク ションは Diameter Application の種類によって決まる． トを送信してスイッチの flow table を設定する． AVP は図 12 (b) で示すように AVP のタイプによって 5866 (Diameter QoS Application) に準拠している．MN 11 Diameter QoS Authorization Request/Answer は RFC MN MAG QoS Release Diameter Server own Area RMOC QoS Release Request QoS Release Answer other Area RMOC QoS Release Request QoS Release Answer other Area RMOC MN CN nMAG pMAG nMAG Area RMOC LMA Diameter Server other Area RMOC handover detect CT CTA QoS Release Request QoS Release Answer QoS Reserve Request ・・・ QoS Reserve Request CTでフラグが 立っていた場合 QoS Reserve Response ・・・ QoS Reserve Response STR MN L2 attach EAP-Initiate/Re-Auth-Start STA EAP-Initiate/Re-Auth QoS Response EAP-Finish/Re-Auth PMIPv6 PBU PMIPv6 PBA AAR + LMA-to-HAAA AVPs AAA + LMA-to-HAAA AVPs RA CTR CTRA 図 14: QoS 通信終了時のメッセージシーケンス CTでフラグが立っていなかった場合はQoS経路予約 RMOCからpMAGのQoS経路を削除 と MAG 間で送られる QoS Reserve/Response は本提案 独自のもので RVR/RVA に従ったフォーマットとなる． RVR/RVA は RFC 5624 (QoS Parameters for Diameter)， RFC 5777 (Traffic Classification and QoS Attributes for Diameter) を参考にして本方式が定義したものである． ofp queue set config パケットのフォーマットは Open- 図 15: ハンドオーバ時のメッセージシーケンス 4.4 ハンドオーバ時 図 15 に QoS 保証通信を継続しながらハンドオーバ したときのメッセージシーケンスを示す．PMIPv6 で Flow Switch Specification [14] に準拠している． は MN が MAG に接続したり切断したりしたときには 4.3 MAG がこれらのイベントを検知できることを前提とし ている．そこで本方式でも pMAG (previous MAG，ハン QoS 保証通信終了時 図 14 に QoS 保証通信終了時のメッセージシーケ ドオーバ前に MN が接続していた MAG) が MN のハン ンスを示す． まず MN は MAG に QoS Release メッ ドオーバを事前に検知できるものと仮定する．また，こ セージを送信する．これを受信した MAG は自エリア こでは pMAG は nMAG (new MAG，ハンドオーバ後に の RMOC に RLR (Diameter QoS Release Request) を 送信する．このメッセージを受信した RMOC は QoS MN が接続する MAG) を事前に知ることができると仮 定する．ただし，pMAG は隣接関係にある複数の MAG パスに沿った RMOC に順次 RLR を転送していく．最 を nMAG とみなすこともある．ハンドオーバ時には， 終的に通信相手が存在するエリアの RMOC から RLA まず pMAG が MN のハンドオーバを事前に検知して (Diameter QoS Release Answer) が返送され，最終的に nMAG を認識する．pMAG は全ての nMAG に Context MAG に届く．これを受信した MAG は QoS 保証通信の 終了を Diameter Server に知らせるため，STR (SessionTermination-Request) を送信し，Diameter Server は STA Transfer Protocol の CT (Context Transfer data) メッセー ジにより PMIPv6 の BUL (Binding Update List) の情報， (Session-Termination-Answer) を返す．これにより，Diameter Server は Accounting を終了する． つに特定できている場合，CT メッセージ中のフラグ MN と MAG 間で送られる QoS Release/Response は 本提案独自のもので RLR/RLA に従ったフォーマットと なる．RLR/RLA は RFC 5624，RFC 5777 を参考にし 報を以下に示す． 認証情報および QoS 通信情報を転送する．nMAG が 1 がセットされる．CT メッセージで転送される主な情 • BUL (MN ID，MN NHP，LMA アドレス，MAG のアドレス) て本方式が定義したものである．Diameter Session Ter- • 認証情報 (MSK) mination Request/Answer は RFC 3588 (Diameter Base Protocol) に準拠している． • QoS 通信情報 (5 tuple，service class) 5 tuple とはフローを一意に識別するための情報で， src/dst IP，src/dst Port，Protocol を示す．nMAG はこ 12 0 8 Type=0x3 16 24 2Flags & Reserved QoS Signaling App OpenFlow Daemon Diameter Base Protocol Elapsed Time (in milliseconds) OpenFlow Daemon Context Data Block (a) Context Transfer data (CT) format 8 16 24 Feature Profile Type (FPT) Length Data Vers. 3bit 16 モビリティサポート EAP App + PMIPv6 Diameter Base Protocol 1Flag & Reserved QoS App context transfer QoS Signaling App Diameter Base Protocol MAG AAAサポート サポート 24 2Flags & Reserved PMIPv6 Daemon 各Switch 31 EAP App + PMIPv6 Type=0x5 OpenFlow Daemon EAP App + PMIPv6 LMA (b) Context Data Block (CDB) format 8 OpenFlow Daemon PMIPv6 Daemon 31 Presence Vector (if P = 1) 0 QoS保証通信サポート 保証通信サポート RMOC Mobile Node's Previous Care-of Address (IPv6 address = 16 octets) 0 他エリアRMOCの のQoS エリア Signaling Appと連携 と連携 31 Length サポート AAA Vers. 3bit Length Diameter Server QoS App Diameter Base Protocol ：新規の実装箇所 ：既存の実装箇所 Mobile Node's Previous IP Address (IPv6 address = 16 octets) ・ ・ ・ FPT (if present) Status Code Reserved 図 17: 実装モジュール (c) Context Transfer data Reply (CTR) format 図 16: ハンドオーバ時のメッセージシーケンス CT/CTR に従ったフォーマットとなる．MN と nMAG 間での EAP 再認証メッセージは RFC 5296 (EAP Ex- tensions for EAP Re-auth Protocol) に準拠している． のメッセージを受信すると，pMAG へ CTA (Context Transfer data Ack) メッセージを返す．CT メッセージ 中のフラグがセットされていた場合，nMAG は MN の 4.5 ハンドオーバ後の QoS パスを設定するため，RVR を 障害時 RMOC はエリア内の各スイッチと OpenFlow Protocol 自エリアの RMOC に送信する．このメッセージには， QoS パスを識別するための 5 tuple と，pMAG および に従って接続されている．そのため，障害によるトポ nMAG の IP アドレスが含まれている．このメッセー ジを受信した RMOC はハンドオーバ後の経路を計算 してハンドオーバ前後での変更部分を検出し，変更部 ロジの変化を RMOC は検知することができる．RMOC はトポロジの変化を検知すると，QoS 保証通信開始時 の RVR を受信した以降と同じ処理を行う． 分に関して QoS パスの確立手順を実行する．最終的 には RVA が nMAG まで返送される．その後，nMAG 5 は MN の EAP 再認証処理を行う．nMAG は Context Transfer によってすでに MN の MSK を保持している ので MN と nMAG 間で認証が完了する．認証後は接 今後の計画 図 17 に実装モジュール図を示す．図で青い部分は既 存実装であり，オレンジ色の部分が新規実装部分であ 続時の処理と同様の処理が行われ，接続処理が完了す る．RMOC は実運用ではサーバマシンが担当すると想 ると CTR (Context Transfer data Reply) メッセージに 定される．RMOC には Diameter のためのモジュールと， よって pMAG にハンドオーバが完了したことを伝え OpenFlow のためのモジュールが存在する．Diameter モ る．pMAG は CTR を受信すると MN の情報を削除し， nMAG へ CTRA (Context Transfer data Reply Ack) メッ ジュールには QoS Signaling App モジュールと Diameter Base Protocol モジュールが含まれる．前者は新規実装部 セ―ジを返す．その後，CT メッセージ中のフラグが であり，後者はすでに freeDiameter [24] として実装済 セットされていなかった場合は QoS 保証通信開始時の である．Open Flow モジュールも新規実装である．MAG 処理を行う．最後に nMAG は RMOC から pMAG の には大きく分けて OpenFlow，PMIPv6，Diameter の 3 QoS 経路を削除する． 図 16 に Context Transfer Protocol の CT/CTR のメ つのモジュールが存在する．PMIPv6 の主要部分は実装 済だが，コンテキスト転送の部分を新規に実装する必 ッセージフォーマットを示す．CT/CTR は RFC 4067 要がある．Diameter モジュール内には，PMIPv6 対応， (Context Transfer Protocol) に準拠している．また， CTA/CTRA は本方式中で CT/CTR それぞれの到達性 確認のために定義したメッセージである．それぞれ QoS App，QoS Signaling App モジュールを実装する必 要がある．LMA にも大きく分けて OpenFlow，PMIPv6， Diameter の 3 つのモジュールが存在する．LMA はコン 13 PMIP Domain Area 0 (Backbone Area) 考慮している．具体的には，ネットワーク接続時やハ LMA ンドオーバ時におけるネットワーク利用のための AAA と，QoS パスを確立する際の AAA である．また QoS Diameter Server 保証通信を継続しながらのスムーズなハンドオーバも 実現する． RMOC Area 1 実現手法としては，ドメインをバックボーンアエリア Area 2 とサブエリアに分け，エリアごとにネットワーク資源を RMOC MAG MAG MAG MN RMOC 管理するための RMOC (Resource Manager & OpenFlow MAG Controller) を設置し，階層的な分散管理とした．厳密 な QoS 保証のためには End-to-End で連続した QoS パ MN スを確立し，クラスごとの QoS 保証にはルータ間で確 立してあるクラスごとのパスを連結することで End-to- 図 18: 想定する評価環境 End の QoS パスを実現する．AAA には Diameter を利 用する．メッセージ転送の信頼性，セキュリティ，拡張 テキスト転送には関与しないので，PMIPv6 もジュー 性などの特徴を考慮し，Diameter をシグナリングプロ ルに関しては既存のものを利用する．Diameter Server トコルとしても利用する．QoS パスへのフローのマッ にも PMIPv6 対応と QoS App モジュールを実装する ピングのためには OpenFlow 技術を適用し，開発や運 必要がある．各スイッチについては OpenFlow に準拠 用の効率化を図った．また，OpenFlow はスイッチのベ したスイッチを利用する計画である． ンダ間の相違を吸収するため，実用性にも優れている． 評価については，図 18 のような環境を想定する．評 本論文においてはパケットフォーマットなどの詳細 価項目は大きく分けて，各要件の動作確認と性能確認 設計までとなっている．今後は 5 節に従って実装を進 を行う予定である．各要件の動作確認は以下の 3 つを めていきたい． 確認する． • QoS 保証 (IntServ， DiffServ) 参考文献 • ハンドオーバ [1] D. Clark R. Barden and S. Shenker. Integrated Services in the Internet Architecture: an Overview. RFC 1633, IETF, June 1994. • AAA また，性能確認では以下の 2 つを確認する． [2] F. Baker K. Nichols, S. Blake and D. Black. Definition of the Differentiated Services Field (DS Field) • ハンドオーバ時間 in the IPv4 and IPv6 Headers. RFC 2474, IETF, December 1998. • オーバヘッド 以上の各評価を踏まえて，今後の課題を考えていく． 6 [3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss. An Architecture for Differentiated Service. RFC 2475, IETF, December 1998. まとめ 本研究は，IPv6 を利用した単一管理ドメインにお いて多数の携帯機器に QoS 保証通信を実現するため， QoS サービスを (1) 高価だがフローごとの厳密な QoS 保証 (2) 安価だが複数のフローを束ねたクラスごとの QoS 保証に分けた．そして実運用上必要不可欠である [4] C. Perkins D. Johnson and J. Arkko. Mobility Support in IPv6. RFC 3775, IETF, June 2004. [5] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. Patil. Proxy Mobile IPv6. RFC 5213, IETF, August 2008. AAA (Authentication, Authorization and Accounting) を 14 [18] P. Calhoun, J. Loughney, E. Guttman, G. Zorn, and J. Arkko. Diameter Base Protocol. RFC 3588, IETF, Sep 2003. [6] Brownson Obaridoa Obele and Minho Kang. Mobility Management: A Proactive QoS-Aware Proxy MIP with improved Handover Latency for End-toEnd QoS provisioning in a Proxy MIP domain. In [19] J. Korhonen, ICACT 2009., Feb 2009. J. Bournelle, K. Chowdhury, A. Muhanna, and U. Meyer. Diameter Proxy Mobile IPv6: Mobile Access Gateway and Local Mobility Anchor Interaction with Diameter Server. [7] Jihae Park Taehyong Lim, Tri M. Nguyen and Jinwoo Park. QoS Provisioning Based on Flow-State RFC 5779, IETF, February 2010. Routing for Proxy Mobile IP. In NISS 2009., Jun 2009. [20] D. Sun, P. McCann, H. Tschofenig, T. Tsou, A. Do- [8] J. Wroclawski. The Use of RSVP with IETF Integrated Services. RFC 2210, IETF, September 1997. ria, and G. Zorn. Diameter Quality-of-Service Application. RFC 5866, IETF, May 2010. [9] Yingli Sheng, Haitham Cruickshank, A. Dev Pra- [21] C. Perkins J. Loughney, M. Nakhjiri and R. Koodli. gad, Paul Pangalos, and A. Hamid Aghvami. An integrated QoS, security and mobility framework for Context Transfer Protocol (CXTP). IETF, July 2005. delivering ubiquitous services across all IP-based networks. In PIMRC 2008., Sep 2008. RFC 4067, [10] 3GPP Home Page. http://www.3gpp.org/. [22] B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, and H. Levkowetz. Extensible Authentication Protocol (EAP). RFC 3748, IETF, June 2004. [11] F. Le Faucheur F. Baker, C. Iturralde and B. Davie. Aggregation of RSVP for IPv4 and IPv6 Reserva- [23] B. Aboba and M. Beadles. The Network Access Identifier. RFC 2486, IETF, January 1999. tions. RFC 3175, IETF, September 2001. [24] freeDiameter Home freediameter.net. [12] J. Moy. OSPF Version 2. RFC 2328, IETF, April 1998. [13] OpenFlow Home Page. http://www.openflow. org. [14] OpenFlow Consortium. OpenFlow Switch Specification, Version 1.1.0, February 2011. [15] J. Korhonen, H. Tschofenig, and E. Davies. Quality of Service Parameters for Usage with Diameter. RFC 5624, IETF, August 2009. [16] J. Korhonen, H. Tschofenig, M. Arumaithurai, M. Jones, and A. Lior. Traffic Classification and Quality of Service (QoS) Attributes for Diameter. RFC 5777, IETF, February 2010. [17] A. Rubens C. Rigney, S. Willens and W. Simpson. Remote Authentication Dial In User Service (RADIUS). RFC 2865, IETF, June 2000. 15 Page. http://www.