Groupe de travail Réseau

Version 2 des opérations de protocole pour le protocole simple de gestion de réseau (SNMP)

Le présent document spécifie un protocole de l’Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et suggestions pour son amélioration. Prière de se référer à l’édition en cours des "Protocoles officiels de l’Internet" (STD 1) pour voir l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.

Le présent document définit la version 2 des opérations de protocole pour le protocole simple de gestion de réseau (SNMP, Simple Network Management Protocol). Il définit la syntaxe et les éléments de procédure pour l’envoi, la réception, et le traitement des PDU SNMP. Le présent document rend obsolète la RFC 1905.

Table des Matières

1. Introduction

2. Généralités

2.1 Informations de gestion

2.2 Retransmission des demandes

2.3 Tailles des messages

2.4 Transpositions de transport

2.5 Transpositions de type de données SMIv2

3. Définitions

4. Spécification du protocole

4.1 Constructions communes

4.2 Traitement des PDU

5. Notice sur la propriété intellectuelle

6. Remerciements

7. Considérations pour la sécurité

8. Références

8.1 Références normatives

8.2 Références pour information

9. Changements depuis la RFC 1905

10. Adresse de l’éditeur

11. Déclaration complète de droits de reproduction

Le cadre de gestion SNMP comporte au moment de la rédaction du présent texte cinq composantes majeures :

- Des mécanismes de description et de dénomination des objets et événements pour les besoins de la gestion. La première version de cette structure d'informations de gestion (SMI, Structure of Management Information) est appelée SMIv1 et elle est décrite dans le STD 16, [RFC1155], [RFC1212] et [RFC1215]. La seconde version, appelée SMIv2, est décrite dans le STD 58, [RFC2578], [RFC2579] et [RFC2580].

- Des protocoles de message pour le transfert des informations de gestion. La première version du protocole de message SNMP est appelée SNMPv1 et elle est décrite dans le STD 15, [RFC1157]. Une seconde version du protocole de message SNMP, qui n'est pas un protocole Internet en cours de normalisation, est appelée SNMPv2c et elle est décrite dans la [RFC1901] et dans le STD 62, [RFC3417]. La troisième version du protocole de message est appelée SNMPv3 et elle est décrite dans le STD 62, [RFC3417], [RFC3412] et [RFC3414].

- Des opérations de protocole pour accéder aux informations de gestion. Le premier ensemble d'opérations de protocole et de formats de PDU associées est décrit dans le STD 15, [RFC1157]. Un second ensemble d'opérations de protocole et de formats de PDU associées est décrit dans le présent document.

- Un ensemble d'applications fondamentales décrites dans le STD 62, [RFC3413] et le mécanisme de contrôle d'accès fondé sur la vue décrit dans le STD 62, [RFC3415].

Une introduction plus détaillée au cadre de gestion SNMP au moment de la rédaction se trouve dans la [RFC3410].

On accède aux objets gérés via un magasin virtuel d'informations, appelée la base de données d'informations de gestion (MIB, Management Information Base). Les objets de la MIB sont définis en utilisant les mécanismes définis dans la SMI.

Le présent document, version 2 des opérations de protocole pour le protocole simple de gestion de réseau, définit les opérations du protocole par rapport à l'envoi et la réception des PDU à transporter par le protocole de message.

Les entités SNMP qui prennent en charge les applications de générateur de commandes ou de receveur de notification (traditionnellement appelées "gestionnaires") communiquent avec des entités SNMP qui prennent en charge des applications de réponse aux commandes ou de générateur de notifications (traditionnellement appelés "agents"). L'objet de ce protocole est le transport des informations et opérations de gestion.

Le terme "variable" se réfère à une instance de type d'objet non agrégeable défini conformément aux conventions établies dans la SMI [RFC2578] ou aux conventions textuelles fondées sur la SMI [RFC2579]. Le terme "liaison de variable" se réfère normalement à l'appariement du nom de la variable et de sa valeur associée. Cependant, si certaines sortes de conditions exceptionnelles surviennent durant le traitement d'une demande de restitution, une liaison de variable va apparier un nom et une indication de cette exception.

Le nom d'une variable est un IDENTIFIANT D'OBJET qui est l'enchaînement de l'IDENTIFIANT D'OBJET du type d'objet correspondant avec un fragment d'IDENTIFIANT D'OBJET qui identifie l'instance. L'IDENTIFIANT D'OBJET du type d'objet correspondant est appelé le préfixe d'IDENTIFIANT D'OBJET de la variable.

Pour tous les types de demandes de ce protocole, le receveur est obligé, dans des circonstances normales, de générer et transmettre une réponse à l'origine de la demande. Qu'une demande doive être retransmise, si aucune réponse correspondante n'est reçue dans l'intervalle de temps approprié, est à la discrétion de l'application qui génère la demande. Cela va normalement dépendre de l'urgence de la demande. Cependant, une telle application doit agir de façon responsable par rapport à la fréquence et à la durée des retransmissions. Voir le BCP 41 [RFC2914] pour un exposé des principes pertinents de contrôle de l'encombrement.

(1) la taille maximum de message que l'entité de destination SNMP peut accepter ; et,

La première peut s'apprécier sur la base du receveur ; et en son absence, elle est indiquée par le domaine de transport utilisé lors de l'envoi du message. La seconde est imposée par des contraintes locales spécifiques de la mise en œuvre.

Chaque transposition de transport pour SNMP indique la taille de message minimum qu'une mise en œuvre SNMP doit être capable de produire ou consommer. Bien que les mises en œuvre soient invitées à prendre en charge de plus grandes valeurs chaque fois que possible, une mise en œuvre conforme ne doit jamais générer de messages plus grands que ce qui est autorisé par l'entité SNMP receveuse.

Un des buts de la PDU GetBulkRequest, spécifiée dans le présent protocole, est de minimiser le nombre d'échanges de protocole nécessaires pour restituer une grande quantité d'informations de gestion. À ce titre, ce type de PDU permet à une entité SNMP qui prend en charge des applications de générateur de commandes de demander que la réponse soit aussi grande que possible étant données les contraintes de taille de message. Ces contraintes incluent les limites de taille des messages que peut générer l'entité SNMP qui prend en charge les applications de réponse aux commandes, et que peut recevoir l'entité SNMP qui prend en charge les applications de générateur de commandes.

