RFC 1157 - Protocole simple de gestion de réseau (SNMP)

Groupe de travail réseau Demande de commentaires: 1157 Obsolète: RFC 1098

Auteurs: J. Case (SNMP Research) M. Fedor (Performance Systems International) M. Schoffstall (Performance Systems International) J. Davin (MIT Laboratory for Computer Science)

Date: May 1990

---

Table des matières

• 1. Statut de ce mémoire
• 2. Introduction
• 3. Architecture de SNMP
• 3.1. Objectifs de l'architecture
• 3.2. Éléments de l'architecture
• 3.2.1. Portée des informations de gestion
• 3.2.2. Représentation des informations de gestion
• 3.2.3. Opérations prises en charge sur les informations de gestion
• 3.2.4. Forme et signification des échanges de protocole
• 3.2.5. Définition des relations administratives
• 3.2.6. Forme et signification des références aux objets gérés
• 3.2.6.1. Résolution des références MIB ambiguës
• 3.2.6.2. Résolution des références entre versions de la MIB
• 3.2.6.3. Identification des instances d'objet
• 3.2.6.3.1. Noms de types d'objet ifTable
• 3.2.6.3.2. Noms de types d'objet atTable
• 3.2.6.3.3. Noms de types d'objet ipAddrTable
• 3.2.6.3.4. Noms de types d'objet ipRoutingTable
• 3.2.6.3.5. Noms de types d'objet tcpConnTable
• 3.2.6.3.6. Noms de types d'objet egpNeighTable
• 4. Spécification du protocole
• 4.1. Éléments de procédure
• 4.1.1. Structures communes
• 4.1.2. GetRequest-PDU
• 4.1.3. GetNextRequest-PDU
• 4.1.3.1. Exemple de parcours de table
• 4.1.4. GetResponse-PDU
• 4.1.5. SetRequest-PDU
• 4.1.6. Trap-PDU
• 4.1.6.1. Trap coldStart
• 4.1.6.2. Trap warmStart
• 4.1.6.3. Trap linkDown
• 4.1.6.4. Trap linkUp
• 4.1.6.5. Trap authenticationFailure
• 4.1.6.6. Trap egpNeighborLoss
• 4.1.6.7. Trap enterpriseSpecific
• 5. Définitions
• 6. Remerciements
• 7. Références
• 8. Considérations relatives à la sécurité
• 9. Adresses des auteurs

---

1. Statut de ce mémoire

Cette RFC est une réédition de la RFC 1098, avec une section modifiée « Statut de ce mémo » ainsi que quelques corrections typographiques mineures. Ce mémo définit un protocole simple par lequel les informations de gestion pour un élément de réseau peuvent être inspectées ou modifiées par des utilisateurs logiquement distants. En particulier, conjointement avec les mémos qui l'accompagnent qui décrivent la structure des informations de gestion ainsi que la base d'informations de gestion, ces documents fournissent une architecture et un système simples et fonctionnels pour gérer des Internet basés sur TCP/IP et en particulier l'Internet.

L'Internet Activities Board recommande que toutes les implémentations IP et TCP soient gérables en réseau. Cela implique la mise en œuvre d'Internet MIB (RFC-1156) et d'au moins un des deux protocoles de gestion recommandés SNMP (RFC-1157) ou CMOT (RFC-1095). Il convient de noter qu’à l’heure actuelle, SNMP est une norme Internet complète et CMOT est un projet de norme. Voir également les RFC sur les exigences en matière d'hôte et de passerelle pour des informations plus spécifiques sur l'applicabilité de cette norme.

Veuillez vous référer à la dernière édition de la RFC « IAB Official Protocol Standards » pour obtenir des informations actuelles sur l'état et le statut des protocoles Internet standard.

La diffusion de ce mémo est illimitée.

2. Introduction

Comme indiqué dans la RFC 1052, Recommandations de l'IAB pour le développement de normes de gestion de réseau Internet [1], une stratégie à deux volets pour la gestion de réseau des Internets basés sur TCP/IP a été entreprise. À court terme, le Simple Network Management Protocol (SNMP) devait être utilisé pour gérer les nœuds de la communauté Internet. A terme, l'utilisation du framework de gestion de réseau OSI devait être étudiée. Deux documents ont été produits pour définir les informations de gestion : la RFC 1065, qui définit la structure des informations de gestion (SMI) [2], et la RFC 1066, qui définit la base d'informations de gestion (MIB) [3]. Ces deux documents ont été conçus de manière à être compatibles avec les cadres de gestion de réseau SNMP et OSI.

Cette stratégie a été couronnée de succès à court terme : en quelques mois, la technologie de gestion de réseau basée sur Internet a été mise en œuvre par les communautés de recherche et commerciale. En conséquence, certaines parties de la communauté Internet sont devenues gérables en réseau en temps opportun.

Comme indiqué dans la RFC 1109, rapport du deuxième groupe ad hoc de révision de la gestion de réseau [4], les exigences des cadres de gestion de réseau SNMP et OSI étaient plus différentes que prévu. En tant que tel, l'exigence de compatibilité entre le SMI/MIB et les deux frameworks a été suspendue. Cette action a permis au cadre opérationnel de gestion de réseau, le SNMP, de répondre aux nouveaux besoins opérationnels de la communauté Internet en produisant des documents définissant les nouveaux éléments MIB.

L'IAB a désigné le SNMP, le SMI et le MIB Internet initial comme étant des « protocoles standard » complets avec le statut « Recommandé ». Par cette action, l'IAB recommande que toutes les implémentations IP et TCP soient gérables en réseau et que les implémentations gérables en réseau doivent adopter et implémenter SMI, MIB et SNMP.

En tant que tel, le cadre de gestion de réseau actuel pour les Internet basés sur TCP/IP comprend : La structure et l'identification des informations de gestion pour les Internet basés sur TCP/IP, qui décrit comment les objets gérés contenus dans MIB sont définis comme indiqué dans la RFC 1155 [5] ; Base d'informations de gestion pour la gestion de réseau des Internet basés sur TCP/IP, qui décrit les objets gérés contenus dans le MIB comme indiqué dans la RFC 1156 [6] ; et le Simple Network Management Protocol, qui définit le protocole utilisé pour gérer ces objets, comme indiqué dans le présent mémo.

Comme indiqué dans la RFC 1052, Recommandations de l'IAB pour le développement de normes de gestion de réseau Internet [1], l'Internet Activities Board a demandé à l'Internet Engineering Task Force (IETF) de créer deux nouveaux groupes de travail dans le domaine de la gestion de réseau. Un groupe a été chargé de préciser et de définir davantage les éléments à inclure dans la base d'informations de gestion (MIB). L'autre était chargé de définir les modifications apportées au protocole de gestion de réseau simple (SNMP) pour répondre aux besoins à court terme des communautés de fournisseurs de réseaux et d'exploitation, et pour s'aligner sur les résultats du groupe de travail MIB.

Le groupe de travail MIB a produit deux mémos, l'un qui définit une structure pour les informations de gestion (SMI) [2] à utiliser par les objets gérés contenus dans le MIB. Un deuxième mémo [3] définit la liste des objets gérés.

