議論

5.7.1 Translator

TranslatorがTopDLをSpringOSの手続きに変更した際に幾つかのセマンティク スの変更が行われている．これは，TopDLがDeterLab Federation Architectureで 使用することを前提に設計されているため，幾つかの属性が検証施設連携を前提 に設計されているためである．例えば，Emulab-baseの検証施設ではOSのデフォ ルトイメージを設定する項目があり，TopDLでもOSイメージを設定する項目が 存在する．一方StarBEDではデフォルトイメージは用意されておらず，この部分

はTranslatorによる変換時に我々が用意したディスクイメージ情報に書き換えら

れる．

5.7.2 Testbed Controller

SpringOSの機能の実行にはいくつかの順番がある．SpringOSの機能を用いて

PCにOSをインストールする際にbootに関する設定を事前に入れる必要がある．

一方，OSのインストール後はOSのboot情報を再度変更する必要があり，OSのイ ンストール前後でbootパラメータの変更が必要になる．ネットワークスイッチの 設定に関しても，ポートに指定されたVLAN IDを設定する前に現在のVLAN ID の設定を一度clearした上で設定を投入する必要がある．このように，Translator で変換されたコマンドに対して，暗黙的な処理をControllerで行わなければなら ない．

5.7.3 Resource Mapper

今回のケーススタディでは，PCとVLAN ID情報のみをResource Mapperでは 管理している．検証施設では，PCとVLAN ID以外にも実験環境または実験シナ リオの実行という観点から管理が必要な情報があると考えられる．それぞれ管理 が必要な情報が異なってくる可能性があるため，どのようにこれらの情報を統一 的に管理するか今後検討する必要があると思われる．

5.7.4 Function Adapter

本研究では，帯域幅と遅延をStarBED上で再現するためにNCを用いた．エ ミュレーションのシナリオとしては，NCを用いることによりEmulab-base検証 施設と同等のパラメータ設定がStarBEDで可能になった一方，DeterLabが独自に 開発しているSEERなどの機能の設定は現状行うことができない．これらを実行 可能とするためには，それぞれの機能をFunction Adapterとして実装しなければ ならない．

5.7.5 Ditto subsystem

Ditto subsystemは検証施設に機能の追加というかたちで付加価値を与えること

が目的である．本論文でのケーススタディから，従来の検証施設管理ツールが持っ

ていない機能を従来のツールに手を入れないで実現することができることを示し た．このケーススタディを通して今後の検討事項について議論を行う．

本論文ではDitto subsystemのケーススタディとしてTopDLの記述でSpringOS 上に実験環境を構築するために必要な機能を検討し，translatorとFunction Adapter を作成した．しかし，ORBITやGENI, Fireではことなる実験環境記述を持って おり，現状のDittoの仕組みではそれぞれの検証施設ごとにTranslatorとFunction

Adapterの作成が必要になってしまう．抽象的に実験環境を記述する記法があれ

ば，それぞれに対応するTranslatorを作成する必要がなくなり，Dittosubsystemの 実装コストを減らすことができる．抽象的な記法を考えるときに必要になってく ることはネットワークに関連する実験が持ちうるパラメータの整理が必要である と考えられるため，この点を今後検討する必要がある．

また，今回のケーススタディでは実験環境を構築することに主眼が置かれてい る．一方，実験の中には実験環境のトポロジに現れないが実験の実行に必要な ノードが発生する場合がある．例えば，ネットワークに外乱を発生させるための パケットジェネレータやソフトウェアにおけるストレッサーがこの事例にあたる．

このような機能をDitto subsystemに加えることは可能であると思われるが，実験 シナリオに記述があった場合にTestbed側で機能にどのように変換するかについ ては考察が必要である．

5.7.6 Ditto subsystemの仮想化環境への適用

今回のケーススタディでは，仮想化を用いない実験環境を対象とした．これは，

TopDLおよびSpringOSがどちらもベアメタルのPCサーバとネットワークスイッ

チを対象としているからである．そこで，Ditto subsystemで仮想化を用いた実験 環境の構築を考える．

はじめに，検証施設管理ツールに対しての考察を行う．仮想化されたノードや ネットワークが記述された場合に現状の検証施設管理ツールに仮想化に対応した

Function Adapterを導入する方法がある．２つ目の方法として，検証施設管理ツー

ルを仮想化に対応したものに変更する方法がある．本論文では，StarBEDで使わ れているSpringOSを修正することなくDitto subsystemを実現することを想定し

たが，Ditto subsystemが他の検証施設管理ツールにも適用が可能であるかについ ての議論は今後行わなければならない．

次に，実験環境記述に対しての考察を行う．今回使用したTopDLはベアメタ ルの資源についての記述のみを対象としている．よって，TopDLに仮想化された 資源に関する記述を可能とする拡張を行う方法が考えられる．また，TopDLでは なく他の仮想化された資源を記述可能な記述式を採用することでDitto subsystem で仮想化に対応する方法が考えられる．この場合，他の記述を用いる場合にDitto

subsystemに制約が発生するかどうかについて今後検討を行わなければならない．

5.7.7 異なる記述形式を組み合わせた実験環境記述

異なる種類の実験記述を組み合わせることを考える．はじめに，複数の実験環 境記述により構築された実験環境があった場合を考える．異なる記述により構築 された実験環境は，実験のシナリオにより組み合わされて新しい実験として行う ことできると考えられる．他の考えとして，レイヤ２やレイヤ３の環境が記述さ れたネットワークトポロジが展開された実験環境に対して，ノードの役割が記述 された環境記述を組み合わせた実験の実行も考えられる．これらの場合，複数の 実験環境記述を組み合わせることにあらたな実験の創出が行われるが，記述を組 み合わせるときにどのように実験環境が組み合わされるか検討しなければなら ない．

5.7.8 Ditto subsystemの他の検証施設管理ツールおよび検証環境構築記述への適

用について

ここでは，他の検証施設管理ツールおよび検証環境構築記述への適用について 述べる．例として検証環境構築記述に関してはProtoGeniのRspecやPlanetlabの 構築記述について適用の可能性について述べる．また，検証環境構築ツールに関 しては，EmulabのEmulab toolsやGeniのOmnitoolに関して適用の可能性につい て述べる．