Cependant, il est possible que de tels messages de taille maximum soient plus grands que la MTU du chemin traversé par les messages à travers le réseau. Dans une telle situation, de tels messages sont soumis à la fragmentation. La fragmentation est généralement considérée comme dommageable [FRAG], parce que entre autres problèmes, elle conduit à une diminution de la fiabilité du transfert des messages. Et donc, une entité SNMP qui envoie une PDU GetBulkRequest doit veiller à régler ses paramètres en conséquence, de façon à réduire le risque de fragmentation. En particulier, dans des conditions de tensions sur le réseau, seules de petites valeurs devraient être utilisées pour max-repetitions.

Il est important de noter que l'échange des messages SNMP exige seulement un service non fiable de datagrammes, chaque message étant entièrement contenu dans un seul datagramme de transport et ce, de façon indépendante. Les règles spécifiques de transposition de transport et de codage sont spécifiée ailleurs [RFC3417]. Cependant, la transposition préférée est l'utilisation du protocole de datagramme d'utilisateur [RFC0768].

La SMIv2 [RFC2578] définit onze types de base (INTEGER (entier), OCTET STRING (chaîne d'octets), OBJECT IDENTIFIER (identifiant d'objet), Integer32, IpAddress, Counter32, Gauge32, Unsigned32, TimeTicks, Opaque, Counter64) et la construction BITS. Les types de base de SMIv2 sont transposés dans les types choisis correspondants dans les choix SimpleSyntax et ApplicationSyntax de la définition ASN.1 du protocole SNMP. Noter que les types de base INTEGER et Integer32 de SMIv2 sont transposés dans le type de choix de valeur d'entier du choix SimpleSyntax. De même, les types de base Gauge32 et Unsigned32 de SMIv2 sont transposés dans le type de choix unsigned-integer-value (valeur d'entier non signé) du choix ApplicationSyntax.

La construction BITS de SMIv2 est transposée dans le type de choix string-value du choix SimpleSyntax. Une valeur BITS est codée comme une CHAÎNE D'OCTETS, dans laquelle tous les bits désignés dans (la définition de) la chaîne binaire, en commençant par le premier bit et en continuant jusqu'au dernier bit, sont placés du bit 8 (bit de plus fort poids) au bit 1 (bit de moindre poids) du premier octet, suivis par les bits 8 à 1 de chaque octet suivant à son tour, suivis par autant de bits que nécessaire pour l'octet final suivant, en commençant par le bit 8. Les bits restants, s'il en est, de l'octet final sont mis à zéro à leur génération et ignorés à réception.

Counter64 ::= [APPLICATION 6] ENTIER IMPLICITE (0 à 18 446 744 073 709 551 615)

-- L'usage et la sémantique précise de la PDU Report ne sont pas définis dans ce document. Tout cadre administratif de SNMP utilisant cette PDU doit définir son usage et sa sémantique.

La valeur du champ request-id dans une PDU Response prend la valeur du champ request-id dans la PDU de demande à laquelle elle répond. Par l'utilisation de la valeur du request-id, une application peut distinguer les demandes en cours (qui peuvent être nombreuses) et corréler par là les réponses entrantes avec les demandes en cours. Dans les cas d'utilisation d'un service de datagrammes non fiable, l'identifiant de demande donne un moyen simple pour identifier les messages dupliqués par le réseau. L'utilisation du même identifiant de demande sur la retransmission d'une demande permet à la réponse de satisfaire aussi bien la transmission originale que la retransmission de la demande. Cependant, afin de calculer le délai d'aller retour de la transmission et du traitement d'une transaction de demande-réponse, l'application doit utiliser une valeur d'identifiant de demande différente sur une demande retransmise. Il est recommandée d'utiliser cette dernière stratégie dans la majorité des situations.

Une valeur différente de zéro dans le champ État d'erreur dans une PDU de réponse est utilisée pour indiquer qu'une erreur est intervenue qui a empêché le traitement de la demande. Dans ces cas, une valeur différente de zéro du champ Indice d'erreur de la PDU de réponse donnera des informations supplémentaires en identifiant sur la liste la liaison de variable qui a causé l'erreur. Une liaison de variable est identifiée par sa valeur d'indice. La première liaison de variable dans une liste de liaisons de variables est l'indice un, la seconde est l'indice deux, etc.

SNMP limite les valeurs d'IDENTIFIANT D'OBJET à un maximum de 128 sous identifiants, et chaque sous identifiant a une valeur maximum de 2**32-1 (2³² -1).

Dans les éléments de procédure ci-dessous, tout champ d'une PDU qui n'est pas référencé par la procédure pertinente est ignoré par l'entité SNMP receveuse. Cependant, tous les composants d'une PDU, y compris ceux dont les valeurs sont ignorées par l'entité SNMP receveuse, doivent avoir une syntaxe et un codage ASN.1 valides. Par exemple, certaines PDU (par exemple, la PDU GetRequest) ne sont concernées que par le nom d'une variable et pas par sa valeur. Dans ce cas, la portion valeur de la liaison de variable est ignorée par l'entité SNMP receveuse. La valeur unSpecified est définie pour être utilisée comme portion de valeur de telles liaisons.

Lors de la génération d'une communication de gestion, "l'enveloppe" de message pour encapsuler la PDU est générée conformément aux "Éléments de procédure" du cadre administratif utilisé. La définition de "max-bindings" impose une limite supérieure au nombre de liaisons de variables. En pratique, la taille d'un message est aussi limitée par des contraintes sur la taille maximum de message. Une mise en œuvre conforme doit prendre en charge autant de liaisons de variables dans une PDU ou BulkPDU qu'il en tient dans la limite globale de taille maximum de message du moteur SNMP, mais pas plus de 2 147 483 647 liaisons de variables.

