Mobile IPv6

2009 年度 修士論文

Mobile IPv6 マルチホーミングにおける

Home Agent の障害対策

提出日： 2010 年 2 月 5 日

指導：後藤滋樹教授

早稲田大学大学院 基幹理工学研究科 情報理工学専攻 学籍番号： 5108B077-6

田代 賢治

目次

1 序論 5

1.1 研究の背景 . . . 5

1.2 研究の目的 . . . 5

1.3 本論文の構成. . . 6

1.4 Mobile IPv6の主な用語 . . . 7

2 Mobile IPv6におけるマルチホーミング 8 2.1 Mobile IPv6の概要 . . . 8

2.2 Mobile IPv6の基本的な動作 . . . 8

2.3 マルチホーミング . . . 15

3 マルチホーミングにおける問題と従来の解決法 19 3.1 マルチホーミングにおける問題 . . . 19

3.1.1 Secondary HA発見までの所要時間. . . 19

3.1.2 HAダウンのタイミング . . . 19

3.2 既存の解決策. . . 20

4 本研究における提案および実験 25 4.1 本研究の提案. . . 25

4.2 実験による検討 . . . 26

4.2.1 実験1 (HAのダウン時に新しいCNが通信に参加しようとする場合) . . . 27

4.2.2 実験2 (HAのダウン時にCNがHAを経由してBRRを行おうとする場合) 28 4.3 実験の結果 . . . 28

4.3.1 実験1の結果 . . . 28

4.3.2 実験2の結果 . . . 29

5 まとめ 31 5.1 結論 . . . 31

目次

5.2 今後の課題 . . . 32

謝辞 33

参考文献 34

A 追加実験 35

図一覧

2.1 MNがHome Linkに接続しているときのCNとの通信 . . . 9

2.2 MNがForeign Linkに接続しているときの冗長経路を利用したCNとの通信 . . 10

2.3 MNがForeign Linkに接続しているときの直接経路を利用したCNとの通信 . . 10

2.4 MNがForeign LinkにてRouter Advertisementを受信. . . 11

2.5 MNによる動的HA探索とHAによる応答 . . . 11

2.6 MNのHAに対するBinding Update . . . 12

2.7 MNによるHoTIとCoTIの送信 . . . 13

2.8 CNによるHoTとCoTの送信 . . . 13

2.9 CNによるBinding情報更新要求(BRR) . . . 14

2.10 MNによるPrimary HAに対するBU . . . 16

2.11 Primary HAに対するBUの失敗 . . . 17

2.12 MNによるDHAADの送信 . . . 17

2.13 Secondary HAに対するBU . . . 18

3.1 RRPを行う直前のPrimary HAのダウンによるHoTI送信の失敗 . . . 20

3.2 Primary HAによるHoTI転送後のダウンによるHoT送信の失敗 . . . 21

3.3 MNとCNが直接通信中のPrimary HAのダウンによるBRR送信の失敗 . . . . 21

3.4 Primary HAのダウンからMNがダウンを検知するまでに要した時間 . . . 23

4.1 提案した解決法 . . . 26

4.2 MNが複数のHAに対してBUを行う方法 . . . 27

4.3 本研究におけるシミュレーション環境 . . . 28

4.4 新しいCNが通信に加わるまでに要した時間 . . . 29

4.5 通信中のCNがSecondary HAにBRRを実行するまでに要した時間. . . 30

A.1 HA同士が互いを監視しあう方法 . . . 35

A.2 新しいCNが通信に加わるまでに要した時間 . . . 36

A.3 通信中のCNがSecondary HAにBRRを実行するまでに要した時間. . . 36

表一覧

3.1 Primary HAのダウンからMNがダウンを検知するまでに要した時間 . . . 23

4.1 新しいCNが通信に加わるまでに要した時間 . . . 29

4.2 通信中のCNがSecondary HAにBRRを実行するまでに要した時間. . . 30

A.1 新しいCNが通信に加わるまでに要した時間 . . . 35

A.2 通信中のCNがSecondary HAにBRRを実行するまでに要した時間. . . 36

第 1 章 序論

1.1 研究の背景

最近の急速なインターネットの発達および電子機器の小型高性能化により、ノートパソコンや 携帯電話などを利用して通信機器を持ち運びながらインターネットを使えるようになり、いつで もどこでも利用できる、フレキシブルなインターネットが身近なものになっている。

その際に重要になるのが、通信機器が移動して接続しているネットワークが切り替わっても、

現在の位置(厳密には、どのネットワークに接続しているか)やそれに伴うIPアドレスの更新を 素早く把握および通知して、通信が途絶えないようにすることである。(以降、端末が移動して 接続しているネットワークを切り替えることを「端末が移動する」と表記する。)

このような移動端末における通信継続性を確保するための技術にMobile IPがある。IETFに おいては、2004年6月10日に、近年普及し始めているIPv6プロトコルに対応したMobile IPv6 という技術が、RFC3775として標準化された。この技術によって、IPv6を利用した端末が移 動しながらでも固定端末とさして変わらない通信性を確保できることになった。しかし、この時 点で標準化された内容は技術的には必要最低限のもので、現在も様々な形で改良が続けられてい る。

本研究では、既存の改良案の一部に改良の余地があると考えられる問題点があることを指摘 し、その問題点について改良を行い実験によって有効性を実証する。

1.2 研究の目的

