ID HIMALIS HANA * a) System Design and Software Implementation for User-oriented and Network-oriented High-Availability Networking ID/Locator Separati

(1)

招待論文

ユーザ主体及びネットワーク主体の高可用ネットワークを実現する

システムの設計とソフトウェア実装

——ID

・ロケータ分離アーキテク

チャ

HIMALIS

とロケータ自動割振プロトコル

HANA——*

藤川

賢治

†a)

_福島

_裕介

†

System Design and Software Implementation for User-oriented and

Network-oriented High-Availability Networking——ID/Locator Separation

Architecture HIMALIS and Automatic Locator Allocation Protocol HANA——

∗

Kenji FUJIKAWA

†a)

and Yusuke FUKUSHIMA

†

あらまし本論文では，ユーザ主体及びネットワーク主体の高可用ネットワークを実現するためのネットワークシステムの設計と実装を行う．ユーザ主体として，端末が様々なネットワーク環境に適応して接続し，利用するネットワーク環境を変更しても通信を継続できるHIMALIS アーキテクチャについて説明する．ネットワーク主体として，ネットワークの耐障害性の向上，設計・設定の自動化を図り人的ミスによる障害を取り除くHANA プロトコルを提案する．またHIMALIS 及び HANA のシステム設計とソフトウェア実装を紹介する．HIMALIS システムを実装するに当り，機能と性能を考慮して，ユーザ空間実装とカーネル空間実装の機能分割を行う．またHIMALIS ノードの役割に応じてカーネルにモジュールを追加できるようにする．HANA システムの実装に当り，プロトコルメッセージの変更・追加，及び開発時のデバッグ容易性の実現，また各種ハードウェアへの可搬性をもたせるための設計を行う．これらのHIMALIS 及び HANA の設計・実装を，様々なネットワーク環境に適用・応用し，各環境においてネットワークや端末の高可用化が実現できることを示す．キーワード高可用ネットワーク，ID・ロケータ分離，ロケータ自動割振，システム設計，ソフトウェア実装

1. まえがき

我々は，PCやスマートフォンなど一般ユーザがもつ通信用端末が，どこにあっても通信でき，かつ通信を継続できるネットワークの構築を目指し，ユーザ主体，及びネットワーク主体の高可用ネットワークの研究開発を行っている．ユーザ主体とは，端末から見た通信可用性の向上である．様々な通信環境において，端末にその環境のネットワークに対応できる機能をもたすことで，相手が接続するネットワーク環境に依存せず通信と通信の継続を提供する．一方，ネットワーク主体とは，ネットワーク自身の高可用性の提供であ †_{情報通信研究機構，小金井市}

National Institute of Information and Communications Technology, 4–2–1 Nukui-Kitamachi, Koganei-shi, 184–8795 Japan a) E-mail: hudikaha@nict.go.jp *本論文は，システム開発・ソフトウェア開発論文である．る．ネットワークの通信障害や輻輳に備え，迂回経路をあらかじめ用意したり，あるいは，ネットワーク設計・設定の自動化を図り，人的ミスによる障害を取り除いたりして，ネットワークの稼働率を高くする．例えば，総務省が公表する事故を分析するとその約2%が人的ミスであり，重大事故の中にはアドレス設定の誤りが含まれる[1]． PCやスマートフォンなどの端末は，有線LAN，無線LAN，3G回線など，複数の通信インタフェースをもち，異なるネットワーク環境に同時に接続したり，それらの環境間を移動することが一般的になっている．しかしこれらの環境をシームレスに活用できているとはいい難い．端末が複数のインタフェースを利用する場合や，ネットワーク間を移動する場合，IPアドレスの変化により通信相手からの自身への識別が困難となり，通信が継続できなくなる．これは現在のインターネットではIPアドレスをホストの位置情報（ロケー

(2)

タ）だけでなくホスト識別子(ID)として利用していることが原因である．ここで以下の議論では，位置情報として用いられるIPアドレスをロケータと呼ぶこととする．ロケータがIDとして使われていることに起因する問題を解決する手法として，ID・ロケータ分離思想に基づいたネットワーク技術[2], [3]が提案されている．その中で，我々はID・ロケータ分離ネットワーク

アーキテクチャHIMALIS (Heterogeneity Inclusion Mobility Adaptation through Locator ID Separa-tion) [4]を提案し，研究開発を行っている．HIMALIS では，全てのホストが固有のIDをもち，トランスポート層とネットワーク層の間にIDを扱う識別層を新たに導入することで，ホスト認証やデータセッションのハンドオーバを実現する．ネットワーク層として，IPv4 アドレスとIPv6アドレスに対応しており，利用するネットワーク層のプロトコルが異なる場合でも相互通信可能な環境を提供する． HIMALISシステムでは，ユーザ主体として， HI-MALISノードがロケータ情報に依存せず互いを識別しながら通信する．一方で，HIMALISノード間の接続は，ルータやスイッチ等のネットワーク層までの情報でルーティングするネットワーク機器を用いる．そこでネットワーク全体の可用性を高めるため，ネットワーク主体の高可用実現について考える．

Network Service Provider (NSP)やデータセンタなどのサイト，比較的大きな規模の会社などは，ネットワークの耐障害性確保の為マルチホーム構成を取っていることがある．マルチホームは複数の上流NSP との接続をもつことで，障害時の迂回経路を確保するものである．しかし現在のBGPプロトコル[5]をベースとしたマルチホームでは，サイトに固有のロケータ空間を必要とし，インターネットコア経路表増大の原因の一つとなっている．また別のサイトからそのサイトに向かう経路を同時には一つしか使えず，別の経路を使うには経路が完全に切替わる必要がある．複数のロケータ空間を活用するマルチホームを利用して迂回経路を確保すれば，別のサイトからマルチホームしているサイトへの経路を同時に利用することができ，障害時には即座に経路を切替えることができる．しかし複数ロケータを利用するマルチホームは，サイトのグローバルロケータを利用しているネットワーク機器への複数のロケータ設定に加えて，上流 NSPを変更したときにそれらの機器のロケータ再割当が必要であり，ネットワーク管理者のロケータ割振・設定の負担を増やすため，現在普及していない．そこで我々は複数ロケータを階層的に自動で割振・割当する技術としてHANA (Hierarchical/Automatic Number Allocation for locators) [6], [7]を提案する．

一例ではサーバ1000台規模のネットワークにおいて，ロケータ設定の手間が約1/100となる[8]．HANAは，管理者に負担を強いずに，複数ロケータを用いたマルチホームによってネットワークの耐障害性を向上し，また管理者の設定ミスに起因するネットワーク障害を防ぐことで，ネットワークの可用性を向上できる．更にHANAを用いることで，ネットワーク追加時のロケータ割当やNSP変更の際のネットワーク全体のロケータ再割当も自動で行われ，柔軟性の高いネットワークが構築できる．本論文では上述の特長をもつHIMALISシステム及び HANA システムを設計し実装する．また HIMALISノードを接続するためのバックボーンネットワークにHANA を導入したネットワークを構築し，HIMALIS/HANA統合ネットワークと呼ぶこととする． HIMALISシステムの実装には，制御プレーンとデータプレーンそれぞれに要求される役割と性能を考慮する．具体的には，処理が複雑であるが高いスループットは要求されない制御プレーン処理部はユーザ空間に実装し，処理は簡単であるが高いスループットが要求されるデータプレーン処理部はカーネル空間に実装する．またデータプレーン処理部をモジュール化し， HIMALISノードの役割に応じてカーネルにモジュールを追加できるようにする． HANAシステムの実装には，階層的なネットワークを扱うことを念頭に，プロトコルメッセージの変更・追加，及び開発時のデバッグ容易性や，各種ハードウェアへの可搬性をもたせる設計を行う．具体的には，階層を扱うためのサブノードと呼ぶ概念の導入や，メッセージフォーマットをテキストとし，CLIやログと構文を共通化する手法，プロトコル処理部とそれ以外の部分とでプロセスを分割する手法を提案する．また，設計したネットワークの動作検証シミュレーションや，性能評価のためのエミュレーションを容易にする．以下，2.では，高可用ネットワーク実現に向けた HIMALISとHANAのアーキテクチャ・プロトコル設計について述べる．3.では，HIMALISシステムの基本実装と評価について述べる．4.では，HANAシス