À réception d'une communication de gestion, les "Éléments de procédure" du cadre administratif utilisé sont suivis, et si ces procédures indiquent que l'opération contenue dans le message est à effectuer en local, ces procédures indiquent alors aussi la vue de MIB qui est visible pour l'opération.

À réception d'une PDU GetRequest, l'entité SNMP receveuse traite chaque liaison de variable dans la liste de liaisons de variables pour produire une PDU Response. Tous les champs de la PDU Response ont les mêmes valeurs que les champs correspondants de la demande reçue excepté comme indiqué 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 demande, le champ de valeur de la liaison de variable est réglé à la valeur de la variable désignée.

(2) Autrement, si le nom de la liaison de variable n'a pas un préfixe IDENTIFIANT D'OBJET qui correspond exactement au préfixe IDENTIFIANT D'OBJET de toute (potentielle) variable accessible par cette demande, son champ de valeur est alors réglé à "noSuchObject".

(3) Autrement, le champ de valeur de la liaison de variable est réglé à "noSuchInstance".

Si le traitement de toute liaison de variable échoue pour une raison autre que celles énumérées ci-dessus, la Response-PDU est alors reformatée avec les mêmes valeurs dans ses champs request-id et variable-bindings que dans la PDU GetRequest reçue, avec la valeur de son champ État d'erreur réglé à "genErr", et la valeur de son champ indice d'erreur réglé à l'indice de la liaison de variable en échec.

Autrement, la valeur du champ état d'erreur de la PDU Response est réglé à "noError", et la valeur de son champ indice d'erreur est zéro.

La PDU Response générée est alors encapsulée dans un message. Si la taille du message résultant est inférieure ou égale à la fois à une contrainte locale et à la taille maximum de message de l'origine, il est transmis à l'origine de la PDU GetRequest.

Autrement, une PDU Response de remplacement est générée. Cette PDU Response de remplacement est formatée avec la même valeur dans son champ d'identifiant de demande que celle de la PDU GetRequest reçue, avec la valeur de son champ État d'erreur réglé à "tropGros", la valeur de son champ d'indice d'erreur réglé à zéro, et un champ vide de liaisons de variables. Cette PDU Response de remplacement est alors encapsulée dans un message. Si la taille du message résultant est inférieure ou égale à la fois à une contrainte locale et à la taille maximum de message de l'origine, il est transmis à l'origine de la PDU GetRequest. Autrement, le compteur snmpSilentDrops [RFC3418] est incrémenté et le message résultant est éliminé.

Une PDU GetNextRequest est générée et transmise à la demande d'une application.

À réception d'une PDU GetNextRequest, l'entité SNMP receveuse traite chaque liaison de variable de la liste de variable-binding pour produire une PDU Response. Tous les champs de la PDU Response ont les mêmes valeurs que les champs correspondants de la demande reçue excepté comme indiqué ci-dessous. Chaque liaison de variable est traitée comme suit :

(1) On localise la variable qui est dans la liste ordonnée lexicographiquement des noms de toutes les variables qui sont accessibles par cette demande et dont le nom est le premier successeur lexicographique du nom de la liaison de variable dans la PDU GetNextRequest entrante. Les champs de nom et de valeur de la liaison de variable correspondante dans la PDU Response sont mis au nom et à la valeur de la variable localisée.

(2) Si le nom de la liaison de variable demandée ne précède pas lexicographiquement le nom d'une variable accessible par cette demande, c'est-à-dire, si il n'a pas de successeur lexicographique, la liaison de variable correspondante produite dans la PDU Response a son champ de valeur réglé à "endOfMibView", et son champ de nom est réglé au nom de la liaison de variable de la demande.

Si le traitement d'une liaison de variable échoue pour une raison autre que celles énumérées ci-dessus, la PDU Response est alors reformatée avec les mêmes valeurs dans ses champs request-id et variable-bindings que dans la PDU GetNextRequest reçue, avec la valeur de son champ error-status réglé à "genErr", et la valeur de son champ error-index réglée à l'indice de la liaison de variable qui a échoué.

Autrement, la valeur du champ error-status de la PDU Response est réglé à "noError", et la valeur de son champ error-index est à zéro.

La PDU Response générée est alors encapsulée dans un message. Si la taille du message résultant est inférieure ou égale à une contrainte locale et à la taille maximum de message du générateur, il est transmis au générateur de la PDU GetNextRequest.

Autrement, une PDU Response de remplacement est générée. Cette PDU Response de remplacement est formatée avec les mêmes valeurs que dans le champ request-id de la PDU GetNextRequest reçue, avec la valeur de son champ error-status réglé à "tooBig", la valeur de son champ error-index réglée à zéro, et un champ variable-bindings vide. Cette PDU Response de remplacement est alors encapsulée dans un message. Si la taille du message résultant est inférieure ou égale à la fois à une contrainte locale et à la taille maximum de message du générateur, il est transmis au générateur de la PDU GetNextRequest. Autrement, le compteur snmpSilentDrops [RFC3418] est incrémenté et le message résultant est éliminé.

Une utilisation importante de la PDU GetNextRequest est la traversée des tableaux conceptuels d'informations au sein d'une MIB. La sémantique de ce type de demande, ainsi qu'avec la méthode d'identification des instances individuelles des objets dans la MIB, fournit l'accès aux objets en rapport dans la MIB comme si ils bénéficiaient d'une organisation en tableaux.

Dans le scénario d'échange de protocole ci-dessous, une application restitue l'adresse physique dépendante du support et le type de transposition d'adresse pour chaque entrée dans le tableau de traduction d'adresse IP du réseau au support [RFC1213] d'un certain élément de réseau. Elle restitue aussi la valeur de sysUpTime [RFC3418], à laquelle les transpositions ont eu lieu. Supposons que le tableau de réseau à support du répondeur de commandes ait trois entrées :

L'entité SNMP qui prend en charge une application de générateur de commandes commence par envoyer une PDU GetNextRequest contenant les valeurs d'IDENTIFIANT D'OBJET indiquées comme noms de variable demandés :

L'entité SNMP qui prend en charge une application de répondeur de commande répond par une PDU Response :

L'entité SNMP qui prend en charge l'application de générateur de commande continue avec :

