透過型アドホックネットワーク構築ミドルウェア ATMOS
藤 田祥†1

江 崎浩†1

MANET は戦場や被災地にネットワークを構築する技術として注目されてきたが，日常的に MANETを利用するためには解決しなければならない課題が多い．特に，従来のネットワーク環境向けに作られたソフトウェアを MANET 環境では十分に利用することができず，また単一のネットワーク処理ロジックしかサポートしないソフトウェアでは異なる様々な MANET 環境に適応することができな
い．そこで我々はまずインターネットアーキテクチャのリンク層とネットワーク層にリンク補完層を導入し，上位層には従来のネットワークと同じリンク性質を見せながら MANET 環境の不完全なリンクを利用する手法を提案した．次にリンク補完層の処理をミドルウェアとしてユーザ空間に実装し，アプリケーションの通信パターンなどに応じてネットワーク処理のロジックを変更，拡張を可能にした．ミドルウェア上に IETF で仕様策定中のプロトコルである DYMO と SMF を実装し，従来のネットワーク向けに設計されたアプリケーションの mDNS が実際に MANET 環境上でそのまま利用できることを確認した．

ATMOS: A middleware for Transparent MObile ad-hoc networking Systems
Sho FUJITA†1 and Hiroshi ESAKI†1Although MANET has been promising for constructing networks for battleﬁelds and places
struck by disaster, it is not regarded as being for daily use at all. We address two barriers
that prevent MANET from being used for daily use. The ﬁrst barrier is that MANET is notdesigned for being compatible with softwares that are developed for traditional networks. And
the second barrier is that softwares for MANET environments must be extensible to support
various situations. We introduce link complement layer between link layer and network layer
in order to hide complexities of links in MANET environments. Then, we design and implement a middleware controlling the link complement layer in user space in order to allow users
to dynamically change the network conﬁguration. We implement DYMO and SMF on the
middleware, and then demonstrate that mDNS can work in a MANET environment without
any modiﬁcation.

1. は じ め に

我々は，MANET の普及を妨げているの要因として，まず従来のネットワーク環境向けに作られたソフ

これまで Mobile Ad-hoc Network（以下，MANET）

トウェアは MANET 環境のメリットを十分に利用では戦場や被災地など従来のネットワークインフラが存きないことを取り上げる．特に，自動設定やサービス在しない状況でもネットワークを構築できる技術とし発見などの根本となるアプリケーションが十分に利用て注目を集めてきた．しかし，一度ネットワークインできないことが問題となる．次に，MANET 環境ではフラを失ってしまうとソフトウェアを新たに流通させインターネットアーキテクチャの各層の依存性が高いるのが難しいので，MANET を非常時に機能させるたため，有効なネットワーク処理ロジックがアプリケーめには普段から利用環境を整えておく必要がある．まションの通信パターンやノードの移動パターン依存した，MANET では利用できるリンク技術の制約が少なていることを取り上げる．

く，移動端末をネットワークに含めることもマルチホッ

本研究の貢献は，リンク補完層を導入し MANETプ通信よって広い地域をカバーできるので，MANET環境で従来のネットワーク環境向けに作られた膨大なは日常生活にも有用な費用効果の高いネットワークにソフトウェア資産を利用出来るようにしたことと，リなりうる3) ．以上の理由から本研究では MANET をンク補完層を制御するミドルウェア ATMOS を様々日常的な用途へ普及させることを目的とする．

なプラットフォームに実装しことを同時に達成したことである．

†1 東京大学 情報理工学系研究科

本 論 文 の 構 成 は 以 下 の 通 り で あ る ．２ 節 で はMANET の性質とその普及を妨げている要因につい

ンク層技術が３つの仮定を満たしている限り，ネットて述べる．３節で MANET 環境のリンクを使いやす

ワーク層のソフトウェアはそれを従来の有線リンクをく抽象化するリンク補完アーキテクチャについて述べ等価に扱うことが出来た．IEEE802.11 の BSS モー