インターネットにおいて端末が移動した場合には、その端末のIPアドレスは移動先のネット ワークに対応したアドレスに変更される。特に通信の最中に端末が移動した場合、通信相手の端 末に新しいアドレスを通知しないと、相手から送信したパケットが届かなくなってしまう。特に 注意が必要なのは、双方の端末が同時に移動した場合に、互いのアドレス変更の通知が互いの移

第 1 章 序論

動前のアドレス宛に送信されるため、アドレスの変更の通知が届かずに通信が途絶えてしまう可 能性がある。

Mobile IPv6では、この問題点を解決するため、「端末が移動しても、移動前のアドレスを用

いて通信を継続するシステム」が利用されている。その内容は、Home Agentが、移動端末の元 のアドレスおよび移動先のアドレスを把握して、通信の仲介を行うものである。しかし、この方

法ではHome Agentが同じネットワークを利用しているすべての移動端末の通信を中継するた

め、移動端末の数が増えるほどHome Agentの負担が増大し、さらにHome Agentに障害が発 生するとそのネットワークを利用しているすべての移動端末の通信に影響が出てしまうという問 題点が指摘されている。

その解決策として提案されたのが、Home Agentの複数化(マルチホーミング)である。これ は、文字通り複数のHome Agentを用いて負荷を分散させるとともに、一つのHome Agentに 障害が発生した場合に他のHome Agentがその役割を代行するものである。しかし、マルチホー ミングにおいては、各端末が通信に使用するHome Agentの選択、それぞれのHome Agentの 状態の確認および代行時の処理などにおいて問題点が指摘されており、一部の問題に対してはす でに改良案も多数存在している。本研究では、マルチホーミングにおけるいくつかの問題点に対 する既存の改良案を検討して、別の形でアプローチした改良案を提案する。

1.3 本論文の構成

本論文は以下の章により構成される。

第1章 序論

本研究の概要について述べる。

第2章 Mobile IPv6におけるマルチホーミング

Mobile IPv6およびマルチホーミングの基本的な概要、機能について述べる。

第3章 マルチホーミングにおける問題と従来の解決法

マルチホーミングにおいて本研究で取り上げた問題点と既存の解決策を述べる。

第4章 本研究における提案および実験

本研究で提案した解決策を述べ、実験を行う。

第5章 まとめ

本研究の研究結果の考察および今後の課題を述べる。

(付録) A 追加実験

本研究で追加として行った実験について述べる。

第 1 章 序論

1.4 Mobile IPv6 の主な用語

ここでは、本論文中で使用しているMobile IPv6に関する主な用語を挙げる。

• MN (Mobile Node) ネットワーク間を移動するノード。

• CN (Correspondent Node) MNの通信相手となるノード。(これも、移動端末であれば MNになる。)

• Home Link MNが通信開始時に接続しているネットワーク。

• Foreign Link MNの移動先のネットワーク。

• HA (Home Agent) ホームネットワーク上でMNの通信を中継するノード。Home Link から離れたMNに対して、CNから送信されたパケットを転送する。

• HoA (Home Address) MNに割り当てられる不変のIPアドレス。

• CoA (Care of Address) MNが移動先のネットワークで使用する一時的なアドレス。

• Binding HoAとCoAの対応を示す情報。

• BU (Binding Update) Binding の登録および更新。

• DHAAD (Dynamic Home Agent Address Discovery) MNがForeign Linkに移動した ときに行う、動的にHAを探索するAnycast通信。

• HoTI (Home Test Init) MNが行う、HAを経由する冗長経路を利用したCNに対する 経路認証要求通信。

• CoTI (Care of Test Init) MNが行う、CoAによる直接経路を利用したCNに対する経 路認証要求通信。

• HoT (Home Test) CNが行う、HAを経由する冗長経路を利用したHoTIに対する経路 認証応答通信。

• CoT (Care of Test) CNが行う、CoAによる直接経路を利用したCoTIに対する経路認 証応答通信。

• BRR (Binding Refresh Request) CNが行う、MNに対するBinding情報の更新要求通 信。

• RRP (Return Routability Procedure) MN、CN間で行う経路認証処理。

第 2 章

Mobile IPv6 におけるマルチホーミング

2.1 Mobile IPv6 の概要

Mobile IPv6では、移動端末が他の端末と通信を行う際にHome Agentと呼ばれるノードが互 いの初期状態におけるIPアドレス(Home Adressと呼ばれる、通信開始から終了まで維持され るアドレス)および移動後のアドレス(Care of Addressと呼ばれる、ネットワークの移動に伴い 変更される一時的なアドレス)を記憶する。互いの通信端末には固定されたHome Address宛に 通信を行わせ、通信を中継するHome Agentがこのアドレスを移動端末が実際に使用している

Care of Addressに変換して送信先の端末に送る。これにより、互いの通信端末が相手の移動先

のアドレスを知らなくても、Home Agentが移動先のアドレスにパケットを送信してくれるた め、端末が移動しても通信を維持できる。

2.2 Mobile IPv6 の基本的な動作

• MNがHome Linkに接続している場合

Home Linkでは、MNは自分のHoAを保持し、CNとの通信にHoAを使用する。この 状態ではMobile IPv6による特別な処理はされず、通常のIPv6ノードとしてHAを経由 せずにCNと通信を行う。

• MNがForeign Linkに接続している場合

