4. Spécification du protocole

4.1. Constructions communes

Tous les PDU SNMP sont construits en utilisant la structure ASN.1 définie dans la section 3.

Le request-id est utilisé pour distinguer les requêtes en attente, et par l'entité SNMP supportant les applications de répondeur de commandes pour générer le champ request-id d'un Response-PDU. En utilisant le request-id, une entité SNMP supportant des applications de générateur de commandes peut corréler les Response-PDU entrants avec les requêtes en attente, même lorsque plusieurs requêtes à la même entité SNMP sont en attente simultanément. Dans les cas où un service de transport non fiable est utilisé, le même request-id peut être utilisé pour les retransmissions de la même requête, mais ce n'est pas obligatoire. La valeur de request-id n'a pas besoin d'être séquentielle, et les implémentations doivent veiller à ne pas répéter une valeur récemment utilisée pour request-id, car la requête précédente peut avoir été reçue mais la réponse perdue.

Le composant variable-bindings de tous les PDU est une liste de liaisons de variables. Lorsqu'un PDU est envoyé depuis une application de générateur de commandes, cette liste représente les informations de gestion demandées ou les commandes données. Dans le cas des réponses aux opérations de récupération et de modification, cette liste contient les informations de gestion. Dans le cas des réponses qui rapportent des exceptions, la valeur de chaque liaison de variable dans la liste contiendra l'une des valeurs d'exception : noSuchObject, noSuchInstance ou endOfMibView.

Chaque liaison de variable est un appariement d'un nom et d'une valeur. Le nom est un OBJECT IDENTIFIER spécifiant une instance d'objet particulière, et la valeur représente la valeur de l'instance d'objet.

4.2. Traitement des PDU

Cette section décrit le traitement de chaque type de PDU.

4.2.1. Le GetRequest-PDU

Le GetRequest-PDU est généré par une application de générateur de commandes pour récupérer la valeur d'instance(s) d'objet spécifique(s).

À la réception d'un GetRequest-PDU, l'entité SNMP réceptrice supportant des applications de répondeur de commandes traite chaque liaison de variable dans la liste de liaisons de variables pour produire un Response-PDU. Tous les champs du Response-PDU ont les mêmes valeurs que les champs correspondants de la requête reçue, sauf indication contraire ci-dessous.

Chaque liaison de variable est traitée comme suit :

1. Si le nom de la liaison de variable correspond exactement au nom d'une variable accessible par cette requête, alors le champ de valeur de la liaison de variable est défini sur la valeur de la variable nommée.

2. Sinon, si le nom de la liaison de variable n'a pas de préfixe OBJECT IDENTIFIER qui correspond exactement au préfixe OBJECT IDENTIFIER de toute variable accessible par cette requête, alors le champ de valeur de la liaison de variable est défini sur noSuchObject.

3. Sinon, le champ de valeur de la liaison de variable est défini sur noSuchInstance.

Si le traitement d'une liaison de variable échoue pour une raison autre que celles énumérées ci-dessus, alors le Response-PDU est modifié pour indiquer une condition d'erreur. Le champ error-status est défini sur une valeur indiquant la nature de l'erreur. La valeur du champ error-index est définie sur l'index de la liaison de variable pour laquelle le traitement a échoué (les liaisons de variables sont numérotées à partir de un). Le champ variable-bindings est ensuite modifié : toutes les liaisons de variables autres que celle qui a causé l'erreur sont supprimées, et la liaison de variable qui a causé l'erreur est remplacée par une liaison de variable identique, sauf que le champ de valeur est défini sur NULL.

Le Response-PDU généré est retourné à l'originateur du GetRequest-PDU.

4.2.2. Le GetNextRequest-PDU

Le GetNextRequest-PDU est généré par une application de générateur de commandes pour récupérer la valeur d'instance(s) d'objet, où le nom de l'instance(s) d'objet à récupérer est inconnu.

À la réception d'un GetNextRequest-PDU, l'entité SNMP réceptrice supportant des applications de répondeur de commandes traite chaque liaison de variable dans la liste de liaisons de variables pour produire un Response-PDU. Tous les champs du Response-PDU ont les mêmes valeurs que les champs correspondants de la requête reçue, sauf indication contraire ci-dessous.