GetNextRequest ( sysUpTime, ipNetToMediaPhysAddress.1.9.2.3.4, ipNetToMediaType.1.9.2.3.4 )

L'entité SNMP qui prend en charge l'application de répondeur de commande répond par :

L'entité SNMP qui prend en charge l'application de générateur de commande continue avec :

GetNextRequest ( sysUpTime, ipNetToMediaPhysAddress.1.10.0.0.51, ipNetToMediaType.1.10.0.0.51 )

L'entité SNMP qui prend en charge l'application de répondeur de commande répond par :

L'entité SNMP qui prend en charge l'application de générateur de commande continue avec :

GetNextRequest ( sysUpTime, ipNetToMediaPhysAddress.2.10.0.0.15, ipNetToMediaType.2.10.0.0.15 )

Comme il n'y a plus d'autre entrée dans le tableau, l'entité SNMP qui prend en charge l'application de répondeur de commande répond avec les variables qui suivent dans l'ordre lexicographique des noms d'objets accessibles, par exemple :

Noter comment, ayant atteint la fin de la colonne pour ipNetToMediaPhysAddress, la seconde liaison de variable provenant de l'application de répondeur de commande est maintenant "revenue" à la première rangée de la colonne suivante. De plus, noter comment, ayant atteint la fin de ipNetToMediaTable pour la troisième liaison de variable, l'application de répondeur de commandes a répondu par le prochain objet disponible, qui est en dehors de ce tableau. Cette réponse signale la fin du tableau à l'application de générateur de commande.

Une PDU GetBulkRequest est générée et transmise à la demande d'une application. L'objet de la PDU GetBulkRequest est de demander le transfert d'une quantité de données potentiellement grande, incluant, mais sans s'y limiter, la restitution efficace et rapide de grands tableaux.

À réception d'une PDU GetBulkRequest, l'entité SNMP receveuse traite chaque liaison de variable de la liste des liens de variable pour produire une PDU Response avec son champ Identifiant de demande qui a la même valeur que dans la demande.

Pour le type GetBulkRequest, la réussite du traitement de chaque liaison de variable dans la demande génère zéro, une ou plusieurs liaisons de variables dans la PDU Response. C'est-à-dire, la transposition biunivoque entre les liaisons de variables des types de PDU GetRequest, GetNextRequest, et SetRequest et les PDU Response résultantes ne s'appliquent pas pour la transposition entre les liaisons de variables d'une PDU GetBulkRequest et la PDU Response résultante.

Les valeurs des champs non-repeaters et max-repetitions dans la demande spécifient le traitement demandé. Une liaison de variable dans la PDU Response est exigée pour les N premières liaisons de variables dans la demande et M liaisons de variables sont exigées pour chacune des R liaisons de variables restantes dans la demande. Par conséquent, le nombre total de liaisons de variables demandées communiqué par la demande est donné par N + (M * R), où N est le minimum de : a) la valeur du champ non-repeaters dans la demande et, b) le nombre de liaisons de variables dans la demande ; M est la valeur du champ max-repetitions dans la demande ; et R est le maximum de : a) le nombre de liaisons de variables dans la demande - N, et b) zéro.

L'entité SNMP receveuse produit une PDU Response avec jusqu'au nombre total de liaisons de variables demandées communiqué par la demande. L'identifiant de demande devra avoir la même valeur que la PDU GetBulkRequest reçue.

Si N est supérieur à zéro, les premières des (N)èmes liaisons de variables de la PDU Response sont chacune produites comme suit :

(1) On localise la variable dont le nom est le premier successeur lexicographique du nom de la liaison de variable dans la liste ordonnée lexicographiquement des noms de toutes les variables qui sont accessibles par cette demande dans la PDU GetBulkRequest entrante. Les champs correspondants de nom et de valeur de la liaison de variable dans la PDU Response sont réglés au nom et valeur de la variable localisée.

(2) Si le nom de la liaison de variable demandée ne précède lexicographiquement le nom d'aucune variable accessible par cette demande, c'est-à-dire, si il n'y a pas de successeur lexicographique, la liaison de variable correspondante produite dans la PDU Response a son champ Valeur réglé à "endOfMibView", et son champ Nom réglé au nom de la liaison de variable dans la demande.

Si M et R ne sont pas à zéro, la (N + 1)ème liaison de variable et les suivantes de la PDU Response sont chacune produites de manière similaire. Pour chaque itération i, telle que i est supérieur à zéro et inférieur ou égal à M, et pour chaque variable r répétée, telle que r supérieur à zéro et inférieur ou égal à R, la (N + ( (i-1) * R ) + r)ème liaison de variable de la PDU Response est produite comme suit :

(1) La variable qui est dans la liste ordonnée lexicographiquement des noms de toutes les variables qui sont accessibles par cette demande et dont le nom est le (i)ème successeur lexicographique du nom de la (N + r)ème liaison de variable dans la PDU GetBulkRequest entrante est localisée et les champs Nom et Valeur de la liaison de variable sont réglés au nom et à la valeur de la variable localisée.

(2) Si il n'y a pas de (i)ème successeur lexicographique, alors la liaison de variable correspondante produite dans la PDU Response a son champ Valeur réglé à "endOfMibView", et son champ Nom est réglé soit au dernier successeur lexicographique, soit, si il n'y a pas de successeur lexicographique, au nom de la (N + r)ème liaison de variable dans la demande.

Bien que le nombre maximum de liaisons de variables dans la PDU Response soit limité à N + (M * R), la réponse peut être générée avec un nombre of liaisons de variables inférieur (éventuellement zéro) pour une des trois raisons suivantes.

(1) Si la taille du message qui encapsule la PDU Response contenant le nombre demandé de liaisons de variables serait supérieur à une contrainte locale ou à la taille maximum de message du générateur, la réponse est alors générée avec un nombre moindre de liaisons de variables. Ce moindre nombre est l'ensemble ordonné de liaisons de variables avec certaines des liaisons de variables retirées à la fin de l'ensemble, de telle sorte que la taille du message encapsulant la PDU Response soit approximativement égal mais pas supérieur à une contrainte locale ou à la taille maximum de message du générateur. Noter que le nombre de liaisons de variables retiré n'a pas de relation avec les valeurs de N, M, ou R.

