仮想化ノードを使用した非 IP プロトコル開発法と経験 (金田の論文)

全文

(1)

社団法人電子情報通信学会 信学技報

THE INSTITUTE OF ELECTRONICS, IEICE Technical Report

INFORMATION AND COMMUNICATION ENGINEERS 電子情報通信学会 IA 研究会 2010-12-17

仮想化ノードを使用した非 IP プロトコル開発法と経験

金田 泰 中尾 彰宏

*†

日立製作所 中央研究所

185-8601

東京都国分寺市東恋ヶ窪 1-280

*東京大学大学院 情報学環・学際情報学府

〒113-0033 東京都文京区本郷 7-3-1

†情報通信研究機構

113-0001

東京都文京区白山 1-33-16

E-mail: Yasusi.Kanada.yq@hitachi.com E-mail: nakao@iii.u-tokyo.ac.jp

あらましあらましあらまし

あらまし 情報通信研究機構

(NICT)

はネットワーク仮想化技術を使用して自由なフレーム形式をもつ非

IP

プロトコルを 実装可能にした

10 Gbps

級の仮想化ノード

(VNode)

の開発を推進している.このプロジェクトでは,VNodeが研究開発 用ネットワーク

JGN2plus

に導入され,開発者

(JGN2plus

使用者)のためのユーザビリティ向上が課題になっている.そこ で我々は,課題解決のための第一歩として

VNode

を使用した実験用ネットワーク上で

IPEC (IP-Ether-Chimera)

という非

IP

プロトコルを開発・実験してその手順や経験を記述し,そこからユーザビリティに関する問題やノウハウを抽出した.課 題として開発者によるケアレスミスの防止策の必要性,ノウハウとして

Linux PC

による小規模な実験を

VNode

を使用した 広域網の実験にスケールアップすることによって開発を容易化できることがあげられる.今回の実験には広帯域は必要 でなかったが,今後

10 Gbps

の帯域を活用した実験へのスケールアップも比較的容易に実現できるとかんがえられる.

キーワード キーワードキーワード

キーワード ネットワーク仮想化,非

IP

プロトコル,仮想化ノード,アドレス学習.

Development Method and Experience of A Non-IP Proocol Using the Virtualization Nodes

Yasusi Kanada Akihiro Nakao

*†

Central Research Laboratory, Hitachi, Ltd.

Higashi-Koigakubo 1-280, Kokubunji, Tokyo 185-8601

*

The University of Tokyo Interfaculty Initia- tive in Information Studies, Graduate School

of Interdisciplinary Information Studies Bunkyo-ku Hongo 7-3-1, Tokyo 113-0033

National Institute of Information and Communications Technology Bunkyo-ku Hakusan 1-33-16,

Tokyo 113-0001 E-mail: Yasusi.Kanada.yq@hitachi.com E-mail: nakao@iii.u-tokyo.ac.jp

Abstract

In the National Institute of Information and Communications Technology (NICT), 10-Gbps-class virtualization nodes (VNodes) that enables implementing non-IP protocols with any frame format are developed using network- virtualization technology. In this project, because the VNodes have been introduced into the R & D test-bed network called JGN2plus, an important challenge is to improve usability for developers (JGN2plus users). Therefore, we developed and tested a non-IP protocol called IPEC (IP-Ether-Chimera) on the experimental network using the VNodes, described the procedure and experiments, and extracted the problems and knowhow concerning usability. A problem to solve is to develop methods for avoiding careless mistakes by developers, and an obtained knowledge is that a combination of a small-scale experiment using connected several Linux PCs and a scaled-up experiment on wide-area network reduced the complexity of the development. This experiment did not need wide bandwidth, but this method will enable scaling up the experiment utilizing 10-Gbps bandwidth relatively easier.

Keywords

Network virtualization, Non-IP protocol, Virtualization node, Address learning.

1. はじめに

インターネットはもともと単純なネットワークをめざしてきたが,さま ざまな用途につかわれるようになるのにしたがって複雑化してきた.

インターネットにおいてはすべてのプロトコルがインターネット・プロト コル(IP)をベースとしているため,さまざまなプロトコル機能が干渉 しあい,それらを共存させるために調整が必要になって複雑化する とともに,新機能を追加するのが困難になってきている.一方でクラ ウド・コンピューティングの普及などによってインターネットへの要求 がさらに多様化・高度化するなかで,IPv4やIPv6などをベースとす るプロトコルでは対応が困難になっている.

このような状況のなかで新世代ネットワーク・プロジェクトにおいて はIPにとらわれない新プロトコルを開発し,そのうえでIP上では困

難だったさまざまなアプリケーションの実現をはかろうとしている.そ のベースとなっているのが仮想化ノード・プロジェクトにおいて開発 されているネットワーク仮想化技術と仮想化ノードである.このプロ ジェクトは情報通信研究機構 (NICT)を中心とし,東大,NTT,

NEC,富士通,日立が協力してすすめている.このプロジェクトにお

