4. プロトコル仕様

4.1. 共通構造

すべての SNMP PDU は、第3節で定義された ASN.1 構造を使用して構築されます。

request-id は、未完了の要求を区別するため、およびコマンドレスポンダアプリケーションをサポートする SNMP エンティティが Response-PDU の request-id フィールドを生成するために使用されます。request-id を使用することで、コマンドジェネレータアプリケーションをサポートする SNMP エンティティは、同じ SNMP エンティティへの複数の要求が同時に保留されている場合でも、着信 Response-PDU を未完了の要求と相関させることができます。信頼性の低いトランスポートサービスが使用されている場合、同じ要求の再送信に同じ request-id を使用することができますが、これは必須ではありません。request-id の値は連続している必要はなく、実装は最近使用された request-id 値を繰り返さないように注意する必要があります。なぜなら、以前の要求は受信されたが応答が失われた可能性があるためです。

すべての PDU の variable-bindings コンポーネントは、変数バインディングのリストです。PDU がコマンドジェネレータアプリケーションから送信される場合、このリストは要求されている管理情報または発行されているコマンドを表します。検索操作と変更操作の両方への応答の場合、このリストには管理情報が含まれます。例外を報告する応答の場合、リスト内の各変数バインディングの値には、例外値の1つ（noSuchObject、noSuchInstance、または endOfMibView）が含まれます。

各変数バインディングは、名前と値のペアリングです。名前は、特定のオブジェクトインスタンスを指定する OBJECT IDENTIFIER であり、値はオブジェクトインスタンスの値を表します。

4.2. PDU 処理

このセクションでは、各タイプの PDU の処理について説明します。

4.2.1. GetRequest-PDU

GetRequest-PDU は、特定のオブジェクトインスタンスの値を取得するためにコマンドジェネレータアプリケーションによって生成されます。

GetRequest-PDU を受信すると、コマンドレスポンダアプリケーションをサポートする受信 SNMP エンティティは、変数バインディングリスト内の各変数バインディングを処理して Response-PDU を生成します。Response-PDU のすべてのフィールドは、以下に示す場合を除き、受信した要求の対応するフィールドと同じ値を持ちます。

各変数バインディングは次のように処理されます：

変数バインディングの名前がこの要求によってアクセス可能な変数の名前と正確に一致する場合、変数バインディングの値フィールドは名前付き変数の値に設定されます。
それ以外の場合、変数バインディングの名前に、この要求によってアクセス可能な任意の変数の OBJECT IDENTIFIER プレフィックスと正確に一致する OBJECT IDENTIFIER プレフィックスがない場合、変数バインディングの値フィールドは noSuchObject に設定されます。
それ以外の場合、変数バインディングの値フィールドは noSuchInstance に設定されます。

上記にリストされた理由以外の理由で変数バインディングの処理が失敗した場合、Response-PDU はエラー条件を示すように変更されます。error-status フィールドは、エラーの性質を示す値に設定されます。error-index フィールドの値は、処理が失敗した変数バインディングのインデックスに設定されます（変数バインディングは1から番号付けされます）。その後、variable-bindings フィールドが変更されます：エラーを引き起こしたもの以外のすべての変数バインディングが削除され、エラーを引き起こした変数バインディングは同一の変数バインディングに置き換えられますが、値フィールドは NULL に設定されます。

生成された Response-PDU は、GetRequest-PDU の発信者に返されます。

4.2.2. GetNextRequest-PDU

GetNextRequest-PDU は、取得するオブジェクトインスタンスの名前が不明な場合に、オブジェクトインスタンスの値を取得するためにコマンドジェネレータアプリケーションによって生成されます。

GetNextRequest-PDU を受信すると、コマンドレスポンダアプリケーションをサポートする受信 SNMP エンティティは、変数バインディングリスト内の各変数バインディングを処理して Response-PDU を生成します。Response-PDU のすべてのフィールドは、以下に示す場合を除き、受信した要求の対応するフィールドと同じ値を持ちます。

各変数バインディングは次のように処理されます：

