3. 手順の要素

以下のセクションでは、5種類のSNMPアプリケーションのそれぞれがSNMPメッセージを生成および処理する際に従う手順について説明します。

3.1. コマンドジェネレータアプリケーション

コマンドジェネレータアプリケーションは、SNMPメッセージ処理サブシステムを利用して、SNMPメッセージをリモートSNMPアプリケーションに渡します。

コマンドジェネレータは、リモートアプリケーションのトランスポートドメインとトランスポートアドレスを決定できる必要があります。これを実現する方法は実装に依存し、本書の範囲外です。

コマンドジェネレータは、リモートアプリケーションと通信するときに使用する適切なSNMPメッセージパラメータ（メッセージ処理モデル、セキュリティモデル、セキュリティレベル、およびセキュリティ名）を決定できる必要があります。これを実現する方法は実装に依存し、本書の範囲外です。

3.1.1. コマンドリクエストの生成

SNMPコマンドリクエストを送信するには、コマンドジェネレータアプリケーションは以下を行います。

1. ローカル構成情報を使用して、以下を決定します。

   • トランスポートドメインとトランスポートアドレス
   • メッセージ処理モデル
   • セキュリティモデル
   • セキュリティ名
   • セキュリティレベル
   • コンテキストエンジンID (contextEngineID)
   • コンテキスト名 (contextName)
   • 適切なPDU (GetRequest, GetNextRequest, GetBulkRequest, または SetRequest)

2. メッセージ処理サブシステムのPDU送信プリミティブを呼び出し、以下を渡します。

   • トランスポートドメインとトランスポートアドレス
   • メッセージ処理モデル
   • セキュリティモデル
   • セキュリティ名
   • セキュリティレベル
   • contextEngineID
   • contextName
   • PDU

3. メッセージ処理サブシステムはステータス表示を返します。エラーが返された場合、コマンドジェネレータはエラーを適切に処理する必要があります。

3.1.2. 応答の処理

コマンドジェネレータが応答を受信すると、以下のようになります。

1. メッセージ処理サブシステムは、コマンドジェネレータのPDU受信プリミティブを呼び出し、以下を渡します。

   • メッセージ処理モデル
   • セキュリティモデル
   • セキュリティ名
   • セキュリティレベル
   • contextEngineID
   • contextName
   • PDU
   • 最大サイズ (maxSizeResponseScopedPDU)
   • ステータス情報

2. コマンドジェネレータは、応答が未解決のリクエストと一致することを確認します（request-idを使用）。

3. コマンドジェネレータは、応答内のerror-statusを確認します。error-statusフィールドがゼロ以外の場合、エラーが発生しました。

4. コマンドジェネレータは、応答内の変数バインディングリストを処理します。

3.1.3. タイムアウトと再試行

妥当な時間内に応答が受信されない場合、コマンドジェネレータはリクエストを再送信できます。再試行回数とタイムアウト値は、ローカル構成またはポリシーによって決定されます。

信頼性の高いトランスポートプロトコル（TCPなど）の場合、トランスポート層自体が再送信を提供する場合があります。そのような場合、アプリケーション層の再試行は不要または不適切な場合があります。

3.2. コマンドレスポンダアプリケーション

コマンドレスポンダアプリケーションは、SNMPコマンドリクエストを受信し、適切な応答を生成します。

3.2.1. リクエストの処理

コマンドレスポンダがリクエストを受信すると、以下のようになります。

1. メッセージ処理サブシステムは、コマンドレスポンダのPDU受信プリミティブを呼び出し、以下を渡します。

   • メッセージ処理モデル
   • セキュリティモデル
   • セキュリティ名
   • セキュリティレベル
   • contextEngineID
   • contextName
   • PDU
   • 最大サイズ (maxSizeResponseScopedPDU)
   • ステータス情報

2. コマンドレスポンダは、contextEngineIDがローカルSNMPエンジンを識別していることを確認します。そうでない場合、リクエストは破棄されます。

3. コマンドレスポンダは、アクセス制御サブシステム（RFC 3415で定義されているVACMなど）を使用して、セキュリティ名が要求された操作を実行する権限を持っているかどうかを判断します。

4. コマンドレスポンダはPDUを処理します。

   • GetRequest: 要求されたMIBオブジェクトの値を取得します
   • GetNextRequest: 要求されたオブジェクト名の辞書順で次のMIBオブジェクトを取得します
   • GetBulkRequest: 最適化された多変数取得を実行します
   • SetRequest: 指定されたMIBオブジェクトの値を変更します

5. コマンドレスポンダは、以下を含む応答PDUを作成します。

   • リクエストと同じrequest-id
   • Error-status (noError または適切なエラーコード)
   • Error-index (エラーが発生した場合、どの変数バインディングがエラーの原因であるかを示します)
   • 変数バインディングリスト（Get操作の場合、取得された値が含まれます。Set操作の場合、設定された変数が含まれます）

3.2.2. 応答の生成

コマンドレスポンダは、以下によって応答を生成します。

1. 適切なerror-status、error-index、および変数バインディングリストを使用してResponse-PDUを作成します。