る．４節では拡張性の高いアドホックネットワーク向ドが爆発的に普及した背景にこの後方互換性があった

けミドルウェアである ATMOS について述べる．５節

ことは間違いない．しかし，一方でリンク層に３つので評価を行い，６節で関連研究について述べる．最後

仮定を押し付ける限り無線メディアの持つ可能性を最に７節で本論文をまとめ，今後の課題について述べる．

大限に引き出す事は出来ない．

MANET は３つの性質を仮定していないため，リン

2. MANET 普及への課題

ク層は制約が減り設計の自由度は増える． 図 2 はノー

MANET は戦場や被災地でのネットワーク構築な

ド配置は図 1 の AP を他ノードと同じ機能を持つノーど特殊な利用は見込まれてはいるが，これまで日常的ド０に置き換え，リンク層に IEEE802.11 IBSS モーな利用については全く普及が進んでいない．本節では，ドを使ったネットワークのリンク使用状況である．各

まず MANET の性質について述べ，次に MANET のノードは自由に他ノードとリンクを形成することがで日常的な利用を妨げている要因について考察する．

きるので，図 1 のように全てのトラヒックが単一ノードに集中することがなく通信可能範囲も広くなってい

2.1 MANET
従来のネットワークは，双方向かつ推移的かつ安定4)る．しかし一方で，片方向リンクの検出やマルチホッなリンク層を仮定して構築されてきた ．つまり，ノープ通信，そしてリンク状態のモニタなど IEEE802.11

ド１が２のフレームを受信出来るならばノード２も１BSS モードでは必要なかった複雑な処理を各ノードがのフレームを受信出来（双方向），ノード１と２が通こなさなければならない．

信可能でノード２と３が通信可能ならばノード１と３2.2 普及への課題は通信可能であり（推移的），ノード間の接続性はほ被災地や戦場などのシナリオではそもそも従来のとんど変わらない（安定）. これら３つの仮定は，有ネットワークが利用できないので MANET を利用し線リンクでは自然であり容易に成り立つが，無線リンていたが，日常的には従来のネットワークが同時に存クでは一般に難しく成り立つとしても高コストであ在していることが多い．よって日常的に MANET をる． 図 1 は IEEE802.11 BSS モードを使ったネット利用する機会を増やすためには，従来のネットワークワークのリンク利用状況を表している．IEEE802.11によるリンクは失わずにそのまま活用しながらこのBSS モードでは，アクセスポイント（以下，AP）と新しく利用可能になったリンクを有効活用しなければ呼ばれる特別なノードとアソシエーション処理を完了ならない．また，アプリケーションや移動パターンをしたノードだけがそのネットワークに参加し，参加しある程度仮定できる特殊な用途では適切なネットワーたノード間は全て AP を経由して通信する．参加ノーク処理ロジックをあらかじめ決定しておくことができドは AP を中心としたスター型のリンクを構成するのるが，仮定できない状況では単一のネットワーク処理で上記の３つの仮定が満たされる．一方で，利用可能ロジックを提供するのではなく状況に合わせて複数かなリンクは限定されて AP に全ての負荷が集中するのら選択したり拡張したりできることが望ましい．しかで AP が通信スループットのボトルネックになったり，し，現在の MANET にはこの両面で課題を抱えてい通信範囲が狭くなったりしてしまう．実際に，図 1 のる．具体的な課題はそれぞれ以下の通りである．

ノード６は AP の通信可能範囲外にいるためにネットワークに参加出来ず通信可能範囲にいるノード２と３とも通信出来ない．確かに，無線メディアを使ったリAP

125• MANET によって増えたリンク活用することが難しい• 通信ロジックを変更させることが困難
1402

36

543

利用するリンク
利用しないリンク

図 1 IEEE802.11 BSS モードのリンク利用状況

6

利用するリンク
利用しないリンク

図 2 IEEE802.11 IBSS モードのリンク利用状況

2.2.1 従来のアプリケーションへの互換性

仮想リンク