変数バインディングの名前は、この要求によってアクセス可能なすべての変数の名前の辞書順リストに配置されます（順序付きリストは、すべての MIB ビューに対して維持される個々の変数の順序付きリストの概念的な結合です）。
変数バインディングの名前の最も近い辞書順の後継者の名前が決定されます。これは、この要求によってアクセス可能な辞書順の次の変数の名前です。
辞書順の後継者がない場合、変数バインディングの値フィールドは endOfMibView に設定され、変数バインディングの名前フィールドは要求からの名前に設定されます。
それ以外の場合、変数バインディングの値フィールドは名前付き変数の値に設定され、変数バインディングの名前フィールドはその変数の名前に設定されます。

生成された Response-PDU は、GetNextRequest-PDU の発信者に返されます。

4.2.2.1. テーブル走査の例

GetNextRequest-PDU の最も重要な用途の1つは、MIB 内の概念的な情報テーブルの走査です。この PDU タイプのセマンティクスにより、このような走査は非常に簡単になります。

走査の最初の GetNextRequest-PDU は、テーブルの最初の行を取得するために発行されます。この要求の変数バインディングは通常、テーブルエントリオブジェクトを命名しますが、先行するオブジェクト名を命名することもできます。GetNextRequest-PDU のセマンティクスにより、返される変数バインディングはテーブルの最初の行のものになります。

後続の GetNextRequest-PDU は、テーブルの後続の行を取得するために発行されます。これらの PDU はそれぞれ、その変数バインディングで前の Response-PDU で返された変数の名前を指定します。これらの名前は辞書順に並んでおり、GetNextRequest-PDU のセマンティクスにより、返される名前は要求内のものの辞書順の後継者であるため、テーブルの行は辞書順に返されます。

Response-PDU で返される変数の名前がテーブルエントリオブジェクトの名前をプレフィックスとして持たない場合、走査プロセスは完了します。これは、エージェントがそのテーブルにこれ以上インスタンスを持たない場合、または次の辞書順のオブジェクトインスタンスが異なるオブジェクトタイプのインスタンスである場合（次の辞書順のオブジェクトタイプがそのテーブルの列オブジェクトではない、または異なるテーブルの列オブジェクトであるため）に発生します。

この例は、GetNextRequest-PDU を使用したテーブル走査を示しています。架空のテーブル「fooTable」を使用し、3つのオブジェクトが含まれています：

fooIndex    OBJECT-TYPE
    SYNTAX      INTEGER
    MAX-ACCESS  not-accessible
    STATUS      current
    ::= { fooEntry 1 }

fooDescr    OBJECT-TYPE
    SYNTAX      DisplayString
    MAX-ACCESS  read-only
    STATUS      current
    ::= { fooEntry 2 }

fooValue    OBJECT-TYPE
    SYNTAX      INTEGER
    MAX-ACCESS  read-write
    STATUS      current
    ::= { fooEntry 3 }

次のインスタンスが存在すると仮定します：

fooIndex.1 = 1
fooDescr.1 = "alpha"
fooValue.1 = 10
fooIndex.2 = 2
fooDescr.2 = "beta"
fooValue.2 = 20

コマンドジェネレータアプリケーションは、次の変数バインディングを持つ GetNextRequest-PDU を発行します：

fooIndex
fooDescr
fooValue

エージェントは次を含む Response-PDU で応答します：

fooIndex.1 = 1
fooDescr.1 = "alpha"
fooValue.1 = 10

コマンドジェネレータアプリケーションは、次を含む別の GetNextRequest-PDU を発行します：

fooIndex.1
fooDescr.1
fooValue.1

エージェントは次で応答します：

fooIndex.2 = 2
fooDescr.2 = "beta"
fooValue.2 = 20

コマンドジェネレータアプリケーションは、次を含む別の GetNextRequest-PDU を発行します：

fooIndex.2
fooDescr.2
fooValue.2

テーブルにこれ以上行がない場合、エージェントは fooTable にないオブジェクトの変数バインディングで応答する可能性があり、テーブルの終わりに達したことを示します。

4.2.3. GetBulkRequest-PDU

