3Selon l'architecture de gestion de réseau NETCONF
3.1 Basé sur le terminal de gestion NETCONF
La partie gestion contient au total trois modules, comme le montre la figure 1, à savoir l'interface interactive, la couche de traitement des messages de gestion et la couche de communication de session. L'interface interactive est responsable de l'interaction des informations avec l'administrateur. La couche de traitement des messages est le module central de la partie gestion et est responsable de la gestion des messages de gestion. Le message est encapsulé dans un message de gestion basé sur NETCONF et transmis à la couche de communication de session. Elle est également chargée de vérifier le message reçu.
et analyse les résultats de l'opération. L'encapsulation de la couche contenu encapsule le message selon le modèle de données adopté. L'encapsulation de la couche d'opération et l'encapsulation RPC encapsulent le message dans le message RPC correspondant selon le type d'opération sélectionné par l'utilisateur. Communication de session La couche correspond à la couche de transport dans le modèle logique NETCONF, qui est responsable de la transmission des messages de gestion au convertisseur de messages, de l'attente de la réponse du convertisseur de messages et du renvoi des résultats de la réponse à la couche de traitement des messages.
3.2 Architecture du convertisseur de messages
Le convertisseur de messages présenté dans cet article communique sur la base d'un service web. Grâce à l'acceptation généralisée de XML, les services web sont devenus des applications qui utilisent des transmissions, des encodages et des protocoles standard pour échanger des informations. Le choix du service web pour la transmission des messages entre le terminal de gestion et le convertisseur de messages répond aux exigences caractéristiques de la transmission des messages de gestion de réseau dans le cadre de l'internet des objets et facilite la supervision multiplateforme, multiappareil et multiréseau de l'équipement de réseau.
Le convertisseur de messages convertit les messages de gestion envoyés afin que l'unité de gestion du réseau puisse communiquer avec différents types d'agents. Le convertisseur de messages est publié sous la forme d'un service web pour interagir avec l'unité de gestion et interagir directement avec l'environnement de l'internet des objets. Différents types d'agents interagissent entre eux.
L'architecture globale du convertisseur de messages est présentée à la figure 2 de la page suivante. Elle est principalement divisée en trois modules fonctionnels, à savoir le classificateur de messages SNMP, le module de conversion de messages et d'autres modules de conversion de messages d'agents.
3.2.1 Conversion des messages de gestion NETCONF-SNMP
Le convertisseur responsable de la conversion des messages de gestion NETCONF en messages de gestion SNMP est principalement composé de 6 modules, à savoir l'analyseur de requêtes, le traducteur MIB-XML, XML DOM, l'interrogateur XML, le module de traitement des pièges (composé du récepteur de pièges, qui comprend l'analyseur de pièges et le filtre de pièges) et le générateur de messages.
L'analyseur de demande combine XMLSchema pour déterminer la légalité du message de gestion et combine la table de correspondance des types d'opération pour extraire le type d'opération. Le traducteur MIB-XMIL est chargé de convertir la MIB SMI en XML. Le XML converti peut être utilisé pour trouver l'OID correspondant à l'objet d'opération. et le mappage des objets d'opération. XML DOM est le cœur du convertisseur. Il analyse le fichier XML et transmet l'adresse de l'appareil, le type d'opération, l'OID de l'objet d'opération, etc. obtenus au poller SNMP. Il est également responsable de la réception des traps et de l'implémentation des paramètres dans les traps. Après la mise en correspondance, il est transmis au générateur de messages XML. Le poller SNMP emballe les paramètres obtenus dans un PDU SNMP et le transmet à l'agent SNMP, puis accepte la réponse de l'agent SNMP. Afin de réduire le trafic de communication entre la partie gestion et le convertisseur, le traitement des trappes SNMP utilise un mécanisme de filtrage. Le processeur de trappes se compose de trois modules. Il classe les trappes reçues et établit un système de classification pour déterminer le degré d'urgence. Enfin, il filtre certains messages en double ou non valides et les transmet à XML. Le générateur de messages DOM génère le message de réponse ou le message de notification correspondant et l'envoie au terminal de gestion NETCONF et à l'ordinateur de gestion. Passerelle IoT.
Le convertisseur NETCONF-SNMP peut également assurer la compatibilité avec les agents ANMP. En effet, ANMP utilise le même format PDU que SNMP et utilise également UDP comme protocole de transport pour envoyer les messages ANMP. En termes de collecte et de contrôle des données, ANMP étend la MIB SNMP afin d'enregistrer les informations uniques du réseau ad hoc. Pour gérer l'agent ANMP, la partie gestion charge d'abord le fichier MIB correspondant, et le classificateur de messages détermine l'adresse du message de gestion.
Si l'agent ANMP correspondant est un agent ANMP, la transmission du message de gestion au convertisseur permet de gérer efficacement le dispositif correspondant à l'agent ANMP.
3.2.2 Prise en charge d'autres protocoles de gestion de réseau
Étant donné qu'il existe un petit nombre d'autres protocoles de gestion de réseau dans l'environnement de l'internet des objets, cet article ajoute une architecture théorique qui prend en charge d'autres protocoles de gestion de réseau. Cette architecture est expliquée ci-dessous.
Comme le montre la figure 2, l'architecture se compose principalement de quatre parties, à savoir les tables de données, les adaptateurs, les générateurs de messages et les récepteurs de pièges. Trois tables de données et trois adaptateurs sont la clé de l'architecture. La table d'informations sur les appareils enregistre les informations pertinentes sur l'agent. La table de données privées permet de distinguer l'agent avec lequel l'unité de gestion communique ; la table de données privées fait correspondre les propriétés de NETCONF aux propriétés privées de l'agent ; la table d'opérations fait correspondre le type d'opération de NETCONF au type d'opération privé de l'agent. L'adaptateur de message met en œuvre la correspondance des formats de message ; l'adaptateur de transport est responsable de la communication du convertisseur avec les différents agents ; l'adaptateur de piège est responsable de la manière dont l'agent communique activement avec le processus de gestion et notifie au processus de gestion que quelque chose s'est produit. Passerelle pour l'internet des objets
Lorsque l'unité de gestion communique avec l'agent, le convertisseur charge d'abord le fichier de configuration XML de l'agent et génère trois tables de données, à savoir la table d'informations sur le dispositif, la table de type d'opération et la table de données privées. Les détails spécifiques des trois adaptateurs susmentionnés sont générés par les tables de données. Lors de la mise en œuvre, le gestionnaire d'adaptation est chargé d'initialiser l'adaptateur et de l'appeler au moment opportun. Sous la coordination du gestionnaire d'adaptation, le générateur de messages peut convertir le message de configuration NETCONF transmis par l'extrémité de gestion via l'adaptateur en un PDU qui peut être reconnu par l'agent. Le PDU renvoyé peut également être converti en un message de réponse basé sur NETCONF par l'intermédiaire du générateur de messages de gestion.
3.3 Conception de l'architecture côté agent
Actuellement, les fabricants d'équipements de réseau tels que Cisco et Juniper ont mis en œuvre des agents basés sur la norme RFC4741 et les ont intégrés dans leurs derniers routeurs.
NETCONF utilise XML pour la transmission des données et l'expression des modules, et présente une forte évolutivité. Les fournisseurs d'équipements de réseau peuvent utiliser ce protocole pour obtenir et définir toutes les données de configuration, ce qui convient à l'ajout rapide et à la gestion efficace de différents types d'équipements dans le cadre de l'internet des objets. Ces fonctions dépendent en grande partie de la mise en œuvre de l'agent. Comment appliquer efficacement l'agent basé sur NETCONF à différents types de dispositifs de réseau et effectuer la gestion du réseau sur eux est un problème urgent qui doit être résolu. Ce problème est lié à la vitalité de NETCONF dans la gestion du réseau de l'internet des objets. Cet article divise les agents en trois catégories
Il en existe trois types, à savoir l'agent SNMP, l'agent NETCONF et les autres agents.
Cette section analyse la conception de l'architecture de l'agent NETCONF en fonction des caractéristiques de l'internet des objets. Selon les dispositions de la RFC4741, un agent NETCONF de base est conçu dans une structure à quatre couches. En outre, l'agent doit prendre en charge les caractéristiques de capacité, trois états de base de données et les notifications d'événements. L'architecture proxy de NETCONF est présentée à la figure 3.
The session communication layer is responsible for interacting with the management terminal. After the agent is started, it will monitor the management messages from the management terminal. After the message processor receives the management messages from the session communication layer, it can parse out the operation type and operation object and pass them to the operation processor. The result of the operation processor operation can be encapsulated into a response message based on NETCONF. The operation processor performs the specific operations parsed by the message processor. The configuration information status in the management object information base is divided into 3 stages, corresponding to 3 database statuses : Running state (running), start up state (start up) and candidate state (candidate). Capabilities (capabilities) are a new feature of NETCONF. This feature allows the client to discover the set of protocol extensions supported by the server. The introduction of “capabilities” The basic operation set is enriched and new operations are added to improve the scalability of the agent. The managed device passes the capability set to the management database for storage. After the management end sends a “HELLO” message, it is passed to the management end to inform the management end that it is being used. The set of protocol extensions supported by the managed device. The notification module is responsible for delivering messages actively sent by the managed device to the message processor, which is then encapsulated by the message processor and delivered to the management end through the session communication layer.
This article does not focus on discussing the two characteristics of “capability” and “notification”, but these two characteristics are crucial for applying NETCONF to the Internet of Things environment, because the Internet of Things environment requires “capability” to support Scalability, “notification” to support real-time monitoring of managed devices, is also the focus of our future work discussion.
Mots-clés : Passerelle Internet des objets