2. メッセージ処理サブシステムの応答PDU返却プリミティブを呼び出し、以下を渡します。

   • メッセージ処理モデル（リクエストと同じ）
   • セキュリティモデル（リクエストと同じ）
   • セキュリティ名（リクエストと同じ）
   • セキュリティレベル（リクエストと同じ）
   • contextEngineID（リクエストと同じ）
   • contextName（リクエストと同じ）
   • PDU（応答PDU）
   • 最大サイズ（リクエストからのmaxSizeResponseScopedPDU）
   • 状態参照（リクエスト処理から取得）

3. メッセージ処理サブシステムは、応答メッセージのフォーマットと送信を処理します。

3.2.3. エラー処理

リクエストの処理中にエラーが発生した場合、コマンドレスポンダは応答PDUに適切なerror-statusを設定する必要があります。

• tooBig: 応答メッセージが大きすぎて、最大メッセージサイズの制約内で送信できません
• noSuchName: 要求されたオブジェクトが存在しません（SNMPv1のみ）
• badValue: 提供された値が要求された操作に不適切です（SNMPv1のみ）
• readOnly: 読み取り専用オブジェクトを変更しようとしました
• genErr: 一般的なエラーが発生しました
• noAccess: アクセスが拒否されました（SNMPv2以降）
• wrongType: 変数のタイプが間違っています（SNMPv2以降）
• wrongLength: 値の長さが間違っています（SNMPv2以降）
• wrongEncoding: 値のエンコーディングが間違っています（SNMPv2以降）
• wrongValue: 値が正しくありません（SNMPv2以降）
• noCreation: 作成は許可されていません（SNMPv2以降）
• inconsistentValue: 値が一貫していません（SNMPv2以降）
• resourceUnavailable: リソースが利用できません（SNMPv2以降）
• commitFailed: コミットに失敗しました（SNMPv2以降）
• undoFailed: 元に戻す操作に失敗しました（SNMPv2以降）
• authorizationError: 認証エラー（SNMPv2以降）
• notWritable: オブジェクトは書き込み可能ではありません（SNMPv2以降）
• inconsistentName: 名前が一貫していません（SNMPv2以降）

3.3. 通知オリジネータアプリケーション

通知オリジネータアプリケーションは、SNMP通知メッセージ（トラップまたはインフォームリクエスト）を生成します。

3.3.1. 通知の生成

SNMP通知を送信するには、通知オリジネータは以下を行います。

1. この通知を受信する必要がある管理ターゲットのセットを決定します。これは通常、SNMP-TARGET-MIBおよびSNMP-NOTIFICATION-MIBを参照することによって行われます。

2. 選択された各管理ターゲットについて：

   a. トランスポートドメインとトランスポートアドレスを決定します

   b. SNMPメッセージパラメータを決定します。

   • メッセージ処理モデル
   • セキュリティモデル
   • セキュリティ名
   • セキュリティレベル

   c. 通知タイプ（トラップまたはインフォーム）を決定します

   d. 適切なPDUを作成します。

   • SNMPv2-Trap-PDU: 未確認の通知用
   • InformRequest-PDU: 確認済みの通知用

   e. PDUには以下を含める必要があります。

   • sysUpTime.0 変数（エンジン起動からの時間）
   • snmpTrapOID.0 変数（通知のオブジェクト識別子）
   • 通知の追加の変数バインディング

   f. メッセージ処理サブシステムのPDU送信プリミティブを呼び出します

3.3.2. インフォームリクエストへの応答の処理

通知タイプがインフォーム (InformRequest-PDU) の場合、通知オリジネータは応答を待機する必要があります。

1. タイムアウト期間内に応答が受信された場合：

   • 応答が未解決のインフォームリクエストと一致することを確認します（request-idを使用）
   • error-statusを確認します
   • 通知が正常に配信されたことを確認します

2. タイムアウト期間内に応答が受信されない場合：

   • 構成された再試行ポリシーに応じて、インフォームリクエストを再送信する場合があります
   • または、失敗をローカルにログに記録し、この配信試行を放棄します

3. トラップ (SNMPv2-Trap-PDU) の場合、応答は予期されないため、通知オリジネータは送信直後に完了します。

3.4. 通知レシーバアプリケーション

通知レシーバアプリケーションは、SNMP通知メッセージを受信します。

3.4.1. 受信した通知の処理

通知レシーバが通知を受信すると、以下のようになります。

1. メッセージ処理サブシステムは、通知レシーバのPDU受信プリミティブを呼び出し、以下を渡します。

   • メッセージ処理モデル
   • セキュリティモデル
   • セキュリティ名
   • セキュリティレベル
   • contextEngineID
   • contextName
   • PDU
   • 最大サイズ
   • ステータス情報

2. 通知レシーバは、通知情報を抽出します。

   • sysUpTime.0 (タイムスタンプ)
   • snmpTrapOID.0 (通知タイプ)
   • 追加の変数バインディング (通知データ)

3. 通知レシーバは、ローカルポリシーに従って通知を処理します。

   • ログファイルへの記録
   • アラートの表示
   • 自動応答アクションのトリガー
   • 他の管理システムへの転送