いては,独立かつ自由に設計された機能を実装した複数の仮想 ネットワークがひとつの物理ネットワーク上で同時に動作できる環境 を実現することをめざしている [Nak 10b].実装されるべきネットワー ク機能としてはIPにかわるプロトコルやアプリケーション依存の機能 などがある.ここで開発された仮想化ノードは2010年度に研究開 発用テストベッド・ネットワークJGN2plusに導入されたが,新プロトコ ルなどの研究開発にひろく使用できるようになる予定である.

この報告においては実験用の非 IPプロトコルIPEC (IP Ether

(2)

Chimera)の開発からえられた経験を報告する.このプロトコルの特 徴や実験結果などについては別途,報告している[Kan 10].

このプロトコルの開発目標はつぎのとおりである.第1に,仮想 化ノードの開発に関連した目標は,仮想化ノード使用のネットワーク 上で非IPの新プロトコルが開発でき動作するのを実証することであ る.この目標はさらにつぎの3つの副目標にわけられる.

• 仮想化ノードによって構成されたネットワークの動作検証とユー ザビリティの検証をおこなう.

• 今後の仮想化ノード使用による新プロトコル開発のテストケース

をつくる(開発者にノウハウを提供する).

• 仮想化ノードが新プロトコルの実験に適していることをデモする.

第2に,プロトコルの研究に関する目標は,単純で汎用性のある 非IPプロトコルの確立をめざした研究に踏みだすことである.すな わち,IP上で実現すると多層化し複雑化する機能をEthernetやIP の長所をあわせもつ1層の単純な非IPプロトコルにより実現し,

Ethernetスイッチの学習アルゴリズムを拡張してループをふくむ任

意の構造のネットワークにおいて使用可能な転送アルゴリズムを実 現することをめざしている.

この報告はこれらの目標のうち第1の,プロトコル開発のテスト ケースという面,そのなかでもとくにユーザビリティとノウハウ獲得に 焦点をあてる.まず2章においてNICTの仮想化ノードと仮想化 ネットワークについてかんたんに説明し,3章において実験用プロト コルIPECについてかんたんに説明する.4章において,仮想化 ノードを使用した新プロトコル開発の一般的な手順を意識しながら,

今回のIPEC開発のながれを説明し,5章においてそこでえられた 経験的知識を記述し,6 章において結論をのべる.

2. 仮想化ネットワークと仮想化ノード

この章においては仮想化ネットワークとそれを構成する仮想化 ノードについて説明する.なお,これらについては,もうひとつの報

告[Kan 10]においてよりくわしく記述している.

2.1 仮想化ネットワーク

仮想化技術はまずコンピュータ本体における記憶の仮想化や CPUなどの分割使用(タイムシェアリング)の技術として発展してき たが,最近は仮想マシン(VM)というかたちでコンピュータじたいが 仮想化されている.ネットワークに関してはVPNによるWANの仮

想化がすすめられてきた.最近ではデータセンタ内のネットワーク もVMと連携しつつ仮想化されてきている.

新世代ネットワークの研究においては,こうしたネットワーク仮想 化技術を発展させて,あたらしいプロトコルを他のユーザに影響を あたえることなしに開発できる環境(ユーザの組織ごとにきちんとア イソレートされた環境)をつくることがもとめられている.仮想化ノー ド・プロジェクトは,このような状況のもとでまず研究者が自由にプロ トコルを設計できる環境をつくることを目標としているが,さらにはそ れを商業的展開も可能なようにすることもめざしている.

ネットワーク仮想化においては,仮想化前のネットワークと仮想化 後のネットワークとが共存する.仮想化前の下層のネットワークを仮 想化ネットワーク(virtualized network)とよび,仮想化後の上層の ネットワークを仮想ネットワーク(virtual network)とよぶ.

2.2 仮想化ノード・プロジェクトにおける仮想化ネットワーク 仮想化ネットワークに関してはすでに多様な研究がおこなわれ,

多様なモデルが提案されている. そのなかで PlanetLab [Pet 02]

[Tur 07]がもっとも有名だが,GENI [GEN 09]は現在進行中の注目 するべきプロジェクトである.仮想化ノード・プロジェクトのモデル

[Nak 10b]は管理に重点をおいている.

このモデルにおいては,物理的なネットワーク(図2.1)は1個また は複数個のドメインによって構成される.各ドメインはドメイン・コント ローラ(DC)によって管理される.ドメインのなかには仮想化機能を もつつぎの2種類のノードが存在する.

• 仮想化ノード(VNode): 仮想ネットワークにおける中継機能をも つノード.

• アクセス・ゲートウェイ(AGW): 仮想ネットワークとユーザ端末や ユーザのネットワークとのあいだの中継機能をもつノード.

VNodeどうしはGRE (Generic Routing Encapsulation)のようなプロト コルによるトンネルによってむすばれるため,途中のルータやスイッ チに依存せず自由なトポロジーをもつネットワークが構成できる.

各VNodeはつぎの3種類の構成要素によって構成されている.

