調査と解説

最下位の機器・サーバ

最下位にネットワーク機器，計算サーバ，ストレージ・サーバなどが位置する． 基本的なネットワーク機能にだけ注目するときは後 2 者はかんがえる必要がないが，IDC, インテリジェント・ネット，アクティブ・ネットなどをかんがえると，これらが重要になる． ネットワーク機器のはたらきがパケットのスイッチングやルーティングであることはいうまでもないが，計算サーバは Web における CGI (Common Gateway Interface), ASP (Microsoft Active Server Pages) などのスクリプトの実行や，アクティブ・ネットにおけるデータ変換 (たとえば動画の階層コーディングなど) などをおこなう． ストレージ・サーバは Web ページやその他のデータを格納し，そのアクセスに対応する．^*

下位インタフェース

上記の最下位の機器と管理サーバとのあいだのインタフェースを下位インタフェースとよぶ． このインタフェースは IEEE P1520 においては L-Interface [Bis 00] とよばれている． 下位インタフェースは基本的に下層の機器，サーバごとに独立した 1 対 1 のインタフェースである． 下位インタフェースには COPS-PR と PIB のくみあわせ，COPS-RSVP [Her 00], SNMP と MIB のくみあわせ，コマンド言語 (CLI) などがつかわれる． このうち CLI は標準化されていないが，汎用性のあるインタフェースである． COPS-PR はプロビジョニングのためのプロトコルであり，COPS-RSVP は資源管理のアウトソーシング (ネットワーク機器から管理サーバへの決定タスクの依頼) のための汎用のプロトコルである． しかし，COPS-PR とくみあわせて使用される PIB や SNMP とくみあわせて使用される MIB は通常，目的ごとにことなる専用のものを使用する必要がある．

これらのインタフェースのなかでどれが主流になるかは現在はまだわからない． 現在有力視されているのは COPS-PR であり，おおくの PIB が標準化提案されているが，現在はまだ標準化途上にある． また，これらが普及するかどうかはまだわからない． SNMP だけは下位のプロトコルとして UDP を使用しているが，他は TCP を使用している． プロビジョニングにおいては大量のデータを転送する必要がしばしばあり，信頼性がひくく，一度に大量のデータをおくることができない UDP はこの目的に適していないとかんがえられる． しかし，SNMP によるポリシー制御は IETF の SNMP Conf (SNMP Configuration Management) WG において標準化がすすめられている． 大量のデータをおくる必要がなく既存の MIB が使用できるばあいには，SNMP が実際にポリシー制御のためにつかわれる可能性もある． また，標準化されていない CLI はマルチベンダ環境では不利だが，汎用コンピュータ用 OS として Unix がひろく普及して比較的少数ののシェル言語がつかわれている現状をみれば，ネットワーク機器においても CLI が比較的少数に淘汰され，de facto 標準となる可能性もある．

下位インタフェースは設定のためだけではなく，ネットワーク機器などから情報を収集するのにもつかわれる． この目的では COPS よりも MIB や CLI がよくつかわれるとかんがえられる．

中間層

中間層はポリシーサーバのような管理サーバである． 通常，管理サーバは内部にデータベースをもっている． おおくのばあい，複数の管理サーバが使用される． したがって，これらをマクロ・コンポーネントとよぶことができるであろう． また，管理サーバにはコンポーネントを追加して機能を拡張できるようになっていることがおおい． 管理サーバじたいがマクロ・コンポーネントであることから，この管理サーバを拡張するコンポーネントはマイクロ・コンポーネントとよぶことができるだろう． マイクロ・コンポーネントとマクロ・コンポーネント，あるいはマイクロ・コンポーネントどうしのインタフェースとしては API がつかわれるであろう． 管理サーバが管理対象オブジェクトの拡張可能なオブジェクト指向モデルをサポートするとき，オブジェクトのインスタンスはデータベースに格納されるが，そのクラスはマイクロ・コンポーネントだとかんがえることができる．

マイクロ・コンポーネントは通常 C++ や Java のような汎用プログラミング言語で記述されるが，これではマイクロ・コンポーネントの開発に時間がかかりすぎて臨機応変に管理サーバの機能を拡張することができない． したがって，それをさらにこまかいプリミティブ・コンポーネントをくみあわせることによって構成できるようなアーキテクチャをとることがのぞましいとかんがえられる．　GUI においてはこのようなプリミティブ・コンポーネントの設計はむずかしいが，それによる工数削減の効果もおおきいとかんがえられる． プリミティブ・コンポーネントは API として提供するにはこまかすぎ，また手続き型言語のセマンティクスになじまないばあいもあるとかんがえられるので，視覚的言語あるいはスクリプト言語のようなかたちで提供されるべきだとかんがえられる．

マイクロ・コンポーネントは管理サーバにだけ存在するのではなく，下層のネットワーク機器や計算サーバ，ストレージ・サーバにも存在しうる． アクティブ・ネットにおいてはマイクロ・コンポーネントを動的にネットワーク機器や計算サーバなどに注入することになる． 管理サーバがネットワーク機器や計算サーバ，ストレージ・サーバにおくりこむポリシーも，マイクロ・コンポーネントとみなすことができる．^*