Chaque liaison de variable est traitée comme suit :

1. Le nom de la liaison de variable est situé dans la liste ordonnée lexicographiquement des noms de toutes les variables qui sont accessibles par cette requête (la liste ordonnée est l'union conceptuelle des listes ordonnées individuelles de variables maintenues pour toutes les vues MIB).

2. Le nom du successeur lexicographique le plus proche du nom de la liaison de variable est déterminé. C'est le nom de la variable lexicographiquement suivante qui est accessible par cette requête.

3. S'il n'y a pas de successeur lexicographique, le champ de valeur de la liaison de variable est défini sur endOfMibView, et le champ de nom de la liaison de variable est défini sur le nom de la requête.

4. Sinon, le champ de valeur de la liaison de variable est défini sur la valeur de la variable nommée, et le champ de nom de la liaison de variable est défini sur le nom de cette variable.

Si le traitement d'une liaison de variable échoue pour une raison autre que celles énumérées ci-dessus, alors le Response-PDU est modifié pour indiquer une condition d'erreur. Le champ error-status est défini sur une valeur indiquant la nature de l'erreur. La valeur du champ error-index est définie sur l'index de la liaison de variable pour laquelle le traitement a échoué. Le champ variable-bindings est ensuite modifié comme décrit pour le traitement GetRequest-PDU.

Le Response-PDU généré est retourné à l'originateur du GetNextRequest-PDU.

4.2.2.1. Exemple de traversée de table

L'une des utilisations les plus importantes du GetNextRequest-PDU est la traversée de tables conceptuelles d'informations au sein d'une MIB. La sémantique de ce type de PDU rend de telles traversées assez simples.

Le premier GetNextRequest-PDU dans une traversée est émis pour obtenir la première ligne de la table. Les liaisons de variables dans cette requête nomment généralement les objets d'entrée de table, mais peuvent également nommer n'importe quel nom d'objet précédent. La sémantique du GetNextRequest-PDU dicte que les liaisons de variables retournées seront celles de la première ligne de la table.

Les GetNextRequest-PDU suivants sont émis afin d'obtenir les lignes suivantes de la table. Chacun de ces PDU spécifie dans ses liaisons de variables le nom de la variable retournée dans le Response-PDU précédent. Parce que ces noms sont ordonnés lexicographiquement, et parce que la sémantique du GetNextRequest-PDU dicte que les noms retournés sont les successeurs lexicographiques de ceux de la requête, les lignes de la table sont retournées dans l'ordre lexicographique.

Le processus de traversée est terminé lorsque le nom d'une variable retournée dans un Response-PDU n'a pas le nom de l'objet d'entrée de table comme préfixe. Cela se produit soit parce que l'agent n'a plus d'instances dans cette table, soit parce que l'instance d'objet lexicographiquement suivante est une instance d'un type d'objet différent (parce que le type d'objet lexicographiquement suivant n'est pas un objet colonne de cette table, ou est un objet colonne d'une table différente).

Cet exemple démontre la traversée de table en utilisant le GetNextRequest-PDU. Il utilise la table fictive "fooTable", qui contient trois objets :

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 }

Supposons que les instances suivantes existent :

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

L'application de générateur de commandes émet un GetNextRequest-PDU avec les liaisons de variables suivantes :

fooIndex
fooDescr
fooValue

L'agent répond avec un Response-PDU contenant :

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

L'application de générateur de commandes émet un autre GetNextRequest-PDU avec :

fooIndex.1
fooDescr.1
fooValue.1

L'agent répond avec :

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

L'application de générateur de commandes émet un autre GetNextRequest-PDU avec :

fooIndex.2
fooDescr.2
fooValue.2

S'il n'y a plus de lignes dans la table, l'agent pourrait répondre avec des liaisons de variables pour des objets qui ne sont pas dans fooTable, indiquant que la fin de la table a été atteinte.

4.2.3. Le GetBulkRequest-PDU

Le GetBulkRequest-PDU est généré par une application de générateur de commandes pour récupérer efficacement de grandes quantités de données, telles que plusieurs lignes dans une table.