(2) La réponse peut aussi être générée avec un moindre nombre de liaisons de variables si pour une certaine valeur d'itérations i, tel que i soit supérieur à zéro et inférieur ou égal à M, toutes les liaisons de variables générées ont le champ Valeur réglé à "endOfMibView". Dans ce cas, les liaisons de variables peuvent être tronquées après la (N+(i*R))ème liaison de variable.

(3) Dans le cas où le traitement d'une demande avec de nombreuses répétitions exige un temps de traitement significativement supérieur à celui d'une demande normale, une application de répondeur de commandes peut terminer la demande avec moins que le nombre complet de répétitions, pourvu qu'au moins une répétition soit achevée.

Si le traitement d'une liaison de variable échoue pour une raison autre que celles données ci-dessus, la PDU Response est alors reformatée avec les mêmes valeurs dans ses champs request-id et variable-bindings que ceux de la PDU GetBulkRequest reçue, avec la valeur de son champ error-status réglée à "genErr", et la valeur de son champ error-index réglée à l'indice de la liaison de variable dans la demande originale qui correspond à la liaison de variable en échec.

Autrement, la valeur du champ error-status de la PDU Response est réglé à "noError", et la valeur de son champ error-index est à zéro.

La PDU Response générée (éventuellement avec un champ variable-bindings vide) est alors encapsulée dans un message. Si la taille du message résultant est inférieure ou égale à la fois à une contrainte locale et à la taille maximum de message du générateur, il est transmis au générateur de la PDU GetBulkRequest. Autrement, le compteur snmpSilentDrops [RFC3418] est incrémenté et le message résultant est éliminé.

Cet exemple montre comment la PDU GetBulkRequest peut être utilisée comme solution de remplacement à la PDU GetNextRequest. La même traversée du tableau IP réseau à support que montré au paragraphe 4.2.2.1 est réalisée avec moins d'échanges.

L'entité SNMP qui prend en charge l'application de générateur de commande commence par envoyer une PDU GetBulkRequest avec la valeur modeste de max-repetitions de 2, et contenant les valeurs d'IDENTIFIANT D'OBJET indiquées comme noms de variables demandées :

L'entité SNMP qui prend en charge l'application de répondeur de commande répond par une PDU Response :

L'entité SNMP qui prend en charge l'application de générateur de commande continue avec :

( sysUpTime, ipNetToMediaPhysAddress.1.10.0.0.51, ipNetToMediaType.1.10.0.0.51 )

L'entité SNMP qui prend en charge l'application de répondeur de commande répond avec :

On notera, comme dans le premier exemple, comment les liaisons de variables dans la réponse indiquent que la fin du tableau a été atteinte. La quatrième liaison de variable le fait en retournant des informations de la prochaine colonne disponible ; la cinquième liaison de variable le fait en retournant des informations du premier objet disponible qui suit lexicographiquement dans le tableau. Cette réponse signale la fin du tableau à l'application de générateur de commandes.

Une PDU Response n'est générée par une entité SNMP qu'à réception d'une PDU GetRequest, GetNextRequest, GetBulkRequest, SetRequest, ou InformRequest, comme décrit dans le présent document.

Si le champ error-status de la PDU Response n'est pas zéro, les champs Valeur des liaisons de variables dans la liste de liaisons de variable sont ignorés.

Si les deux champs error-status et error-index de la PDU Response ne sont pas à zéro, la valeur du champ error-index est alors l'indice de la liaison de variable (dans la liste variable-binding de la demande correspondante) pour lequel la demande a échoué. La première liaison de variable dans la liste de liens de variable d'une demande est l'indice un, la seconde a l'indice deux, etc.

Une entité SNMP conforme qui prend en charge une application de générateur de commandes doit être capable de recevoir et traiter correctement une PDU Response avec un champ error-status égal à "noSuchName", "badValue", ou "readOnly". (voir les paragraphes 1.3 et 4.3 de la [RFC2576].)

À réception d'une PDU Response, l'entité SNMP receveuse présente son contenu à l'application qui a généré la demande avec la même valeur de request-id. Pour les détails, voir la [RFC3412].

À réception d'une PDU SetRequest, l'entité SNMP receveuse détermine la taille d'un message encapsulant une PDU Response ayant les mêmes valeurs dans ses champs request-id et variable-bindings que la PDU SetRequest reçue, et les plus grandes tailles possibles des champs error-status et error-index. Si la taille de message déterminée est supérieure à une contrainte locale ou à la taille maximum de message du générateur, une PDU Response de remplacement est alors générée, transmise au générateur de la PDU SetRequest, et le traitement de la PDU SetRequest se termine immédiatement après. Cette PDU Response de remplacement est formatée avec les mêmes valeurs dans son champ request-id que la PDU SetRequest reçue, avec la valeur de son champ error-status réglée à "tooBig", la valeur de son champ error-index réglée à zéro, et un champ variable-bindings vide. Cette PDU Response de remplacement est alors encapsulée dans un message. Si la taille du message résultant est inférieure ou égale à la fois à la contrainte locale et à la taille maximum de message du générateur, elle est transmise au générateur de la PDU SetRequest. Autrement, le compteur snmpSilentDrops [RFC3418] est incrémenté et le message résultant est éliminé. De toutes façons, le traitement de la PDU SetRequest se termine.

Autrement, l'entité SNMP receveuse traite chaque liaison de variable de la liste de variable-binding pour produire une PDU Response. Tous les champs de la PDU Response ont la même valeur que les champs correspondants de la demande reçue, sauf comme indiqué ci-dessous.

Les liaisons de variables sont traitées conceptuellement comme une opération en deux phases. Dans la première phase, chaque liaison de variable est validée ; si toutes les validations sont réussies, chaque variable est alors altérée dans la seconde phase. Bien sûr, les mises en œuvre ont la liberté de traiter la première, ou la seconde, ou les deux, de ces phases conceptuelles comme plusieurs phases de mise en œuvre. Bien sûr, de telles phases de mise en œuvre multiples peuvent être nécessaires dans certains cas pour assurer la cohérence.