^* 下層のネットワーク機器や計算サーバ，ストレージ・サーバにおいては，ポリシーはそのふるまいに影響をあたえる一種のプログラムであり，したがって，マイクロ・コンポーネントとみなされる． しかし，中間層の管理サーバにおいては，ポリシーはデータとしてあつかわれるので，ポリシーそのものは管理サーバにとってのマイクロ・コンポーネントではない．

上位インタフェース

中間層のサーバどうしは情報を交換する必要がある． このためのインタフェースが上位インタフェースである． IEEE P1520 のドキュメントにはこのようなインタフェースは明記されていない． 交換すべき情報としては，たとえばネットワークのトポロジー，データ・パス (たとえば MPLS のパス (LSP)) などがある． 上位インタフェースは任意の管理サーバ間で情報を交換するための多対多のインタフェースである． 情報を交換の必要が発生するたびに管理サーバ間で 1 対 1 で交換するのはあまり効率がよくないとかんがえられるので，その情報じたい，またはそれへのインデクスをいったん共通データベースにおくのがよいとかんがえられる． このデータベースは HP 社においては CMDB (Configuration Management Database) とよばれている． このデータベースの形式として有力なのは CIM (Common Information Model)，RDB, XML，ディレクトリ (DEN) である．^* 上位インタフェースとしては，これらをアクセスするための SQL, XML, LDAP, またそれらの API を記述するための CORBA, Java などがつかわれるであろう．

複数のポリシーサーバ間でポリシー (のインスタンス) を共有し集中管理するときは，その高速よみだしのために共通データベースに DEN の形式で格納し LDAP によってアクセスすることが必要だとかんがえられる．^** しかし，これほど高速性がもとめられないデータについては，このデータベースは仮想的でもよい． すなわち，データベースの実体は各管理サーバだけがもち，それへの参照 (reference) だけを共通データベースがもつか，または名前サーバだけがあればよいとかんがえられる． CORBA をつかえばこのような実装は容易にできる． このようにデータをできるだけコピーしないことによってデータベース間の整合性 (integrity) を容易にためすことができる． しかし，実際にデータを使用するときにはオブジェクトのコピーが必要になる． CORBA 2 にはオブジェクトをコピーしてわたすことができないという制約があるため，CORBA 2 をつかうと真のオブジェクト指向インタフェースを実現するのがむずかしい． CORBA 3 においてはこの制約は解消されるはずだが，まだ実現されていない． また，CORBA にはつぎのような問題点もある． ひとつはことなる ORB の実装間での互換性がとぼしく，それを混在させることができないことである． もうひとつは，さまざまの実装のなかで普及がすすんでいる Visibroker と Orbix は高価だという点である． したがって，CORBA の採用はポリシー / プロビジョニング・サーバの普及にあたって，その裾野をせまくする可能性がある．

CIM はオブジェクト指向設計言語である UML にもとづいているのでオブジェクト指向インタフェースの実現に関して制約は存在しないが，現在の CIM は各オブジェクトが実現するべきメソッドについては規定していないので，オブジェクト指向データベースのモデルではあっても，オブジェクト指向ソフトウェアのモデルではない． すなわち，ソフトウェアの設計においては CIM にたよることができない．^***

層間の関係

上位インタフェースと下位インタフェースとはかならずしもくべつする必要はないとかんがえられる． 実際，下位インタフェースとして CORBA，Java, XML などを使用することも可能であり，そうすれば階層をわける必要はなくなる． しかし，すくなくとも現在はおおくのネットワーク機器において CORBA, Java, XML などをつかうのは適切でないとかんがえられているので，上位と下位とのくべつは存在するとかんがえられる． サーバ内データベースとこの共通データベースとを統合することもかんがえられるが，それはレガシーな管理サーバにおいてはむずかしいし，注意しなければ効率の低下をまねくであろう．

管理サーバ間が CORBA でむすばれるなら，これ以上の階層は論理的には必要がないとかんがえられる．^* コンソール (GUI, Graphical User Interface) や OSS は管理サーバとおなじ層にあるとみなすことができる． IEEE P1520 においては汎用の中間層とそのうえのアプリケーション層とをくべつし，両者をむすぶインタフェースを U-Interface，アプリケーション層とユーザとのインタフェースを V-Interface [x] としているが，ここではおなじ理由によってこれらもくべつしない．

参考文献

• [Bis 00] Biswas, J., Vicente, J., Kounavis, M., Villela, D., Lerner, M., Yoshizawa, S., and Denazis, S., “Proposal for IP L-Interface Architecture”, IP Subworking Group, IEEE P1520, 2000.
• [Her 00] Herzog, S., ed., Boyle, J., Cohen, R., Durham, D., Rajan, R., and Sastry, A., “COPS usage for RSVP”, RFC 2749, IETF, January 2000.