MANET によって新しく利用可能になったリンクを既存のアプリケーションが活用することは難しい．

4

従来のネットワークではリンク層によって到達性が提2供される範囲（以下，リンクローカルスコープ）がサブネットワーク全体をカバーしていた．しかしリンク
ローカルスコープは，一般にマルチホップ通信で通信範囲を広げる MANET 全体の中ではごく一部に過ぎ531

外部ネットワーク１
EC
Dず，MANET 全体の対象とした通信手段としては不B十分である．MANET のマルチキャスト制御手法が実リンク議論されている11) がその対象となるマルチキャスト

A

外部
ネットワーク２

IP アドレスはサイトローカルスコープであり，やはりリンクローカルスコープと MANET 全体は明確に区別されている．よって，従来のネットワークで使われ図3てきた DHCP などの自動設定と mDNS などのサー実リンクと仮想リンク

ビス発見はリンクローカルスコープを利用するため，特にマルチホップを許可することで新しく利用可能にアプリケーション層なったリンクには全く機能しない．自動設定やサービ

トランスポート層

ス発見は通信を始める前に必要な根本的な機能であり，これらがないことが MANET を使い難いものにしている．
確かに MANET 独自の自動設定機構とサービス

PIF1
リンク層

発見機構については多くの研究が存在する15)7) が，ネットワーク層

VIF
リンク補完層
PIF2

図4

PIF
VIF

物理インタフェース
仮想インタフェース
経路表

仮想リンク内の経路表

リンク補完層アーキテクチャ

MANET のために全く別のソフトウェアを準備しなければいけないことは日常的な利用への普及を妨げる層の技術である MPLS13) のものと似ている．仮想リ大きな要因の１つになっていると考えている．

ンクへ入るパケットにはリンク補完ヘッダが挿入され，2.2.2 ネットワーク処理ロジックの拡張性

仮想リンク内のルーティングはネットワーク層の経路単一のネットワーク処理ロジックでは想定される様々表ではなくリンク補完層の経路表が利用されるからでな MANET 環境をカバーすることが難しい．実際に，アプリケーションやノードの移動モデルが適切なルー
2)

ティング手法は大きく異なることが分かっている ．

3. リンク補完層ある．
図 3 は仮想リンクの具体例であり，IP アドレス A〜E は物理インターフェースに割り当てられたものとし
IP アドレス 1〜5 は仮想インターフェースに割り当てられたものとする．便宜上物理インターフェースの IP

我々は，従来ネットワークのために作られたソフトアドレスを使ってノードを識別するものとする．また，ウェア資産を生かしつつ無線リンクの持つ可能性を最物理インターフェースを通してノード C は外部ネット大限に活用するために，ネットワーク層とリンク層のワーク１へ接続され，ノード A は外部ネットワーク間に新たにリンク補完層を導入する．リンク補完層は，２へ接続されている．リンク補完処理によって実リン双方向かつ推移的かつ安定的であるという３つの仮定

クの複雑な構成が隠されるので，実リンク上ではノーを必ずしも満たさない不完全なリンク層を補完しネッ

ド C と E は最低でも３ホップは離れているが仮想リトワーク層の間に完全なリンク層を提供する． リンク

ンク上では隣接しているように見える．仮想リンクは補完層は実リンクの上に仮想リンクを構築し，仮想リ３つの仮定を満たす完全なリンクであり，ノード A とンクに接続するネットワークの仮想インターフェース

C は仮想リンクを経由してユニキャストはもちろんリを提供する．リンク補完層のアーキテクチャは図 4 のンクローカルマルチキャストで通信できる．以下ではようになっている．各ノードはネットワーク層の経路リンク補完層を内で行われる具体的な処理を送信処理表に加えて，リンク補完層には仮想リンク１つあたりと受信処理に分けて述べる．ただし各ノードのリンクに１つ経路表を持つ．このアーキテクチャは同じ 2.5

補完層の経路表を，宛先 IP アドレスが仮想リンク外にある場合と自分自身のアドレスの場合は，パケットを上位のネットワーク層に渡すように設定している．