(3)

テムの基本実装について述べる．5.では，HIMALIS とHANAを適用した各種システムについて述べる． 6.はまとめである．

2. 高可用ネットワーク実現に向けたアーキ

テクチャ・プロトコル設計

本節では高可用ネットワーク実現に向けたアーキテクチャ及びプロトコル設計について述べる．以下，多様なネットワーク環境へ端末を対応可能とするネットワークアーキテクチャHIMALISと，ネットワークの可用性と柔軟性を向上させるHANAの設計概要を説明する． 2. 1 多様なネットワーク環境へ端末を対応可能とするHIMALISの設計 2. 1. 1 HIMALISアーキテクチャの設計 [9], [10]ではHIMALISアーキテクチャを設計しており，本節ではその概要を説明する．図1及び図2に HIMALISネットワーク構成並びにプロトコルスタックを示す．ネットワークは，ホストが接続するエッジネットワークと，複数のエッジネットワークを接続するトランジットネットワークで構成される．各ネットワークでは， IPv4，IPv6またはその他のネットワーク層プロトコルが利用される．図1では，トランジットネットワークにIPv4が利用され，エッジネットワークではIPv4 とIPv6が利用されている．これらのネットワークはネットワーク層プロトコル変換機能をもつHIMALIS 図 1 HIMALISネットワーク構成 Fig. 1 Construction of HIMALIS network.

図 2 HIMALISプロトコルスタック Fig. 2 HIMALIS protocol stack.

ゲートウェイ(HG)で相互接続する．各HIMALIS対応ノード（DNR，HNR，HG，ホスト）には，ネットワーク初期接続のときに固有のホスト名と128ビット長のIDを割り当てる仕組みをもつ．ホスト名は，ドメイン名とドメイン内で固有の名前を「#」で接続した文字列で表現される（例： host#himalis.net）．トランジットネットワークには，ホスト情報（ホスト名，ID，ロケータと公開鍵）を管

理するHost Name Registry (HNR)と，ホストのド

メイン名からホストの情報を管理するHNRの検索を

可能とするDomain Name Registry (DNR)がある．ホスト情報は，ホストが初めてネットワークに接続するときにHNRに登録される．HNRに登録済みのロケータ情報は，ホストがネットワークに接続したときにホストが更新する．全てのHIMALISノードは，IPアドレスではなくノード固有のID を用いて通信相手を識別する．ロケータの変化に依存しない通信を実現するため，トランスポート層とネットワーク層の間に識別(Identity) 層を導入している．識別層はホストIDとロケータの対応（IDテーブル）をもち，パケットを送信するときにIDテーブルを参照して送信元・宛先ロケータを選択可能な仕組みにしている．IDテーブルのロケータ情報を更新することで，モビリティやマルチホーム接続時のロケータ変化に対応する．また識別層では， HNRに登録する公開鍵情報を用いてホスト間で互いを認証する仕組みをもつ．この仕組は，公開鍵で暗号化したメッセージが対応する秘密鍵でしか正しく復号できない非対称鍵暗号の原理を用いている．通信開始前にこの仕組を用いて互いを認証することにより，送信元を詐称した攻撃を受けにくくなっている．通信前の相互認証の後，識別層が宛先ホストに対する通信状態の管理を行う．これをIDセッションと呼び，通信中の経路障害を検知できる．このような識別層の仕組みを用いることで，HIMALISで動作する通信プログラムに以下の機能が付与される． • モビリティ，マルチホーム • 異種ネットワーク層プロトコル間の通信 • 相互のホスト認証，パケット改ざん防止 • 通信障害検出・代替経路への自動切り替え上記の機能を実現するHIMALISシステムの基本実装については3.で述べる． 2. 1. 2 HIMALISパケットの設計他のID・ロケータ分離技術[3]では，ホストがネッ

(4)

トワークを切替える際のロケータ変更に対応するため， IPトンネリング技術（IPSec，VPN等）を用いるものが多い．しかしIPネットワークでの使用に限定されるため，将来のIP以外で構成されるネットワークへの拡張は困難である． HIMALISでは，ネットワークヘッダとトランスポートヘッダの間にホスト識別情報を有するIDヘッダを挟んだパケットフォーマットを用いる（図3）．IDヘッダは，バージョン情報，制御情報の他に送信元，宛先のホストIDを有する．IPヘッダで，既存のトランスポートヘッダと，IDヘッダを区別するため，IANA

(Internet Assigned Numbers Authority)で未割当の

248を用いており，IPヘッダのプロトコルフィールドには，248がセットされる．識別層でパケット転送制御を行うHGでは，IDヘッダの情報を参照して，ネットワークヘッダの送信元，宛先ロケータを書き換えた上，パケット転送を行う．また，エンドツーエンドのセキュリティを改善するための手段として，16オクテットのセキュリティオプションヘッダをもつ．オプションヘッダには，シーケンス番号とIDヘッダ情報の署名（IDセッション開始時に交換する共有鍵を利用）が付与される．上記のとおり，HIMALISでは，識別層を有する HIMALISノードが，互いを識別しながら通信することで，ロケータ情報に依存しない安全な通信を実現する．一方で，HIMALISノード間の接続は，ルータやスイッチ等のネットワーク層までの情報でルーティングするネットワーク機器を用いる．このため，ネットワーク全体の可用性を高めるには，ネットワーク機器の大部分を占める識別層をもたないノードに対する検図 3 HIMALISパケットフォーマット

Fig. 3 HIMALIS packet format.

討が重要となる．本論文では，このようなノードで構築されるネットワークに対し，後述するロケータ自動割振機構HANAを導入し，ネットワーク全体の更なる可用性向上を図る． 2. 2 ネットワークの可用性と柔軟性を向上させる HANAの提案以下の項目を目標にしたプロトコルとしてHANA を提案し，設計する． • 複数ロケータ割振による迂回経路の確保及びネットワークの耐障害性の向上 • 複数ロケータ割振によるインターネットの経路表の削減，及び経路表削減によるネットワーク障害時経路収束速度の向上 • ロケータ自動割振によるネットワーク管理者負担の軽減及び，人為ミスによるネットワーク障害の防止これらはネットワーク可用性を向上させ，柔軟なネットワーク構築に貢献する．以下，HANAで利用するロケータの構造を説明した後，HANAのロケータ割振・割当方式を提案する．またロケータの動的な変化に対応するために設計した経路制御プロトコルも併せて説明する． 2. 2. 1 ロケータの構造 HANAではロケータを上位部，中位部，下位部に分

割し，それぞれPrefix, Midfix, Suffixと呼ぶこととし，