3.4.2. インフォームリクエストへの応答

InformRequest-PDUが受信された場合、通知レシーバは応答を生成する必要があります。

1. 以下を含むResponse-PDUを作成します。

   • リクエストと同じrequest-id
   • Error-status (通常はnoError)
   • Error-index (通常は0)
   • 変数バインディングリスト（通常はリクエストと同じ）

2. メッセージ処理サブシステムの応答PDU返却プリミティブを呼び出して、応答を送信します。

SNMPv2-Trap-PDUの場合、応答は生成されません。

3.5. プロキシフォワーダアプリケーション

プロキシフォワーダアプリケーションは、SNMPエンティティ間でSNMPメッセージを転送します。プロキシフォワーダは、プロトコル変換、セキュリティ変換、または管理情報ビュー変換を実行できます。

プロキシフォワーダアプリケーションは、2種類の転送を実行します。

1. リクエスト転送: コマンドリクエストとその応答の転送
2. 通知転送: 通知メッセージの転送

3.5.1. リクエスト転送

プロキシフォワーダがコマンドリクエストを受信すると、以下のようになります。

1. メッセージ処理サブシステムは、プロキシフォワーダのPDU受信プリミティブを呼び出し、リクエストパラメータを渡します。

2. プロキシフォワーダは、SNMP-PROXY-MIBを使用して、リクエストを転送する方法を決定します。

   a. 受信したパラメータをキーとして使用して、snmpProxyTableを参照します。

   • contextEngineID
   • contextName
   • トランスポートドメインとトランスポートアドレス
   • PDUタイプ

   b. 一致するエントリが見つかった場合、転送パラメータを抽出します。

   • ターゲットトランスポートドメインとトランスポートアドレス
   • ターゲットメッセージ処理モデル
   • ターゲットセキュリティモデル
   • ターゲットセキュリティ名
   • ターゲットセキュリティレベル
   • ターゲットcontextEngineID
   • ターゲットcontextName

3. プロキシフォワーダは、ターゲットSNMPバージョンに対応するためにPDUを変更する必要がある場合があります。たとえば：

   • SNMPv2からSNMPv1へ：error-statusコードを変換
   • SNMPv1からSNMPv2へ：トラップPDU形式を変換

4. プロキシフォワーダは、メッセージ処理サブシステムのPDU送信プリミティブを呼び出して、変更されたリクエストをターゲットに転送します。

5. ターゲットから応答が受信されると：

   a. 元のリクエスタのSNMPバージョンに対応するために、応答PDUを再度変更する必要がある場合があります

   b. メッセージ処理サブシステムの応答PDU返却プリミティブを呼び出して、応答を元のリクエスタに転送します

3.5.2. 通知転送

プロキシフォワーダが通知を受信すると、以下のようになります。

1. メッセージ処理サブシステムは、プロキシフォワーダのPDU受信プリミティブを呼び出し、通知パラメータを渡します。

2. プロキシフォワーダは、SNMP-PROXY-MIBを使用して、通知を転送する方法を決定します。

   a. 受信したパラメータをキーとして使用して、snmpProxyTableを参照します

   b. 一致するエントリが見つかった場合、転送パラメータを抽出します

3. プロキシフォワーダは、通知PDUを変更する必要がある場合があります。

   • SNMPv1トラップからSNMPv2トラップへ：PDU形式と変数バインディングを変換
   • SNMPv2トラップからSNMPv1トラップへ：PDU形式を変換

4. プロキシフォワーダは、メッセージ処理サブシステムのPDU送信プリミティブを呼び出して、通知をターゲットに転送します。

5. 元の通知がInformRequest-PDUであり、転送された通知もInformRequest-PDUである場合：

   a. ターゲットからの応答を待機します

   b. 応答が受信されると、応答を元の通知オリジネータに転送します

3.5.3. プロキシフォワーダの特別な考慮事項

プロキシフォワーダは、いくつかの特別なケースを処理する必要があります。

1. PDUサイズの調整: ターゲットが元のリクエストよりも小さい最大メッセージサイズをサポートしている場合、プロキシフォワーダはtooBigエラーを返すか、リクエストを分割する必要がある場合があります。

2. コンテキスト変換: プロキシフォワーダは、異なるcontextEngineIDとcontextNameの間でマッピングする必要がある場合があります。

3. アクセス制御: プロキシフォワーダは、ターゲットコマンドレスポンダでのアクセス制御に加えて、独自のアクセス制御ポリシーを適用します。

4. エラーマッピング: SNMPバージョン間で変換する場合、エラーコードのマッピングが必要になる場合があります。たとえば、SNMPv2のnoAccessエラーは、SNMPv1のgenErrにマッピングする必要がある場合があります。

5. タイムアウトと再試行: プロキシフォワーダは、元のリクエスタのタイムアウトとは独立して、転送されたリクエストに対して独自のタイムアウトおよび再試行メカニズムを実装する必要がある場合があります。

6. 通知フィルタリング: 通知転送の場合、プロキシフォワーダはフィルタリングルールを適用して、特定の種類の通知を選択的に転送できます。