2. Vue d'ensemble

Les entités SNMP qui prennent en charge les applications de générateur de commandes ou de récepteur de notifications (traditionnellement appelées "gestionnaires") communiquent avec les entités SNMP qui prennent en charge les applications de répondeur de commandes ou d'initiateur de notifications (traditionnellement appelées "agents"). Le but de ce protocole est le transport des informations et des opérations de gestion.

2.1. Informations de gestion

Le terme "variable (variable)" fait référence à une instance d'un type d'objet non agrégé défini selon les conventions énoncées dans la SMI [RFC2578] ou les conventions textuelles basées sur la SMI [RFC2579]. Le terme "liaison de variable (variable binding)" fait normalement référence à l'appariement du nom d'une variable et de sa valeur associée. Cependant, si certains types de conditions exceptionnelles se produisent lors du traitement d'une demande de récupération, une liaison de variable associera un nom et une indication de cette exception.

Une liste de liaisons de variables (variable-binding list) est une simple liste de liaisons de variables.

Le nom d'une variable est un OBJECT IDENTIFIER qui est la concaténation de l'OBJECT IDENTIFIER du type d'objet correspondant avec un fragment OBJECT IDENTIFIER identifiant l'instance. L'OBJECT IDENTIFIER du type d'objet correspondant est appelé le préfixe OBJECT IDENTIFIER de la variable.

2.2. Retransmission des requêtes

Pour tous les types de requêtes dans ce protocole, le récepteur est tenu, dans des circonstances normales, de générer et de transmettre une réponse à l'initiateur de la requête. Qu'une requête doive ou non être retransmise si aucune réponse correspondante n'est reçue dans un intervalle de temps approprié, est à la discrétion de l'application qui initie la requête. Cela dépendra normalement de l'urgence de la requête. Cependant, une telle application doit agir de manière responsable en ce qui concerne la fréquence et la durée des retransmissions. Voir BCP 41 [RFC2914] pour une discussion des principes de contrôle de congestion pertinents.

2.3. Tailles des messages

La taille maximale d'un message SNMP est limitée au minimum de :

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

(2) la taille maximale de message que l'entité SNMP source peut générer.

La première peut être connue sur une base par destinataire ; et en l'absence d'une telle connaissance, 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 à l'implémentation.

Chaque mappage de transport pour SNMP indique la taille minimale de message qu'une implémentation SNMP doit être capable de produire ou de consommer. Bien que les implémentations soient encouragées à prendre en charge des valeurs plus grandes chaque fois que possible, une implémentation conforme ne doit jamais générer de messages plus grands que ceux autorisés par l'entité SNMP réceptrice.

L'un des objectifs du GetBulkRequest-PDU, spécifié dans ce document, est de minimiser le nombre d'échanges de protocole requis pour récupérer une grande quantité d'informations de gestion. En tant que tel, ce type de PDU permet à une entité SNMP prenant en charge les applications de générateur de commandes de demander que la réponse soit aussi grande que possible compte tenu des contraintes sur les tailles de messages.

Ces contraintes incluent les limites sur la taille des messages que l'entité SNMP prenant en charge l'application de générateur de commandes peut générer ou recevoir, et les limites sur la taille des messages que l'entité SNMP prenant en charge l'application de répondeur de commandes peut générer ou recevoir. La taille de toute réponse à une requête est limitée par le minimum de ces deux contraintes.

2.4. Mappages de transport

Il est un objectif de SNMP d'être aussi indépendant que possible de l'architecture et des mécanismes de services de transport particuliers. Les interfaces de service abstrait fournies par l'architecture SNMP [RFC3411] prennent en charge le mappage du protocole sur différents services de transport. Ces mappages sont décrits dans [RFC3417].

2.5. Mappages de types de données SMIv2

La syntaxe des divers PDU décrits dans ce document est spécifiée en utilisant les règles d'encodage de base ASN.1 (BER). Cependant, le protocole SNMP fait un usage extensif de la SMIv2 [RFC2578], qui elle-même est définie en utilisant ASN.1 [ASN1]. La SMIv2 définit un sous-ensemble de types ASN.1 à utiliser pour définir des modules d'information. Pour certains de ces types définis par SMIv2, les règles d'encodage ASN.1 standard ne fournissent pas une représentation non ambiguë. Dans de tels cas, la SMIv2 elle-même spécifie la représentation à utiliser. En particulier, cela s'applique aux types suivants :

• Counter32
• Counter64
• Gauge32
• TimeTicks
• Opaque
• IpAddress

Les détails sur la façon dont les types SMIv2 sont encodés peuvent être trouvés dans [RFC2578].