• プログラマ(Programmer): パケットに対する処理をおこなう構成 要素である.ハードウェアとソフトウェアとで構成される.パケット に対する処理を仮想ネットワークの開発者がプログラムできるた め,プログラマとよばれる.1個の仮想化ノードのなかに複数個 存在することができる.

• リダイレクタ(Redirector): 通信データ(パケッ ト)を他の仮想化ノードや他の種類のノードか ら受信したり,それらに通信データを送信した りする転送機能をもつ構成要素である.

• VNodeマネジャ(VNode Manager): 仮想化 ノード全体の管理をおこなう構成要素である.

1個の仮想化ノードのなかに1個だけ存在す る.通常,ソフトウェアだけで構成される.ネッ トワーク全体を管理する管理サーバであるドメ イン・コントローラ(DC)からの指示にもとづい て動作する.

また,このモデルにおいては,PlanetLabにな らって,仮想化ネットワーク上につくられる仮想 ネットワーク(または仮想ネットワークの構成要素 の集合)をスライス(slice)とよぶ.スライスは複数 の仮想ノードとそれらをつなぐ仮想リンクとで構成 される(図2.2参照)が,このモデルにおいてはこ

VNode

ユーザのネットワーク1

AGW Server PC

AGW PC

PC ユーザのネットワーク2 C

C C

VNode

R P

VNode

R P

VNode

R P

VNode

R P VNode

R P

VNode

R P ドメイン1

C

DC

DC

DC

Server

VNode

R P

ドメイン2

ドメイン3

VNode: 仮想化機能をもつノード

R: リダイレクタ(仮想ネットのパケットをP に回送 するノード)

P: プログラマ(プログラマブルなノード) C: 仮想化機能をもたない(conventional) ノード DC: ドメイン・コントローラ

RC: リダイレクタ制御装置 AGW: アクセスゲートウェイ

: トンネル

SMC: サービス・モジュール・カード リダイレクタ

リダイレクタ リダイレクタ リダイレクタ プログラマ

プログラマ プログラマ プログラマ

RC VNodeマネジャマネジャマネジャマネジャ

XML-RPC XML-RPC

XML-RPC() VLAN () AX-6000

CLI SMC

図2.1 仮想化ノード・プロジェクトにおけるネットワークの物理構成

(3)

れらをつぎのようによぶ[Nak 10a].

• ノードスリバー(Node Sliver): 1個の仮想化ノードのなか(プログ ラマのなか)に存在する計算資源である.プロトコル処理やノー ド制御などを実行するのに使用する.大別すると,Linux (Ubun- tu 9.1)を搭載したVMであるスローパス(slow path)と,ネット ワーク・プロセッサによるファストパス(fast path)の2種類がある.

• リンクスリバー (Link Sliver): ノ ー ド ス リ バー間を結合する仮 想リンクを意味する.

通常は こ と な る 物 理 ノード内にあるノード スリバーを結合する.

リンクスリバーは複数 のVNodeやAGWに またがって存在し,リ

ダイレクタが設定し資源管理するトンネルによって実現される.

3. 実験用プロトコル IPEC とその実験環境

実験用プロトコルIPECについてはもうひとつの報告[Kan 10]に おいてよりくわしく記述しているが,ここでは開発経験の記述に必要 なだけの内容を記述する.

3.1 アドレスとフレームの形式

IPECにおいてあつかうアドレスとフレーム(パケット)の形式は図 3.1のとおりとする.すなわち,まずアドレス(ながさ8バイト)に関し てはつぎのとおりである.

• ホストID: アドレスの下位(仕様上は可変長だが実装上は4バイ

トに固定している)はホストIDをふくむ.

• グループID: アドレスの上位はグループIDすなわち複数個また は1個のホストによって構成されるグループのIDをふくむ.

グループIDはロケータと解釈することもできる.

また,フレーム・ヘッダは 22バイトあり,上位から順につぎの フィールドから構成されている.

• 受信者アドレス: フレームを受信するべきホストのアドレスを指定 する.上記のアドレス形式をしている.

• 送信者アドレス: フレームを送信したホストのアドレスを指定す る.上記のアドレス形式をしている.

他のフィールドについてはここでは説明を省略する.

Total len

Dest addr Src addr Src GID length

Age Payload パケット形式(any frame)

0 2 10 18 20 22 バイト

アドレス形式

0 Prefix length 4 8 バイト

Group ID (network address)

Host ID

図3.1 プロトコル・フォーマット

3.2 スライス構成

NICT白山リサーチラボにおいて,IPECに関する実験をおこなう ために,3個のVNode,3個のAGWのうえに生成した図3.2のよう な構成のスライス(仮想ネットワーク)を使用した.この図にはこのス ライスに接続した端末(Linux PC)も記述し,またVNodeやAGWが もつテーブルの内容も記述している.これらのテーブルの意味につ いてはもうひとつの報告[Kan 10]において説明している.

スライスの構造は物理ネットワークによって制約される一定の範 囲のなかで,設計者が自由に選択することができる.すなわち,設 計者は物理ノード数をこえない範囲で自由にスライスを構成する ノードスリバー(仮想ノード)の個数をきめ,それらのあいだのリンクス