MNがHome LinkからForeign Linkに移動すると、IPv6アドレス自動取得(Router Ad- vertisement)によってForeign Link上でCoAを割り当てられる。この時には、他のノー ドとの通信にHoAを使用する。MNから送信されるパケットは、MNとHAとの間に作 られたIPv6 over IPv6トンネルを使って、いったんホームネットワークに送られる。それ をHAがCNに転送することで、パケットがホームネットワークから発信されたように見 せる。同様に、CNからHoA宛に送られたパケットもHAが代理受信し、IPv6 over IPv6

第 2 章 MOBILE IPV6におけるマルチホーミング

図 2.1: MNがHome Linkに接続しているときのCNとの通信

トンネルを利用してForeign Linkに接続しているMNに届けられる。そしてその後に、

HAからMNとCNを直接結ぶ最適経路が通知され、IPv6 over IPv6トンネルを利用し直 接通信するようになる。

• MNがForeign Linkに移動する際の処理

MNがネットワークを移動した際に行われる一連の処理は、以下の通りである。

1. CoAの自動取得

MNがRouter AdvertisementによってCoAを取得する。HoAとプレフィックス(IPv6ア ドレスの前半部に位置する、現在接続しているネットワークを表す64ビットの識別子)が 異なっていればForeign Linkに移動したと認識する。

2. HAの動的探索(DHAAD)

もともとMNがHome Linkに接続している場合は、移動前からHAのアドレスを認識で きるが、MNがForeign Linkに移動した場合には、Home Link上のHAを動的に探索す る必要がある。MNがHAに割り当てられているエニーキャストアドレス宛に動的HA探 索要求を送り、HAが応答メッセージを送ることで、MNはHAの位置(Home Linkのネッ トワークアドレス)を認識する。

3. HAに対するBinding Update

Binding UpdateメッセージにはCoAとHoAが格納されており、メッセージを受信した HAは、その中に含まれるCoAの情報をもとにMNとの間に作成したトンネルの終端ア

第 2 章 MOBILE IPV6におけるマルチホーミング

図 2.2: MNがForeign Linkに接続しているときの冗長経路を利用したCNとの通信

図 2.3: MNがForeign Linkに接続しているときの直接経路を利用したCNとの通信

第 2 章 MOBILE IPV6におけるマルチホーミング

図 2.4: MNがForeign LinkにてRouter Advertisementを受信

図 2.5: MNによる動的HA探索とHAによる応答

第 2 章 MOBILE IPV6におけるマルチホーミング

ドレスを更新する。また、MNは自分が接続しているネットワークが変わるたびに、新し いBinding情報をHAに登録する必要がある。HAは常に最新のCoAを把握しているた め、CNがMNのホームアドレスに送ったパケットを適切に現在のMNの位置に配送する ことができる。また、HAはBinding Updateに対し、Binding Acknowledgment (Bind- ingを確認したことをMNに通知する応答メッセージ)をMNへ返送する。

図 2.6: MNのHAに対するBinding Update

4. CNに対する認証(RRP)

MNがCNにBinding Updateを行う際に、不正なMNによる悪意のあるBUを防ぐため、

CNに対して認証を行う必要がある。

まずMNはHAに対するBinding Updateを行った後に、冗長経路(HA経由)と直接経路 (CoAを利用)を用いてCN宛に認証要求パケットを送信する。冗長経路を通るパケットを HoTI (Host Test Init)、直接経路のそれをCoTI (Care of Test Init)と言う。これに対 しCNは、それぞれの経路でHoT、CoTという応答パケットを返送する。なお、これら 一連のやり取りにはnonceと呼ばれる一度限りの計算された値が保持され、これらを比較 することで認証完了とする。これら一連の認証に要する処理をReturn Routability Proce- dure (RRP)と言う。

5. CNに対するBinding Update

RRPを行うことにより、冗長経路、直接経路の二つの経路における通信が確立できたこと になる。確立した直接経路においてBinding Updateを行うことにより、CNとの直接通 信が可能となり、互いに最適な経路を利用した通信が実現できる。また、CNとMNの間

第 2 章 MOBILE IPV6におけるマルチホーミング

図 2.7: MNによるHoTIとCoTIの送信

図 2.8: CNによるHoTとCoTの送信

第 2 章 MOBILE IPV6におけるマルチホーミング

にIPv6 over IPv6トンネルを設けているため、アプリケーション層から見るとMNの移動 が隠匿されており、同一IPを利用した通信が継続できる。ただし、直接通信を行うために は、CNもMobile IPv6に対応している必要がある。

• MNがForeign Linkに移動した後の処理

MNが外部ネットワークに移動して通信を再開した後に、次のような処理をMNからHA、 CNそれぞれに対して継続的に行う必要がある。

1. HAに対する処理

●HAに対するBinding Update

Binding情報にはlifetimeというものが存在する。lifetimeによって設定された時間が過ぎ るとBinding情報を自ら削除しなければならないという規定になっている。そのため、life- timeが0になる前にMNからHAにBinding Updateを行う必要がある。

2. CNに対する処理

●CNによるBinding情報更新要求(BRR)

Bindingのlifetimeが0になると、CNとMNの通信はHome Linkを経由した冗長なもの になる。そこで、CNは冗長経路による通信とならないように、一定間隔ごとにBinding 情報を更新するよう要求するパケットを送信する。このパケットは、CNとMNの間に直 接経路が確立していてもHome Linkを経由した冗長経路を利用する。

図 2.9: CNによるBinding情報更新要求(BRR)

●CNに対する認証(RRP)

第 2 章 MOBILE IPV6におけるマルチホーミング MNはBRRを受信すると、RRPの処理を始める。この処理はMNがForeign Linkに移 動してきたときのRRPの処理と同じである。

