SNMPの今後と他のプロトコル CMIP/SNMPv2

始めにも述べましたが、SNMPはCMIPへの移行を前提に過渡的なプロトコルとして制定されたものですので、その将来像はCMIPというのが建て前になっています。ところがCMIPのCは"Common(共通)"ではなく"Complex(複雑)"だとからかわれているようにCMIPへの移行はまだまだ先の話の様です。また最近、SMP（Simple Management Protocol）として開発が進められてきたものがSNMPv2（SNMP version 2）として公表され注目を浴びています。

SNMPの最大の弱点は、ネットワークの規模が大きくなった時に、管理のための通信量が大きくなることです。これはポーリング手法であることと単純なデータ検索手法しか提供されていないことに起因しています。また、マネージャ間通信のサポートやセキュリティ機能の強化もSNMPの課題の一つです。
CMIPもSNMPv2もSNMPの弱点を補う機能を持っていますが、既に業界標準の地位にあるSNMPが急に置き替わることはなく、しばらくは共存状態が続くものと思われます。では、CMIPとSNMPv2について簡単に紹介することにしましょう。

CMIP(CMOT/CMOL)

CMIPのTCP/IP対応であるCMOTのプロトコル階層を図10に示します。

図10 CMOT(CMIP Over TCP)のプロトコル階層

また、以下のコマンド（CMOTではサービスと呼ばれています）がサポートされています(表5)。

表5 CMIPのコマンド

SNMPでは管理オブジェクトはMIBとして固定的に定義されていなければだめでしたが、CMIPではこの機能により、管理オブジェクトの生成／削除を動的に行なうことができ、ネットワークの動的な管理が可能になります。CMIPではアプリケーションプログラムも管理オブジェクトとして生成することができ、その起動/停止等が可能になります。これはシステム運営上の管理能力のアップも期待できることを意味しています。

●CMIP独自の機能 

これ以外にもCMIPには、"Scoping"と"Filtering"の２つの強力な機能が付加されています。

＜Scoping機能＞
"Scoping"はマネージャからの管理操作が機器の一部分を対象にするか全体を対象にするかを指定できる機能です。
例えば、ある製品のシリアル番号管理を想定した場合に、製品全体でのシリアル番号だけとするか、その製品を構成しているボード群のシリアル番号まで含めるかといった区別が可能になります。

＜Filtering機能＞
"Filtering"は管理オブジェクトの値に応じた条件設定を提供する機能です。
例えば、ルータが使用するルーティングテーブルから"ipRouteAge > 100"の条件を満足するもののみ検索するといったことが行なえ、ＳＮＭＰより効率的な運用が可能です（管理のためのデータのトラフィック量を減少できます）。
また、ＣＭＩＰにおける管理オブジェクトにはオブジェクト指向の考えが強く導入されており、これも特色の一つになっています。

●CMIPの課題と対策 

以上の様に、機能的には期待できるCMIPですが、残念なことにその複雑さから実際の機器への登載は遅れ気味です。この現状を打破するためにプロトコルスタックの階層を減らしたアプローチがCMOL(CMIP over Logical Link Control)として提唱されていますので、それについても簡単に触れて置きましょう(図11)。

図11 CMIPとCMOLのプロトコル階層

通常のCMIPはネットワークの最上位レベルであるアプリケーション層（OSIモデルの第７層）で動作しますので、全ての階層のプロトコルの実装が必要となり、実装上非常に多くのメモリとCPUパワーを必要とします。これがCMIPの普及上最も大きな障害になってきた訳です。

＜CMOLの特徴(利点＞
CMOLはCMIPを第２層のデータリンク層までで実現することによりこの障害を克服しようとするもので、CMOLエージェントはわずか20Kバイト以下のメモリしか必要としないと言われています。このレベルであればMS-DOSマシンでも十分登載可能でしょう。SNMPでも70Kバイトから80Kバイトのメモリを必要としますし、通常のCMIPでは数百Kバイトが必要となりますので、魅力的なアプローチであると思われます。

＜CMOLの特徴(欠点)＞
ところがCMOLには大きな欠点があります。それはCMOLがデータリンク層での実装ですので、ルーティングができないことです。大きなネットワークでルーティングができないのは致命的ですが、OSIルータがCMOLの転送をサポートすることによる解決が期待されています。
CMOLの実際の導入には他にもソフトウェアに絡んだ問題等種々あるようですが、IEEEでの規格化が進んでいますので注目しておく必要があるでしょう。

SNMPv2

SNMPでは管理データを収集する時に多数のパケットのやりとりが発生し、ネットワークの有効利用率が低下することについては既に述べましたが、SNMPv2ではこれを改善するためにGetBulkRequestというコマンドが追加になりました。このコマンドを利用すればSNMPにおけるGetNextRequestを使用したトライ＆エラー型のデータ収集のかわりに大量データの一括収集が可能となり、管理データパケットによるネットワーク利用率の低下が緩和されます。

不要なパケットのやりとりを防ぐという観点では、GetResponseにも改善が見られます。SNMPでは管理オブジェクトの複数のインスタンスを検索した場合、その中の一つでもエラーが発生すると全体がダメになっていましたが、SNMPv2ではエラーが発生しなかったインスタンスは有効であると同時に、エラーが発生したインスタンスではインスタンス毎にエラーコードが通知される様になりました。

SNMPではエラーが複数発生した場合にはエラーが発生したインスタンスの特定が困難ですが、再検索の際にはエラー要因を排除した上でGetRequestを発行しなければならないというジレンマがあります。これはSNMPではトライ＆エラー方式でしか解決できませんので、結果として余分なトラフィックが発生してしまう訳です。

SNMPv2ではマネージャ間通信用のコマンドとしてInformRequestも新たにサポートされました。このコマンドを使用すれば、サブマネージャを配置して階層的な分散管理システムの構築が可能になります。また、セキュリティ機能のサポートも大きな特徴です。SNMPv2ではMIBは、３つのグループに分けて考えられています(表6)。

表6 SNMPv2のMIBのグループ分け

SNMPv2とSNMPとはPDUは上位互換ですが、セキュリティ機能に関連してメッセージ形式が変更され、パケットとしての互換性はありませんので注意が必要です(図12,13)。

図12 SNMPv2 メッセージ構成

図13 SNMPv2 のPDUの構成

ＳＮＭＰを廃止して一挙にSNMPv2へ移行するとことは不可能ですので、まずはSNMPとSNMPv2の両方のエージェントをサポートしたマネージャを登場させ、順次移行していく形態が考えられています。