リバー(仮想リンク)を自由に設定することができる.

現在の仮想化ネットワークにおいては,スライス構成は設計者が XMLを使用して記述するようになっている.スライス定義の例を図 3.3にしめす.これは図3.2の構成をもつIPEC_Slice_000という名 称のスライスの定義の一部だけをしめすものである.

スライス定義はおおきくわけてつぎの4つの部分からなっている:

1)リンクスリバー定義,2)ノードスリバー定義,3)ノードスリバーとリン クスリバーとの結合の定義,4)ノードスリバーの物理ノード(VNode,

AGW)への配置(マッピング)の定義.スライス定義には物理装置

名と論理装置名の両方が記述され,それ らの対応も記述される.図3.2にもその両 方を記 述 して いる . たと えば,論理名

AGW1は物理名 agw-f5に対応してい

る. また,ノードスリバー NS00は物理

ノードVNode 2内にある.これらの対応

は配置定義によって指定される.

現在はスライスを生成するために開発 者がXMLによる定義を記述する必要が ある.しかし,仮想化ノード・プロジェクト においては,ちかい将来GUIなどを使用 してより容易にスライスを定義できるように することが検討されている.

4. 開発における関係者の役割 と開発法

この章においては,はじめに仮想ネット ワークの開発における関係者の3つの役

割[NTT 11]についてのべ,つづいて新

プロトコル開発のながれにそって操作法

Link sliver

Node sliver Node

sliver Node sliver

Node sliver

Link sliver

図2.2 仮想ネットワークの論理構成

(スライスの構造)

VNode 1 (NS03) PC1

(UT14)

AGW 1 (agw-f5)

VNode 3 (NS02) VNode 2

(NS00)

AGW 3 (agw-f6)

PC3 (UT11) AGW 2

(agw-f0) PC2 (UT00)

P1 P2

P3 P2 P3

P1

P2 P1 Tunnel 284/285 P3

T12

Tunnel 278/279 IPSec

tunnel 256/257

GRE link sliver (LS01)

Len Dest prefix Port Age 32 x00000100 P1 1 32 x00000002 P2 1 32 x00000030 P3 1 Forwarding table

(DC 経由でロード)

Forwarding table (in Node Sliver)

Len Dest prefix Port Age 32 x00000100 P2 1 32 x00000002 P3 0 32 x00000030 P1 1 Group = x00000100

Group = x00000002

ID = x00000011

Len Dest prefix Port Age 32 x00000100 P3 1 32 x00000002 P1 1 32 x00000030 P2 0 Forwarding table (in Node Sliver)

Forwarding table (in Node Sliver) ID = x00000021

ID = x80000022 Grp = x00000002 Forwarding table (DC 経由でロード)

GRE link sliver (LS04)

GRE link sliver (LS03) GRE link sliver

(LS05)

Forwarding table (DC 経由でロード) VNM

rp-nh0

VNM rp-nh3

VNM rp-nh2 IPSec tunnel 258/259 PC3’

(UT01)

ID = x80000022

D-IP: 192.168.14.23

Y-IP: 192.168.40.43 D-IP: 192.168.13.22

Y-IP: 192.168.40.32 D-IP: 192.168.11.21

Y-IP: 192.168.40.11

D-IP: 192.168.11.24 Y-IP: 192.168.40.14

DT01 Y-IP: 192.168.40.51 Z-IP: 192.168.50.51 DT02 Y-IP: 192.168.40.52 Z-IP: 192.168.50.52

Dest ID Tunnel (SPI) x80000022 278/279

Dest ID Tunnel (SPI) x00000021 256/257 x80000022 258/259

Dest ID Tunnel (SPI) x00000011 284/285

ループ ループループ ループ

D-IP: 192.168.14.11 D-IP: 192.168.13.11

D-IP: 192.168.11.11

図3.2 スライス構成 (学習後の状態)

(4)

[NTT 11]や開発法を説明する.

4.1 役割

仮想化ノード・プロジェクトにおいては,仮想ネットワークの生成と 運用にかかわる役割は,運用者,開発者,一般ユーザという3者に わけられている.

• 運用者(オペレータ): 実ネットワークを管理する.開発者は運用

者が登録する.

• 開発者(デベロッパ): 仮想ネットワークを生成し管理する.すな

わち,ノードスリバーのプログラムを開発し,スライスを設定し,一 般ユーザを登録する.

• 一般ユーザ: 仮想ネットワークを使用する.端末の設定と端末に 関する情報は一般ユーザがポータルに登録する.現在は端末 数と同数の一般ユーザIDが使用される.

ただし,今回の新プロトコル開発においてもそうだったが,実験の

場合はひとりの研究者がすべての役割をはたすことが多いとかん がえられる.上記3者のいずれもが,ポータルとよばれるWebイン ターフェイスを介してこれらの登録・設定をおこなう1

4.2 スライスごとの操作

開発者はポータルにログインして,まず図3.3のようなスライス定 義をファイルから入力してスライス予約(Slice Reservation)する.そ してつぎのような一連のスライス操作(Slice Operation)をおこなう.