●CNに対するBinding Update

これもForeign Linkに移動してきたときの処理と同じである。

2.3 マルチホーミング

• マルチホーミングの概要

Home Linkでは、MNは自分のHoAを保持し、CNとの通信にHoAを使用する。この 状態ではMobile IPv6による特別な処理はされず、通常のIPv6ノードとしてHAを経由 せずにCNと通信を行う。

Mobile IPv6において、HAは非常に重要な役割を果たすノードである。MNは、CNと 直接経路で通信している場合も、ネットワークを移動するたびにそれを通知するためにHA との通信を必要とする。また、CNがMobile IPv6に対応していない場合には、直接経路 で通信を行うことができないため、常にHAを経由した通信になる。これらの通信にHA が利用されるため、MNの数が増える程、HAを利用した通信のトラフィックは増大し、

HAにかかる負荷が大きくなる。

さらに、HAに何らかの障害が発生した場合、そのHAを利用したMobile IPv6通信がす べて途絶えてしまう。そこで提案されたのが、マルチホーミングと呼ばれる技術である。

これは一つのHome Link上に複数のHAを設ける方法である。これにより一つ一つのHA にかかる負荷が分散され、また一つのHAに障害が発生した場合にも、他のHA(以後、Sec- ondary HAと呼ぶ)で処理を代行してMobile IPv6を安定して運用することができる。

• 複数のHome Agentの動作

複数のHAを設置した場合でも、基本的なMobile IPv6の動作について大きな変更はない。

ただし、Primary HA (ここではMNが最初に接続しているHAをPrimary HAと呼ぶ) に障害が発生した時に、Secondary HAに接続して通信を継続する処理が追加されている。

1. Secondary HA接続までの手順

Primary HAの障害が発生してからSecondary HAに接続するまでの処理の手順は以下の 通りである。

●Primary HAに対してBUを送信する。

MNはPrimary HAに対して一定間隔でBUを送信し続ける。Primary HAはそれに対す る応答(Binding Acknowledgment) を返す。

第 2 章 MOBILE IPV6におけるマルチホーミング

図 2.10: MNによるPrimary HAに対するBU

●Primary HAがダウンする。

Primary HAになんらかの障害が発生し、通常のHAの処理ができなくなる。

●Primary HAに対するBUが失敗する。

ここでBinding Acknowledgmentが返ってくるはずだが、Primary HAがダウンしている ために応答はない。

●Home LinkにDHAADを送信する。

Secondary HAの応答(DHAAD Acknowledgment)を待つ。

●Secondary HAに対しBUを送信して、通信を再開する。

DHAAD Acknowledgment受信後にSecondary HAに対してBUを送信する。その後は通 常のMobile IPv6と同様の処理を行い、通信を再開する。

2.Secondary HA接続までの手順

MNはForeign Linkに移動したとき、DHAADによってHome Link上にあるHAの応答

を待つ。RFC3775によると、返信のあったHAに対しBUを送信すると規定されている

が、複数のHAから返信があった場合に、どのHAに対してBUを利用するかは仕様とし ては決まっておらず、場合によっては特定HAに通信が偏ってしまい、最適なHAの選択 がされないことがある。これに関しては、それぞれのHAの通信量や処理能力などに応じ て、負担が偏らないよう通信を分散する方法が提案されている。(ただし、この課題につい ては本研究では扱わない。)

第 2 章 MOBILE IPV6におけるマルチホーミング

図 2.11: Primary HAに対するBUの失敗

図 2.12: MNによるDHAADの送信

第 2 章 MOBILE IPV6におけるマルチホーミング

図 2.13: Secondary HAに対するBU

第 3 章

マルチホーミングにおける問題と従来の解決法

3.1 マルチホーミングにおける問題

3.1.1 Secondary HA発見までの所要時間

既存のMobile IPv6の仕様では、MNがPrimary HAに障害が発生したことを検知すること ができるのは、一定間隔で行っているHAに対するBUを行ったときのみである。そのためBU の間隔が長ければ長いほど、MNがPrimary HAの障害に気づくまでに時間がかかり、その間 は通信に使用するHAがSecondary HAに切り替わらないため、他ノードからのMNに対する アクセスに反応できなくなるという問題点が指摘されている。

3.1.2 HAダウンのタイミング

HAに障害が発生するタイミングによって様々な問題が起こる可能性がある。ここではHAが ダウンするときのタイミングごとに、起こりうる問題について記載する。

• MNがForeign Linkに移動する前および移動した直後

MNは移動してすぐDHAADによりHAを探索する。そのためそれ以前にHAがダウンし ていた場合には、DHAADに対するレスポンスがないためすぐにHAのダウンを検知して、

Secondary HAに切り替えることができる。またDHAADに対するレスポンスがあった直 後にHAがダウンしても、そのすぐ後のBUでMNがHAのダウンを検知することができ るため、通信のダウンタイムは最小に抑えられる。

• MNがHAにBUした直後

HAに対するBUが完了すると、次はCNに対してBUを行う。ただしCNに対するBUを 行う前には、前述したとおりにRRPという処理を行う必要がある。このタイミングでHA がダウンすると、HAを経由して送信するHoTI、HoTのやり取りができず、CNにBU を送信できない。それどころか、CNにBUを送信するまでのCNとの通信と、BUが行

第 3章 マルチホーミングにおける問題と従来の解決法

われずにlifetimeが0になった後の通信は、HAを経由した通信であるため、その通信自 体も途絶えてしまう。