Les validations suivantes sont effectuées dans la première phase sur chaque liaison de variable jus qu'à ce qu'elles soient toutes réussies, ou qu'une échoue :

(1) Si le nom de la liaison de variable spécifie une variable existante ou non à laquelle cette demande est ou serait refusé l'accès parce qu'elle n'est/serait pas dans la vue de MIB appropriée, la valeur du champ error-status de la PDU Response est alors réglée à "noAccess", et la valeur de son champ error-index est réglée à l'indice de la liaison de variable en échec.

(2) Autrement, si il n'y a pas de variable qui partage le même préfixe IDENTIFIANT D'OBJET que le nom de la liaison de variable, et qui est capable d'être créée ou modifiée quelle que soit la nouvelle valeur spécifiée, alors la valeur du champ error-status de la PDU Response est réglée à "notWritable", et la valeur de son champ error-index est réglée à l'indice de la liaison de variable en échec.

(3) Autrement, si le champ Valeur de la liaison de variable spécifie, conformément au langage ASN.1, un type qui n'est pas cohérent avec celui requis pour toutes les variables qui partagent le même préfixe d'IDENTIFIANT D'OBJET que le nom de la liaison de variable, alors la valeur du champ error-status de la PDU Response est réglée à "wrongType", et la valeur de son champ error-index est réglée à l'indice de la liaison de variable en échec.

(4) Autrement, si le champ Valeur de la liaison de variable spécifie, conformément au langage ASN.1, une longueur qui n'est pas cohérente avec celle requise pour toutes les variables qui partagent le même préfixe d'IDENTIFIANT D'OBJET que le nom de la liaison de variable, alors la valeur du champ error-status de la PDU Response est réglée à "wrongLength", et la valeur de son champ error-index est réglée à l'indice de la liaison de variable en échec.

(5) Autrement, si le champ Valeur de la liaison de variable contient un codage ASN.1 qui n'est pas cohérent avec l'étiquette ASN.1 de ce champ, alors la valeur du champ error-status de la PDU Response est réglée à "wrongEncoding", et la valeur de son champ error-index est réglée à l'indice de la liaison de variable en échec. (Noter que toutes les stratégies de mise en œuvre ne vont pas générer cette erreur.)

(6) Autrement, si le champ Valeur de la liaison de variable spécifie une valeur qui ne pourrait en aucune circonstance être allouée à la variable, alors la valeur du champ error-status de la PDU Response est réglée à "wrongValue", et la valeur de son champ error-index est réglée à l'indice de la liaison de variable en échec.

(7) Autrement, si le nom de la liaison de variable spécifie une variable qui n'existe pas et ne pourrait pas être créée (même si certaine variables partageant le même préfixe d'IDENTIFIANT D'OBJET pourraient dans certaines circonstances être capables d'être créées) alors la valeur du champ error-status de la PDU Response est réglée à "noCreation", et la valeur de son champ error-index est réglée à l'indice de la liaison de variable en échec.

(8) Autrement, si le nom de la liaison de variable spécifie une variable qui n'existe pas mais ne peut pas être créée dans les circonstances présentes (même si elle pourrait être créée dans d'autres circonstances) alors la valeur du champ error-status de la PDU Response est réglée à "inconsistentName", et la valeur de son champ error-index est réglée à l'indice de la liaison de variable en échec.

(9 Autrement, si le nom de la liaison de variable spécifie une variable qui existe mais ne peut pas être modifiée quelle que soit la nouvelle valeur spécifiée, alors la valeur du champ error-status de la PDU Response est réglée à "notWritable", et la valeur de son champ error-index est réglée à l'indice de la liaison de variable en échec.

(10) Autrement, si le champ Valeur de la liaison de variable spécifie une valeur qui pourrait dans d'autres circonstances être portée par la variable, mais est présentement incohérente ou par ailleurs impossible à allouer à la variable, alors la valeur du champ error-status de la PDU Response est réglée à "inconsistentValue", et la valeur de son champ error-index est réglée à l'indice de la liaison de variable en échec.

(11) Lorsque, durant l'étape ci-dessus, l'allocation de la valeur spécifiée par le champ Valeur de la liaison de variable à la variable spécifiée exige l'allocation d'une ressource présentement indisponible, alors la valeur du champ error-status de la PDU Response est réglée à "resourceUnavailable", et la valeur de son champ error-index est réglée à l'indice de la liaison de variable en échec.

(12) Si le traitement de la liaison de variable échoue pour une raison autre que celles énumérées ci-dessus, alors la valeur du champ error-status de la PDU Response est réglée à "genErr", et la valeur de son champ error-index est réglée à l'indice de la liaison de variable en échec.

À la fin de la première phase, si la validation de toutes les liaisons de variables a réussi, alors la valeur du champ error-status de la PDU Response est réglée à "noError" et la valeur de son champ error-index est de zéro, et le traitement continue comme suit.

Pour chaque liaison de variable dans la demande, la variable désignée est créée si nécessaire, et la valeur spécifiée lui est allouée. Chacune de ces allocations de variable survient comme si elle était simultanée par rapport à toutes les autres allocations spécifiées dans la même demande. Cependant, si la même variable est désignée plus d'une fois dans une seule demande, avec des valeurs associées différentes, l'allocation réelle faite à cette variable est alors spécifique de la mise en œuvre.

Si une de ces allocations échoue (même après toutes les validations précédentes) alors toutes les autres allocations sont annulées, et la PDU Response est modifiée pour avoir la valeur de son champ error-status réglée à "commitFailed", et la valeur de son champ error-index réglée à l'indice de la liaison de variable en échec.

Si et seulement si il n'est pas possible d'annuler toutes les allocations, la PDU Response est alors modifiée pour avoir la valeur de son champ error-status réglée à "undoFailed", et la valeur de son champ error-index est réglée à zéro. Noter que les mises en œuvre sont fortement encouragées à prendre toutes les mesures possibles pour éviter d'utiliser "commitFailed" ou "undoFailed" – ces deux codes d'état d'erreur ne sont pas à interpréter comme une licence de faire n'importe quoi dans une mise en œuvre.

Finalement, la PDU Response générée est encapsulée dans un message, et transmise au générateur de la PDU SetRequest.

Une PDU SNMPv2-Trap est générée et transmise par une entité SNMP au nom d'une application de générateur de notification. La PDU SNMPv2-Trap est souvent utilisée pour notifier à une application de receveur de notification à l'entité SNMP logiquement distante la survenance d'un événement ou la présence d'une condition. Il n'y a pas de confirmation associée à ce mécanisme de livraison de notification.

La ou les destinations auxquelles une PDU SNMPv2-Trap est envoyée sont déterminées d'une façon qui dépend de la mise en œuvre par l'entité SNMP. Les deux premières liaisons de variables de la liste des liaisons de variable d'une PDU SNMPv2-Trap sont respectivement sysUpTime.0 [RFC3418] et snmpTrapOID.0 [RFC3418]. Si la clause OBJECTS est présente dans l'invocation de la macro TYPE DE NOTIFICATION correspondante, chaque variable correspondante, comme instanciée par cette notification, est alors copiée, dans l'ordre, dans le champ variable-bindings. Si des variables supplémentaires sont incluses (ce qui est une option de l'entité SNMP génératrice) chacune est alors copiée dans le champ variable-bindings.