GetBulkRequest-PDU は、テーブル内の複数の行など、大量のデータを効率的に取得するためにコマンドジェネレータアプリケーションによって生成されます。

GetBulkRequest-PDU を受信すると、コマンドレスポンダアプリケーションをサポートする受信 SNMP エンティティは、次のように要求を処理します：

non-repeaters フィールドは、単一の辞書順の後継者を返す変数バインディングリスト内の変数バインディングの数を指定します。

max-repetitions フィールドは、変数バインディングリスト内の残りの変数バインディング（最初の non-repeaters バインディングの後のもの）に対して返される辞書順の後継者の最大数を指定します。

受信 SNMP エンティティは、次の規則に従って Response-PDU を生成します：

Response-PDU の request-id フィールドは、受信した GetBulkRequest-PDU の request-id フィールドの値に設定されます。
Response-PDU の error-status フィールドは noError に設定され、error-index フィールドはゼロに設定されます。
Response-PDU の変数バインディングリストは、次の手順に従って埋められます：

a. N を GetBulkRequest-PDU の変数バインディングリスト内の変数バインディングの数とします。

b. M を GetBulkRequest-PDU の max-repetitions フィールドの値とします。

c. R を GetBulkRequest-PDU の non-repeaters フィールドの値とします。

d. GetBulkRequest-PDU の変数バインディングリスト内の最初の R 個の変数バインディングについて、それぞれに GetNext 操作を実行し、結果を Response-PDU の変数バインディングリストに配置します。

e. GetBulkRequest-PDU の変数バインディングリスト内の残りの（N - R）個の変数バインディングのそれぞれについて、次のステップを M 回、または辞書順の後継者がなくなるまで実行します：

i. 変数バインディングに対して GetNext 操作を実行します。

ii. 結果を Response-PDU の変数バインディングリストに配置します。

iii. 結果をこのステップの次の反復（ある場合）の基礎として使用します。
生成された Response-PDU のサイズがローカル制限または要求のソースパーティの最大メッセージサイズを超える場合、サイズ制約を満たすように、より小さい max-repetitions 値またはより少ない変数バインディングを使用して代替変数バインディングリストで応答が生成されます。この場合、より小さい max-repetitions 値が使用されている場合、Response-PDU の max-repetitions フィールドの値は GetBulkRequest-PDU からの値に設定されます（つまり、実際に使用されたより小さい値を反映するために減少されません）。

上記にリストされた理由以外の理由で変数バインディングの処理が失敗した場合、Response-PDU はエラー条件を示すように変更されます。error-status フィールドは、エラーの性質を示す値に設定されます。error-index フィールドの値は、GetBulkRequest-PDU で処理が失敗した変数バインディングのインデックスに設定されます。その後、GetRequest-PDU 処理で説明されているように variable-bindings フィールドが変更されます。

生成された Response-PDU は、GetBulkRequest-PDU の発信者に返されます。

4.2.3.1. 別のテーブル走査の例

この例は、GetBulkRequest-PDU を使用してテーブルから複数の行を取得することを示しています。前の例と同じ「fooTable」を考えます。

コマンドジェネレータアプリケーションは、fooTable から最大2行を取得したいと考えています。次の内容で GetBulkRequest-PDU を発行します：

non-repeaters = 0
max-repetitions = 2
変数バインディング：
```
fooIndex
fooDescr
fooValue
```

エージェントは、最大 2 × 3 = 6 個の変数バインディングを含む Response-PDU で応答します：

fooIndex.1 = 1
fooDescr.1 = "alpha"
fooValue.1 = 10
fooIndex.2 = 2
fooDescr.2 = "beta"
fooValue.2 = 20

テーブルにさらに行がある場合、コマンドジェネレータアプリケーションは、最後に返されたオブジェクト名を開始点として使用して別の GetBulkRequest-PDU を発行することで続行できます。

GetBulkRequest-PDU の利点は、単一の操作で複数の行を取得できるようにすることで、大きなテーブルを取得するために必要なプロトコル交換の数を減らすことです。

4.2.4. Response-PDU