図4に示す表記法を用いることとする．ロケータはN ビット長である．Prefix長がnビットであり，Midfix 長がm − nビットであり，Suffix長がN − mビットである．これらはそれぞれ/n, /n-m, and /m-N と表記することとする． 2. 2. 2 HANAプロトコルの概要図5を例にHANAプロトコルの基本方針を以下に述べる．ただし図5は2階層の例であり，3階層以上の具体例は[7]を参照のこと． • NSPや企業などの組織には，外部接続の有無とは無関係にHANAサーバが設置される．HANAサーバは他のHANAクライアントに対してMidfixを割振る．Midfixは図4に示したロケータの中間部分であり，その組織内で他のHANAクライアントがもつ図 4 ロケータの構造

(5)

ものとは異なる固有の空間である． • 最上位のNSPではHANAサーバに対して配布可能なロケータ空間を手動で設定する．図5では， NSP1とNSP2とにそれぞれ1/8と2/8の空間が設定されている． • 最上位の組織を除くNSPや企業などの組織は Prefixを上位NSPから配布される． • HANAサーバは，上位組織に対してはHANA クライアントとなり，上位組織に要求するロケータ空間の大きさが管理者により設定される．具体的には図4に示すmを管理者が設定する．その結果として上位組織からMidfixの割当を受ける． • 最上位の組織を除くNSPや企業などの組織は配布されたPrefixと割当てられたMidfixとを組合せ新たなPrefixとし，内部及び下位の組織に配布する． HANAは機能的にはDHCPやRRv6 [11]を含み，かつそれらの機能を統合する．Midfix割振機能はロケータを割振るという点でDHCPに似ているが，各階層に応じたMidfixを自動割振でき，ホストだけではなくルータにも適用することを初めから考慮している点で異なる．またRRv6のようにPrefixを下流に図 5 HANAプロトコルの概要

Fig. 5 Abstract of HANA protocol.

配布するが，その際HANAではMidfix割振状況に応じて配布するPrefixを変化させることが異なる．先の図5はHANAプロトコルの概要とHANAに基いて構築されたネットワークを示している．NSP1 とNSP2はそれぞれロケータ空間1/8と2/8とを割振られている．またそれぞれロケータ空間1.1/16と 2.2/16をPrefixとして企業ネットワークに対して割振っている．このようにPrefix長は下の階層になるにつれて大きくなっていく．企業ネットワークでは，Midfixが外部接続とは関係なく割振られる．例えば図5では，一番上のルータがHANAサーバとなり，自身も含めたルータに対してそれぞれ0.0.1/16-24，0.0.2/16-24，0.0.3/16-24 を割振っている．末端ホストに対しては，0.0.4/16-24， 0.0.5/16-24，0.0.6/16-24を割振っている．結果として，例えば末端ホストの一つは，Prefix (1.1/16, 2.2/16)とMidfix (0.0.4/16-24)とホストが自身で決めるSuffix(0.0.0.1/24-32)とを結合しロケータを生成する．Prefixが複数あるので，複数のロケータ(1.1.4.1, 2.2.4.1)が生成されることになる． 2. 2. 3 HANAプロトコルシーケンス HANAサーバが1台，HANAクライアントが2台で，クライアントのうち1台が中継ノードとなっているネットワーク構成におけるプロトコルシーケンスを図6に示す． HANAサーバS1は，自身の存在を示すMidfixoffer メッセージを設定された管理ドメイン内でフラッディ図 6 HANAプロトコルシーケンス

(6)

ングする（注 1）．クライアントは，Midfixofferメッセージを受信すると，Midfixofferメッセージが来た方向に，Midfixreq メッセージを送信する．Midfixreqメッセージには，要求するMidfixのビット長をパラメータとして与える． MidfixreqメッセージはMidfixofferが来たのとは逆向きに転送され，HANAサーバに到着する．どちらが逆向きかを判断するためには，受取ったメッセージをノードで記憶する．図6中でR1は，クライアントであると同時に複数のインタフェースをもつので，自身がMidfixreqメッセージを出すとともに，Midfixoffer メッセージをHANAクライアントC1にも転送している．C1もMidfixofferを受信しMidfixreqメッセージを返信する．このMidfixreqメッセージは，R1により転送される．上記二つのMidfixreqメッセージはパラメータとして含まれるノード名により区別される．なおノード名は管理者が設定する．サーバS1は，受信したMidfixreqメッセージそれぞれに対して，ロケータ空間を割振り，その割振情報をパラメータとしてMidfixackメッセージを送信する． Midfixackメッセージは，Midfixreqメッセージの逆向きに転送される．このように，HANAプロトコルメッセージを隣接ノード以外に送信するには，経路上の別のHANAノードがいったん受信し，そのノードが転送先を決定し転送する．つまりHANAメッセージが直接通信する相手は隣接ノードに限られる．4. 3では通信相手が隣接ノードに限られることを前提にモジュール設計を行う． 2. 2. 4 HQLIPプロトコルの概要我々はHANAと協調して動作する経路制御プロ

トコルとして，Hierarchical QoS Link Information Protocol (HQLIP)を設計・実装している[12], [13]． HQLIPはOSPFと同じくリンクステート型の経路制御プロトコルであるが，HANAによる階層的なロケータ割当の仕組みを積極的に利用することで，階層関係を知り，階層的な経路情報を生成するようになっている．またHANAは容易にリナンバリングが行えるように設計されているので，HQLIPではリナンバリング時にも経路情報収束を高速に行えるよう設計されている．詳細は[13]参照のこと．（注1）：HANAで用いられるフラッディングでは，多くの経路制御プロトコルで使われているものと同様に，あるインタフェースから受け取ったメッセージを，まだそのメッセージを転送していないその他のインタフェースに転送する．

3. HIMALIS

システムの基本実装と評価

本節では，HIMALISの基本実装について述べ，その性能を評価する． 3. 1 HIMALISシステムの基本実装 IDベース通信のオーバーヘッドを明らかにし，実用性の検証を行うため，HIMALISシステムの実装を行った．制御プレーンの柔軟性を確保しながら，データプレーンで高いスループットを出すため，識別層でのパケットヘッダ処理やパケット転送処理に関係する部分はカーネル空間実装，それらを制御するシグナリング機能はユーザ空間実装とした． HIMALISソフトウェアは，Ubuntu 12.04 LTS 64bitとLinuxオリジナルカーネル（Vanillaカーネ

ル）バージョン3.4.20をベースに開発した．識別層の

ヘッダ処理機能やIDテーブルの仕組みは，機能別に

三つのカーネルモジュールとして実装した（識別層の基本機能(himalis.ko)，識別層対応UDP (udpidl.ko)，識別層対応TCP (tcpidl.ko)の三つ）．これらのカーネルモジュールは，既存のTCP/IPプロトコルスタックに干渉しないように実装しており，通常のIPv4，IPv6 によるTCP，UDP通信も同時に利用できる． IDベース通信の制御を担うシグナリング機能は，通信オーバーヘッドの少ない識別層対応UDPを用いて実現している．シグナリングパケットを受信したノードは，速やかに受信確認応答を行う．これにより，シグナリングパケット自体の損失と複数のノードを跨るシグナリングシーケンスの遅延の区別を可能とし，応答性を向上させた．また，識別層対応TCPによるデータ通信が不要なノード(HG，DNR，HNR)や，組込み機器等のハードウェア資源の少ないホストでは，tcpidl.koをunload して利用できる作りとした．また，実行速度よりも柔軟性が求められるIDセッションの管理・制御やID ベース通信対応ユーザアプリケーション開発のインタフェースを提供するHIMALISソケットライブラリ等は，ユーザ空間実装とした． HIMALISホスト，HG，DNR，HNRはそれぞれ異なる機能を提供するが，シグナリング機能や名前解決アプリケーション，HIMALISソケットライブラリ