図 3.1: RRPを行う直前のPrimary HAのダウンによるHoTI送信の失敗

• MNがCNにBUした後

CNとの直接経路による通信が始まった後に、MNがHAのダウンを検知することができ るのはHAに対するBUのときのみである。仮にHAに対するBUのlifetimeが長い場合、

HA発見までに時間がかかる。またCNに対する2回目以降のBUは、CNから送信され るBRRというパケットをMNが受信することで処理が始まる。BRRはHAを経由する ため、HAがダウンしてしまうとBRRがMNに届かない。この場合にはCNに対するBU を行うことができなくなる。

3.2 既存の解決策

Primary HAの障害により通信が途絶えてしまう問題点については、これまでにも以下のよう

な解決策が提案されてきた。

• MNがMobile IPv6の認証処理を利用してPrimary HAの障害をより早く検知する。

MNがCNにHoTIを送るとCNからすぐにHoTの返送がある。しかしHoTIを送信して もHoTが来ない場合には、考えられることはHoTIを送信する経路(HA経由)に問題が起 こっているか、単にCNがダウンしているかである。ここで直接経路でCoTの返送があれ ば、冗長経路、つまりHAに問題があることが予想できる。(この方法はMNがHoTIを

第 3章 マルチホーミングにおける問題と従来の解決法

図 3.2: Primary HAによるHoTI転送後のダウンによるHoT送信の失敗

図 3.3: MNとCNが直接通信中のPrimary HAのダウンによるBRR送信の失敗

第 3章 マルチホーミングにおける問題と従来の解決法

送信してからHoTを受信するまでの間にHAがダウンした場合は、わずかな時間でHAの ダウンを検知することができるが、検知できるタイミングがごく短いため、実用度は低い と思われる。)

また、CNから送られるBRRはBUのlifetimeに対して一定間隔で送信されることになっ ている。そのためMNはいつBRRを受信するかそのタイミングを予測することができる。

(ただし、MNにBRR送信の間隔を事前に通知することが前提である。) BRRはHAを 経由した冗長経路から送られてくるため、予測したタイミングでBRRを受信しなかった とき、HAに問題があるのではないかと予想することができる。(今後の課題として、実 際のネットワークの運用に向けて大規模なネットワークで検証を行うこと、ダウンタイム をより短くするためにはBRRの間隔をより短くしてHAの生存を確認する頻度を上げる 必要があるが、同じHome Linkを多数のMNとCNが利用している場合に、そのすべて が頻繁にBRRを行うとHAにかかる負担が増大することなどが指摘されている。)

• HAの処理を一括して監視するマシンを設置し、一部のHAがダウンしたらすぐにMNに 知らせる。

一定時間ごとにHome Link内のすべてのHAをpingを用いて監視するマシンを新たに設 置し、いずれかのHAから応答が途絶えたらそのHAを利用しているMNに通知すること で、MNがHAのダウンに気付くまでの所要時間を短縮する。(今後の課題として、ping のみでなくtelnetやSNMPなどの監視プロトコルと併用することや、実際のネットワーク の運用に向けて大規模なネットワークで検証を行うことなどが提案されている。)

以上2つの提案については、解決策が提案される前の仕様と比較実験した結果が明示され ている。これを以下の表に記す。なお、表中の実験1と実験2および図中の方法1は認証 処理を利用する方法で、実験3および方法2はpingを利用した監視マシンを用いた方法で ある。(実験1はCoTを受信したがHoTが受信されなかった場合の実験で、実験2および 方法1はBRRを受信できなかった場合の実験である。)

以上の結果としては、いずれの場合もBUの間隔やlifetimeに影響されずにほぼ一定のタ イミングでMNがPrimary HAのダウンを検知できることが確認された。(実験1はHoTI の送信からHoTの受信までの待ち時間を1秒に設定したため、HAのダウンに気付くま での時間が約1秒となった。実験2はBRRの間隔を20秒、タイミングをHAのダウンに 対しランダムとしているため、MNがHAのダウンに気付くまで平均して約10秒となっ た。実験3は監視マシンのpingの間隔を10秒とし、監視マシンからHAのダウンを知ら せるメッセージをMNが判定するのにかかる時間が平均して約8秒であったため、MNが HAのダウンに気付くまで平均して約13秒となった。)

なお、解決策が提案される前の状態でMNがPrimary HAのダウンを検知するまでに要

第 3章 マルチホーミングにおける問題と従来の解決法

した時間については、実験1および2と実験3で実験時に設定したBUの間隔およびタイ ミングが異なっていた(RFC3775では、lifetimeが0になる前にBUを行うとしか明記さ れておらず、具体的なBUの間隔については定義されていない。)ためか、結果が大きく 異なっていたので、ここでは割愛するが、いずれもBUの間隔にほぼ比例した値となって いた。このことから、既存の解決策は、BUの間隔が長いほど有効であることがわかる。

(実験1および2では、「BUの間隔はlifetimeの1/2、タイミングはPrimary HAのダウ ンに対してランダム」と明記されており、結果として得られた値は(BUの間隔の1/2 + BUの再送に要する時間8秒間)にほぼ一致するとされている。一方、実験3では、具体的 なBUの間隔およびタイミングは明記されていなかったが、実験結果から推測すると「BU の間隔はlifetimeの3/4、タイミングはPrimary HAのダウンの直前」とみられ、結果と して得られた値は(BUの間隔 + BUの再送に要する時間8秒間)にほぼ一致していた。)