Response-PDU は、セクション 4.2.1、4.2.2、4.2.3、4.2.5、および 4.2.7 で指定された手順で示されているように、GetRequest-PDU、GetNextRequest-PDU、GetBulkRequest-PDU、SetRequest-PDU、または InformRequest-PDU に応答して、コマンドレスポンダアプリケーションをサポートする SNMP エンティティによって生成されます。

Response-PDU を受信すると、コマンドジェネレータまたは通知レシーバアプリケーションをサポートする受信 SNMP エンティティは、アプリケーションの手順に従ってそれを処理します。

Response-PDU の request-id フィールドは、受信エンティティによって応答を元の要求と相関させるために使用されます。

Response-PDU の error-status フィールドは、次のいずれかの値に設定できます：

noError: 要求の処理中にエラーが発生しなかったことを示します。
tooBig: エージェントが、ローカル制約内または要求のソースの最大メッセージサイズ内のサイズの Response-PDU を生成できなかったことを示します。
noSuchName: プロキシ互換性のために使用されます。このエラーは SNMPv2 エンティティによって生成されるべきではありません。
badValue: プロキシ互換性のために使用されます。このエラーは SNMPv2 エンティティによって生成されるべきではありません。
readOnly: プロキシ互換性のために使用されます。このエラーは SNMPv2 エンティティによって生成されるべきではありません。
genErr: 処理中に上記以外のエラーが発生したことを示します。
noAccess: セキュリティ上の理由でオブジェクトへのアクセスが拒否されたことを示します。
wrongType: 変数バインディングの値フィールドが、指定されたオブジェクトに対して誤ったタイプであることを示します。
wrongLength: 変数バインディングの値フィールドが、指定されたオブジェクトに対して誤った長さであることを示します。
wrongEncoding: 変数バインディングの値フィールドが、指定されたオブジェクトに対して誤ったエンコーディングであることを示します。
wrongValue: 変数バインディングの値フィールドが、指定されたオブジェクトに対して有効な値ではない値を持っていることを示します。
noCreation: 指定されたオブジェクトインスタンスが作成されない可能性があることを示します。
inconsistentValue: 変数バインディングの値フィールドが他のオブジェクトの値と一致しないことを示します。
resourceUnavailable: 要求された操作を実行するために必要なリソースが利用できないことを示します。
commitFailed: 値をコミットする試みが失敗したことを示します。
undoFailed: 以前の値のセットを元に戻す試みが失敗したことを示します。
authorizationError: 指定されたオブジェクトへのアクセスが承認されていないことを示します。
notWritable: 指定されたオブジェクトが書き込み可能でないことを示します。
inconsistentName: 指定されたオブジェクトインスタンス名が他のオブジェクトの値と一致しないことを示します。

エラーにならなかった GetRequest-PDU、GetNextRequest-PDU、または GetBulkRequest-PDU に応答して生成された Response-PDU では、error-index フィールドはゼロに設定されます。それ以外の場合は、エラーを引き起こした変数バインディングのインデックスに設定されます。

4.2.5. SetRequest-PDU

SetRequest-PDU は、1つ以上のオブジェクトインスタンスの値を変更するよう要求するためにコマンドジェネレータアプリケーションによって生成されます。

SetRequest-PDU を受信すると、コマンドレスポンダアプリケーションをサポートする受信 SNMP エンティティは、変数バインディングリストで名前が付けられたオブジェクトインスタンスの値を指定された値に設定しようとします。

SetRequest-PDU の処理は2つのフェーズで実行されます：

フェーズ1：

最初のフェーズでは、要求が検証されます。すべての検証が成功した場合、第2フェーズが開始されます。いずれかの検証が失敗した場合、操作全体が失敗し、error-status フィールドがエラーの性質を示すように設定され、error-index フィールドがエラーを引き起こした変数バインディングのインデックスに設定された Response-PDU が生成されます。

最初のフェーズでは、次の検証が実行されます：

各変数バインディングによって名前が付けられたオブジェクトが検証され、次のことが保証されます：
- 名前が有効な OBJECT IDENTIFIER である
- オブジェクトが存在しアクセス可能である
- オブジェクトが書き込み可能である
各変数バインディングの値が検証され、次のことが保証されます：
- 構文が正しい
- 長さが適切である
- 値が許容範囲内である
- 値が関連オブジェクトの値と一致している