Le résultat du groupe de travail sur les extensions SNMP est ce mémo, qui intègre les modifications apportées à la définition initiale de SNMP [7] nécessaires pour atteindre l'alignement avec le résultat du groupe de travail MIB. Les changements devraient être minimes afin d'être cohérents avec la directive de l'IAB selon laquelle les groupes de travail doivent être « extrêmement sensibles à la nécessité de garder le SNMP simple ». Bien que beaucoup de soin et de débats aient été apportés aux modifications apportées au SNMP qui sont reflétées dans ce mémo, le protocole résultant n'est pas rétrocompatible avec son prédécesseur, le Simple Gateway Monitoring Protocol (SGMP) [8]. Bien que la syntaxe du protocole ait été modifiée, la philosophie, les décisions de conception et l'architecture d'origine restent intactes. Afin d'éviter toute confusion, de nouveaux ports UDP ont été alloués pour être utilisés par le protocole décrit dans ce mémo.

3. Architecture de SNMP

Le modèle architectural SNMP comprend implicitement un ensemble de stations de gestion de réseau et d'éléments de réseau. Les stations de gestion de réseau exécutent des applications de gestion qui surveillent et contrôlent les éléments du réseau. Les éléments de réseau sont des dispositifs tels que des hôtes, des passerelles, des serveurs de terminaux, etc., dotés d'agents de gestion chargés d'exécuter les fonctions de gestion de réseau demandées par les stations de gestion de réseau. Le protocole de gestion de réseau simple (SNMP) est utilisé pour communiquer des informations de gestion entre les stations de gestion de réseau et les agents dans les éléments du réseau.

3.1. Objectifs de l'architecture

Le SNMP minimise explicitement le nombre et la complexité des fonctions de gestion réalisées par l'agent de gestion lui-même. Cet objectif est attractif à au moins quatre égards :

1. Le coût de développement du logiciel d'agent de gestion nécessaire à la prise en charge du protocole est en conséquence réduit.

2. Le degré de fonction de gestion prise en charge à distance est en conséquence augmenté, permettant ainsi une utilisation maximale des ressources Internet dans la tâche de gestion.

3. Le degré de fonction de gestion prise en charge à distance est en conséquence augmenté, imposant ainsi le moins de restrictions possibles sur la forme et la sophistication des outils de gestion.

4. Des ensembles simplifiés de fonctions de gestion sont facilement compris et utilisés par les développeurs d'outils de gestion de réseau.

Un deuxième objectif du protocole est que le paradigme fonctionnel de surveillance et de contrôle soit suffisamment extensible pour s'adapter à des aspects supplémentaires, éventuellement imprévus, de l'exploitation et de la gestion du réseau.

Un troisième objectif est que l'architecture soit, autant que possible, indépendante de l'architecture et des mécanismes d'hôtes ou de passerelles particuliers.

3.2. Éléments de l'architecture

L'architecture SNMP articule une solution au problème de gestion de réseau en termes de :

1. la portée des informations de gestion communiquées par le protocole,

2. la représentation des informations de gestion communiquées par le protocole,

3. les opérations sur les informations de gestion supportées par le protocole,

4. la forme et le sens des échanges entre entités de gestion,

5. la définition des relations administratives entre les entités de gestion, et

6. la forme et la signification des références aux informations de gestion.

3.2.1. Portée des informations de gestion

La portée des informations de gestion communiquées par le fonctionnement du SNMP est exactement celle représentée par les instances de tous les types d'objets non agrégés, soit définis dans la norme Internet MIB, soit définis ailleurs selon les conventions énoncées dans la norme Internet SMI [5].

La prise en charge des types d'objets agrégés dans le MIB n'est ni requise pour la conformité avec le SMI ni réalisée par le SNMP.

3.2.2. Représentation des informations de gestion

Les informations de gestion communiquées par le fonctionnement du SNMP sont représentées selon le sous-ensemble du langage ASN.1 [9] qui est spécifié pour la définition des types non agrégés dans le SMI.

Le SGMP a adopté la convention d'utiliser un sous-ensemble bien défini du langage ASN.1 [9]. Le SNMP poursuit et étend cette tradition en utilisant un sous-ensemble légèrement plus complexe de ASN.1 pour décrire les objets gérés et pour décrire les unités de données de protocole utilisées pour gérer ces objets. De plus, le désir de faciliter la transition éventuelle vers des protocoles de gestion de réseau basés sur OSI a conduit à la définition dans le langage ASN.1 d'une structure Internet standard d'informations de gestion (SMI) [5] et d'une base d'informations de gestion (MIB) [6]. L'utilisation du langage ASN.1 a été, en partie, encouragée par l'utilisation réussie de ASN.1 dans des efforts antérieurs, en particulier le SGMP. Les restrictions d'utilisation du ASN.1 qui font partie du SMI contribuent à la simplicité adoptée et validée par l'expérience avec le SGMP. Également par souci de simplicité, le SNMP utilise uniquement un sous-ensemble des règles de codage de base de ASN.1 [10]. À savoir, tous les codages utilisent la forme de longueur définie. De plus, lorsque cela est autorisé, des codages non constructeurs sont utilisés à la place des codages constructeur. Cette restriction s'applique à tous les aspects du codage ASN.1, à la fois pour les unités de données de protocole de niveau supérieur et pour les objets de données qu'elles contiennent.

3.2.3. Opérations prises en charge sur les informations de gestion