表 3.1: Primary HAのダウンからMNがダウンを検知するまでに要した時間

lifetime (秒) 20 40 60 80 100 120

実験1 1.01 1.01 1.01 1.01 1.01 1.01 実験2 8.64 9.51 9.83 10.00 10.09 10.16 実験3 12.98 15.29 12.45 14.68 14.81 14.68

図 3.4: Primary HAのダウンからMNがダウンを検知するまでに要した時間

• HA同士が互いの状態を管理し、一部のHAがダウンしたらすぐにMNに知らせる。

第 3章 マルチホーミングにおける問題と従来の解決法

同じHome Link内に存在するHA同士が、互いにそれぞれのHAを利用しているMNの 情報(特にForeign Linkに移動したMNのCoA)を定期的に通知し合うことにより、一部 のHAからの通知が途絶えるとそのHAのダウンを他のHAがすぐに検知でき、さらにダ ウンしたHAから事前に通知された情報を元に、そのHAをPrimary HAとして利用して いたMNにPrimary HAがダウンしたことをすぐに通知できる。

今後の課題として、「HAが他のHAに情報を通知する間隔が長いと、一度情報を通知し てから次に通知するまでの間にHAがダウンした場合、その間にこのHAに対してBUを 行い情報を更新したHAの情報を他のHAが認識できず、そのMNとの通信に影響が出て しまう」「HAが他のHAに情報を通知する間隔を短くすると、HAとMNの数に応じて、

互いのHAの情報を通知し合うトラフィック量が膨大になる(多数のMNが頻繁にネット ワークを移動する場合、間隔を1秒位にしてもまだ長いかもしれないとされている。)」と いう問題点が指摘されている。

第 4 章

本研究における提案および実験

4.1 本研究の提案

Mobile IPv6におけるマルチホーミングによる問題に対して、これまでに述べた既存の解決策

では「いかにして、通信中のMNに早急にPrimary HAのダウンを知らせるか」ということが 焦点となっていた。その目的は「HAがダウンしたことをMNが認識していないと、新しいCN が通信に参加できない上に、現在通信中のMNやCNがHAを経由した通信(特にCNからMN へのBRR)ができなくなる」という問題を解決することであり、その方法として「HAのダウン からMNが認識するまでの時間を短縮する方法」が提案されていた。

本研究では、上記の問題点を別の方法で解決できれば、HAのダウンをMNに事前に知らせ る必要すらなくなるのではないかと考えた。その方法を以下に示す。

• Primary HAがダウンした場合に備え、他のHAとBU情報を共有しておく。

Primary HAがダウンした後で、新しいCNが通信を行おうとした場合

• MNが移動時に行うDHAADと同じように、CNが動的に利用可能なHA (MNの情報を 保持している)を探索する。

• CNが発見したHAを経由して、MNにBRRを送信する。

• BRRを受け取ったMNが、HAとCNに対してBUおよび認証処理を行う。この時点で、

CNが利用しているHAが、ダウンしたHAに替わってPrimary HAになる。

Primary HAがダウンした後で、通信中のCNがBRRなどのPrimary HAを経由した通信を 行おうとした場合

• 例えば、BRRを行おうとした場合、MNからのRRPが受信できないことでPrimary HA のダウンを知ることができる。後の処理は新しいCNが通信に参加するときと同様。この

第 4 章 本研究における提案および実験

場合にPrimary HAのダウンを確認せずにDHAADを行わせることもできるが、その場合 HAがダウンしていなくてもPrimary HAの変更やHAに対するBUが行われる可能性が あるため、あまり推奨できない。

この方法ならば、たとえMNがHAのダウンに気づくまでの時間がどれだけ長くても(言い換 えれば、Primary HAの状態を確認する間隔がどれだけ長くても)関係なく、「HAを利用した 通信を行おうとした時に即座に気づく」ことができるため、事前にMNに知らせなくても通信の 継続性を維持できる、というのが本研究の提案である。

図 4.1: 提案した解決法

4.2 実験による検討

本論文における実験は、ネットワークシミュレーターNS2およびNS2をMobile IPv6用に拡

張したMobiwanというパッチを使用してシミュレーションを行った。このシミュレーションで、

MNに早急にHAのダウンを知らせなくても、他のHAがBUの情報をバックアップすることで、

CNがHAを通信を利用した通信を行うときにPrimary HAをダウンしていないHAに切り替え て通信の継続性を確保できることを確認する。

なお、BUのlifetimeは30秒、60秒、120秒、180秒、240秒、300秒と変化させ、HAは BUの完了直後にダウンさせ、HAに対するBUはlifetimeの半分の間隔で行われるとした。ま た実験1で新しいCNが通信に参加しようとするタイミングはHAのダウンから次のBUの間の

第 4 章 本研究における提案および実験

ランダムなタイミングに設定し、実験2でCNがBRRを送信する間隔は20秒、タイミングは ランダム、RRPを待つ時間は1秒とし、各実験において10回実行した平均値を取った。

なお、HA同士が互いの情報をバックアップする具体的な方法については、「始めからMNが 複数のHAに対してBUを行う方法」と、「HA同士が互いに常時監視しあう方法」が提案され ているが、本研究では前者の方法を選択した。

図 4.2: MNが複数のHAに対してBUを行う方法

4.2.1 実験1 (HAのダウン時に新しいCNが通信に参加しようとする場合) (1) NS2を用いて図4.3 の通りのシミュレーション環境を作成する。

