Ditto Subsytem の提案

本章では，StarBEDとDeterLabの２つの検証施設を対象として，提案システム の設計を行う．それぞれの検証施設は，StarBEDはSpringOS, DeterLabはEmulab

toolsと呼ばれる検証施設管理ツールを有している．StarBEDは，ネットワーク

技術やセキュリティに関する検証を目的として構築した．一方，Emulab-basedの 検証施設であるEmulabやDeterLabでもStarBEDと同種の検証が行われている．

StarBEDとEmulab-basedの検証施設は同種の検証を目的として構築されている

が，検証施設の実験シナリオの記述，検証施設の資源を制御するツールと実験流 れに関してのツールの補助の考え方の違いがある．

5.3.1 StarBEDとDeterLabの差異

本節では，StarBEDでTopDLで記述された検証環境の設定ファイルを用いて検 証環境を構築する方法を考える．はじめに，StarBEDとDeterLabの差異について

考える．StarBEDおよびDeterLabはネットワークに関するソフトウェア，技術，

プロトコルの検証を目的とした検証施設である．これらの検証施設は，異なる実 験シナリオ記述言語を使用しており，利用者に提供されている検証施設管理ツー ルも異なっている．

ここで，両検証施設における検証施設の利用手順を以下に示す．

1. 利用者は検証のシナリオおよび検証環境のトポロジを作成する．

2. 利用者は検証に用いる資源を自身が作成したシナリオ及び検証環境のトポ ロジに従って検証施設から借り受ける．

3. 利用者は検証環境を自身が作成した検証環境トポロジに従ってネットワー クスイッチやPCサーバに対して設定を行う．

実験シナリオの作成はStarBEDはK言語またはシェルスクリプトで記述し，

DeterLabではEmulab-tools用に拡張されたNSEで記述する．資源の予約に関し

ては，StarBEDは事前に期間を指定しPCの台数とVLAN ID 数を申請するが，

Emulabでは実験シナリオを実験のキューに入れておけばシナリオに記述された

資源の確保が行われる．

5.3.2 資源予約と割り当て

Ditto subsystemには複数の利用者が利用することを想定すると，Ditto subsystem で実行される実験シナリオごとに資源の割り当てを記録したデータベース(DB) が必要になる．StarBEDもDBを持っているが，今回は運用を変更しないことを 想定しているため，StarBEDのデータベースを使用することはできない．そこで，

Ditto subsystemでもDBを持つことで，StarBEDからDitto subsystemで借りてい るノードとDitto subsystemに投入されている実験シナリオで使用している資源の マップを撮る必要がある．

5.3.3 Ditto subsystemの要求

本論文では，StarBEDで使われている検証施設管理ツールや実験シナリオ駆動 システムに変更なしにEmulab NSEの実験シナリオを駆動可能とするシステムを 考える．また，StarBEDの資源に対しての操作はSpringOSで行うため， Emulab-NSEの実験シナリオをSpringOSの機能として実行可能な形式に変換しなければな らない．よって，StarBEDにEmulab NSEが入力可能で入力されたEmulab NSEは

SpringOSの機能として実行可能な形式に変換するコンポーネントが必要になる．

SpringOSの各機能は個別に制御インターフェースを持っており，SpringOSの

機能として実行可能な形式に変換された情報をもとに各SpringOSの機能を制御 するためのコントローラが必要になる．さらに，Emulab-NSEで記述可能なパラ

メータでSpringOSでは実現するための機能がないものがある．この機能に対し

て機能を追加可能とするためのFunction Adaptorが必要である．

本システムが必要とするコンポーネントは以下の4つである．

• Translator

• Testbed Controller

• Resource Mapper

• Function Adaptor

これら4つのコンポーネントは既存のStarBEDで動いているSpringOSや実験 シナリオ駆動システムに対して改変や影響をあたえるものではない．よって，本 システムはSpringOSのsubsystemとみなすことができる．このように，既存のシ ステムに改変や影響を与えずに他の検証施設の実験シナリオを駆動可能とするシ ステムを本論文ではDitto subsystemと名付ける．

Ditto subsystemの処理は３つにわけられる．

工程1

実験環境のトポロジファイルからSpringOSで設定する部分とFunction Adapter で設定する部分に分類し，それぞれの実行のためのコマンドを作成する処 理である．

工程2

検証施設が運用している資源に関するデータベースから実験環境の構築に 十分な資源が利用できるか問い合わ

せ，割り当てた資源とトポロジファイルの対応付を管理する処理である．

工程3

SpringOSとFunction adapterを実行し割り当てられた資源に設定を投入し 実験環境を構築する処理である．

以下にDitto subsystemの処理手順を示す．

1. Ditto subsystemに対して設定ファイルを入力する．

2. Ditto subsystemはデータベースに対して設定ファイルに記述された検証環

境を構築するのに十分な資源の確保が可能か確認を行う．

3. Ditto subsystemは設定ファイルに記述された検証環境を構築するための

SpringOSに対する命令系を作成する．

4. Ditto subsystemは設定ファイルに記述された検証環境を構築するために必要

な命令系の中で，SpringOSでは対応できないものに関してFunction Adapter 用の命令系を作成する．

5. Ditto subsystem で作成された命令系はTestbed ControllerおよびFunction

Adapterに渡され，それぞれで命令系が実行される．