Le SNMP modélise toutes les fonctions d'agent de gestion sous forme de modifications ou d'inspections de variables. Ainsi, une entité de protocole sur un hôte logiquement distant (éventuellement l'élément de réseau lui-même) interagit avec l'agent de gestion résidant sur l'élément de réseau afin de récupérer (obtenir) ou de modifier (définir) des variables. Cette stratégie a au moins deux conséquences positives :

1. Cela a pour effet de limiter à deux le nombre de fonctions de gestion essentielles réalisées par l'agent de gestion : une opération pour attribuer une valeur à une configuration spécifiée ou à un autre paramètre et une autre pour récupérer une telle valeur.

2. Un deuxième effet de cette décision est d'éviter d'introduire dans la définition du protocole le support de commandes de gestion impératives : le nombre de telles commandes est en pratique toujours croissant, et la sémantique de telles commandes est en général arbitrairement complexe.

La stratégie implicite du SNMP est que la surveillance de l'état du réseau à tout niveau de détail significatif est réalisée principalement en interrogeant les informations appropriées de la part du ou des centres de surveillance. Un nombre limité de messages non sollicités (pièges) guident le timing et l'orientation de l'interrogation. Limiter le nombre de messages non sollicités est conforme à l'objectif de simplicité et de minimisation de la quantité de trafic généré par la fonction de gestion du réseau.

Il est peu probable que l'exclusion des commandes impératives de l'ensemble des fonctions de gestion explicitement prises en charge exclue toute opération souhaitable d'agent de gestion. Actuellement, la plupart des commandes sont des requêtes visant soit à définir la valeur d'un paramètre, soit à récupérer une telle valeur, et la fonction des quelques commandes impératives actuellement prises en charge est facilement prise en charge en mode asynchrone par ce modèle de gestion. Dans ce schéma, une commande impérative peut être réalisée sous la forme du réglage d'une valeur de paramètre qui déclenche ensuite l'action souhaitée. Par exemple, plutôt que d'implémenter une « commande de redémarrage », cette action peut être invoquée en définissant simplement un paramètre indiquant le nombre de secondes avant le redémarrage du système.

3.2.4. Forme et signification des échanges de protocole

La communication des informations de gestion entre les entités de gestion est réalisée dans le SNMP via l'échange de messages de protocole. La forme et la signification de ces messages sont définies ci-dessous à la section 4.

Conformément à l'objectif de minimiser la complexité de l'agent de gestion, l'échange de messages SNMP nécessite uniquement un service de datagramme peu fiable, et chaque message est entièrement et indépendamment représenté par un seul datagramme de transport. Bien que ce document spécifie l'échange de messages via le protocole UDP [11], les mécanismes du SNMP sont généralement adaptés à une utilisation avec une grande variété de services de transport.

3.2.5. Définition des relations administratives

L'architecture SNMP admet diverses relations administratives entre les entités qui participent au protocole. Les entités résidant dans les stations de gestion et les éléments de réseau qui communiquent entre eux à l'aide du SNMP sont appelées entités d'application SNMP. Les processus homologues qui implémentent SNMP et prennent ainsi en charge les entités d'application SNMP sont appelés entités de protocole.

L'association d'un agent SNMP avec un ensemble arbitraire d'entités d'application SNMP est appelée communauté SNMP. Chaque communauté SNMP est nommée par une chaîne d'octets, appelée le nom de communauté de ladite communauté.

Un message SNMP provenant d'une entité applicative SNMP qui appartient en fait à la communauté SNMP nommée par le composant communautaire dudit message est appelé message SNMP authentique. L'ensemble de règles par lesquelles un message SNMP est identifié comme un message SNMP authentique pour une communauté SNMP particulière est appelé schéma d'authentification. Une implémentation d'une fonction qui identifie les messages SNMP authentiques selon un ou plusieurs schémas d'authentification est appelée service d'authentification.

De toute évidence, une gestion efficace des relations administratives entre les entités d'application SNMP nécessite des services d'authentification qui (par l'utilisation de cryptage ou d'autres techniques) sont capables d'identifier les messages SNMP authentiques avec un degré élevé de certitude. Certaines implémentations de SNMP peuvent souhaiter prendre en charge uniquement un service d'authentification trivial qui identifie tous les messages SNMP comme des messages SNMP authentiques.

Pour tout élément de réseau, un sous-ensemble d'objets dans MIB qui appartiennent à cet élément est appelé vue SNMP MIB. Notez que les noms des types d'objet représentés dans une vue SNMP MIB ne doivent pas nécessairement appartenir à une seule sous-arborescence de l'espace de noms du type d'objet.

Un élément de l'ensemble { READ-ONLY, READ-WRITE } est appelé mode d'accès SNMP.

L'association d'un mode d'accès SNMP à une vue SNMP MIB est appelée profil de communauté SNMP. Un profil de communauté SNMP représente les privilèges d'accès spécifiés aux variables dans une vue MIB spécifiée. Pour chaque variable de la vue MIB dans un profil de communauté SNMP donné, l'accès à cette variable est représenté par le profil selon les conventions suivantes :

1. si ladite variable est définie dans le MIB avec « Access : » de « aucun », elle n'est disponible en tant qu'opérande pour aucun opérateur ;

2. si ladite variable est définie dans le MIB avec « Accès : » de « lecture-écriture » ou « écriture seule » et que le mode d'accès du profil donné est READ-WRITE, cette variable est disponible en tant qu'opérande pour les opérations get, set et trap ;

3. sinon, la variable est disponible en tant qu'opérande pour les opérations get et trap.

4. Dans les cas où une variable « en écriture seule » est un opérande utilisé pour les opérations get ou trap, la valeur donnée pour la variable est spécifique à l'implémentation.

Le couplage d'une communauté SNMP avec un profil de communauté SNMP est appelé stratégie d'accès SNMP. Une stratégie d'accès représente un profil de communauté spécifié accordé par l'agent SNMP d'une communauté SNMP spécifiée aux autres membres de cette communauté. Toutes les relations administratives entre les entités d'application SNMP sont définies architecturalement en termes de politiques d'accès SNMP.

Pour chaque stratégie d'accès SNMP, si l'élément réseau sur lequel réside l'agent SNMP pour la communauté SNMP spécifiée n'est pas celui auquel appartient la vue MIB pour le profil spécifié, cette stratégie est appelée stratégie d'accès proxy SNMP. L'agent SNMP associé à une stratégie d'accès proxy est appelé agent proxy SNMP. Même si une définition imprudente des politiques d’accès aux proxys peut entraîner des boucles de gestion, une définition prudente des politiques de proxy est utile d’au moins deux manières :

1. Il permet la surveillance et le contrôle d'éléments de réseau qui ne seraient autrement pas adressables à l'aide du protocole de gestion et du protocole de transport. Autrement dit, un agent mandataire peut fournir une fonction de conversion de protocole permettant à une station de gestion d'appliquer un cadre de gestion cohérent à tous les éléments du réseau, y compris des dispositifs tels que des modems, des multiplexeurs et d'autres dispositifs prenant en charge différents cadres de gestion.

2. Il protège potentiellement les éléments du réseau des politiques de contrôle d’accès élaborées. Par exemple, un agent proxy peut mettre en œuvre un contrôle d'accès sophistiqué grâce auquel divers sous-ensembles de variables au sein du MIB sont rendus accessibles à différentes stations de gestion sans augmenter la complexité de l'élément de réseau.

A titre d'exemple, la figure 1 illustre la relation entre les stations de gestion, les agents proxy et les agents de gestion. Dans cet exemple, l'agent proxy est considéré comme un centre d'opérations de réseau Internet normal (INOC) d'un certain domaine administratif qui entretient une relation de gestion standard avec un ensemble d'agents de gestion.

   +------------------+       +----------------+      +----------------+
   |  Region #1 INOC  |       |Region #2 INOC  |      |PC in Region #3 |
   |                  |       |                |      |                |
   |Domain=Region #1  |       |Domain=Region #2|      |Domain=Region #3|
   |CPU=super-mini-1  |       |CPU=super-mini-1|      |CPU=Clone-1     |
   |PCommunity=pub    |       |PCommunity=pub  |      |PCommunity=slate|
   |                  |       |                |      |                |
   +------------------+       +----------------+      +----------------+
          /|\                      /|\                     /|\
           |                        |                       |
           |                        |                       |
           |                       \|/                      |
           |               +-----------------+              |
           +-------------->| Region #3 INOC  |<-------------+
                           |                 |
                           |Domain=Region #3 |
                           |CPU=super-mini-2 |
                           |PCommunity=pub,  |
                           |         slate   |
                           |DCommunity=secret|
           +-------------->|                 |<-------------+
           |               +-----------------+              |
           |                       /|\                      |
           |                        |                       |
           |                        |                       |
          \|/                      \|/                     \|/
   +-----------------+     +-----------------+       +-----------------+
   |Domain=Region#3  |     |Domain=Region#3  |       |Domain=Region#3  |
   |CPU=router-1     |     |CPU=mainframe-1  |       |CPU=modem-1      |
   |DCommunity=secret|     |DCommunity=secret|       |DCommunity=secret|
   +-----------------+     +-----------------+       +-----------------+

Domain : le domaine administratif de l'élément PCommunity : le nom d'une communauté utilisant un agent proxy DCommunity : le nom d'une communauté directe

Figure 1 Exemple de configuration de gestion de réseau

3.2.6. Forme et signification des références aux objets gérés

Le SMI nécessite que la définition d'une adresse de protocole de gestion conforme :

1. la résolution des références MIB ambiguës,

2. la résolution des références MIB en présence de plusieurs versions MIB, et

3. l'identification d'instances particulières de types d'objets définis dans le MIB.

3.2.6.1. Résolution des références MIB ambiguës

Étant donné que la portée de toute opération SNMP est conceptuellement limitée aux objets pertinents pour un seul élément de réseau et que toutes les références SNMP aux objets MIB sont (implicitement ou explicitement) des noms de variables uniques, il n'est pas possible qu'une référence SNMP à un type d'objet défini dans MIB puisse être résolue en plusieurs instances de ce type.

3.2.6.2. Résolution des références entre versions de la MIB

L'instance d'objet référencée par toute opération SNMP est exactement celle spécifiée dans le cadre de la demande d'opération ou (dans le cas d'une opération get-next) son successeur immédiat dans le MIB dans son ensemble. En particulier, une référence à un objet faisant partie d'une version de la norme Internet MIB ne se résout pas en un objet qui ne fait pas partie de ladite version de la norme Internet MIB, sauf dans le cas où l'opération demandée est get-next et où le nom d'objet spécifié est lexicographiquement le dernier parmi les noms de tous les objets présentés dans le cadre de ladite version de la norme Internet MIB.