3.1 送 信 処 理

んだまま再び物理インターフェースから送信される．

4. ATMOS ミドルウェア

ネットワーク以上の層から送信されるパケットはま

MANET を様々な用途に利用することを考えるとずネットワーク層の経路表に基づいて処理される．も単一のネットワーク処理ロジックを提供するのではなし，次ホップが仮想リンク上のノードになった場合はく，複数のネットワーク処理ロジックから選択したりパケットはリンク補完層に渡され，MANET 環境に既存のネットワークロジックを拡張したりできること必要な処理が施される．最後にパケットはリンク補完が望ましい．そこで，我々はリンク補完層をカーネル層を挿入された後リンク層に渡される．

空はなくユーザ空間にミドルウェアとして実装し A

例としてノード B と C の間の通信を考える．ノー

Middleware for Transparent MObile networking(以ド B は物理インターフェースに割り当てられた B と下，ATMOS) と名付けた．ATMOS はアプリケーショ

仮想インターフェースに割り当てられた 2 の２つのンに透過的にネットワーク処理のロジックを変更する

IP アドレスを持つ．同じくノード C も C と 3 の２つことができる．の IP アドレスを持ち，実リンクでも仮想リンクでもATMOS の機能はリンク補完層のどの部分を扱うか

ノード B と隣接している．ノード B から IP アドレスで３つに分けられる．

C に向かってパケットを送信する場合は当然次ホップ

ネットワーク層インターフェース リ ン ク 補 完 層 との IP アドレスは C で物理インターフェースを通る．

ネットワーク層の間を繋ぐ部分 (図 4 の VIF)

一方 IP アドレス 3 に向かって送信する場合には，次リンク層インターフェース リンク補完層とリンク層ホップの IP アドレスは 3 になり仮想インターフェースを通ってリンク補完層に渡されることになる．

3.2 受 信 処 理を繋ぐ部分 (図 4 の PIF2)
内部インターフェース リンク補完層の内部を拡張する部分

リンク層に取ってが受信したパケットを直接ネット

以下でそれぞれについて詳しく述べる．

ワーク層に渡すべきか，リンク補完層に渡すべきかは

4.1 ネットワーク層インターフェース自明である．パケットにリンク補完層が含まれている

リンク補完はユーザ空間のデーモンプロセス（以場合のみリンク補完層に渡せばよい．リンク補完層に下，ATMOS デーモン）によって処理されるため，仮渡されたパケットはリンク補完層の経路表に基づいて想リンクに入ってリンク補完の対象となるパケットを処理される．パケットの宛先が自分自身の IP アドレス

カーネルのネットワーク層からユーザ空間へ渡す機能だった場合や次ホップが実リンク側に存在した場合は，と仮想リンクから出て通常のネットワーク処理に戻る

パケットはリンク補完ヘッダを取り除かれた後ネットパケットをユーザ空間からカーネルのネットワーク層ワーク層に渡される．次ホップが仮想リンク内だったへ渡す機能が必要となる．これらをネットワーク層イ場合は，MANET 環境に必要な処理をしてから再びンターフェースと呼ぶ．

物理インターフェースから送信される．
例としてノード C が仮想リンク側から宛先 IP アド

ATMOS デーモンは TUN/TAP デバイス1) を使ってネットワーク層インターフェースを実現している．

レス C のパケットを受信した場合を考える．パケット

TUN/TAP デバイスは様々なプラットフォームで利用はリンク補完ヘッダを含むのでリンク補完層に渡され可能なデバイスドライバであり，ネットワークの仮想る．リンク補完層はリンク補完ヘッダを剥がした後パインターフェースと対応するファイル記述子の組を提ケットをネットワーク層に渡し，最終的にアプリケー供する．仮想インターフェースから送信されたパケッション層に届けられる．アプリケーションからみると，