Une PDU InformRequest est générée et transmise par une entité SNMP au nom d'une application de générateur de notification. La PDU InformRequest est souvent utilisée pour notifier à une application de receveur de notification qu'un événement est survenu ou qu'une condition est présente. C'est un mécanisme de confirmation de livraison de notification, bien qu'il n'y ait, bien sûr, aucune garantie de livraison.

La ou les destinations auxquelles est envoyée une PDU InformRequest sont spécifiées par l'application de générateur de notification. Les deux premières liaisons de variables de la liste de liaisons de variable d'une PDU InformRequest sont respectivement sysUpTime.0 [RFC3418] et snmpTrapOID.0 [RFC3418]. Si la clause OBJECTS est présente dans l'invocation de la macro TYPE DE NOTIFICATION correspondante, chaque variable correspondante, comme instanciée par cette notification, est alors copiée, dans l'ordre, dans le champ variable-bindings. Si des variables supplémentaires sont incluses (c'est une option de l'entité SNMP génératrice) chacune est alors copiée dans le champ variable-bindings.

À réception d'une PDU InformRequest, l'entité SNMP receveuse détermine la taille d'un message encapsulant une PDU Response avec les mêmes valeurs dans ses champs request-id, error-status, error-index et variable-bindings que dans la PDU InformRequest reçue. Si la taille déterminée du message est supérieure à une contrainte locale ou à la taille maximum de message du générateur, une PDU Response de remplacement est alors générée, transmise au générateur de la PDU InformRequest, et le traitement de la PDU InformRequest se termine immédiatement après. Cette PDU Response de remplacement est formatée avec les mêmes valeurs dans son champ request-id que la PDU InformRequest reçue, avec la valeur de son champ error-status réglée à "tooBig", la valeur de son champ error-index réglée à zéro, et un champ variable-bindings vide. Cette PDU Response de remplacement est alors encapsulée dans un message. Si la taille du message résultant est inférieure ou égale à la fois à la contrainte locale et à la taille maximum de message du générateur, il est transmis au générateur de la PDU InformRequest. Autrement, le compteur snmpSilentDrops [RFC3418] est incrémenté et le message résultant est éliminé. De toutes façons, le traitement de la PDU InformRequest est terminé.

(2) génère une PDU Response avec les mêmes valeurs dans ses champs request-id et variable-bindings que celles de la PDU InformRequest reçue, avec la valeur de son champ État d'erreur réglé à "noError" et la valeur de son champ Indice d'erreur réglé à zéro ;

L’IETF ne prend pas position sur la validité et la portée de tout droit de propriété intellectuelle ou autres droits qui pourraient être revendiqués au titre de la mise en œuvre ou l’utilisation de la technologie décrite dans le présent document ou sur la mesure dans laquelle toute licence sur de tels droits pourrait être ou n’être pas disponible ; pas plus qu’elle ne prétend avoir accompli aucun effort pour identifier de tels droits. Les informations sur les procédures de l’ISOC au sujet des droits dans les documents de l’ISOC figurent dans les BCP 78 et BCP 79.

Des copies des dépôts d’IPR faites au secrétariat de l’IETF et toutes assurances de disponibilité de licences, ou le résultat de tentatives faites pour obtenir une licence ou permission générale d’utilisation de tels droits de propriété par ceux qui mettent en œuvre ou utilisent la présente spécification peuvent être obtenues sur répertoire en ligne des IPR de l’IETF à http://www.ietf.org/ipr.

L’IETF invite toute partie intéressée à porter son attention sur tous copyrights, licences ou applications de licence, ou autres droits de propriété qui pourraient couvrir les technologies qui peuvent être nécessaires pour mettre en œuvre la présente norme. Prière d’adresser les informations à l’IETF à ietf-ipr@ietf.org.

Le présent document est le fruit des travaux du groupe SNMPv3. Des remerciements particuliers sont adressés dans l’ordre alphabétique aux membres suivants du groupe de travail : Randy Bush, Jeffrey D. Case, Mike Daniele, Rob Frye, Lauren Heintz, Keith McCloghrie, Russ Mundy, David T. Perkins, Randy Presuhn, Aleksey Romanov, Juergen Schoenwaelder, Bert Wijnen.

La présente version du document, éditée par Randy Presuhn, se fonde à l’origine sur les travaux d’une équipe de conception dont les membres étaient : Jeffrey D. Case, Keith McCloghrie, David T. Perkins, Randy Presuhn, Juergen Schoenwaelder.

Les versions précédentes de ce document, éditées par Keith McCloghrie, étaient le résultat de travaux significatifs de quatre contributeurs majeurs : Jeffrey D. Case, Keith McCloghrie, Marshall T. Rose, Steven Waldbusser