のAPI（以下，HIMALISソケットAPI，後述）など，共通部分が多いため，一種類のソフトウェアとして開

発している（図7）．OS起動後に，設定ファイルを指

(7)

図 7 HIMALISの実装 Fig. 7 Implementation of HIMALIS.

う端末として動作する．シグナリングアプリケーションは，識別層におけるセッションの生成・管理を司り，ホストのネットワーク接続状態（例：マルチホーム，モビリティ）に基づいてIDテーブルを更新する．ロケータ通知アプリケーションは，ネットワークインタフェースの状態を監視し，割り当てられたロケータやハンドオーバイベントをシグナリングアプリケーションに通知する．名前解決アプリケーションは，ホスト名から，ホストのID，ロケータ，公開鍵を解決する機能を提供する．また，DNR，HNRで提供する名前解決の仕組み

は，Domain Name System (DNS)をベースとしており，BIND 9.8.2でHIMALISシグナリングを扱えるよう拡張することで実現している．DNR，HNRでは，ホストID，公開鍵情報をデータベースに格納するため，新たにHID，PKリソースレコードを追加した． IDベース通信対応ユーザアプリケーション開発手段として，HIMALISソケットAPI（表1）をアプリケーション開発者に提供している．これらの関数では，ホストIDとポート番号を渡すために新たに定義したsockid idl構造体（図8）を扱えるようにした． idlconn conntohost( )は，IDセッション構築を行う HIMALIS独自の機能を呼び出すために新規開発した関数である．IDセッション構築により，モビリティやマルチホーム接続といったロケータ非依存の通信機能がアプリケーションに付与される．そして，socket( ) でHIMALIS対応ソケットをオープンし，その他の関数がソケットタイプに応じた動作をするよう手を加えた．HIMALISソケットAPIで従来のソケットプログラミングと共通の関数を提供することで，従来のソケットプログラミングの知識でソフトウェア開発が可表 1 HIMALISソケット API Table 1 HIMALIS socket API. IDベース通信対応システ

ムコール

socket( ), bind( ), connect( ), sendmsg( ), recvmsg( ), getsockname( ), setsockopt( ), getsockopt( ) IDテーブル操作対応 ioctl( ) システムコール IDベース通信対応ライブラリ idlconn conntohost( )※新規開発， getaddrinfo( ), getnameinfo( ), inet ntop( ), inet pton( )

図 8 HIMALIS用新規アドレスファミリーの定義

Fig. 8 Definition of new address family for HI-MALIS.

図 9 システム評価環境

Fig. 9 Environment of system evaluation.

能となる．シグナリングアプリケーションは，ヘッダ処理のような高速な処理は不要なため開発・デバッグの容易なユーザ空間で実装した．パケット送受信はHIMALIS ソケットAPIを用い，シグナリングメッセージの署名やセッション情報の管理等は可能な限り既存のライブラリを用いることで実現している． 3. 2 HIMALISシステムの性能評価実装したHIMALISシステムを評価するため，図9 に示す実験ネットワークを構築した．従来のIP通信と比較する目的で，ホスト間に2台のLinuxルータ設置し，IDベース通信の場合はHGとして，IP通信の場合はIPルータ，NAT，GREをセットアップし，各端末をGigabit Ethernetで接続した．NATはiptables

コマンドを，GREはip tunnelコマンドを用いて構築した．ルータ間は常にIPv4，ルータとホスト間は IPv4またはIPv6で接続した．HGのハードウェア仕様は，CPUがDual-Core 2.67GHz，メモリが2GB，ネットワークインタフェースがGigabit Ethernet 2 ポートのPCである．ホストはGigabit Ethernet 1 ポートのPCである．

(8)

表 2 TCPスループットの比較 (Mbps) Table 2 Comparison of TCP throuputs (Mbps).

図 10 HG，ルータのパケット転送遅延 (µs)

Fig. 10 Packet forwarding delay in HG and router (µs). 本性能評価では，ルータでのパケット転送遅延並びに TCPスループットの比較を行った．なお，IDセッション構築のシグナリングを動作させるため，DNR/HNR を図の位置に接続しているが，DNR/HNRへの通信は，データパス構築後に発生しないため，発生する通信オーバーヘッドは本評価に含まれない． Host1，Host2間のTCPスループットの測定結果を表2と図10に示す．TCPスループットを評価するため，ホスト間でiperfプログラムを実行した．このとき，TCPの最大セグメントサイズを1420バイトに設定し，IPヘッダ，HIMALISのIDヘッダやGREトンネルのヘッダ追加によるフラグメントが発生しないようにした．なお，IDベース通信による評価の際は，通常のiperfプログラムが利用できないため，iperfプログラムをHIMALISソケットAPIで書き換えることで実施した． TCPスループットに関しては，他の方式と比べて HIMALISはわずかな低下が認められるが，各ヘッダのオーバーヘッド（IDヘッダは40バイト）も含めると，ゲートウェイタイプがTCP/IPの場合と遜色ないレートで送受信できることを確認した（表2）．一方で，パケット転送遅延は，従来のIP通信と比べて劣化がほとんど見られない（図10）．次に，追加実装したHIMALISのプロトコルスタックが通信性能に与える影響を明らかにするため，図9 と同様のネットワークでMTUサイズとTCPスループットの関係を調べる．Linuxルータ1台と，ホスト2 台の構築には，Quad-Core CPU 3.1 GHz，8GBメモ図 11 MTUサイズとスループットの関係

Fig. 11 Relationship between MTU size and trouputs.

リ，Gigabit Ethernet 2ポートのPCを用いる．もう一台のLinuxルータは，Dual-Core CPU 2.66 GHz，

4GBメモリ，Gigabit Ethernet 2ポートのPCを用いる．本実験では，MTUサイズを1500バイトから500 バイトまで，200バイトずつ減少させたときのTCP スループットを測定する．本実験はIPv4のみで実施した．スループット測定には表3の比較で用いたものと同じiperfプログラムを用いる．図11に比較結果を示す．TCP/IP及びHIMALIS (Actual)は，それぞれTCP/IP，HIMALISでのiperf

によるTCPスループットを示している．HIMALIS

(Ideal)は，計測したTCP/IP通信のスループットから，HIMALISの通信オーバーヘッド（40バイトの

IDヘッダー）分を引いて計算した理想的な値である．

HIMALIS (Actual)とHIMALIS (Ideal)との差はほ

とんどなく，実装したID層の処理オーバーヘッドは無視できるほど小さいことが分かる．以上の結果より，HIMALISは従来のTCP/IP通信と同程度のパケット処理性能を実現できることを確認した．モビリティ性能については[10]を参照のこと．

4. HANA

システムの基本実装

以下の点を考慮して，HANAソフトウェアの基本実装を行う． • プロトコルメッセージの変更・追加，及び開発時のデバッグが容易であること • 階層的なネットワークを扱えること • 実ネットワークへの展開を容易にするため，様々なハードウェアに対応可能な構造をもつこと • 設計したネットワークの動作検証シミュレーションや，性能評価のためのエミュレーションを容易にすること以下の節では各項目について説明する．