トはファイル記述子からバイト列として読み込むことパケットが仮想リンク側から届いた場合も実リンク側ができ，逆にファイル記述子に書き込まれたバイト列から届いた場合も，受けとるデータは全く同じようにはパケットとして仮想インターフェースに到着させる扱うことができる．

ことができる．

また別の例としてノード B がノード A から仮想リ

4.2 リンク層インターフェース

ンクを通って宛先 IP アドレス 1 のパケットを受信す

ユーザ空間でパケットにリンク補完ヘッダを挿入しると，やはりパケットはリンク補完層に渡される．リた後には実際にそれらを物理インターフェースから送ンク補完層の経路表によって次ホップの IP アドレス信する機能が必要である．これらをリンク層インターが１に決まるので，パケットはリンク補完ヘッダを含フェースと呼ぶ．

ヘッダ
ヘッダ
UDPヘッダATMOS特有ヘッダ
Ethernet
IPv6

PacketBB準拠

ユーザ

リンク補完ヘッダ

仮想ネットワーク

sock

Dymo
PacketBB
BridgePacketBB
LinkMonitor

sock

MsgClassifier
PacketBB
Extract

カプセル化されたIPパケット

PacketBB
Encap

LookupRoute

Flood

ExtractAddress

図 5 リンク補完ヘッダの実装

ArpQuerier

Strip0x0806 2

ArpResponder

0x0800Classifier

ATMOS のリンク補完ヘッダは図 5 のように ネットワーク層に IPv6，トランスポート層に UDP，データtap

カーネル

0x0806 1

物理ネットワーク

tap部分に TLV 形式を使っていて拡張性に優れた Pack-etBB フォーマット5) を用いている．IPv6 についてはリンクローカルに関する機能のみを使う．つまり，ユ

図6

設定サンプル

ニキャストアドレスとマルチキャストアドレスはそれ
ぞれ fe80::/64 と ﬀ02::/112 に含まれておりホップリミットも 1 であるので，このパケットはオペレーティングシステムの機能では中継されない．

4.3 内部インターフェース
MANET 環境でルーティングやフラッディングを効に対応する全ての物理インターフェースから IPv6リンクローカルマルチキャストする．

• unicastMessage(message, neighbor) は message
をソケットアドレス neighbor に向けてユニキャストする関数である．

率的に行うためのロジックを ATMOS 内に実装する

実際にこれらの基本関数を使ってユニキャストのた必要がある．ATMOS を拡張しロジックを実装するための DYMO とマルチキャストのための SMF を実装

めの機能を内部インターフェースと呼ぶ．

した．

ATMOS では MANET 環境の変化に応じてインタ4.3.1 ユニキャストサポート

ラクティブにパラメータやアルゴリズムを書き換えユニキャストルーティングプロトコルとして DY-るためにスクリプト言語の Python で実装した．まnamice MANET On-demand routing8) （以 下 ，た ATMOS では Click10) のように細かな機能単位にDYMO）を ATMOS 上に実装した．DYMO は IETFモジュール化されており，それらのモジュールの接続の MANET ワーキンググループで仕様策定されてい関係を設定ファイルに記述することにより単純なパラる MANET 用のユニキャストルーティングプロトコル

メータ変更だけでなくネットワーク処理のロジックそであり，Dynamic Source Routing9) や Ad Hoc Onのものを変更することができる． 今回用いた設定はDemand Distance Vector12) と同様，必要になるま図 6 である．

で経路を確立しないリアクティブ型に分類される．一

特に近隣探索や経路探索を行うモジュールにはメッ

般にリアクティブ型のプロトコルは，経路が確立されセージの送受信を行う機能が必要である．ATMOS

るまでパケットをプロトコルスタック内にバッファす

メッセージの送受信に関しては以下の基本関数を提供る必要があるため，プラットフォーム依存の方法で実している．

装されることが多いが，ATMOS ミドルウェアを使っ• handleMessage(message, neighbor) はリンク補て実装した DYMO は ATMOS が動作する全てのプ

完ヘッダを含むメッセージを受信したときに AT-ラットフォームでそのまま動作する．