De plus, il faut aussi remercier des contributions du groupe de travail SNMPv2 aux versions précédentes. En particulier, des remerciements sont adressés pour les contributions de : Alexander I. Alten, Dave Arneson, Uri Blumenthal, Doug Book, Kim Curran, Jim Galvin, Maria Greene, Iain Hanson, Dave Harrington, Jeff Johnson, Michael Kornegay, Deirdre Kostick, David Levi, Daniel Mahoney, Bob Natale, Brian O'Keefe, Andrew Pearson, Dave Perkins, Randy Presuhn, Aleksey Romanov, Shawn Routhier, Jon Saperia, Juergen Schoenwaelder, Bob Stewart, Kaj Tesink, Glenn Waters, Bert Wijnen.

Le protocole défini dans le présent document ne procure pas par lui-même un environnement sûr. Même si le réseau est lui-même sûr (par exemple en utilisant IPSec) il n'y a pas de contrôle sur les personnes qui sont autorisées sur le réseau sûr à accéder aux informations de gestion.

Il est recommandé que les développeurs prennent en considération les caractéristiques de sécurité fournies par le cadre SNMPv3. Précisément, l'utilisation du modèle de sécurité fondée sur l'utilisateur, STD 62, [RFC3414] et le modèle de contrôle d'accès fondé sur la vue , STD 62, [RFC3415] est recommandée.

Il est donc de la responsabilité du consommateur/utilisateur de s'assurer que l'entité SNMP est configurée de façon que :

- seuls les principaux (utilisateurs) qui ont des droits légitimes puissent accéder aux valeurs ou à les modifier pour tout objet de MIB pris en charge par cette entité ;

- l'occurrence d'événements particuliers sur l'entité soit communiquée de façon appropriée ;

- l'entité réponde de façon appropriée et de bonne foi aux événements et informations qui lui sont communiqués.

[RFC3413] D. Levi, P. Meyer et B. Stewart, "Applications du protocole simple de gestion de réseau (SNMP)", STD 62, décembre 2002.

[ASN1] Organiaation Internationale de Normalisation, "Systèmes de traitement de l'information – Interconnxion des systèmes ouverts - Spécification de la notation de syntaxe abstraite numéro un (ASN.1)". Norme internationale 8824, décembre 1987.

[FRAG] Kent, C. and J. Mogul, "Fragmentation Considered Harmful," Proceedings, ACM SIGCOMM '87, Stowe, VT, août 1987.

[RFC1157] J. Case, M. Fedor, M. Schoffstall et J. Davin, "Protocole simple de gestion de réseau", STD 15, mai 1990. (Historique)

[RFC1215] M. Rose, "Convention pour la définition de filtres à utiliser avec le SNMP", mars 1991. (Info)

[RFC1901] J. Case, K. McCloghrie, M. Rose, S. Waldbusser "Introduction à SNMPv2 fondé sur la communauté", janvier 1996. (Hisorique)

[RFC2576] R. Frye, D. Levi, S. Routhier, B. Wijnen, "Coexistence entre les version 1, version 2 et version 3 du cadre de gestion de réseau de l'Internet" mars 2000. (Obsolète, voir RFC3584) (P.S.)

[RFC2863] K. McCloghrie, F. Kastenholz, "MIB de groupe Interfaces", juin 2000. (D.S.)

- Suppression de l'ancien paragraphe 2.3, intitulé "Accès aus informations de gestion" ;

- Changement de la façon de définir l'identifiant de demande, bien qu'avec la même syntaxe et sémantique finales, pour éviter le couplage avec le SMI. Cela n'affecte en aucune façon le protocole ;

- Remplacement du mot "exception" par le mot "erreur" dans l'ancien paragraphe 4.1. Cela n'affecte en aucune façon le protocole ;

- Précision du nombre maximum de liaisons de variables qu'une mise en œuvre doit prendre en charge dans une PDU. Cela n'affecte en aucune façon le protocole ;

- Suppression de trois phrases dans le paragraphe 4.2.3 décrivant le traitement d'une situation impossible. Cela n'affecte en aucune façon le protocole ;

- Précision de l'utilisation de SNMPv2-Trap-Pdu dans le paragraphe 4.2.6. Cela n'affecte en aucune façon le protocole ;

- Alignement de la description de l'utilisation de InformRequest-Pdu dans le paragraphe 4.2.7 avec l'architecture. Cela n'affecte en aucune façon le protocole ;

- Remplacement de la terminologie d'entité gestionnaire/agent/SNMPv2 par la terminologie de la RFC 2571. Cela n'affecte en aucune façon le protocole ;

- Elimination des IMPORTS provenant du SMI, remplacés par l'équivalent en ligne ASN.1. Cela n'affecte en aucune façon le protocole ;

- Ajout de notes attirant l'attention sur deux manifestations différentes pour atteindre la fin d'un tableau dans les exemples de tableaux ;

- Mise à jour des commentaires ASN.1 sur l'utilisation de Report-PDU. Cela n'affecte en aucune façon le protocole ;

- Le traitement des liaisons de variables supplémentaires dans informs a été rendu cohérent avec celui de traps. Ceci est la correction d'un oubli rédactionnel, et reflète la practique des mises en œuvre ;

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de droits de reproduction ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus de normes pour Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet ou ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et L'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation des informations ci présentes n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Le financement de la fonction d’édition des RFC est actuellement fourni par la Internet Society.

Groupe de travail Réseau	Éditeur de cette version : R. Presuhn, BMC Software, Inc.
Request for Comments : 3416	Auteurs de la version précédente :
STD 62	J. Case, SNMP Research, Inc.
RFC rendue obsolète : 1905	K. McCloghrie, Cisco Systems, Inc.
Catégorie : Norme	M. Rose, Dover Beach Consulting, Inc.
	S. Waldbusser, International Network Services
Traduction Claude Brière de L’Isle	décembre 2002

Numéro d'interface	Adresse réseau	Adresse physique	Type
1	10.0.0.51	00:00:10:01:23:45	statique
1	9.2.3.4	00:00:10:54:32:10	dynamique
2	10.0.0.15	00:00:10:98:76:54	dynamique