• 結合(Bind): ノードスリバーとリンクスリバーを結合する.これら

はスライス予約時に生成されるが,初期状態ではまだ結合され ていないので,この操作によって結合する.

• 実行(Run): スライスを実行状態にして,ノードスリバーのプログ

ラム起動やパラメタ設定などができるようにする.このときスロー パス・ノードスリバーに関してはVMが起動される.

• 端末へのパケットふりわけのための設定: AGWから端末へは パケットをふくむ受信ホストIDによってふりわける.そのため,

パケットふりわけ用のデータを抽出するパケット上の位置を設定

する(Egress抽出設定).IPECにおいては受信者アドレスがパ

ケット先頭から2~10バイトめにあり,その後半4バイトが受信 者IDであるから(図3.1),オフセットが6,ながさは4である.こ の設定は開発プロトコルの形式にかかわる中核の設定である.

• サービス開始(Service Start): 上記の各設定が終了するとサー ビスを開始することができる.ただし,後述する一般ユーザの設 定がなされていなければ実際にはサービスされない.

4.3 一般ユーザごとの操作

一般ユーザごとの操作は開発者と一般ユーザとが連携しておこ なう.まず,開発者がポータルにてつぎの一連の操作をおこなう.

• 一般ユーザの登録: まだ登録されていないときは,まずユーザ 登録(User Registration)する.管理上必須の情報はユーザID とユーザが属する物理AGW名である.現在のシステムにおい ては各ユーザ(端末)はいずれか1個のAGWだけを使用する.

• アクセス設定(Access Configuration): スライス操作画面でボタ ンをおしてアクセス設定画面を表示し,スライスにアクセスできる 一般ユーザを指定する.すなわち,登録ずみ一般ユーザのリス トのなかからスライスにアクセスしてよいユーザを選択する.

• 受信ホストIDの登録: Egress中継登録画面において,AGWに おける端末へのパケットふりわけの際に使用する受信ホストID とともに,物理AGW名,ユーザIDを設定する.パケットから抽 出されたデータにマスクをかける機能があるのでマスク値も指定 す る が , 通常は –1 (IPEC に お い て は 4 バイ ト な の で

0xFFFFFFFF)を指定する.開発プロトコルの動作をきめる中核

の設定である.IPECでは本来この情報を学習によって獲得した いが,現在は固定的に登録する必要がある.

• IPsec情報の設定: AGWから端末へは認証とセキュリティのた

めIPsecを使用して通信するので,そこで使用するモード(トンネ

ルなど),プロトコル,暗号化モード,暗号化キーなどをIPsec SA 設定において指定する.端末の識別にはユーザIDではなく,こ こで指定するSPIが使用される.そのため,SPI以外の値は各 ユーザが共通の値を使用できるが,SPIだけは一意な値を指定

1 なお,著者の使用経験からつぎのようなことがわかった:ひとりの開発者は 複数のセッションをひらくことはできないので,ひとつのプロジェクトのために 複数の開発者IDを用意したほうがよい場合がある.

<?xml version="1.0" encoding="UTF-8"?>

<slice-design>

<slicespec name="IPEC_Slice_000">

<sliverdef>

<linkSlivers><!-- 以下はリンクスリバーの定義 -->

<linkSliver name="LS01" subtype="GRE" type="link">

<vports><vport name="e1"/><vport name="e2"/></vports>

</linkSliver>

… </linkSlivers>

<nodeSlivers><!-- 以下はノードスリバーの定義 -->

<nodeSliver name="Node2" type="prog">

<vports><vport name="vp1"/><vport name="vp2"/>

<vport name="vp3"/></vports>

<hierarchy>

<sliverdef>

<nodeSlivers>

<nodeSliver name="SP00">

<vports><vport name="vip1"/><vport name="vip2"/>

<vport name="vip3"/></vports>

<instance subtype="KVM" type="SlowPath_VM">

<resources><!-- ノードスリバーの計算資源 -->

<resource keyword="cpu" value="1"/><!-- CPUの個数 -->

<resource keyword="arch" value="x86_64"/>

<resource keyword="memory" value="2048"/>

</resources>

<params><!-- 以下はあらかじめ用意されたVMイメージ -->

<param keyword="bootImage"

value="http://…/KVM_Ubuntu910Server32.img"/>

</params>

</instance>

</nodeSliver>

</nodeSlivers>

<linkSlivers>…</linkSlivers>

</sliverdef>

<structure>… </structure>

<params>…</params>

</hierarchy>

</nodeSliver>

<nodeSliver name="AGW2" type="agw">

<vports><vport name="vp1"/></vports>

</nodeSliver>

</nodeSlivers>

</sliverdef>

<structure><!-- 以下はノードスリバーとリンクスリバーとの結合の定義-->

<bind name="w11"><!-- w11 は AGW2 と LS01 を結合する -->

<vport portname="vp1" slivername="AGW2"/>

<vport portname="e1" slivername="LS01"/>