3.2.6.3. Identification des instances d'objet

Les noms de tous les types d'objets du MIB sont définis explicitement soit dans la norme Internet MIB, soit dans d'autres documents conformes aux conventions de dénomination du SMI. Le SMI exige que les protocoles de gestion conformes définissent des mécanismes permettant d'identifier des instances individuelles de ces types d'objets pour un élément de réseau particulier.

Chaque instance de tout type d'objet défini dans MIB est identifiée dans les opérations SNMP par un nom unique appelé « nom de variable ». En général, le nom d'une variable SNMP est un OBJECT IDENTIFIER de la forme x.y, où x est le nom d'un type d'objet non agrégé défini dans MIB et y est un fragment OBJECT IDENTIFIER qui, d'une manière spécifique au type d'objet nommé, identifie l'instance souhaitée.

Cette stratégie de dénomination permet l'exploitation la plus complète de la sémantique du GetNextRequest-PDU (voir Section 4), car elle attribue des noms aux variables liées de manière à être contiguës dans l'ordre lexicographique de tous les noms de variables connus dans le MIB.

La dénomination spécifique au type des instances d'objet est définie ci-dessous pour un certain nombre de classes de types d'objet. Les instances d'un type d'objet auquel aucune des conventions de dénomination suivantes n'est applicable sont nommées par des IDENTIFIANTS D'OBJET de la forme x.0, où x est le nom dudit type d'objet dans la définition MIB.

Par exemple, supposons que l'on veuille identifier une instance de la variable sysDescr. La classe d'objet pour sysDescr est :

             iso org dod internet mgmt mib system sysDescr
              1   3   6     1      2    1    1       1

Par conséquent, le type d'objet, x, serait 1.3.6.1.2.1.1.1 auquel est ajouté un sous-identifiant d'instance de 0. Autrement dit, 1.3.6.1.2.1.1.1.0 identifie la seule et unique instance de sysDescr.

3.2.6.3.1. Noms de types d'objet ifTable

Le nom d'une interface de sous-réseau, s, est la valeur OBJECT IDENTIFIER de la forme i, où i a la valeur de cette instance du type d'objet ifIndex associé à s.

Pour chaque type d'objet t, pour lequel le nom défini n a le préfixe ifEntry, une instance i de t est nommée par un OBJECT IDENTIFIER de la forme n.s, où s est le nom de l'interface de sous-réseau sur laquelle i représente des informations.

Par exemple, supposons que l'on veuille identifier l'instance de la variable ifType associée à l'interface 2. En conséquence, ifType.2 identifierait l'instance souhaitée.

3.2.6.3.2. Noms de types d'objet atTable

Le nom d'une adresse réseau mise en cache AT, x, est un OBJECT IDENTIFIER de la forme 1.a.b.c.d, où a.b.c.d est la valeur (dans la notation familière « point ») du type d'objet atNetAddress associé à x.

Le nom d'une équivalence de traduction d'adresse e est une valeur OBJECT IDENTIFIER de la forme s.w, telle que s est la valeur de cette instance du type d'objet atIndex associée à e et telle que w est le nom de l'adresse réseau mise en cache AT associée à e. Pour chaque type d'objet t, pour lequel le nom défini n a le préfixe atEntry, une instance i de t est nommée par un OBJECT IDENTIFIER de la forme n.y, où y est le nom de l'équivalence de traduction d'adresse sur laquelle i représente des informations.

Par exemple, supposons que l'on veuille trouver l'adresse physique d'une entrée dans la table de traduction d'adresses (cache ARP) associée à une adresse IP de 89.1.1.42 et à l'interface 3. En conséquence, atPhysAddress.3.1.89.1.1.42 identifierait l'instance souhaitée.

3.2.6.3.3. Noms de types d'objet ipAddrTable

Le nom d'un élément de réseau adressable par IP, x, est le OBJECT IDENTIFIER de la forme a.b.c.d tel que a.b.c.d est la valeur (dans la notation familière « point ») de cette instance du type d'objet ipAdEntAddr associé à x.

Pour chaque type d'objet t, pour lequel le nom défini n a le préfixe ipAddrEntry, une instance i de t est nommée par un OBJECT IDENTIFIER de la forme n.y, où y est le nom de l'élément de réseau adressable IP sur lequel i représente des informations.

Par exemple, supposons que l'on veuille rechercher le masque réseau d'une entrée dans la table d'interface IP associée à une adresse IP de 89.1.1.42. Par conséquent, ipAdEntNetMask.89.1.1.42 identifierait l’instance souhaitée.

3.2.6.3.4. Noms de types d'objet ipRoutingTable

Le nom d'une route IP, x, est le OBJECT IDENTIFIER de la forme a.b.c.d tel que a.b.c.d est la valeur (dans la notation familière « point ») de cette instance du type d'objet ipRouteDest associé à x.

Pour chaque type d'objet t, pour lequel le nom défini n a le préfixe ipRoutingEntry, une instance i de t est nommée par un OBJECT IDENTIFIER de la forme n.y, où y est le nom de l'itinéraire IP sur lequel i représente des informations.

Par exemple, supposons que l'on veuille rechercher le saut suivant d'une entrée dans la table de routage IP associée à la destination de 89.1.1.42. Par conséquent, ipRouteNextHop.89.1.1.42 identifierait l’instance souhaitée.

3.2.6.3.5. Noms de types d'objet tcpConnTable