(2) まず、HAの複数化における問題点の解決策が導入されていない状態でシミュレーション

を行い、Primary HAがダウンした状態で新しいCNが通信に参加するのにかかった時間

を記録する。

(3) 次に、提案した解決法を導入した状態で、(2)と同じくシミュレーションを行い、新しい CNが通信に参加するのにかかった時間を記録する。

(4) (2)と(3)でかかった時間を比較する。

(5) BUのlifetimeを変化させながら(2)〜(4)を繰り返す。

第 4 章 本研究における提案および実験

図 4.3: 本研究におけるシミュレーション環境

4.2.2 実験2 (HAのダウン時にCNがHAを経由してBRRを行おうとする場合) 実験1の手順を以下のように変更する。

(1) 実験1と同様。

(2) HAの複数化における問題点の解決策が導入されていない状態で、Primary HAがダウン した状態でCNがPrimery HAへBRRを試みてからSecondary HAにBRRを実行する までにかかった時間を記録する。

(3) 提案した解決法を導入した状態で、(2)と同じくシミュレーションを行い、CNがPrimery HAへBRRを試みてからSecondary HAにBRRを実行するまでにかかった時間を記録す る。

(4) (2)と(3)でかかった時間を比較する。

(5) BUのlifetimeを変化させながら(2)〜(4)を繰り返す。

4.3 実験の結果

実験1における、新しいCNが通信に加わるまでに要した時間は以下の表 4.1 の通りである。

第 4 章 本研究における提案および実験

結果として、解決策なしで実験を行った場合は平均してBUの間隔の半分(lifetimeの1/4)に 5〜8秒を加えた値となった。これに対して、提案した方法を用いた場合はlifetimeの長さに関 係なく0.6秒前後となった。

表 4.1: 新しいCNが通信に加わるまでに要した時間

lifetime (秒) 30 60 120 180 240 300

解決策なし 15.87 22.42 37.85 51.93 67.91 80.38 提案手法 0.58 0.61 0.53 0.59 0.58 0.64

図 4.4: 新しいCNが通信に加わるまでに要した時間

4.3.2 実験2の結果

実験2における、通信中のCNがPrimery HAへBRRを試みてからSecondary HAにBRR を実行するまでに要した時間は以下の表 4.2 の通りである。

結果として、解決策なしで実験を行った場合は、実験1とほぼ等しく、平均してBUの間隔の 半分(lifetimeの1/4)に5〜8秒を加えた値となった。これに対して、提案した方法を用いた場 合は、実験1の結果に「CNがBRRに対するPrimary HAからの応答を待つ時間」が加わり、

lifetimeの長さに関係なく1.5秒前後となった。

第 4 章 本研究における提案および実験

表 4.2: 通信中のCNがSecondary HAにBRRを実行するまでに要した時間

lifetime (秒) 30 60 120 180 240 300

解決策なし 15.24 20.96 37.09 51.68 67.45 80.42 提案手法 1.54 1.48 1.39 1.60 1.47 1.49

図 4.5: 通信中のCNがSecondary HAにBRRを実行するまでに要した時間

第 5 章 まとめ

5.1 結論

本論文では、Mobile IPv6におけるマルチホーミングにおける問題すなわち、一部のHAに障 害が発生したとき他のHAに切り替える際に生じるタイムラグにより通信の継続性が損なわれる 問題点について取り上げ、既存の解決策としてHAのダウンをいち早くMNに通知する方法が いくつか提案されていることを述べた。

本研究では、複数のHAがMNの情報を共有すれば、事前に一部のHAの障害をMNに通知 しなくても、CNがHAを利用した通信を行おうとするときに利用可能なHAを探索してMNに 通知してBUを行わせることで、通信の継続性を維持する方法を提案した。

提案した方法について実験した結果、通信中のCNや新しいCNが現在利用可能なHAを探索 してMNに通知することで、MNが通信に使用していたHAに障害が発生してもその後の通信 継続性を維持できることが確認された。具体的な結果は、新しいCNが通信に参加しようとする 場合、実際に通信が開始されるまでにかかった時間は約0.6秒前後となった。MNと通信中のCN がHAにBRRを行おうとした場合、実験1の結果に、Primary HAからのRRPを待つ1秒間 を加えた値とほぼ一致した。

既存の解決策の場合には、Primary HAの障害をMNに通知し、Secondary HAに切り替え るのにかかった時間が表 3.1 の通りであり、仮にその間のランダムなタイミングでCNがHAを 利用しようとした通信を行おうとすると、そのダウンタイムは平均して「MNがPrimary HAの 障害を検知するのにかかった時間の半分」となる。これが大体5秒前後であることを考えると、

事前に通知するよりも臨時に通知する方が効率的である。

第 5章 まとめ

5.2 今後の課題

• 実際のネットワーク環境への応用

今回の実験は、CNがHAのダウンを通知する機能の動作確認を行うためだけの小規模な ネットワークによるシミュレーションであった。実際のネットワーク環境に取り入れる場 合には、実機を使った大規模なネットワークでの実験も必要になると。

• 既存の解決策との厳密な比較

今回の実験では、既存の解決策との比較を通信のダウンタイムで行った。理想的には、既 存の解決策においてHAの状態を管理するために増加するトラフィックや、提案した解決 策において多数のMNが複数のHAにBUを行う場合に増加するトラフィックも比較する ことが望ましい。

• トラフィック量増加の抑制

