3. Éléments de Procédure

Les sections suivantes décrivent les procédures suivies par chacun des cinq types d'applications SNMP lors de la génération et du traitement des messages SNMP.

3.1. Applications Générateur de Commandes

Une application générateur de commandes utilise le sous-système de traitement des messages SNMP pour transmettre des messages SNMP à une application SNMP distante.

Le générateur de commandes doit être capable de déterminer le domaine de transport et l'adresse de transport de l'application distante. La méthode par laquelle cela est accompli dépend de l'implémentation et ne relève pas du domaine de ce document.

Le générateur de commandes doit être capable de déterminer les paramètres de message SNMP appropriés (modèle de traitement de message, modèle de sécurité, niveau de sécurité et nom de sécurité) à utiliser lors de la communication avec l'application distante. La méthode par laquelle cela est accompli dépend de l'implémentation et ne relève pas du domaine de ce document.

3.1.1. Génération d'une demande de commande

Pour envoyer une demande de commande SNMP, l'application générateur de commandes :

1. Utilise ses informations de configuration locale pour déterminer :

   • Domaine de transport et adresse de transport
   • Modèle de traitement de message
   • Modèle de sécurité
   • Nom de sécurité
   • Niveau de sécurité
   • ID de moteur de contexte (contextEngineID)
   • Nom de contexte (contextName)
   • Le PDU approprié (GetRequest, GetNextRequest, GetBulkRequest, ou SetRequest)

2. Invoque la primitive d'envoi de PDU du sous-système de traitement des messages, en passant :

   • Domaine de transport et adresse de transport
   • Modèle de traitement de message
   • Modèle de sécurité
   • Nom de sécurité
   • Niveau de sécurité
   • contextEngineID
   • contextName
   • PDU

3. Le sous-système de traitement des messages renvoie une indication d'état. Si une erreur est renvoyée, le générateur de commandes doit gérer l'erreur de manière appropriée.

3.1.2. Traitement d'une réponse

Lorsqu'un générateur de commandes reçoit une réponse :

1. Le sous-système de traitement des messages invoque la primitive de réception de PDU du générateur de commandes, en passant :

   • Modèle de traitement de message
   • Modèle de sécurité
   • Nom de sécurité
   • Niveau de sécurité
   • contextEngineID
   • contextName
   • PDU
   • Taille maximale (maxSizeResponseScopedPDU)
   • Informations d'état

2. Le générateur de commandes vérifie que la réponse correspond à une demande en attente (via request-id).

3. Le générateur de commandes vérifie le statut d'erreur (error-status) dans la réponse. Si le champ error-status est non nul, une erreur s'est produite.

4. Le générateur de commandes traite la liste des liaisons de variables dans la réponse.

3.1.3. Délais d'attente et tentatives

Si aucune réponse n'est reçue dans un délai raisonnable, le générateur de commandes peut retransmettre la demande. Le nombre de tentatives et les valeurs de délai d'attente sont déterminés par la configuration locale ou la politique.

Pour les protocoles de transport fiables (tels que TCP), la couche transport elle-même peut fournir une retransmission. Dans de tels cas, les tentatives au niveau de l'application peuvent être inutiles ou inappropriées.

3.2. Applications Répondeur de Commandes

Une application répondeur de commandes reçoit des demandes de commande SNMP et génère des réponses appropriées.

3.2.1. Traitement d'une demande

Lorsqu'un répondeur de commandes reçoit une demande :

1. Le sous-système de traitement des messages invoque la primitive de réception de PDU du répondeur de commandes, en passant :

   • Modèle de traitement de message
   • Modèle de sécurité
   • Nom de sécurité
   • Niveau de sécurité
   • contextEngineID
   • contextName
   • PDU
   • Taille maximale (maxSizeResponseScopedPDU)
   • Informations d'état

2. Le répondeur de commandes vérifie que le contextEngineID identifie le moteur SNMP local. Sinon, la demande est rejetée.