</bind>

</structure>

</slicespec>

<!-- 以下はノードスリバーの物理ノードへの配置 (マッピング) -->

<mapping slice="IPEC_Slice_000" vnetwork="NICTtestbed">

<amap node="AGW2" vnode="agw-f0"/>

<amap node="Node2" vnode="rp-nh0"/>

</mapping>

</slice-design>

図3.3 スライス定義の例 (一部省略)

(5)

する.この値は端末で指定する値と一致する必要がある.

開発者による設定後,まずユーザごと(使用する端末ごと)にポー タルにログインし,スライス設定(Slice Configuration)により端末の IPアドレスと参加するべきスライスとを登録する.この登録の結果え られるSPIなどのIPsec関連の情報を端末(Linux PCを仮定)にお いて図4.1(a)のように設定する[VNP 10].ここではIPsecの外側の IPアドレスとしてAGWには192.168.13.11,端末には192.168.13.22 を使用し,ingress SPI, egressSPIとしてそれぞれ278と279を使用 することを仮定している.また,AGW-端末間にはGREトンネルが 使用されるため,図4.1(b)の設定が必要である1

flush;

spdflush;

add 192.168.13.22 192.168.13.11 esp 278 -m tunnel -E 3des-cbc

"abcdefghijklmnopqrstuvwx" -A hmac-sha1

add 192.168.13.11 192.168.13.22 esp 279 -m tunnel -E 3des-cbc

"abcdefghijklmnopqrstuvwx" -A hmac-sha1 (a) IPsecの設定 ifconfig eth0:1 192.168.13.1 netmask 255.25.255.0 -arp

iplink add gretap0 type gretap remote 192.168.13.11 local 192.168.13.1 ifconfig gretap0 up -- gretap0 を link up させる必要がある.

[ ifconfig gretap0 mtu 1381 ]

(b) GREの設定

図4.1 端末におけるGREとIPsecの設定

4.4 ノードスリバー用プログラムの開発とローディング 現在のIPEC実装にはスローパス・ノードスリバーを使用してい る.ファストパス・ノードスリバーを開発する際には他におなじ環境 がないので,最初から仮想化ノードを使用して開発する必要がある だろう.しかし,スローパス・ノードスリバーに関しては通常のLinux PCを数台使用すれば仮想ネットワークにちかい環境で開発しテスト することができるので,まずそうするのがよいだろう.IPECに関する

Linuxマシン上での予備開発については5章においてのべる.

現在,スローパス・ノードスリバーはUbuntu上のKVMにおいて 動作する.非IPによる通信にはLinuxのpromiscuous modeを使用 する.通常の環境ではpromiscuous modeにおいてEthernetパケッ トをあつかうが,仮想化ノードにおいてはEthernetヘッダは必要な い.すなわち,非IPによる通信においては,先頭から自由にきめた フォーマット,IPECにおいては図3.1のフォーマットをあつかう.

プ ロ グ ラ ム 上 で Ethernet type を 記 述 す る と き は , つねに ETH_P_ALLという値を指定すればよい(IPのときはETH_P_IPとい う値が使用される). この値はパケット上の Ethernet typeの値が

ETH_P_ALLであることをあらわすのではなく,パケットがEthernet

typeフィールドをもたないことをあらわす.

これらのノードのあいだではGREトンネルが使用されているが,

それによって任意のフォーマットを使用した通信がIPネットワークを

1 仮想化ノード・プロジェクトにおいては,このようにAGW-端末間において

も,またVNode間やVNode-AGW間においてもGREトンネルが使用されて

いる.このようにやや複雑なパケット形式が使用されている理由は,これらす べてのリンクにおいて任意の非IPフォーマットによる通信ができるようにする ことである.それぞれのリンクにおけるパケット形式はつぎのとおりである.

ユーザ

PC AGW VNode

Ethernet IPEC

IP IPSec

IP GRE

Ethernet IPEC

IP GRE

介したVNode間およびVNode-AGW間でできるようになっている.

スローパス・ノードスリバーのプログラムは論理インターフェイス eth1, eth2, …を使用して通信する.図3.2 の構成においてノードス リバーは3つのポートをもつので,eth1, eth2, eth3を使用する.

開発者用端末などでプログラムをクロス・コンパイルし,バイナリ・

ファイルをスローパス・ノードスリバー上のVMに転送して起動す る.転送先VMのIPアドレスとポートはポータルのスライス情報 (Slice Info)画面においてLogin Infoのメニュー項目にスライス名を 入力すればわかる.この画面にはノードスリバーごとにそのVMに 関する情報が表示される.えられた情報を使用してsloginコマンド やsshコマンドなどによってログインし,クロスコンパイルしたバイナリ が存在するPCからscopyコマンドやsftpコマンドなどによってバイ ナリ・ファイルをVMに転送する.この状態では各インターフェイス

(ethiとする)はリンクアップしていないので,インターフェイスごとに

つぎのようなコマンドを入力してからプログラムを起動する.

ifconfig ethi up

4.5 端末用プログラムの開発