(9)

4. 1 HANAプロトコルメッセージの設計一般にプロトコルメッセージを設計する場合には，以下のような項目で指針の選択が必要となる． • ソフトステート，ハードステートの選択 • バイナリ，テキストの選択 • コネクション型，コネクションレス（データグラム）型の選択

HANAでは，Midﬁxを割振及びPreﬁxの配布は，

HANAサーバの役割である．HANAサーバの障害や HANAサーバへの経路の切断によってメッセージが届かなくなった場合は，HANAクライアントは割振りを受けたロケータを削除するのが適当と考えた．また2. 2. 3で示したように，あるメッセージの逆向きに別のメッセージを送るために，メッセージを一定期間途中経路のノードが記憶しておく必要がある．以上の理由によりHANAではソフトステート方式を選択する．例えばHANAクライアントはMidfixreq メッセージをHANAサーバに向けて送信し，HANA サーバが割振るロケータ空間を確保しMidfixackメッセージを返信するが，割振った後でも定期的にこのやり取りを繰り返すことで，割振り状況を維持する．また途中経路のノードも，Midfixreqメッセージを一定期間覚えておくことで，Midfixackメッセージの送信方向を決めることができる．ソフトステート方式により，HANAクライアントは，HANAサーバが明示的にロケータ割振の削除をしなくても，HANAサーバとの通信が跡絶えた段階で保持している割振を削除する．一般にネットワークプロトコルではプロトコルが正しく設計されている場合でも，実装の不具合等で削除すべき情報が残ってしまうことがあるが，HANAではメッセージ交換をソフトステート方式とすることで情報が残ってしまう事態を回避できる． HANAの実装にあたっては，メッセージフォーマットにテキストを利用する．これはテキストデータでのメッセージ交換は，サイズが大きくなるという欠点があるが，ログ確認やデバッグが容易という利点があるためである．コネクションタイプは，フォーマットをテキストにしたので，コネクション型，すなわちTCPを利用する．TCPを利用することでメッセージサイズが大きくなっても，データグラムサイズを意識したフラグメント処理等が不要となる．テキストでのパラメータのやり取りでは，各ノードでメッセージ構文解析及び構文に従ったメッセージ作図 12 HANAメッセージの BNF 表記（一部抜粋）

Fig. 12 BNF expression of HANA messages (ex-cerpt).

図 13 TCPコネクション中に流れるテキストメッセージ

Fig. 13 Text message transmitted in TCP connec-tion. 成が必要となる．構文解析部は，Haskell言語により C言語の構文解析・作成コードを生成させる．図12は，HANAメッセージのBNF表記である．純粋なBNFではなく，後にCのコードを生成するたための特殊な意味をもつTagNamingと呼ぶキー

ワードやunsinged intを意味するunitといった型が記述されている．ここではタグの詳細説明は割愛する． Haskellで書かれたコードは図12のBNFから，C言語で記述されたメッセージの構文解析・作成コードを生成する．その結果，HANAプロトコルメッセージはTCPコネクションの中を図13に示す形式で送受信される． 4. 2 階層を扱うためのサブノードの設計と実装 HANAは階層を意識したロケータ割振プロトコルであることを意識し，ノード内の動作の最小単位として「サブノード」と呼ぶ概念を提案する．ノード内には複数のサブノードが定義され，各サブノードにはインターフェースが一つ，または複数対応付けられる．サブノードの構成例を図14に示す．図14は図6のネットワーク構成に，上流HANAノード二つを加えたものである．Sと書かれたサブノードはHANAサーバとして動作し，Cと書かれたサブノードはHANA クライアントとして動作する． HANAサーバは，上流に対してはHANAクライアントとなる．よって下流インタフェースに対してはサーバの動作をするサブノードが定義され，上流インタフェースに対してはクライアントの動作をするサブノードが定義される．途中のルータはメッセージを中継するがHANAクライアントでもある．HANAクラ

(10)

図 14 サブノードの接続 Fig. 14 Connection of subnodes.

イントR1とC1には，二つともクライアントの動作をするサブノードが一つ定義され，そのサブノードが全てのインタフェースを操作する．R1はHANAプロトコルメッセージも中継するが，この機能は全ての HANAクラアントの動作をするサブノードに共通のもので，C1はインタフェースを一つしかもたないので中継動作をしないだけである．図14中のHANAサーバの動作を規定するCLI例を図15 に示す（行末の「\」は次の行にも継続することを意味する）．serverという名前をもつノードは，

server-upper1とserver-upper2，server-lowerの三つのサブノードから構成される．そのうち，サブノードserver-upper1は10000番のsubnodeclassと呼ぶ定義を参照している．10000番のsubnodeclassでは，どのようなmidfixreqメッセージを送信するかが，またインタフェースはeth0を制御していることが記述されている．図15のmidfixreq以降の構文は，図13 のmidfixreq以降の構文と同じとなっている．図15 のCLIの構文解析も，メッセージフォーマットの構文解析と同じく，Haskellで処理されたC言語の構文解析コードにより実行される．なお実際には，subnodeclassにはmidfixofferメッセージなど，全てのメッセージの定義が記述される．また図14中のHANAサーバは最上位階層ではないので，具体的なロケータの値を記述しない．サブノードの定義は複雑に見えるかもしれないが，同じ階層に属し，上流と下流のインタフェースの接続関係が同じであれば，ノード名とそのノード名を冠したサブノード名を除いて，同じ設定でよい．よって典図 15 サブノードの定義例

Fig. 15 Examples of subnode definition.

型的なネットワーク構築例を用意しておけば，ネットワーク構築時に毎回新しく用意する必要はない．

以上述べたように，サブノードの概念を導入したことで，階層的な動作の記述・実現，またデバッグが容易となる．またHANAのCLIとHANAパケットフォーマット，更にログメッセージも共通のテキスト形式としBNF表記で記述することで，メッージやCLI，ログの変更・追加を容易なものとしている． 4. 3 HANAソフトウェアのモジュール設計 HANAノードは基本的に隣接ノードとしか通信をしない点と，メッセージフォーマットをテキストとしたことを念頭にHANAソフトウェアのモジュール設計をする．モジュールとしては以下の三つの機能に切り分け，それぞれを別々のプロセスとした（図16）． • プロトコルを処理する中核機能(hanad) • 隣接ノードの発見機能(hanapeerd) • カーネルの物理インタフェースのロケータ情報と経路情報を書き込む機能(hanaroute) これらのプロセスをまとめてHANAプロセス群と呼ぶ．これらのプロセスは，HANAサーバかHANA クライアントかに関係なく，実ネットワーク環境で稼動するHANAノード全てに基本的に導入される．これらのプロセス群をPC/Linux (Ubuntu 10.04 LTS)上に実装した．PC/Linuxにおいてこれらのプロセスを稼動させることでHANAプロトコルによるロケータの自動設定が可能となる．複数のインタフェースをもつPCはルータとして動作させる．そのさい，リンクステート型の経路制御プロトコルとして，HANAの階層関係を活用するHQLIPプロトコル（2. 2. 4参照）を利用する．ロケータ空間は64bitまで対応できるように設計してある．これはInterface ID部を除いたIPv6の Preﬁxと同じビット数である．

(11)

図 16 PC/Linux上の HANA プロセス群 Fig. 16 HANA processes on PC/Linux.