フェーズ2：

最初のフェーズが正常に完了した場合、第2フェーズが開始されます。このフェーズでは、オブジェクトインスタンスの値が設定されます。

第2フェーズが何らかの理由で失敗した場合、このフェーズ中に行われたすべての変更を元に戻す試みが行われます（「ロールバック」）。ロールバックが成功した場合、error-status が commitFailed に設定された Response-PDU が生成されます。ロールバックが失敗した場合、error-status が undoFailed に設定された Response-PDU が生成されます。

第2フェーズが正常に完了した場合、次の内容で Response-PDU が生成されます：

error-status が noError に設定されます
error-index がゼロに設定されます
variable-bindings リストに、正常に設定されたすべてのオブジェクトインスタンスの名前と値が含まれます

生成された Response-PDU は、SetRequest-PDU の発信者に返されます。

原子性：

SetRequest-PDU はアトミックです - すべての変数が更新されるか、何も更新されません。これにより、管理対象システムが一貫性のない中間状態に置かれることがないことが保証されます。

4.2.6. SNMPv2-Trap-PDU

SNMPv2-Trap-PDU は、通知ジェネレータアプリケーションの代わりに通知オリジネータアプリケーションをサポートする SNMP エンティティによって生成されます。通知レシーバアプリケーションをサポートする SNMP エンティティにイベントの非請求通知を提供するために使用されます。

SNMPv2-Trap-PDU の変数バインディングリストの最初の2つの変数バインディングは、それぞれ sysUpTime.0 [RFC3418] と snmpTrapOID.0 [RFC3418] です。sysUpTime.0 変数バインディングは、SNMP エンティティの最後の初期化とトラップの生成との間に経過した時間を表します。snmpTrapOID.0 変数バインディングは、送信されているトラップのタイプを識別します。

snmpTrapOID.0 の値に対応する NOTIFICATION-TYPE マクロ呼び出しに OBJECTS 句が含まれている場合、変数バインディングリストには、それらの句で指定されたオブジェクトの変数バインディングも含まれます。通知オリジネータアプリケーションの裁量により、変数バインディングリストに追加の変数バインディングを含めることができます。

SNMPv2-Trap-PDU を受信すると、通知レシーバアプリケーションをサポートする受信 SNMP エンティティは、受信アプリケーションの手順に従ってトラップを処理します。SNMPv2-Trap-PDU に対する応答は生成されません。

4.2.7. InformRequest-PDU

InformRequest-PDU は、通知ジェネレータアプリケーションの代わりに通知オリジネータアプリケーションをサポートする SNMP エンティティによって生成されます。受信確認付きで通知レシーバアプリケーションをサポートする SNMP エンティティにイベントの通知を提供するために使用されます。

InformRequest-PDU の変数バインディングリストの最初の2つの変数バインディングは、SNMPv2-Trap-PDU で説明されているように、それぞれ sysUpTime.0 と snmpTrapOID.0 です。

InformRequest-PDU を受信すると、通知レシーバアプリケーションをサポートする受信 SNMP エンティティは、受信アプリケーションの手順に従って通知を処理し、Response-PDU を生成します。Response-PDU は、request-id フィールドに受信した InformRequest-PDU と同じ値を持ち、error-status が noError で、error-index がゼロです。Response-PDU の variable-bindings フィールドは、受信した InformRequest-PDU と同一です。

生成された Response-PDU は、InformRequest-PDU の発信者に返されます。これにより、通知が受信されたことの確認が提供されます。

4.1. 共通構造​

4.2. PDU 処理​

4.2.1. GetRequest-PDU​

4.2.2. GetNextRequest-PDU​

4.2.2.1. テーブル走査の例​

4.2.3. GetBulkRequest-PDU​

4.2.3.1. 別のテーブル走査の例​

4.2.4. Response-PDU​

4.2.5. SetRequest-PDU​

4.2.6. SNMPv2-Trap-PDU​

4.2.7. InformRequest-PDU​