上記に述べた通り、HAの障害に備え複数のHA同士でMNのBU情報を共有すると、ど うしてもMNやHAの数に比例して情報を通知するためのトラフィック量が増大すること になる。そのための解決策の一例として、Home Link上で情報を共有するHAの数を絞る 方法が提案されている。なお、HA同士が互いに常時監視しあう方式ならば、他のHAに 通知する情報を、変更・更新のあったMNのみに絞るという方法も考えられる。

また、複数のMNからのBU情報を一括してまとめるという方法も考えられるが、そのた めには、BU情報を一括して受け取ってまとめる監視マシンが別に必要になる。さらに、

監視マシンがダウンした場合HAがMNの情報を共有できなくなるという危険がある。

謝辞

本論文の作成にあたって、色々とお世話になりました後藤研究室の皆様に、感謝の気持ちを申 し上げます。特に、日頃からご指導頂きました後藤滋樹教授、Mobile IPv6についてアドバイス してくださった片桐 友之助さん、今回の研究テーマである「Home Agentの複数化」について相 談に乗ってくださった史 虹波さんに深く感謝いたします。

参考文献

[1] NS2チュートリアル

http://www.cool.giti.waseda.ac.jp/~onoder/onoder/ns-tutorial.htm [2] The Network Simulator ns-2

http://netlab.ce.nihon-u.ac.jp/~sue/

[3] Home Agent Reliability Protocol draft-ietf-mip6-hareliability-05

http://tools.ietf.org/html/draft-ietf-mip6-hareliability-05 [4] An Implementation of Multiple Home Agents Mechanism in Mobile IPv6

http://www.net-computer.com/IEEE-tridentcom2007.pdf [5] Tutorial for the Network Simulator ns

http://www.isi.edu/nsnam/ns/tutorial/index.html [6] Miscellaneous ns-2-related things

http://www.nicta.com.au/people/mehanio/nsmisc

[7] MobiWan: NS-2 extensions to study mobility in Wide-Area IPv6 Networks http://www.inrialpes.fr/planete/mobiwan/

[8] 片桐 友之助 Mobile IPv6におけるHome Agentの高速な障害発見法 早稲田大学 理工学部 卒業論文 2007年度, 2008年2月.

[9] 石井 勇弥 Mobile IPv6における認証処理を利用したHome Agentの障害発見の高速化 早稲田大学大学院 理工学研究科 情報・ネットワーク専攻 修士論文 2006年度, 2007 年2月.

[10] 銭飛 NS2によるネットワークシミュレーション - 実験で学ぶQoSネットワーク技術 森北出版株式会社, 2006年.

付録 A 追加実験

HA同士が互いの情報をバックアップする方法について、「HA同士が互いに監視しあう方法」

を用いた場合について、同様に実験を行った。

図 A.1: HA同士が互いを監視しあう方法

追加実験における結果は、以下の図表の通り、第4章の実験とほぼ同様の結果になった。

表 A.1: 新しいCNが通信に加わるまでに要した時間

lifetime(秒) 30 60 120 180 240 300

解決策なし 15.87 22.42 37.85 51.93 67.91 80.38 追加実験 0.59 0.57 0.62 0.55 0.58 0.59

付録 A 追加実験

図 A.2: 新しいCNが通信に加わるまでに要した時間

表 A.2: 通信中のCNがSecondary HAにBRRを実行するまでに要した時間

lifetime(秒) 30 60 120 180 240 300

解決策なし 15.24 20.96 37.09 51.68 67.45 80.42 追加実験 1.49 1.52 1.49 1.38 1.44 1.51

図 A.3: 通信中のCNがSecondary HAにBRRを実行するまでに要した時間

付録 A 追加実験

以上の結果から、HA同士が互いを監視する場合にも、MNが複数のHAにBUを行う場合 とほぼ同等の通信継続性を維持できることが確認できた。

また、「MNのアドレス情報(CoA)が変更されてPrimary HAに通知されてからSecondary HAに通知するまでの間にPrimery HAがダウンした場合」についても、そのタイミングでHA をダウンさせることによるシミュレーションを行ったところ、「解決策なし」の場合とほぼ同等 の時間がかかった。

ただし、この結果は本実験における小規模なネットワーク上でのシミュレート結果であり、現 実の大規模なネットワークに応用する場合、多数のMNが頻繁にネットワークを移動するとHA も頻繁に情報を更新して他のHAに通知しなければならず、HAの負担が増大するという問題が ある。

これにより、HA同士が情報を交換しあって互いのバックアップをとる方法は、MNの数と ネットワーク移動の頻度が大きい場合は「既存の解決策」の紹介時にも述べたとおり、HA同士 の情報送信の間隔を短くすればHAの負担が増し、長くすれば通信の安定性が損なわれるという トレードオフの関係になることが確認された。なお、MNからPrimary HAに対してBUが行 われたときに他のHAに情報を送信するという方法も考えられるが、これはMNの数や移動の 頻度が少ない場合は有効であるが、多数のMNが頻繁に移動する場合は無数に情報交換が行わ れ、却って効率が落ちると考えられる。

これに対し、MNが複数のHAに対してBUを行う場合は、対応するすべてのHAが同時に 情報を更新するため、通信の安定性がMNの数や移動の頻度に左右されない。また、HA同士 の情報交換のトラフィックも発生しないが、そのかわりMNとHAの数に比例して、BUのト ラフィックが増大することになる。今後の課題として、両者のトラフィックの比較や、HAの負 担と安全性のトレードオフの問題点を踏まえて最適なHAの情報交換の間隔を検証することが望 ましい。