以下，各プロセスについて説明する． 4. 3. 1 hanad hanad はプロセス群の中心となるプロセスであり，HANA プロトコルだけを動かすことと， HANA/HQLIPの両方のプロトコルを動かすことができる．hanadは他のノード中のhanadプロセスとコネクションを確立し，HANA及びHQLIPプロトコルメッセージを交換する．管理者はhanadに tel-net等でコネクションを確立し，hanadに用意された

Command Line Interface (CLI)により操作及び情報

の取得をすることができる．このCLIは他のプロセスも利用しており，それらのプロセスは，hanadにTCP 接続し操作及び情報の取得を行う． hanadのCLIは4. 2で述べたノードやサブノードを定義するコマンドや，ログの形式を定義するコマンドなどで構成される． 4. 3. 2 hanapeerd hanapeerdはIPv6リンクローカルマルチキャストを用いて，同じL2ネットワーク上に存在する隣接ノードを発見する．続いてhanapeerdはhanadとノード内でTCP接続し，CLIを用いて，hanadが隣接ノードのhanadとTCPコネクションを確立するコマンドを実行する．これにより隣接hanad同士がTCPコネクションを確立する．IPv6のリンクローカルアドレスはDHCPや手動設定なしで通信に利用できるため，HANAによるロケータ割振・割当が行われる前に hanad同士のコネクションを確立できる． 4. 3. 3 hanaroute

hanarouteは，hanadのCLIを用いてhanadのロケータや経路に関する情報を受取り，カーネルに反映させる．具体的には，インタフェースのロケータ設定や，経路表の次ホップ情報などである．hanadと hanarouteとを分けていることで，HANAの基本的な機能を実現するhanadの変更なしに，HANAを様々なOS環境に適応させることが可能となっている．

5. HIMALIS

と

HANA

の適用

HIMALISとHANAの適用例を，これまで述べてきた設計と基本実装の適用，及び，それらの応用の観点から紹介する． 5. 1 階層型広域HANAネットワーク環境構築広域ネットワークテストベッドJGN-X [14]では，市販のルータを利用して，仮想ルータ(Virtual Router, VR)を提供している．我々は，JGN-X上のVR 10台，及び実験室のPCやPC内で起動する仮想マシン (Vir-tual Machine, VM)を用いて，200台規模のHANA

広域ネットワークを構築し運用している（図17）．PC 及びVMには上述のHANAプロセス群がそのまま導入され，それぞれ，HANA対応のPCルータや各種サーバとして稼動している．コアルータとなるVRは， HANAソフトウェアが機能ごとにプロセスで分割されていることを利用して，HANAプロトコル処理は，別PCで行っている（詳しくは後述）． JGN-X上にHANAで構築したネットワークのコア部分は，HIMALISのトランジットネットワークとしても利用される．エッジに当る拠点ネットワークは HIMALISのエッジネットワークとしても利用され，全国5箇所に分散配置されている．図17ではそのうちの3拠点を示している．図17中のコアネットワーク，データセンタネットワーク及びHIMALIS/HANA統合ネットワークについて説明する． 5. 1. 1 コアネットワークコアネットワークを構成するVRはJGN-Xより10 台提供されており，実際の設置場所は日本中に分散している．我々が直接hanadをVR上に実装して起動するのは，VRの利用制限によりできなかったので，外部の PCでhanadを起動し，VRのCLIを用いて制御することとした．このために対象となるVRのOSのCLI に対応するようにhanarouteに修正を施した[15]． HANAプロセス群は，利用するポート番号を変更すれば1台のPC上で複数組起動することが可能なので，全10台のVR用のHANAプロセス群は全て1台の PC上で起動している（図18）．各hanadはVR制御用のVLANを用いてVRに接続し，CLIによりインタフェースのロケータ設定や経路情報を投入する．図18

(12)

図 17 JGN-Xをバックボーンとした 200 台規模ネットワーク Fig. 17 Network of 200 nodes on JGN-X backbone.

図 18 Virtual Router (VR)の構成 Fig. 18 Construction of Virtual routers (VRs).

中のL2スイッチには下流のHANAノードが接続され

る．下流のHANAノード中のhanadはHANAサーバ内のhanadのうちの一つとHANA/HQLIPメッセージを交換する．一方，上流とのデータの送受信は， VRに向かうことになる．このようにして，実質的に VRをHANA/HQLIPプロトコルに対応した状態として運用できるようにした．本実装も，HANAのモジュール分割により容易に実現できた． JGN-X上の各VRには図18で示すようにロケータ空間が設定されている．ロケータに関わる設定はこれのみであり，下流のロケータ空間及びVRも含む全てのインタフェースアドレスは，全て階層的に自動で設定される．既に述べたようにHANAはロケータのリナンバリングも容易に行えるよう設計されている．例えば図17 中のミニデータセンタ上流の東京側VRのロケータ空間を別の空間に変更した場合，ミニデータセンタの末端のVMにPrefix変更の情報が5秒程で伝わり，30 秒程で経路情報も含めて安定する．この間，大阪側 VRから割当てられているPrefixは変更されていないので，そのPrefixから生成されるロケータを利用した通信は影響を受けない． 5. 1. 2 データセンタネットワークデータセンタは，HTTPサーバとなるVM 200台で構築されており，二つのPCルータ，GW1とGW2 により外部と接続されている．それぞれの外部接続ルータは異なるVRと接続されており，異なるロケータ空間，10.2.1/24と10.3.1/24とを割振られている．内部の各VMには二つのロケータが割当てられる．例えば図17中では，1台のVMに10.2.1.6と10.3.1.6 とが割当てられている．このVMには外部からこの二つのロケータによってアクセスが可能となり，各ロケータに対応する経路は，東京のVRとGW1を通る

(13)

経路と大阪のVRとGW2を通る経路とになる． 5. 1. 3 HIMALIS/HANA統合ネットワーク HIMALISノードを接続するためのバックボーンネットワークにHANAを導入したHIMALIS/HANA統合ネットワークにおいては，HANAによりネットワーク全体のロケータ割当てが階層的に行われ，HIMALIS により端末が利用するロケータを決定する．図17に示すように，HIMALIS/HANA統合ネットワークは，異なる二つのルータ，仙台のVRと大阪の VRに接続され，それぞれ10.1.2/24と10.3.2/24とを HANAにより割当てられる．DNR1∼2及びHNR1∼ 2はそれぞれ図17に示されたロケータが割当てられている．HIMALISホストが接続されるHIMALISエッジネットワークは，HG1∼3により上流とは無関係のロケータが割振られる．これは，HANAでは，上流から割振られたロケータの一部，若しくは独自に設定されたロケータ，若しくはその両方を下流に割振ることが可能であることを利用している．HIMALISホストは，例えば，172.16.1.4と2002:db8:1::4のIPv4と IPv6の二つのロケータを異なるインターフェースに割当てられる． HIMALIS/HANA統合ネットワークでは上流への経路の障害が発生すると，HANAにより即座に，その上流から割振られたロケータが利用できないことが，下流に通知される．その情報を契機にHIMALISノードが通信に用いるロケータ情報を更新し，即座に通信障害を回避する． 5. 2 IDベース通信対応ミドルウェア HIMALISソケットAPI（表1）を用いてソースコードを書き換えることで，既存の有用なアプリケーションをIDベース通信対応させることが可能である．しかしながら，膨大な数のアプリケーションソースコードを書き換え，その一つ一つを保守するのは非常に困難である．HIMALIS環境に最適なアプリケーション実装を目的とする場合は，HIMALISソケットAPIを用いた開発が推奨されるが，最適化が必ずしも必要でない場合や，手軽にIDベース通信対応させてみたい場合はより簡単な手段が望まれる．そこで，我々は，ソースコードの書き換えをせず既存アプリケーションのIDベース通信対応を可能とするミドルウェアを開発した． Linuxでは，アプリケーション起動時にソケットライブラリが読み込まれる．この原理を利用して，ミドルウェアは起動時に読み込まれるソケットライブラリ図 19 HIMALISミドルウェア Fig. 19 HIMALIS middleware.