端末間の通信を可能にするためには,ノードスリバーだけでなく,

端末用のプログラムも開発する必要がある.端末用プログラムにお いてもノードスリバーと同様にpromiscuous modeを使用し,Ethernet

typeとしてETH_P_ALLを指定して通信する.ただし,ノードスリ

バーにおいてはインターフェイスとしてethiを使用したのに対して,

端末においてはgretap0を使用する(4.3節参照).端末のデータ用 インターフェイスは通常1個だけなので,gretap0だけを使用する.

5. 開発上の話題と経験

この章においては,IPECの開発経験のなかで前章までに記述し ていない特筆するべき事項を記述する.

5.1 Linuxマシン上での仮想化ノード用プログラム開発法

4.4節においてのべたように,IPECのプログラム開発はまずLi-

nux PC上でおこなった.スライス上でのテストにおいてはプログラム

の修正などにやや時間がかかるので,このように通常のLinux PC 上で予備開発しテストしておくのが有効である.

PCを6台ほど用意すればより 実 環 境 に ち か い テ ス ト が で き る が,実際には2台だけでテストし た.図5.1のように各PCがもとか らもつ物理インターフェイス(NIC) にくわえて2枚ずつNICを追加し てクロスケーブルで接続し,1台 にはノードスリバーのプログラム

vnode.c,もう1台には端末のプログラムterm.cをのせてテストした.

3枚のNICのうち1枚(図ではeth0)は基本的に制御・管理用で

ある.これらのPC上または他のPCからこれらのPCにログインした りファイル転送したりするために使用した.のこりの2枚はデータ転 送用であり,promiscuous modeで使用する.Promiscuous modeに おいてはIP通信とはちがってNICを直接指定するので,端末用 PC上ではeth1からパケットを送信するプログラムとeth2からパケット を受信するプログラムとを動作させ,VNode用PC上ではeth1-eth2 間で双方向にパケットを転送するプログラムを動作させれば,最低 限の通信テストができる(図の矢印).ただし,端末用のプログラムに おいては,実際の端末で使用するgretap0のかわりにeth1, eth2な どが使用できるようにプログラムする必要がある.また,1台のPC上

端末用 PC

VNode PC LAN ハブ

eth0 eth1 eth1 eth0

eth2 eth2

図5.1 Linuxマシン上での仮 想化ノード用プログラム開発

(6)

でVNode用のプログラムを複数個動作させたりVNode用のプログ ラムと端末用のプログラムを同時に動作させるには,インターフェイ

ス(eth1, eth2, …)の番号を自由選択できるようにする必要がある.

さらにNICを増設すれば複数のVNodeや3台以上の端末もシ ミュレートできる.ただし,複数のプログラムが動作できるためには CPU時間を独占しないようにプログラムする必要がある.それでも なお,PCが2台だけではタイミングに依存するテストはやりにくい.

なお,このテストにおいてはEthernetのNICをそのまま使用して いるため,任意のプロトコルがそのまま使用できるとはかぎらない.

Ethernetパケットの最初の12バイトには2個のMACアドレスがふく まれ,つづく部分はtypeフィールドであるが,IPECにおいてはそこ に他のフィールドがふくまれ,アドレス長もことなっている.カードや ドライバによっては想定外の動作をする可能性があるとかんがえら れるが,IPECのテストにおいてはこれまでのところとくに問題はお こっていない.いずれにしても,Ethernetにこのような形式のパケット をながすことは局所的なネットワークでなければできないし,このよう なパケットを使用するとEthernetスイッチを使用することもできない.

当初はこのような使用によって問題が発生することもかんがえて,

VNode, 端末共通のヘッダ・ファイルIPEC.h上でIPECoverEthernet というスイッチをオンにすればEthernetヘッダをつけるようにした.

仮想化ノードを使用したテストにおいても最初はEthernetヘッダつ きの形式を使用したが,すくなくとも今回はその必要はなかった.

5.2 失敗経験

まだ環境やマニュアルが整備されていないので,IP以外による通 信プログラムを記述した経験がほとんどない著者がIPECの実験と デモのための環境を構築するときにつまずいたいくつかの点を報告 する.ただし,これらの問題点は近日中に解消されるはずである.

• 端末設定において発生した問題: VNode-端末間の通信プロトコ ルには,認証・セキュリティと自由な非IP通信を可能にするた め,GRE over IPSecという,やや複雑なプロトコルが使用される.

そのため,図4.1に記述したように端末の設定がやや複雑にな り,まちがえやすい.しかも,並行して進行中だった開発ではス ライス上でIPを使用していたため,図4.1の設定にさらにIP通 信のための設定が追加されて複雑化していた.そのなかで非IP プロトコル通信にどの部分が必要なのかが明確になっていな かったため,パラメタ誤記などで通信できないときの原因究明に 時間がかかった.しかし,非IP通信に必要な設定が図4.1に記 述したものだけであることが事前にわかっていれば,さらには適 切なツールが使用できれば,もっと迅速にできたはずである.

• スライス操作において発生した問題: スライスの生成においては