MOS によって呼び出されるコールバック関数で4.3.2 マルチキャストサポートある．message は受信したパケット全体のバイト

Simpliﬁed Multicast Flooding11) （以下，SMF）列であり，neighbor はリンク補完ヘッダを含むは同じく IETF で仕様策定されているマルチキャストパケットを送信したノードのソケットアドレスでプロトコルである．SMF は厳密にマルチキャストツある．

リーを管理するプロトコルではなく，フラッディング• multicastMessage(message) は message を全ての近隣ノードに送信する関数である．全ての近隣ノードに送信するために，仮想インターフェースと冗長なパケット抑制を組み合わせた仕組みである．

CPU

Pentium M 1700MHz
2G
NIC
EEPRO/1000
OSlinux 2.6.22
表 1 実験マシンの構成

1

メモリ

32A

5. 評

価C

D
B

ATMOS を使って，パケット処理のオーバヘッドについての前提実験と後方互換性についての確認実験をE行った．２つの実験のどちらについても参加ノードはF
図7mDNS 実験構成

全て ATMOS を図 6 の設定で利用している．

5.1 前 提 実 験向けの技術を適用し，ネットワークの通信範囲を広げまず，ATMOS のパケット処理オーバヘッドを測定ることが確認できた．

するための前提実験を行った．実験環境には表 1 の構成のコンピュータを２台を UTP で接続したものを用

6. 関 連 研 究

いた． 仮想リンク越しに netperf で TCP のスルーIEEE802.11s6) は IEEE802.11 系プロトコルのメップットを計測した．10 回計測して平均が 8.90Mbps，シュネットワーク拡張である．上位層から見るとマルチ標準偏差が 0.381Mbps でほぼ安定していた．全てのホップ通信は意識することはなく，その点で ATMOS

試行で ATMOS は CPU をほとんど食いつぶしておと類似している．しかし，IEEE802.11s プロトコルがり，Python インタプリタの実行速度がボトルネック

そのベースとなるリンク層技術を IEEE802.11 系プロになっていると考えられる．計測された ATMOS のトコルに限っているのに対し，ATMOS は様々なリンスループットは IEEE802.11a や 11g の無線リンクのク層技術をサポートできる点で異なっている．また，実効帯域をサポートしきれていない．しかし，無線リIEEE802.11 プロトコルは仕様策定プロセスが比較的ンクをマルチホップ使った通信のスループットでは１閉鎖的であり IEEE802.11 はデバイスドライバの一ホップで達成されるスループットの 1/3 から 1/4 程部として実装されバイナリで配布されることも多い．

度になるのが一般的であり，MANET 環境のマルチATMOS のように処理を自由に再設定出来ることは出

ホップパスを従来ネットワーク向けのアプリケーショ

来ない．

ンで利用する目的には十分であった．今後，より貧弱protolib14) はネットワークプロトコルやアプリケー

な CPU を持つアクセスポイントへの対応や高速なションをネットワークシミュレータを含む様々なプラッ

IEEE802.11n リンクへの対応を考えた場合，パケッ

トフォーム上に実装するための C++クラスライブラ

ト転送部分のコードのみ C で書き直すことを検討しリである．OLSR や SMF など様々な MANET 環境ている．

向けのプロトコルが protolib を利用して実装されて5.2 mDNS 実験いる．protolib は現時点で WIN32 プラットフォーム

マルチキャストについて後方互換性を実証するためと NS2 や OPNET などのシミュレーションプラットに図 7 の構成で mDNS を使った．物理インターフェー

フォームをサポートしており移植性の面では非常に優スと仮想インターフェースに割り当てたアドレスの関れている．しかし，既存のソフトウェアとの下方互換係は図 4 と同様である． ノード A〜C は ATMOS を性やネットワーク処理アルゴリズムの動的な変更などサポートし仮想リンクに接続しているが，ノード D〜については考えられていない．

F は接続していない．
ノード B が物理インターフェースから mDNS クエ

7. お わ り にリを送信するとノード A，D，E，F からレスポンス