À la réception d'un GetBulkRequest-PDU, l'entité SNMP réceptrice supportant des applications de répondeur de commandes traite la requête comme suit :

Le champ non-repeaters spécifie le nombre de liaisons de variables dans la liste de liaisons de variables pour lesquelles un seul successeur lexicographique doit être retourné.

Le champ max-repetitions spécifie le nombre maximum de successeurs lexicographiques à retourner pour les liaisons de variables restantes (celles après les premières liaisons non-repeaters) dans la liste de liaisons de variables.

L'entité SNMP réceptrice produit un Response-PDU selon les règles suivantes :

1. Le champ request-id du Response-PDU est défini sur la valeur du champ request-id du GetBulkRequest-PDU reçu.

2. Le champ error-status du Response-PDU est défini sur noError, et le champ error-index est défini sur zéro.

3. La liste de liaisons de variables du Response-PDU est remplie selon la procédure suivante :

   a. Soit N le nombre de liaisons de variables dans la liste de liaisons de variables du GetBulkRequest-PDU.

   b. Soit M la valeur du champ max-repetitions du GetBulkRequest-PDU.

   c. Soit R la valeur du champ non-repeaters du GetBulkRequest-PDU.

   d. Pour les R premières liaisons de variables dans la liste de liaisons de variables du GetBulkRequest-PDU, effectuez l'opération GetNext pour chacune, et placez les résultats dans la liste de liaisons de variables du Response-PDU.

   e. Pour chacune des (N - R) liaisons de variables restantes dans la liste de liaisons de variables du GetBulkRequest-PDU, les étapes suivantes sont effectuées M fois, ou jusqu'à ce qu'il n'y ait plus de successeurs lexicographiques :

   i. Effectuez l'opération GetNext pour la liaison de variable.

   ii. Placez le résultat dans la liste de liaisons de variables du Response-PDU.

   iii. Utilisez le résultat comme base pour l'itération suivante (le cas échéant) de cette étape.