をHIMALIS対応版に置き換える（図 19）．そして，ミドルウェアが，関数に渡される情報の相互変換（例：宛先ホストのIPアドレス <=> 宛先ホストのID）を行うことで，既存のアプリケーションがIDベース通信に対応できるようにしている．我々は，本ミドルウェアを用いて既存のWebサーバやストリーミングサーバアプリケーションが，ソースコードの書き換えなしにIDベース通信対応できることを実証した[16]． 5. 3 モバイルセンサ収容HIMALISネットワークネットワーク層プロトコルに依存しない移動通信とセキュリティを実現するIDベース通信技術は，将来のモノのインターネット技術，マシンツーマシン通信を利用した人間中心サービス[17] への利用が期待される．我々は，センサデバイスをもち，センサネットワークに接続する組込み無線端末（モバイルセンサ，または MS）と，センサネットワークとエッジネットワークを接続し，MSの通信を中継する小型無線端末（モバイルゲートウェイ，またはMG）を開発した．MSとMGはそれぞれRaspberry Pi model BとAndroidタブレットをベースとし，各OS（MSはRasbian 3.2.27，MG はAndroid OS 4.2.2）に，3. 1で述べたHIMALIS カーネルモジュールのうち，識別層の基本機能 (hi-malis.ko)と識別層対応UDP(udpidl.ko)を組み込んだ．なお，識別層でTCPを利用しないため，識別層対応TCP(tcpidl.ko)は組み込まなかった．これらの実装により，管理者やサービスが，ネットワークを介してMS，MGを検索，通信することが可能となった（実装の詳細は[18]を参照のこと）．図20にMS，MG を用いたアプリケーション例を示す． HIMALISネットワークに，MSとシンク，MGが接続しており，それぞれにIDベース通信機能が実装されている．MSには4種類の環境センサ（温度，湿度，気圧，照度）があり，センシングデータをシンクへ送信する．MSは，省電力無線通信方式である6LoWPAN

(14)

図 20 IDベース通信を用いたモバイルセンサの遠隔制御 Fig. 20 Mobile sensor remote control using ID-based

communication. を用いてMGと通信する．MGは，HGと同様のプロトコル変換機能をもち，センサデータ送受信を仲介する．シンクでは，MSから送られるセンサデータを蓄積する従来の機能の他に，IDベース通信により， MSの検索と直接通信が可能となっている．これにより，配置後のセンサに対して，アップロードするセンサデータの種類やデータ取得間隔などを必要に応じて再設定可能になっている． 5. 4 その他その他のHIMALISシステム及びHANAシステムの応用について簡単に述べる． 5. 4. 1 HANA L3スイッチの実装我々は，HANAをL3スイッチとしては最も普及している規模のハードウェア機器に組み込んだ[8]．実験用PC上でのソフトウェアでは8ポート×各2Gbps の性能だったが，ハードウェア化により48ポート× 各10Gbpsの性能でHANAが利用できる（図21）．ハードウェアL3スイッチへのHANAの移植に際して，前述のhanarouteのソースコードを，ハードウェアL3スイッチのOSであるZebOS/Linuxに対応するように修正を施した．hanadやhanapeerdのソースコードは改変を必要とせず，CPUやOS環境に応じたコンパイルのみで対応させることができた． 5. 4. 2 HANA/SDN連携システム

Software Deﬁned Networking (SDN)は通信の制

御方法をソフトウェアで定義することで，SDNコントローラによりネットワーク全体の機器の集中制御を可能とし，柔軟なネットワークを構築する．SDNネットワーク構築にHANAを利用することで，ロケータ設計・割当を自動化し，保全管理表も同時に自動作成す図 21 実装した HANA 対応 L3 スイッチ Fig. 21 Implementation of HANA-supported L3

switch.

るHANA/SDN連携システムを設計・実装した[19]．

HANA/SDN連携システム上において，SDNコントローラは，hanadのCLIを利用してHANAで自動

割当されたロケータ情報を知り，OpenFlowインタフェースを利用してフローの制御等を行う．従来までは，ネットワーク管理者がロケータ割当情報を設計し，保全管理表を作り，機器に割当てていたが，本システムではHANAがロケータを自動で割当て，保全管理表を作り管理者に提供する．これにより管理者の負担が軽減され，またロケータ設定に関わる人的ミスも防ぐ． 5. 4. 3 インターネット規模HANAエミュレーション HANAプロトコルはインターネット規模でも動くことを想定して設計している．[7] では10,000規模のHANAノードが階層的に接続されている場合に，HANAプロトコルが正しく動作し，ノード間で正しくロケータの割振と割当てが行えることを， StarBED [20]と呼ばれる大規模エミュレーション環境を用いて検証した．トポロジーは実際のASトポロジーから1万ASを抜出したものを利用している．AS のトポロジーは，CAIDA [21]で提供される，実際に計測したものをデータ化したデータを利用している．現在CAIDAのデータを利用して約46000個（2014 年12月時点での観測ASの総数）のASでのエミュレーション実験を行っている．トポロジーから上下関係があるところだけを抜き出し，HANAによるロケータ割当てが正常に動作することを確認する．このエミュレーションでは，HANAが複数プロセスに分割されていることを利用し，プロトコル検証に必要な hanadだけを起動する．

(15)

表 3 1台で利用するためのハードウェアスペック Table 3 Hardware specs for standalone environment.

最小スペック推奨スペック

CPU Intel Core2 Duo 2.0GHz 4 cores/8 threads以上または同等（KVM対応）（KVM対応）

メモリ 8GB 16GB以上

HDD 150GB 300GB以上

NIC GbE x 1 GbE x 3

5. 4. 4 1台のノートPC上でのHIMALISネットワーク環境の構築 HIMALISのIDベース通信を利用したアプリケーションの開発・実験には，複数のHIMALIS対応機器を用意しネットワークに配置する必要がある．これは HIMALIS対応アプリケーションを新規に開発しようとするユーザにとっては，手間のかかる作業である．そこで，HIMALISネットワークの最小構成をKVM を用いて1台のノートPC上で動作するスタンドアロン環境の構築を行い，インストールメディアを用意した[22]．ノートPCでも動作するようネットワーク構成を最適化している．複数の機器でネットワークを構築せずとも，手持ちのPC上に構築し，HIMALISソケットAPIを用いてアプリケーションの開発やHIMALIS の高度化開発ができるようになる．必要なハードウェアスペックは，表3である．

6. むすび

