博士論文原案 大枠 • Mobile Centric L3/L4 Framework 問題意識 イメージ図 アプリケーション層 アプリケーション要求値/アプリケーションタイプ コントロール副層 TCP UDP SCTP フロー生成/変更通知 割り当て可能リソース通知 コンバージェンス副層 PS管理副層(IP) 帯域割り当て要求 PSデータリンク層 CS管理副層 L1/L2情報 帯域割り当て要求/呼制御 CSデータリンク層 Mobile Centric Layer3 - エンドノード • CSとPSの使い分け – CS → 通信品質(実行帯域、遅延 etc)を予想可能なネット ワーク – PS → 通信品質を予想することが困難なネットワーク • CS用ネットワーク層プロトコルの設計 • CS L3プロトコルとPS L3プロトコル(IP)の融合副層 の設計 • Layer 4からの要求に従い、実際に帯域割り当て/回 線選択 • 抽象IDの定義 – CSネットワーク、PSネットワーク双方からアクセス可能な ID 音楽ダウンロード 動画ストリーミング VoIP 動的コントロール 層選択/要求値 通知 コンバージェンス副層 PSコントロール 帯域割り当て要求 CSコントロール 呼制御/ (Optionalとして) 1フローあたりの シェイピング Mobile Centric Layer3 - バックボーンネットワーク • 現在のネットワーク環境に関係する情報(実効帯域、 リンク遅延等)を経路制御に反映 – パラメータ毎に異なる経路表(?) – 複数のパラメータの組み合わせもありうる以上、単一の 経路表を用い、動的にパスを生成することが望ましい • 遅延の要求値と帯域の要求値の双方を参照する場合には単一 の経路(パス)表に複数のパラメータを関連づけ、最適なパスを選 択するアプローチが妥当 • 現時点で理想に近いのはMPLS-TE • 輻輳を動的に回避 Mobile Centric Layer3 - バックボーンネットワーク 経路情報とともにネッ トワーク環境 情報を交換 新たなフローに は別パスを割り 当て 輻輳発生 Mobile Centric Layer4 • アプリケーション非依存なポリシ記述インター フェース • アプリケーションの要求に応じたフロータイプ (L4プロトコル)選択 • セッションマネージメント • セッションリカバリー • ネットワーク層に対する要求通知 – アプリケーション独自の表現を吸収、共通の表現 に生計 MANET Issue • Hierarchical MANET – – – – • 近隣ノードでグループを形成(Not Zone) グループ内はProactiveでManagement グループ間はグループIDを基に、ReactiveでRouting DR Selection Layer 1/Layer 2 Aware MANET – RSSI等のL1 Information/L2 Informationに基づいた経路制御 – 下層情報を経路制御メッセージを用いてネットワーク内に配信 • MANEMO – MANET – NEMO融合技術 – シナリオ • NEMO - MANET並列環境 – NEMOトンネルはMANETインターフェースとは別のインターフェース上 – MANETを用いるかNEMOを用いるかはポリシ経路制御 • MANET Assisted NEMO – MANETを経由してインターネット接続、その上でNEMOトンネルをはる • Global6 – 経路制御プロトコルの拡張アプローチの実装 Hierarchical MANET • 背景 – 広大なエリアを単一のMANETで構成することの非現実性 • 従来のアプローチ – ノードは自身を中心にホップ特定ホップまでの経路(ゾーン)を確保 – ゾーン内の経路はproactive, ゾーン外の経路はreactiveの経路制御 で管理 • 従来手法の問題点 – メッセージングオーバーヘッドが高い • アプローチ – MANETノードのグループ化 – グループ内経路はproactive, グループ間経路はreactive HMANET概要図 グループ間経路検索は グループIDを基に reactive型経路検索 同一グループ内は proactive型で管理 代表ノード選択 • Main addressの大きいノードが代表ノード (DR) • 新しく参加したノードのmain addressがDRの main addressより大きかったとしてもリプレー スは行われない • BDRも必要かもしれない グループ管理 • グループ参加 – – 代表ノードマルチキャストアドレスにグループ情報要求メッセージを送信(グループを超えて転送さ れない) 各グループ代表ノードは送信元ノードに対し、グループ情報応答メッセージを送信 • – – – • 送信元ノードはタイマー期間中に受け取った応答メッセージ中からノード数がMAXグループノード 数に達しておらず、かつグループノード数が最少のグループに参加要求メッセージを送信 グループ代表ノードは現在のグループノード数/MAXグループノード数を比較し、余裕があれば参 加許可メッセージを送信、それ以外の場合は参加拒否メッセージを送信 ノードは参加することができるグループを発見できなかった場合、グループ形成手順に移行 グループ形成 – – – – • メッセージの中身: グループID、MAXグループノード数、現在のグループノード数 グループIDをランダム生成 グループホップリミットまでグループ形成通知をフラッディング タイマーで設定された期間反応がなければグループIDを使用 グループIDが重複していれば手順1に戻る グループ破壊 – – – 通信中に同一グループIDを検出した際に動作する機能 グループに所属するノード数が少ないグループが解散 解散したグループのノードはグループ参加手順から行う Neighbor管理 • HELLOメッセージ中にはグループIDを埋め込む • 同一グループ内のneighborへのリンクはグループ 内にフラッディング • 隣接グループIDとneighborのmain addressをDR に送信 • DRはグループ内に隣接グループIDとneighbor main address-グループ内ノード間リンクをグループ 内にフラッディング • 隣接グループ管理はneighborステータスの変更とと もに更新 グループ間経路検索 • ノードは自身の経路表を参照し、あて先アド レスを発見できなければグループ間検索手 順(proactive)に移行 • グループ間経路は通過グループIDを保存し ながらグループ間をring search – 隣接グループへの経路要求は、隣接グループ neighborのmain addressあてに行うことで実効 • 経路要求のループの発生を検知すると要求 の転送は行われない
© Copyright 2024 ExpyDoc