人間(開発者)が介入するべき回数が多い.そこで誤操作などを

するとエラーが発生することがある.著者も誤操作によってとまど うことになった.しかし,エラー発生時の対策がマニュアルに記 述されれば,とまどう機会は減少するだろう.

• インターフェイスのリンクアップ: 4.4節に記述したように,ノードス リバーのプログラムを動作させるまえにインターフェイスをリンク アップする必要があった.著者はそれをしなかったため,パケッ トがながれない理由がしばらくわからなかった.つまり,リンクアッ プしなくてもエラーが発生しないので,わかりにくい.リンクアップ が必要なのは端末側も同様であり,図4.1(b)にはその設定がふ くまれているので,それを使用すれば問題ない.しかし著者はこ こでもその設定をいれていなかったためにつまずくことになった.

• 32ビットと64ビット混在による問題: 最近はIntelのCPUを搭載

したPCでも32ビットのものと64ビットのもの(x86-64)が混在する ようになっている.著者も,端末プログラムを32ビット専用に書い ているのに,気づかずに64ビットのLinux上でコンパイルして異 常な動作を起こしてしまった.OSが64ビット版であることをあら かじめ知っていればすぐに気づいただろうが,知らなかったため にバグの原因がわかるまでに時間がかかった.

6. 結論

仮想化ノードを使用したIPECの開発と実験をおこなってその手 順や経験を記述し,そこからわかったユーザビリティに関する課題 やノウハウ等を記述した.課題としては,開発者によるケアレスミス の防止策の必要性,スライス仕様やスライス操作の実装上の改善点 などがある.また,えられたノウハウとして,Linux PCどうしをつなぐ 実験からはじめて仮想化ノードを使用した広域実験にスケールアッ プすることによって,仮想化ノードのための開発が容易になることが ある.局所的な環境で1Gbps以下の通信を実験するだけならば

LinuxPCどうしをつなぐだけでもできるが,10Gbpsのリンクを使用し

た実験や広域での実験,ファストパスを使用する実験などは困難で ある.仮想化ノードを使用すれば,Linux PC上で開始した実験を 容易にそういった実験にスケールアップできるとかんがえられる.

IPECの 開 発 のな か で, い く つ か軽度 の失 敗を か さねたが ,

JGN2plusに導入された仮想化ノードを一般ユーザが使用する際に

は,これらの点でユーザが失敗しないようにツールを開発し,スライ ス開発法をマニュアル化するべきである.プロジェクトは実際その方 向にむかっている.とくに著者はこの開発からえられたノウハウ等を 今後の新プロトコル開発にやくだつようにまとめていきたい.

謝辞

IPECの開発と実験にあたり,NICT,東大,NTT,NEC,富士通 研,日立による仮想化ノード・プロジェクトの参加者各位,とくにNEC の元木顕弘氏,富士通の渡辺紀一氏,NTTの高橋紀之氏,ア ラクサラの木谷誠氏に意見や助力をいただいたので感謝する.

参考文献

[GEN 09] The GENI Project, “Lifecycle of a GENI Experiment”, GENI-SE-SY-TS-UC-LC-01.2, April 2009, http://groups.geni.- net/geni/attachment/wiki/ExperimentLifecycleDocument/- ExperimentLifeCycle-v01.2.pdf?format=raw .

[Kan 10] 金田 泰, “仮想化ノードを使用した実験用非 IP プロトコ

ルの開発”, 電子情報通信学会IN研究会, 2010-9.

[Nak 10a] Nakao, A., “Network Virtualization as Foundation for Enabling New Network Architectures and Applications”, IEICE Trans. Commun., Vol. E93-B, No. 3, pp. 454–457, March 2010.

[Nak 10b] 中尾彰宏, “ネットインフラを用途別に“スライス” 柔軟な 機能拡張の実現に効果”, 日経コミュニケーション, June 2010.

[NTT 11] 山本猛仁, 築島幸男, 高橋紀之, 中尾彰浩, “プログラ マブルな仮想化ネットワークにおける NW 管理モデルの提案”,

電子情報通信学会,新世代ネットワーク研究会, 2011-1 (予定).

[Pet 02] Peterson, L., Anderson, T., Culler, D., and Roscoe, T.,

“A Blueprint for Introducing Disruptive Technology into the In- ternet”, ACM SIGCOMM Computer Communication Review, Vol.

33, No. 1, pp. 59–64, January 2003.

[Tur 07] Turner, J., Crowley, P., Dehart, J., Freestone, A., Heller, B., Kuhms, F., Kumar, S., Lockwood, J., Lu, J.,Wilson, M., Wiseman, C., and Zar, D., “Supercharging PlanetLab - High Per- formance, Multi-Application, Overlay Network Platform”, ACM SIGCOMM Computer Communication Review, Vol. 37, No. 4, pp.

85–96, October 2007.

[VNP 10] 仮想化ノードプロジェクト, “デベロッパーズマニュア

ル”,未公開.

Updating...

参照

Updating...

関連した話題 :

Scan and read on 1LIB APP