本論文で我々はリンク補完層を導入し従来のネッを得た．一方，ノード B が仮想インターフェースかトワーク向けに開発されたソフトウェアを使って，

ら mDNS クエリを送信すると，ATMOS の SMF 機

MANET 環境を有効活用出来るようにした．また，リ構により仮想リンク全体にクエリが配布され，ノードンク補完層上の処理ロジックを自由に組み立てるためA, C からレスポンスを得た．このように ATMOS はのミドルウェアとして ATMOS を実装した．さらに実

従来のネットワーク接続性を壊さずに MANET 環境

際に ATMOS 上に DYMO と SMF を実装し，mDNSなどの従来ネットワーク向けに作られたアプリケーションをそのまま利用出来る事を確認した．
今後の課題として，ほげー．

謝辞

本論文を執筆するにあたり多くの方のお世話になった．特に，度重なる議論に付き合って頂いた研究室同僚の吉田 薫氏と IIJ 技術研究所の宇夫 陽次朗氏，島慶一氏に感謝したい．

参 考 文 献1) VTun Project. http://vtun.sourceforge.net/.
2) Josh Broth, David A. Maltz, David B. Johnson, Yih-Chun Hu, and Jorjeta Jetcheva. A
Performance Comparison of Multi-Hop Wireless Ad Hoc NeWork Routing Protocols. In International Conference on Mobile Computingand Networking, 1998.
3) Raﬀaele Bruno, Marco Conti, Enrico Gregori,and National Research Council. Mesh Networks: Commodity Multihop Ad Hoc Network.
IEEE Communications Magazine, 2005.
4) I. Chakeres, J. Macker, and T. Clausen. Mobile Ad hoc Network Architecture. Work inProgress, November 2007. draft-ietf-autoconfmanetarch-07.
5) T.Clausen, C.Dearlove, J.Dean, and C.Adjih.
Generalized MANET Packet/Message Format,
draft-ietf-manet-packetbb-04. IETF Internet
Draft(ID). ”Work in Progress”, March 2008.
6) W. Steven Conner, Jan Kruys, Joseph Kim,
and JuanCarlos Zuniga. 802.11s: WLAN MeshNetworking. Technical report, The IEEE 802
LAN/MAN Standards Committee, 2006.
7) S. Helal, N. Desai, V. Verma, and Choonhwa
Lee. Konark - a service discovery and delivery protocol for ad-hoc networks. In WirelessCommunications and Networking, March 2003.
8) I. Chakeres and C. Perkins. Dynamic MANET
On-demand (DYMO) Routing.
Work inProgress, February 2008.
draft-ietf-manetdymo-12.
9) D.Johnson, Y.Hu, and D.Maltz. . The Dynamic Source Routing Protocol (DSR) for Mobile Ad Hoc Networks for IPv4, February 2007.
10) Eddie Kohler, Robert Morris, Benjie Chen,John Jannotti, and M. Frans Kaashoek. The
Click modular router. ACM Transactions on
Computer Systems, 18(3), August 2000.
11) J.Macker and SMFDesign Team. Simplifeid
Multicast Forwarding for MANET. Work in
Progress, Februrary 2008. draft-ietf-manet-smf-05.
12) C. Perkins, E. Belding-Royer, and S. Das.
Ad hoc On-Demand Distance Vector (AODV)
Routing. Network Working Group RFC 3561,July 2003.
13) E.Rosen, A.Viswanathan, and R.Callon. Multiprotocol Label Switching Architecture. Network Working Group RFC 3031, January 2001.
14) Ian Taylor, Brian Adamson, Ian Downard,and Joe Macker. AgentJ: Enabling Java NS-2
Simulations for Large Scale Distributed Multimedia Applications. In Distributed Frameworksfor Multimedia Applications, 2006.
15) Ulas C. Kozat and Leandros Tassiulas. Network Layer Support for Service Discovery inMobile Ad Hoc Networks. In INFOCOM, volume3, pages 1965 – 1975, March 2003.