本論文では，高可用ネットワークを実現するため，端末が様々ネットワーク環境に適応して接続し，利用するネットワーク環境を変更しても通信を継続できる，ユーザ主体の高可用性を実現するHIMALISアーキテクチャについて述べた．またネットワークの耐障害性の向上，設計・設定の自動化を図り人的ミスによる障害を取り除く，ネットワーク主体の高可用性を実現するHANAのシステム設計及びソフトウェア実装について述べた． HIMALISシステムを実装するに当り，制御プレーン処理部はユーザ空間に実装し，データプレーン処理部はカーネル空間に実装することで，複雑なシグナリング処理と高速なデータ転送を実現した．またデータプレーン処理部をモジュール化し，HIMALISノードの役割に応じてカーネルにモジュールを追加できるようにした． HANAシステムの実装に当り，階層を扱うためのサブノードの概念の導入した．またプロトコルメッセージの変更・追加，及び開発時のデバッグ容易性を実現するため，メッセージフォーマットとテキストとし， CLIやログと構文を共通化する手法を提案した．更に各種ハードウェアへの可搬性をもたせるため，プロトコル処理部とそれ以外の部分とでプロセスを分割する設計とした．これらのHIMALISとHANAの設計・実装を，様々な環境に適用・応用した．具体的には，HANAによる広域ネットワーク及びHIMALIS/HANA統合ネットワーク，モバイルセンサを収容HIMALISネットワークの構築，IDベース通信対応ミドルウェアの提供，HANA L3スイッチの実装，HANA/SDN連携システムの実装などである．将来の拡張性を考慮し HIMALISシステム及びHANAシステムを設計・実装したことで，様々な適用・応用例に対してネットワーク及び端末の高可用化を実現できた．今後は，これまで設計・実装してきた高可用性ネットワークシステムの社会展開を推進していく．HIMALIS ソフトウェアは，通信中の端末移動を伴うアプリケーション開発・運用基盤として，既に幾つかの教育・研究機関への提供を行っている．これらの機関と連携し，IDベース通信の特性を活かしたアプリケーション開発を行うとともに，テストベッドを構築し，インターネットへの展開を図る．またHANAの各種ネットワークにおける運用経験を活かして，HANAによる構内網や広域網，及びHANA/SDN連携システムを組織ネットワークやNSPの実ネットワークへ展開していく．謝辞本研究を進めるに当り，高可用ネットワークの研究開発をともに実施し，有益な助言をいただいた国立研究開発法人情報通信研究機構の原井洋明氏，ベドカフレ氏に深く感謝致します．また，本ソフトウェアの設計・開発に当り，ご助言頂きました同機構の戸室知二氏と小針康永氏，並びにご協力頂きました株式会社トランス・ニュー・テクノロジー様，株式会社ビットマイスター様に深く感謝致します．文献 [1] 総務省，“電気通信サービスの事故発生状況（平成 25 年度），” http://www.soumu.go.jp/menu news/s-news/01kiban05 02000072.html, Sept. 2014. [2] D. Farinacci, V. Fuller, D. Meyer, and D. Lewis,

“Locator/ID separation protocol (LISP),” RFC 6830, January 2013.

[3] R. Moskowitz, T. Heer, P. Jokela, and T. Henderson, “Host identity protocol version 2 (HIPv2),” RFC

(16)

7401, April 2015.

[4] V.P. Kafle and M. Inoue, “HIMALIS : Heterogeneity inclusion and mobility adaptation through locator ID separation in new generation network,” IEICE Trans. Commun., vol.E93-B, no.3, pp.478–489, March 2010. [5] Y. Rekhter, T. Li, and S. Hores, “A border gateway

protocol 4 (bgp-4),” RFC 4271, Jan. 2006.

[6] K. Fujikawa, H. Harai, and M. Ohta, “The basic procedures of hierarchical automatic locator num-ber allocation protocol HANA,” Asia Workshop on Future Internet Technologies (AWFIT2011), pp.124– 131, Nov. 2011.

[7] K. Fujikawa, H. Tazaki, and H. Harai, “Inter-AS lo-cator allocation of hierarchical automatic number al-location in a 10,000-AS network,” 2012 IEEE/IPSJ 12th International Symposium on Applications and the Internet (SAINT2012), pp.68–73, July 2012.

[8] 藤川賢治，原井洋明，“ロケータ番号自動割振プロトコ

ル HANA の L3 スイッチへの実装，” 信学技報，NS2014-123, Oct. 2014.

[9] V.P. Kafle, R. Li, D. Inoue, and H. Harai, “Design and implementation of security for HIMALIS archi-tecture of future networks,” IEICE Trans. Inf. & Syst., vol.E96-D, no.2, pp.226–237, Feb. 2013. [10] V.P. Kafle, Y. Fukushima, and H. Harai, “ID/Locator

split-based distributed mobility management mecha-nism,” Wirel. Pers. Commun., vol.76, no.4, pp.693– 712, June 2014.

[11] M. Crawford, “Router renumbering for IPv6,” RFC 2894, Aug. 2000.

[12] 藤川賢治，太田昌孝，“階層化経路制御プロトコルの為の

階層的なロケータ番号自動割振プロトコル HANA の拡張，”信学技報，IA2011-7, June 2011.

[13] K. Fujikawa, M. Ohmori, and H. Harai, “Stable renumbering in link-state routing protocol network,” IEICE Technical Report, IA2014-44, Nov. 2014. [14] JGN–X http://www.jgn.nict.go.jp/ [15] 藤川賢治，小針康永，原井洋明，“階層的なロケータ番号自動割振プロトコル HANA による広域ネットワーク及びミニデータセンタの構築，”信学技報，IA2012-1, June 2012. [16] 福島裕介，ベドカフレ，原井洋明，“既存ソケットアプリケーションを ID ベース通信可能とするミドルウェアの実装と評価，”信学技報，IN2013-205, Oct. 2013. [17] M. Srivastava, T. Abdelzaher, and B. Szymanski,

“Human-centric sensing,” Philosophical Transactions of the Royal Society A, no.1958, pp.176–197, 2012. [18] V.P. Kafle, Y. Fukushima, and H. Harai, “Design

and implementation of dynamic mobile sensor net-work platform for ID-based communication,” IEEE Commun. Mag. – Communications Standards Sup-plement, no.3, pp.48–57, March 2015.

[19] 藤川賢治，原井洋明，“アドレス自動割振機構 HANA の

SDNへの適用，”電子情報通信学会 NV 時限研専第 15 回研究会，July 2015.

[20] T. Miyachi, K. Chinen, and Y. Shinoda, “StarBED and SpringOS: large-scale general purpose network testbed and supporting software,” Proc. 1st In-ternational Conference on Performance Evaluation Methodolgies and Tools, pp.43–58, Oct. 2006. [21] CAIDA http://www.caida.org/home/.

[22] V.P. Kafle, Y. Fukushima, T. Tomuro, H. Abe, and H. Harai, “HIMALIS experiment networks — for re-search on ID-based communication in heterogeneous mobile networks,” IEICE Society Conference, vol.BS-6-20, Sept. 2015. （平成 27 年 10 月 2 日受付，12 月 7 日再受付）藤川賢治（正員） 1995年京都大学大学院工学研究科修士課程情報工学専攻修了．1997 年同大学院博士後期課程情報工学専攻退学．博士（情報学）．1997 年同大学院助手，2006 年ルート株式会社主任研究員を経て，2008 年，独立行政法人情報通信研究機構に入所し，新世代ネットワークアーキテクチャに関する研究に従事．電子情報通信学会，情報処理学会，IEEE 各会員．福島裕介（正員） 2006年東北大学大学院修士課程修了． 2009年同大学博士課程修了．博士（情報科学）．同大学情報科学研究科助教（2010 年），上智大学理工学部特別研究員（2011∼ 2012年）を経て，2012 年独立行政法人情報通信研究機構入所し，ネットワークアーキテクチャの設計・開発に従事．電子情報通信学会，ACM 各会員．