4. Si la taille du Response-PDU généré dépasse une limitation locale ou la taille maximale de message de la partie source de la requête, alors la réponse est générée avec une liste de liaisons de variables alternative, en utilisant une valeur plus petite pour max-repetitions ou moins de liaisons de variables, de sorte que les contraintes de taille soient satisfaites. Notez que dans ce cas, si une valeur plus petite pour max-repetitions est utilisée, la valeur du champ max-repetitions dans le Response-PDU sera toujours définie sur la valeur du GetBulkRequest-PDU (c'est-à-dire qu'elle n'est pas décrémentée pour refléter la valeur plus petite réellement utilisée).

Si le traitement d'une liaison de variable échoue pour une raison autre que celles énumérées ci-dessus, alors le Response-PDU est modifié pour indiquer une condition d'erreur. Le champ error-status est défini sur une valeur indiquant la nature de l'erreur. La valeur du champ error-index est définie sur l'index de la liaison de variable dans le GetBulkRequest-PDU pour laquelle le traitement a échoué. Le champ variable-bindings est ensuite modifié comme décrit pour le traitement GetRequest-PDU.

Le Response-PDU généré est retourné à l'originateur du GetBulkRequest-PDU.

4.2.3.1. Un autre exemple de traversée de table

Cet exemple démontre l'utilisation du GetBulkRequest-PDU pour récupérer plusieurs lignes d'une table. Considérez le même "fooTable" de l'exemple précédent.

L'application de générateur de commandes souhaite récupérer jusqu'à deux lignes de fooTable. Elle émet un GetBulkRequest-PDU avec :

• non-repeaters = 0
• max-repetitions = 2
• liaisons de variables :

  fooIndex
  fooDescr
  fooValue

L'agent répond avec un Response-PDU contenant jusqu'à 2 × 3 = 6 liaisons de variables :

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

S'il y avait plus de lignes dans la table, l'application de générateur de commandes pourrait continuer en émettant un autre GetBulkRequest-PDU en utilisant les derniers noms d'objets retournés comme point de départ.

L'avantage du GetBulkRequest-PDU est qu'il réduit le nombre d'échanges de protocole requis pour récupérer une grande table, en permettant de récupérer plusieurs lignes en une seule opération.

4.2.4. Le Response-PDU

Le Response-PDU est généré par une entité SNMP supportant des applications de répondeur de commandes en réponse à GetRequest-PDU, GetNextRequest-PDU, GetBulkRequest-PDU, SetRequest-PDU ou InformRequest-PDU, comme indiqué par les procédures spécifiées dans les sections 4.2.1, 4.2.2, 4.2.3, 4.2.5 et 4.2.7, respectivement.

À la réception d'un Response-PDU, l'entité SNMP réceptrice supportant des applications de générateur de commandes ou de récepteur de notifications le traite selon les procédures de l'application.

Le champ request-id du Response-PDU est utilisé par l'entité réceptrice pour corréler la réponse avec la requête originale.

Le champ error-status du Response-PDU peut être défini sur l'une des valeurs suivantes :

• noError : Indique qu'aucune erreur ne s'est produite pendant le traitement de la requête.

• tooBig : Indique que l'agent ne pouvait pas générer un Response-PDU dont la taille était dans les contraintes locales ou dans la taille maximale de message de la source de la requête.

• noSuchName : Utilisé pour la compatibilité proxy. Cette erreur ne devrait pas être générée par une entité SNMPv2.

• badValue : Utilisé pour la compatibilité proxy. Cette erreur ne devrait pas être générée par une entité SNMPv2.

• readOnly : Utilisé pour la compatibilité proxy. Cette erreur ne devrait pas être générée par une entité SNMPv2.

• genErr : Indique qu'une erreur autre que l'une des erreurs ci-dessus s'est produite pendant le traitement.

• noAccess : Indique que l'accès à l'objet a été refusé pour des raisons de sécurité.

• wrongType : Indique que le champ de valeur de la liaison de variable a le mauvais type pour l'objet spécifié.

• wrongLength : Indique que le champ de valeur de la liaison de variable a la mauvaise longueur pour l'objet spécifié.

• wrongEncoding : Indique que le champ de valeur de la liaison de variable a le mauvais encodage pour l'objet spécifié.

• wrongValue : Indique que le champ de valeur de la liaison de variable a une valeur qui n'est pas une valeur valide pour l'objet spécifié.

• noCreation : Indique que l'instance d'objet spécifiée ne peut pas être créée.

• inconsistentValue : Indique que le champ de valeur de la liaison de variable est incohérent avec les valeurs d'autres objets.

• resourceUnavailable : Indique que les ressources nécessaires ne sont pas disponibles pour effectuer l'opération demandée.

• commitFailed : Indique que la tentative de validation des valeurs a échoué.

• undoFailed : Indique que la tentative d'annulation de l'ensemble précédent de valeurs a échoué.

• authorizationError : Indique que l'accès à l'objet spécifié n'est pas autorisé.

• notWritable : Indique que l'objet spécifié n'est pas modifiable.

• inconsistentName : Indique que le nom de l'instance d'objet spécifiée est incohérent avec les valeurs d'autres objets.

Le champ error-index est défini sur zéro dans un Response-PDU généré en réponse à un GetRequest-PDU, GetNextRequest-PDU ou GetBulkRequest-PDU qui n'a pas entraîné d'erreur. Sinon, il est défini sur l'index de la liaison de variable qui a causé l'erreur.

4.2.5. Le SetRequest-PDU

Le SetRequest-PDU est généré par une application de générateur de commandes pour demander que les valeurs d'une ou plusieurs instances d'objets soient modifiées.

À la réception d'un SetRequest-PDU, l'entité SNMP réceptrice supportant des applications de répondeur de commandes tente de définir la valeur des instances d'objets nommées dans la liste de liaisons de variables aux valeurs spécifiées.

Le traitement du SetRequest-PDU est effectué en deux phases :

Phase un :

Dans la première phase, la requête est validée. Si toutes les validations réussissent, alors la deuxième phase est initiée. Si une validation échoue, alors l'opération entière échoue, et un Response-PDU est généré avec le champ error-status défini pour indiquer la nature de l'erreur, et le champ error-index défini sur l'index de la liaison de variable qui a causé l'erreur.

Les validations suivantes sont effectuées dans la première phase :

1. L'objet nommé par chaque liaison de variable est validé pour s'assurer que :

   • Le nom est un OBJECT IDENTIFIER valide
   • L'objet existe et est accessible
   • L'objet est modifiable

2. La valeur de chaque liaison de variable est validée pour s'assurer que :

   • La syntaxe est correcte
   • La longueur est appropriée
   • La valeur est dans la plage acceptable
   • La valeur est cohérente avec les valeurs d'objets connexes

Phase deux :

Si la première phase se termine avec succès, la deuxième phase commence. Dans cette phase, les valeurs des instances d'objets sont définies.

Si la deuxième phase échoue pour une raison quelconque, une tentative est faite pour annuler tous les changements effectués pendant cette phase (un "rollback"). Si le rollback réussit, un Response-PDU est généré avec l'error-status défini sur commitFailed. Si le rollback échoue, un Response-PDU est généré avec l'error-status défini sur undoFailed.

Si la deuxième phase se termine avec succès, un Response-PDU est généré avec :

• error-status défini sur noError
• error-index défini sur zéro
• liste de variable-bindings contenant les noms et valeurs de toutes les instances d'objets qui ont été définies avec succès

Le Response-PDU généré est retourné à l'originateur du SetRequest-PDU.

Atomicité :

Le SetRequest-PDU est atomique - soit toutes les variables sont mises à jour, soit aucune ne l'est. Cela garantit que le système géré n'est jamais laissé dans un état intermédiaire incohérent.

4.2.6. Le SNMPv2-Trap-PDU

Le SNMPv2-Trap-PDU est généré par une entité SNMP supportant des applications d'originateur de notifications au nom d'une application de générateur de notifications. Il est utilisé pour fournir une notification non sollicitée d'événements à une entité SNMP supportant des applications de récepteur de notifications.

Les deux premières liaisons de variables dans la liste de liaisons de variables d'un SNMPv2-Trap-PDU sont sysUpTime.0 [RFC3418] et snmpTrapOID.0 [RFC3418] respectivement. La liaison de variable sysUpTime.0 représente le temps écoulé entre la dernière initialisation de l'entité SNMP et la génération du trap. La liaison de variable snmpTrapOID.0 identifie le type de trap qui est envoyé.

Si l'invocation de macro NOTIFICATION-TYPE correspondant à la valeur de snmpTrapOID.0 inclut des clauses OBJECTS, alors la liste de liaisons de variables inclut également des liaisons de variables pour les objets spécifiés dans ces clauses. Des liaisons de variables supplémentaires peuvent être incluses dans la liste de liaisons de variables à la discrétion de l'application d'originateur de notifications.

À la réception d'un SNMPv2-Trap-PDU, l'entité SNMP réceptrice supportant des applications de récepteur de notifications traite le trap selon les procédures de l'application réceptrice. Aucune réponse n'est générée pour un SNMPv2-Trap-PDU.

4.2.7. Le InformRequest-PDU

Le InformRequest-PDU est généré par une entité SNMP supportant des applications d'originateur de notifications au nom d'une application de générateur de notifications. Il est utilisé pour fournir une notification d'événements à une entité SNMP supportant des applications de récepteur de notifications, avec confirmation de réception.

Les deux premières liaisons de variables dans la liste de liaisons de variables d'un InformRequest-PDU sont sysUpTime.0 et snmpTrapOID.0 respectivement, comme décrit pour SNMPv2-Trap-PDU.

À la réception d'un InformRequest-PDU, l'entité SNMP réceptrice supportant des applications de récepteur de notifications traite l'inform selon les procédures de l'application réceptrice, et génère un Response-PDU. Le Response-PDU a la même valeur dans son champ request-id que l'InformRequest-PDU reçu, un error-status de noError et un error-index de zéro. Le champ variable-bindings du Response-PDU est identique à celui de l'InformRequest-PDU reçu.

Le Response-PDU généré est retourné à l'originateur de l'InformRequest-PDU. Cela fournit une confirmation que la notification a été reçue.