Le nom d'une connexion TCP, x, est le OBJECT IDENTIFIER de la forme a.b.c.d.e.f.g.h.i.j tel que a.b.c.d est la valeur (dans la notation familière "point") de cette instance du type d'objet tcpConnLocalAddress associé à x et telle que f.g.h.i est la valeur (dans la notation familière "point") de cette instance du type d'objet tcpConnRemoteAddress associé à x et tel que e est la valeur de cette instance du type d'objet tcpConnLocalPort associé à x et tel que j est la valeur de cette instance du type d'objet tcpConnRemotePort associé à x.

Pour chaque type d'objet t, pour lequel le nom défini n a le préfixe tcpConnEntry, une instance i de t est nommée par un OBJECT IDENTIFIER de la forme n.y, où y est le nom de la connexion TCP sur laquelle i représente des informations.

Par exemple, supposons que l'on veuille trouver l'état d'une connexion TCP entre l'adresse locale de 89.1.1.42 sur le port 21 de TCP et l'adresse distante de 10.0.0.51 sur le port 2059 de TCP. Par conséquent, tcpConnState.89.1.1.42.21.10.0.0.51.2059 identifierait l'instance souhaitée.

3.2.6.3.6. Noms de types d'objet egpNeighTable

Le nom d'un voisin EGP, x, est le OBJECT IDENTIFIER de la forme a.b.c.d tel que a.b.c.d est la valeur (dans la notation familière "point") de cette instance du type d'objet egpNeighAddr associé à x.

Pour chaque type d'objet t, pour lequel le nom défini n a le préfixe egpNeighEntry, une instance i de t est nommée par un OBJECT IDENTIFIER de la forme n.y, où y est le nom du voisin EGP sur lequel i représente des informations.

Par exemple, supposons que l'on veuille trouver l'état voisin pour l'adresse IP de 89.1.1.42. Par conséquent, egpNeighState.89.1.1.42 identifierait l’instance souhaitée.

4. Spécification du protocole

Le protocole de gestion de réseau est un protocole d'application par lequel les variables du MIB d'un agent peuvent être inspectées ou modifiées.