3. Le répondeur de commandes utilise le sous-système de contrôle d'accès (tel que VACM défini dans le RFC 3415) pour déterminer si le nom de sécurité est autorisé à effectuer l'opération demandée.

4. Le répondeur de commandes traite le PDU :

   • GetRequest : Récupère les valeurs des objets MIB demandés
   • GetNextRequest : Récupère l'objet MIB suivant lexicographiquement après le nom d'objet demandé
   • GetBulkRequest : Effectue une récupération multi-variables optimisée
   • SetRequest : Modifie les valeurs des objets MIB spécifiés

5. Le répondeur de commandes construit un PDU de réponse contenant :

   • Le même request-id que la demande
   • Error-status (noError ou un code d'erreur approprié)
   • Error-index (si une erreur s'est produite, indique quelle liaison de variable a causé l'erreur)
   • Liste des liaisons de variables (pour les opérations Get, contient les valeurs récupérées ; pour les opérations Set, contient les variables définies)

3.2.2. Génération d'une réponse

Le répondeur de commandes génère une réponse en :

1. Construisant un Response-PDU avec le statut d'erreur, l'index d'erreur et la liste de liaisons de variables appropriés.

2. Invoquant la primitive de retour de PDU de réponse du sous-système de traitement des messages, en passant :

   • Modèle de traitement de message (identique à la demande)
   • Modèle de sécurité (identique à la demande)
   • Nom de sécurité (identique à la demande)
   • Niveau de sécurité (identique à la demande)
   • contextEngineID (identique à la demande)
   • contextName (identique à la demande)
   • PDU (le PDU de réponse)
   • Taille maximale (le maxSizeResponseScopedPDU de la demande)
   • Référence d'état (obtenue lors du traitement de la demande)

3. Le sous-système de traitement des messages gère le formatage et la transmission du message de réponse.

3.2.3. Gestion des erreurs

Si une erreur se produit lors du traitement de la demande, le répondeur de commandes doit définir un statut d'erreur approprié dans le PDU de réponse :

• tooBig : Le message de réponse est trop grand pour être transmis dans les limites de taille maximale de message
• noSuchName : L'objet demandé n'existe pas (SNMPv1 uniquement)
• badValue : La valeur fournie est inappropriée pour l'opération demandée (SNMPv1 uniquement)
• readOnly : Tentative de modification d'un objet en lecture seule
• genErr : Une erreur générale s'est produite
• noAccess : Accès refusé (SNMPv2 et versions ultérieures)
• wrongType : La variable a le mauvais type (SNMPv2 et versions ultérieures)
• wrongLength : La valeur a la mauvaise longueur (SNMPv2 et versions ultérieures)
• wrongEncoding : La valeur a le mauvais codage (SNMPv2 et versions ultérieures)
• wrongValue : La valeur est incorrecte (SNMPv2 et versions ultérieures)
• noCreation : La création n'est pas autorisée (SNMPv2 et versions ultérieures)
• inconsistentValue : La valeur est incohérente (SNMPv2 et versions ultérieures)
• resourceUnavailable : Les ressources sont indisponibles (SNMPv2 et versions ultérieures)
• commitFailed : Échec de la validation (SNMPv2 et versions ultérieures)
• undoFailed : Échec de l'annulation (SNMPv2 et versions ultérieures)
• authorizationError : Erreur d'autorisation (SNMPv2 et versions ultérieures)
• notWritable : L'objet n'est pas inscriptible (SNMPv2 et versions ultérieures)
• inconsistentName : Le nom est incohérent (SNMPv2 et versions ultérieures)

3.3. Applications Émetteur de Notifications

Une application émetteur de notifications génère des messages de notification SNMP (traps ou requêtes inform).

3.3.1. Génération d'une notification

Pour envoyer une notification SNMP, l'émetteur de notifications :

1. Détermine l'ensemble des cibles de gestion qui doivent recevoir cette notification. Cela se fait généralement en consultant le SNMP-TARGET-MIB et le SNMP-NOTIFICATION-MIB.

2. Pour chaque cible de gestion sélectionnée :

   a. Détermine le domaine de transport et l'adresse de transport

   b. Détermine les paramètres de message SNMP :

   • Modèle de traitement de message
   • Modèle de sécurité
   • Nom de sécurité
   • Niveau de sécurité

   c. Détermine le type de notification (trap ou inform)

   d. Construit le PDU approprié :

   • SNMPv2-Trap-PDU : Pour les notifications non confirmées
   • InformRequest-PDU : Pour les notifications confirmées

   e. Le PDU doit contenir :

   • Variable sysUpTime.0 (temps écoulé depuis le démarrage du moteur)
   • Variable snmpTrapOID.0 (identifiant d'objet de la notification)
   • Liaisons de variables supplémentaires pour la notification

   f. Invoque la primitive d'envoi de PDU du sous-système de traitement des messages

3.3.2. Traitement d'une réponse à une requête Inform

Si le type de notification est inform (InformRequest-PDU), l'émetteur de notifications doit attendre une réponse :

1. Si une réponse est reçue dans le délai d'attente :

   • Vérifier que la réponse correspond à la requête inform en attente (via request-id)
   • Vérifier le statut d'erreur
   • Confirmer que la notification a été livrée avec succès

2. Si aucune réponse n'est reçue dans le délai d'attente :

   • Selon la politique de tentatives configurée, peut retransmettre la requête inform
   • Ou, enregistrer l'échec localement et abandonner cette tentative de livraison

3. Pour les traps (SNMPv2-Trap-PDU), aucune réponse n'est attendue, donc l'émetteur de notifications termine immédiatement après l'envoi.

3.4. Applications Récepteur de Notifications

Une application récepteur de notifications reçoit des messages de notification SNMP.

3.4.1. Traitement d'une notification reçue

Lorsqu'un récepteur de notifications reçoit une notification :

1. Le sous-système de traitement des messages invoque la primitive de réception de PDU du récepteur de notifications, en passant :

   • Modèle de traitement de message
   • Modèle de sécurité
   • Nom de sécurité
   • Niveau de sécurité
   • contextEngineID
   • contextName
   • PDU
   • Taille maximale
   • Informations d'état

2. Le récepteur de notifications extrait les informations de notification :

   • sysUpTime.0 (horodatage)
   • snmpTrapOID.0 (type de notification)
   • Liaisons de variables supplémentaires (données de notification)

3. Le récepteur de notifications traite la notification selon la politique locale :

   • Enregistrer dans un fichier journal
   • Afficher une alerte
   • Déclencher une action de réponse automatisée
   • Transmettre à d'autres systèmes de gestion

3.4.2. Réponse à une requête Inform

Si un InformRequest-PDU est reçu, le récepteur de notifications doit générer une réponse :

1. Construire un Response-PDU contenant :

   • Le même request-id que la demande
   • Error-status (généralement noError)
   • Error-index (généralement 0)
   • Liste des liaisons de variables (généralement la même que dans la demande)

2. Invoquer la primitive de retour de PDU de réponse du sous-système de traitement des messages pour envoyer la réponse.

Pour SNMPv2-Trap-PDU, aucune réponse n'est générée.

3.5. Applications Transmetteur de Proxy

Une application transmetteur de proxy transmet des messages SNMP entre des entités SNMP. Les transmetteurs de proxy peuvent effectuer une traduction de protocole, une traduction de sécurité ou une traduction de vue d'informations de gestion.

Une application transmetteur de proxy effectue deux types de transmission :

1. Transmission de demande : Transmission des demandes de commande et de leurs réponses
2. Transmission de notification : Transmission des messages de notification

3.5.1. Transmission de demande

Lorsqu'un transmetteur de proxy reçoit une demande de commande :

1. Le sous-système de traitement des messages invoque la primitive de réception de PDU du transmetteur de proxy, en passant les paramètres de la demande.

2. Le transmetteur de proxy utilise le SNMP-PROXY-MIB pour déterminer comment transmettre la demande :

   a. Consulte la table snmpProxyTable, en utilisant les paramètres reçus comme clé :

   • contextEngineID
   • contextName
   • Domaine de transport et adresse de transport
   • Type de PDU

   b. Si une entrée correspondante est trouvée, extrait les paramètres de transmission :

   • Domaine de transport et adresse de transport cibles
   • Modèle de traitement de message cible
   • Modèle de sécurité cible
   • Nom de sécurité cible
   • Niveau de sécurité cible
   • contextEngineID cible
   • contextName cible

3. Le transmetteur de proxy peut avoir besoin de modifier le PDU pour s'adapter à la version SNMP cible. Par exemple :

   • SNMPv2 vers SNMPv1 : Convertir les codes de statut d'erreur
   • SNMPv1 vers SNMPv2 : Convertir le format de PDU de trap

4. Le transmetteur de proxy invoque la primitive d'envoi de PDU du sous-système de traitement des messages pour transmettre la demande modifiée à la cible.

5. Lorsqu'une réponse est reçue de la cible :

   a. Peut avoir besoin de modifier à nouveau le PDU de réponse pour s'adapter à la version SNMP du demandeur d'origine

   b. Invoque la primitive de retour de PDU de réponse du sous-système de traitement des messages pour transmettre la réponse au demandeur d'origine

3.5.2. Transmission de notification

Lorsqu'un transmetteur de proxy reçoit une notification :

1. Le sous-système de traitement des messages invoque la primitive de réception de PDU du transmetteur de proxy, en passant les paramètres de notification.

2. Le transmetteur de proxy utilise le SNMP-PROXY-MIB pour déterminer comment transmettre la notification :

   a. Consulte la table snmpProxyTable, en utilisant les paramètres reçus comme clé

   b. Si une entrée correspondante est trouvée, extrait les paramètres de transmission

3. Le transmetteur de proxy peut avoir besoin de modifier le PDU de notification :

   • Trap SNMPv1 vers trap SNMPv2 : Convertir le format de PDU et les liaisons de variables
   • Trap SNMPv2 vers trap SNMPv1 : Convertir le format de PDU

4. Le transmetteur de proxy invoque la primitive d'envoi de PDU du sous-système de traitement des messages pour transmettre la notification à la cible.

5. Si la notification d'origine était un InformRequest-PDU et que la notification transmise est également un InformRequest-PDU :

   a. Attendre une réponse de la cible

   b. Lorsque la réponse est reçue, transmettre la réponse à l'émetteur de notifications d'origine

3.5.3. Considérations spéciales pour les transmetteurs de proxy

Les transmetteurs de proxy doivent gérer plusieurs cas particuliers :

1. Ajustement de la taille du PDU : Si la cible prend en charge une taille de message maximale inférieure à celle de la demande d'origine, le transmetteur de proxy peut avoir besoin de renvoyer une erreur tooBig ou de diviser la demande.

2. Traduction de contexte : Le transmetteur de proxy peut avoir besoin de mapper entre différents contextEngineID et contextName.

3. Contrôle d'accès : Le transmetteur de proxy applique ses propres politiques de contrôle d'accès en plus de tout contrôle d'accès au niveau du répondeur de commandes cible.

4. Mappage d'erreurs : Lors de la traduction entre les versions SNMP, les codes d'erreur peuvent devoir être mappés. Par exemple, une erreur noAccess SNMPv2 peut devoir être mappée à genErr dans SNMPv1.

5. Délais d'attente et tentatives : Le transmetteur de proxy peut avoir besoin d'implémenter son propre mécanisme de délai d'attente et de tentative pour les demandes transmises, indépendamment du délai d'attente du demandeur d'origine.

6. Filtrage des notifications : Pour la transmission de notifications, le transmetteur de proxy peut appliquer des règles de filtrage pour transmettre sélectivement des types spécifiques de notifications.