La communication entre les entités de protocole est réalisée par l'échange de messages, dont chacun est entièrement et indépendamment représenté dans un seul datagramme UDP en utilisant les règles de codage de base de ASN.1 (comme discuté dans la section 3.2.2). Un message se compose d'un identifiant de version, d'un nom de communauté SNMP et d'une unité de données de protocole (PDU). Une entité de protocole reçoit des messages sur le port UDP 161 sur l'hôte auquel elle est associée pour tous les messages à l'exception de ceux qui signalent des interruptions (c'est-à-dire tous les messages sauf ceux qui contiennent le Trap-PDU). Les messages signalant des interruptions doivent être reçus sur le port 162 UDP pour un traitement ultérieur. Une mise en œuvre de ce protocole n'a pas besoin d'accepter des messages dont la longueur dépasse 484 octets. Cependant, il est recommandé que les implémentations prennent en charge des datagrammes plus volumineux chaque fois que cela est possible.

Il est obligatoire que toutes les implémentations du SNMP prennent en charge les cinq PDU : GetRequest-PDU, GetNextRequest-PDU, GetResponse-PDU, SetRequest-PDU et Trap-PDU.

    RFC1157-SNMP DEFINITIONS ::= BEGIN

     IMPORTS
          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
                  FROM RFC1155-SMI;

     -- top-level message

             Message ::=
                     SEQUENCE {
                          version        -- version-1 for this RFC
                             INTEGER {
                                 version-1(0)
                             },

                         community      -- community name
                             OCTET STRING,

                         data           -- e.g., PDUs if trivial
                             ANY        -- authentication is being used
                     }
     -- protocol data units

             PDUs ::=
                     CHOICE {
                         get-request
                             GetRequest-PDU,

                         get-next-request
                             GetNextRequest-PDU,

                         get-response
                             GetResponse-PDU,

                         set-request
                             SetRequest-PDU,

                         trap
                             Trap-PDU
                          }

     -- the individual PDUs and commonly used
     -- data types will be defined later

     END

4.1. Éléments de procédure

Cette section décrit les actions d'une entité de protocole implémentant le SNMP. Notez cependant qu'il n'est pas destiné à contraindre l'architecture interne d'une implémentation conforme.

Dans le texte qui suit, le terme adresse de transport est utilisé. Dans le cas du UDP, une adresse de transport se compose d'une adresse IP et d'un port UDP. D'autres services de transport peuvent être utilisés pour prendre en charge le SNMP. Dans ces cas, la définition d'une adresse de transport doit être effectuée en conséquence.

Les actions de niveau supérieur d'une entité de protocole qui génère un message sont les suivantes :

1. Il construit d'abord la PDU appropriée, par exemple le GetRequest-PDU, en tant qu'objet ASN.1.

2. Il transmet ensuite cet objet ASN.1 ainsi qu'un nom de communauté, son adresse de transport source et l'adresse de transport de destination, au service qui implémente le schéma d'authentification souhaité. Ce service d'authentification renvoie un autre objet ASN.1.

3. L'entité de protocole construit ensuite un objet Message ASN.1, en utilisant le nom de communauté et l'objet ASN.1 résultant.

4. Ce nouvel objet ASN.1 est ensuite sérialisé, en utilisant les règles de codage de base de ASN.1, puis envoyé à l'aide d'un service de transport vers l'entité de protocole homologue.

De même, les actions de niveau supérieur d'une entité de protocole qui reçoit un message sont les suivantes :

1. Il effectue une analyse rudimentaire du datagramme entrant pour créer un objet ASN.1 correspondant à un objet Message ASN.1. Si l'analyse échoue, il supprime le datagramme et n'effectue aucune autre action.

2. Il vérifie ensuite le numéro de version du message SNMP. S'il y a une discordance, il rejette le datagramme et n'effectue aucune autre action.

3. L'entité de protocole transmet ensuite le nom de communauté et les données utilisateur trouvées dans l'objet Message ASN.1, ainsi que les adresses de transport source et destination du datagramme, au service qui implémente le schéma d'authentification souhaité. Cette entité renvoie un autre objet ASN.1, ou signale un échec d'authentification. Dans ce dernier cas, l'entité de protocole note cet échec, génère (éventuellement) une interruption, rejette le datagramme et n'effectue aucune autre action.

4. L'entité de protocole effectue ensuite une analyse rudimentaire sur l'objet ASN.1 renvoyé par le service d'authentification pour construire un objet ASN.1 correspondant à un objet PDUs ASN.1. Si l'analyse échoue, il supprime le datagramme et n'effectue aucune autre action. Sinon, à l'aide de la communauté nommée SNMP, le profil approprié est sélectionné et la PDU est traitée en conséquence. Si, à la suite de ce traitement, un message est renvoyé, l'adresse de transport source à partir de laquelle le message de réponse est envoyé doit être identique à l'adresse de transport de destination à laquelle le message de demande d'origine a été envoyé.

4.1.1. Structures communes

Avant de présenter les six types de PDU du protocole, il convient de considérer certaines des constructions ASN.1 fréquemment utilisées :

                  -- request/response information

                  RequestID ::=
                          INTEGER

                  ErrorStatus ::=
                          INTEGER {
                              noError(0),
                              tooBig(1),
                              noSuchName(2),
                              badValue(3),
                              readOnly(4)
                              genErr(5)
                          }

                  ErrorIndex ::=
                          INTEGER

                  -- variable bindings

                  VarBind ::=
                          SEQUENCE {
                              name
                                  ObjectName,

                              value
                                  ObjectSyntax
                          }

                  VarBindList ::=
                          SEQUENCE OF
                              VarBind

Les RequestID sont utilisés pour faire la distinction entre les demandes en attente. Grâce au RequestID, une entité d'application SNMP peut corréler les réponses entrantes avec les demandes en attente. Dans les cas où un service de datagramme peu fiable est utilisé, le RequestID fournit également un moyen simple d'identifier les messages dupliqués par le réseau.

Une instance non nulle de ErrorStatus est utilisée pour indiquer qu'une exception s'est produite lors du traitement d'une demande. Dans ces cas, ErrorIndex peut fournir des informations supplémentaires en indiquant quelle variable d'une liste a provoqué l'exception.

Le terme variable fait référence à une instance d'un objet géré. Une liaison de variable, ou VarBind, fait référence à l'association du nom d'une variable à la valeur de la variable. Une VarBindList est une simple liste de noms de variables et de valeurs correspondantes. Certaines PDU ne concernent que le nom d'une variable et non sa valeur (par exemple, le GetRequest-PDU). Dans ce cas, la partie valeur de la liaison est ignorée par l'entité de protocole. Toutefois, la partie valeur doit toujours avoir une syntaxe et un codage ASN.1 valides. Il est recommandé d'utiliser la valeur ASN.1 NULL pour la partie valeur de ces liaisons.

4.1.2. GetRequest-PDU

La forme du GetRequest-PDU est :

                  GetRequest-PDU ::=
                      [0]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,

                              error-status        -- always 0
                                  ErrorStatus,

                              error-index         -- always 0
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

Le GetRequest-PDU est généré par une entité protocolaire uniquement à la demande de son entité applicative SNMP.

Dès réception du GetRequest-PDU, l'entité de protocole réceptrice répond conformément à toute règle applicable dans la liste ci-dessous :

1. Si, pour un objet nommé dans le champ variable-bindings, le nom de l'objet ne correspond pas exactement au nom d'un objet disponible pour les opérations d'obtention dans la vue MIB appropriée, alors l'entité réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est noSuchName, et la valeur du Le champ error-index est l'index dudit composant de nom d'objet dans le message reçu.

2. Si, pour tout objet nommé dans le champ variable-bindings, l'objet est de type agrégat (tel que défini dans le SMI), alors l'entité réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est noSuchName, et la valeur du champ error-index est l'index dudit nom d'objet. composant dans le message reçu.

3. Si la taille du GetResponse-PDU généré comme décrit ci-dessous devait dépasser une limitation locale, alors l'entité réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est tooBig, et la valeur du champ error-index est nulle.

4. Si, pour un objet nommé dans le champ variable-bindings, la valeur de l'objet ne peut être récupérée pour des raisons non couvertes par aucune des règles précédentes, alors l'entité réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est genErr et la valeur du champ error-index est l'index dudit nom d'objet. composant dans le message reçu.

Si aucune des règles précédentes ne s'applique, alors l'entité de protocole réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de telle sorte que, pour chaque objet nommé dans le champ de liaisons de variables du message reçu, le composant correspondant du GetResponse-PDU représente le nom et la valeur de cette variable. La valeur du champ d'état d'erreur de GetResponse-PDU est noError et la valeur du champ error-index est zéro. La valeur du champ request-id du GetResponse-PDU est celle du message reçu.

4.1.3. GetNextRequest-PDU

La forme du GetNextRequest-PDU est identique à celle du GetRequest-PDU à l'exception de l'indication du type de PDU. Dans le langage ASN.1 :

                  GetNextRequest-PDU ::=
                      [1]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,
                              error-status        -- always 0
                                  ErrorStatus,

                              error-index         -- always 0
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

Le GetNextRequest-PDU est généré par une entité protocolaire uniquement à la demande de son entité applicative SNMP.

Dès réception du GetNextRequest-PDU, l'entité de protocole réceptrice répond conformément à toute règle applicable dans la liste ci-dessous :

1. Si, pour un nom d'objet dans le champ variable-bindings, ce nom ne précède pas lexicographiquement le nom d'un objet disponible pour les opérations d'obtention dans la vue MIB appropriée, alors l'entité réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est noSuchName, et la valeur du Le champ error-index est l'index dudit composant de nom d'objet dans le message reçu.

2. Si la taille du GetResponse-PDU généré comme décrit ci-dessous devait dépasser une limitation locale, alors l'entité réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est tooBig, et la valeur du champ error-index est nulle.

3. Si, pour tout objet nommé dans le champ variable-bindings, la valeur du successeur lexicographique de l'objet nommé ne peut être récupérée pour des raisons non couvertes par aucune des règles précédentes, alors l'entité réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est genErr et la valeur du Le champ error-index est l'index dudit composant de nom d'objet dans le message reçu.

Si aucune des règles précédentes ne s'applique, alors l'entité de protocole réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de telle sorte que, pour chaque nom dans le champ variable-bindings du message reçu, le composant correspondant du GetResponse-PDU représente le nom et la valeur de cet objet dont le nom est, dans l'ordre lexicographique des noms de tous les objets disponibles pour les opérations d'obtention dans la vue MIB correspondante, avec la valeur du champ de nom du composant donné, le successeur immédiat de cette valeur. La valeur du champ error-status du GetResponse-PDU est noError et la valeur du champ errorindex est zéro. La valeur du champ request-id du GetResponse-PDU est celle du message reçu.

4.1.3.1. Exemple de parcours de table

Une utilisation importante du GetNextRequest-PDU est le parcours des tableaux conceptuels d'informations au sein du MIB. La sémantique de ce type de message SNMP, ainsi que les mécanismes spécifiques au protocole pour identifier les instances individuelles de types d'objets dans le MIB, permettent d'accéder aux objets associés dans le MIB comme s'ils bénéficiaient d'une organisation tabulaire.

Grâce à l'échange SNMP décrit ci-dessous, une entité d'application SNMP peut extraire l'adresse de destination et la passerelle du saut suivant pour chaque entrée dans la table de routage d'un élément de réseau particulier. Supposons que cette table de routage comporte trois entrées :

         Destination                     NextHop         Metric

         10.0.0.99                       89.1.1.42       5
         9.1.2.3                         99.0.0.3        3
         10.0.0.51                       89.1.1.42       5

La station de gestion envoie à l'agent SNMP un GetNextRequest-PDU contenant les valeurs OBJECT IDENTIFIER indiquées comme noms de variables demandés :

   GetNextRequest ( ipRouteDest, ipRouteNextHop, ipRouteMetric1 )

L'agent SNMP répond avec un GetResponse-PDU :

                 GetResponse (( ipRouteDest.9.1.2.3 =  "9.1.2.3" ),
                         ( ipRouteNextHop.9.1.2.3 = "99.0.0.3" ),
                         ( ipRouteMetric1.9.1.2.3 = 3 ))

La station de gestion continue avec :

                 GetNextRequest ( ipRouteDest.9.1.2.3,
                         ipRouteNextHop.9.1.2.3,
                         ipRouteMetric1.9.1.2.3 )

L'agent SNMP répond :

                 GetResponse (( ipRouteDest.10.0.0.51 = "10.0.0.51" ),
                         ( ipRouteNextHop.10.0.0.51 = "89.1.1.42" ),
                         ( ipRouteMetric1.10.0.0.51 = 5 ))

La station de gestion continue avec :

                 GetNextRequest ( ipRouteDest.10.0.0.51,
                         ipRouteNextHop.10.0.0.51,
                         ipRouteMetric1.10.0.0.51 )

L'agent SNMP répond :

                 GetResponse (( ipRouteDest.10.0.0.99 = "10.0.0.99" ),
                         ( ipRouteNextHop.10.0.0.99 = "89.1.1.42" ),
                         ( ipRouteMetric1.10.0.0.99 = 5 ))

La station de gestion continue avec :

                 GetNextRequest ( ipRouteDest.10.0.0.99,
                         ipRouteNextHop.10.0.0.99,
                         ipRouteMetric1.10.0.0.99 )

Comme il n'y a aucune autre entrée dans le tableau, l'agent SNMP renvoie les objets suivants dans l'ordre lexicographique des noms d'objets connus. Cette réponse signale la fin de la table de routage à la station de gestion.

4.1.4. GetResponse-PDU

La forme du GetResponse-PDU est identique à celle du GetRequest-PDU à l'exception de l'indication du type de PDU. Dans le langage ASN.1 :

                  GetResponse-PDU ::=
                      [2]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,
                              error-status
                                  ErrorStatus,

                              error-index
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

Le GetResponse-PDU est généré par une entité de protocole uniquement à la réception du GetRequest-PDU, du GetNextRequest-PDU ou du SetRequest-PDU, comme décrit ailleurs dans ce document.

À réception du GetResponse-PDU, l'entité protocolaire réceptrice présente son contenu à son entité applicative SNMP.

4.1.5. SetRequest-PDU

La forme du SetRequest-PDU est identique à celle du GetRequest-PDU à l'exception de l'indication du type de PDU. Dans le langage ASN.1 :

                  SetRequest-PDU ::=
                      [3]
                          IMPLICIT SEQUENCE {
                              request-id
                                  RequestID,

                              error-status        -- always 0
                                  ErrorStatus,

                              error-index         -- always 0
                                  ErrorIndex,

                              variable-bindings
                                  VarBindList
                          }

Le SetRequest-PDU est généré par une entité protocolaire uniquement à la demande de son entité applicative SNMP.

Dès réception du SetRequest-PDU, l'entité réceptrice répond conformément à toute règle applicable dans la liste ci-dessous :

1. Si, pour un objet nommé dans le champ variable-bindings, l'objet n'est pas disponible pour les opérations d'ensemble dans la vue MIB correspondante, alors l'entité réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est noSuchName, et la valeur du champ error-index est l'index dudit objet. composant de nom dans le message reçu.

2. Si, pour tout objet nommé dans le champ variable-bindings, le contenu du champ valeur ne manifeste pas, selon le langage ASN.1, un type, une longueur et une valeur cohérents avec ceux requis pour la variable, alors l'entité réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est badValue, et le la valeur du champ error-index est l'index dudit nom d'objet dans le message reçu.

3. Si la taille du message de type Get Response généré comme décrit ci-dessous devait dépasser une limitation locale, alors l'entité réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est tooBig, et la valeur du champ error-index est nulle.

4. Si, pour tout objet nommé dans le champ variable-bindings, la valeur de l'objet nommé ne peut être modifiée pour des raisons non couvertes par aucune des règles précédentes, alors l'entité réceptrice envoie à l'expéditeur du message reçu le GetResponse-PDU de forme identique, sauf que la valeur du champ error-status est genErr et la valeur du champ error-index est l'index dudit objet. composant de nom dans le message reçu.

Si aucune des règles précédentes ne s'applique, alors pour chaque objet nommé dans le champ variable-bindings du message reçu, la valeur correspondante est affectée à la variable. Chaque affectation de variable spécifiée par SetRequest-PDU doit être effectuée comme si elle était définie simultanément par rapport à toutes les autres affectations spécifiées dans le même message.

L'entité réceptrice envoie alors à l'expéditeur du message reçu le GetResponse-PDU de forme identique sauf que la valeur du champ error-status du message généré est noError et la valeur du champ error-index est nulle.

4.1.6. Trap-PDU

La forme du Trap-PDU est :

     Trap-PDU ::=
         [4]

              IMPLICIT SEQUENCE {
                 enterprise          -- type of object generating
                                     -- trap, see sysObjectID in [5]
                     OBJECT IDENTIFIER,

                 agent-addr          -- address of object generating
                     NetworkAddress, -- trap

                 generic-trap        -- generic trap type
                     INTEGER {
                         coldStart(0),
                         warmStart(1),
                         linkDown(2),
                         linkUp(3),
                         authenticationFailure(4),
                         egpNeighborLoss(5),
                         enterpriseSpecific(6)
                     },

                 specific-trap     -- specific code, present even
                     INTEGER,      -- if generic-trap is not
                                   -- enterpriseSpecific

                 time-stamp        -- time elapsed between the last
                   TimeTicks,      -- (re)initialization of the network
                                   -- entity and the generation of the
                                      trap

                 variable-bindings   -- "interesting" information
                      VarBindList
             }

Le Trap-PDU est généré par une entité protocolaire uniquement à la demande de l'entité applicative SNMP. La manière dont une entité d'application SNMP sélectionne les adresses de destination des entités d'application SNMP est spécifique à l'implémentation.

À réception du Trap-PDU, l'entité protocolaire réceptrice présente son contenu à son entité applicative SNMP. L'importance du composant variable-bindings du Trap-PDU est spécifique à l'implémentation.

Les interprétations de la valeur du champ generic-trap sont :

4.1.6.1. Trap coldStart

Une interruption coldStart(0) signifie que l'entité de protocole émettrice est en train de se réinitialiser de telle sorte que la configuration de l'agent ou l'implémentation de l'entité de protocole peut être modifiée.

4.1.6.2. Trap warmStart

Une interruption warmStart(1) signifie que l'entité de protocole émettrice se réinitialise de telle sorte que ni la configuration de l'agent ni l'implémentation de l'entité de protocole ne sont modifiées.

4.1.6.3. Trap linkDown

Une interruption linkDown(2) signifie que l'entité du protocole émetteur reconnaît une défaillance dans l'un des liens de communication représentés dans la configuration de l'agent.

Le Trap-PDU de type linkDown contient comme premier élément de son variable-bindings, le nom et la valeur de l'instance ifIndex pour l'interface concernée.

4.1.6.4. Trap linkUp

Une interruption linkUp(3) signifie que l'entité du protocole émetteur reconnaît que l'un des liens de communication représentés dans la configuration de l'agent est apparu.

Le Trap-PDU de type linkUp contient comme premier élément de son variable-bindings, le nom et la valeur de l'instance ifIndex pour l'interface concernée.

4.1.6.5. Trap authenticationFailure

Une interruption authenticationFailure(4) signifie que l'entité de protocole émettrice est le destinataire d'un message de protocole qui n'est pas correctement authentifié. Même si les implémentations du SNMP doivent être capables de générer cette interruption, elles doivent également être capables de supprimer l'émission de telles interruptions via un mécanisme spécifique à l'implémentation.

4.1.6.6. Trap egpNeighborLoss

Une interruption egpNeighborLoss(5) signifie qu'un voisin EGP pour lequel l'entité de protocole d'envoi était un homologue EGP a été marqué et que la relation d'homologue n'est plus établie.

Le Trap-PDU de type egpNeighborLoss contient comme premier élément de son variable-bindings, le nom et la valeur de l'instance egpNeighAddr pour le voisin concerné.

4.1.6.7. Trap enterpriseSpecific

Une interruption enterpriseSpecific(6) signifie que l'entité de protocole émettrice reconnaît qu'un événement spécifique à l'entreprise s'est produit. Le champ specific-trap identifie l'interruption particulière qui s'est produite.

5. Définitions

     RFC1157-SNMP DEFINITIONS ::= BEGIN

      IMPORTS
          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
              FROM RFC1155-SMI;

          -- top-level message

          Message ::=
                  SEQUENCE {
                      version          -- version-1 for this RFC
                          INTEGER {
                              version-1(0)
                          },

                      community        -- community name
                          OCTET STRING,

                      data             -- e.g., PDUs if trivial
                          ANY          -- authentication is being used
                  }

          -- protocol data units

          PDUs ::=
                  CHOICE {
                              get-request
                                  GetRequest-PDU,

                              get-next-request
                                  GetNextRequest-PDU,

                              get-response
                                  GetResponse-PDU,

                              set-request
                                  SetRequest-PDU,

                              trap
                                  Trap-PDU
                          }
          -- PDUs

          GetRequest-PDU ::=
              [0]
                  IMPLICIT PDU

          GetNextRequest-PDU ::=
              [1]
                  IMPLICIT PDU

          GetResponse-PDU ::=
              [2]
                  IMPLICIT PDU

          SetRequest-PDU ::=
              [3]
                  IMPLICIT PDU

          PDU ::=
                  SEQUENCE {
                     request-id
                          INTEGER,

                      error-status      -- sometimes ignored
                          INTEGER {
                              noError(0),
                              tooBig(1),
                              noSuchName(2),
                              badValue(3),
                              readOnly(4),
                              genErr(5)
                          },

                      error-index       -- sometimes ignored
                         INTEGER,

                      variable-bindings -- values are sometimes ignored
                          VarBindList
                  }

          Trap-PDU ::=
              [4]
                 IMPLICIT SEQUENCE {
                      enterprise        -- type of object generating
                                        -- trap, see sysObjectID in [5]

                          OBJECT IDENTIFIER,
                      agent-addr        -- address of object generating
                          NetworkAddress, -- trap

                      generic-trap      -- generic trap type
                          INTEGER {
                              coldStart(0),
                              warmStart(1),
                              linkDown(2),
                              linkUp(3),
                              authenticationFailure(4),
                              egpNeighborLoss(5),
                              enterpriseSpecific(6)
                          },

                      specific-trap  -- specific code, present even
                          INTEGER,   -- if generic-trap is not
                                     -- enterpriseSpecific

                      time-stamp     -- time elapsed between the last
                          TimeTicks, -- (re)initialization of the
                                        network
                                     -- entity and the generation of the
                                        trap

                       variable-bindings -- "interesting" information
                          VarBindList
                  }

          -- variable bindings

          VarBind ::=
                  SEQUENCE {
                      name
                          ObjectName,

                      value
                          ObjectSyntax
                  }

         VarBindList ::=
                  SEQUENCE OF
                     VarBind

         END

6. Remerciements

Ce mémo a été influencé par le groupe de travail IETF SNMP Extensions :

      Karl Auerbach, Epilogue Technology
      K. Ramesh Babu, Excelan
      Amatzia Ben-Artzi, 3Com/Bridge
      Lawrence Besaw, Hewlett-Packard
      Jeffrey D. Case, University of Tennessee at Knoxville
      Anthony Chung, Sytek
      James Davidson, The Wollongong Group
      James R. Davin, MIT Laboratory for Computer Science
      Mark S. Fedor, NYSERNet
      Phill Gross, The MITRE Corporation
      Satish Joshi, ACC
      Dan Lynch, Advanced Computing Environments
      Keith McCloghrie, The Wollongong Group
      Marshall T. Rose, The Wollongong Group (chair)
      Greg Satz, cisco
      Martin Lee Schoffstall, Rensselaer Polytechnic Institute
      Wengyik Yeong, NYSERNet

7. Références

[1] Cerf, V., "IAB Recommendations for the Development of Internet Network Management Standards", RFC 1052, IAB, April 1988.

[2] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based internets", RFC 1065, TWG, August 1988.

[3] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based internets", RFC 1066, TWG, August 1988.

[4] Cerf, V., "Report of the Second Ad Hoc Network Management Review Group", RFC 1109, IAB, August 1989.

[5] Rose, M., and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", RFC 1155, Performance Systems International and Hughes LAN Systems, May 1990.

[6] McCloghrie, K., and M. Rose, "Management Information Base for Network Management of TCP/IP-based Internets", RFC 1156, Hughes LAN Systems and Performance Systems International, May 1990.

[7] Case, J., M. Fedor, M. Schoffstall, and J. Davin, "A Simple Network Management Protocol", Internet Engineering Task Force working note, Network Information Center, SRI International, Menlo Park, California, March 1988.

[8] Davin, J., J. Case, M. Fedor, and M. Schoffstall, "A Simple Gateway Monitoring Protocol", RFC 1028, Proteon, University of Tennessee at Knoxville, Cornell University, and Rensselaer Polytechnic Institute, November 1987.

[9] Information processing systems - Open Systems Interconnection, "Specification of Abstract Syntax Notation One (ASN.1)", International Organization for Standardization, International Standard 8824, December 1987.

[10] Information processing systems - Open Systems Interconnection, "Specification of Basic Encoding Rules for Abstract Notation One (ASN.1)", International Organization for Standardization, International Standard 8825, December 1987.

[11] Postel, J., "User Datagram Protocol", RFC 768, USC/Information Sciences Institute, November 1980.

8. Considérations relatives à la sécurité

Les problèmes de sécurité ne sont pas abordés dans ce mémo.

9. Adresses des auteurs

Jeffrey D. Case SNMP Research P.O. Box 8593 Knoxville, TN 37996-4800

Téléphone: (615) 573-1434

Email: [email protected]

Mark Fedor Performance Systems International Rensselaer Technology Park 125 Jordan Road Troy, NY 12180

Téléphone: (518) 283-8860

Email: [email protected]

Martin Lee Schoffstall Performance Systems International Rensselaer Technology Park 165 Jordan Road Troy, NY 12180

Téléphone: (518) 283-8860

Email: [email protected] James R. Davin MIT Laboratory for Computer Science, NE43-507 545 Technology Square Cambridge, MA 02139

Téléphone: (617) 253-6020

Email: [email protected]