Brevet FR2853109A1 — publié le 20041001

DISPOSITIF DE GESTION LOCALE D'ASSURANCE POUR UN ÉQUIPEMENT DE RÉSEAU DE COMMUNICATIONS L'invention concerne les réseaux de communications, et plus particulièrement ceux offrant une assurance de continuité de service(s). De nombreux réseaux de communications mettent en oeuvre des procédés d'assurance qui contrôlent l'exécution d'activités de maintenance préventives et réactives destinées à assurer à leurs clients la continuité de la 10 disponibilité de services, définis en termes de qualité de service (QoS). A cet effet, les réseaux disposent d'un système de gestion de réseau (ou NMS pour " Network Management System ") qui analyse continuellement l'état des ressources et les performances de manière à anticiper ou détecter des problèmes ou pannes et à déterminer les actions à entreprendre de sorte que 1 5 les clients ne soient pas pénalisés. Une telle analyse centralisée repose sur la collection d'un très grand nombre de données d'information et d'alarmes auprès des nombreux équipements de réseau, chargés d'effectuer des mesures de valeurs de paramètre(s) du réseau, et plus précisément auprès de leurs bases 20 d'informations de gestion (ou MIB pour " Management Information Base ") chargées de stocker les données de gestion représentatives des valeurs mesurées. Une fois collectées, par exemple via un collecteur SNMP, les données sont stockées dans une base de données d'archivage, par exemple de type Oracle, et alimentent des modules de calcul qui mettent en oeuvre des 25 formules ou équations prédéfinies. Un tel procédé d'assurance centralisé requiert l'emploi de bases de données de très grandes capacités, nécessite des temps de calcul importants et consomme de la bande passante (lors de la collecte), ce qui nuit aux performances du réseau. L'invention a donc pour but d'améliorer la situation. Elle propose à cet effet un dispositif de gestion locale d'assurance 2 2853109 pour un équipement de réseau de communications présentant une configuration choisie et comportant des moyens de mesure de valeurs de paramètre(s) du réseau et une base d'informations de gestion (MIB) stockant des données de gestion représentatives des valeurs mesurées. Ce dispositif se caractérise par le fait qu'il comporte des moyens de gestion chargés d'adapter la configuration de l'équipement dans lequel il est implanté (ou embarqué) en fonction, notamment, des données de gestion stockées dans sa base d'informations de gestion et de règles, dites d'assurance, choisies, définissant une politique locale d'assurance. En d'autres termes, l'invention consiste à intégrer dans des équipements (ou noeuds) du réseau un dispositif d'assurance embarqué de sorte qu'ils puissent assurer localement au moins une partie du procédé d'assurance géré par le NMS. Le dispositif d'assurance embarqué, selon l'invention, pourra 15 comporter des caractéristiques complémentaires qui pourront être prises séparément et/ou en combinaison, et en particulier: - des moyens de gestion capables d'adapter la configuration de leur équipement en fonction de données d'informations provenant d'au moins un autre équipement de réseau, - une adaptation consistant en une modification de la politique de mesure de paramètre(s) et/ou une modification de la politique d'envoi de rapport (ou " reporting ") au NMS, - une adaptation consistant en une modification du mode de fonctionnement de l'équipement, - des moyens de gestion comprenant des moyens d'analyse de paramètres du réseau capables de délivrer des données d'information représentatives de l'évolution temporelle, sur un intervalle choisi, de certaines valeurs de paramètre(s) du réseau (comme par exemple le trafic ou l'état d'un routeur) qui sont stockées dans la MIB. Dans ce cas, les moyens d'analyse peuvent 30 être agencés de manière à délivrer des données d'information représentatives d'une analyse de tendance et/ou d'une analyse de profils ou 3 2853109 de signatures (ou " baselines ") et/ou d'une analyse de discontinuité et/ou d'une agrégation de valeurs de paramètres du réseau. Par ailleurs, ces moyens d'analyse peuvent être configurables, notamment dans le but de mettre en oeuvre de nouveaux calculs, relatifs aux paramètres du réseau, transmis par le NMS, - des moyens de gestion comprenant des moyens d'alarme chargés de déclencher l'envoi d'une alarme et/ou de données d'information au NMS et/ou à au moins un autre équipement de réseau, en fonction de règles d'assurance choisies. De telles données d'information et alarmes sont par 10 exemple représentatives de résultat(s) d'analyse(s) ou d'agrégation(s) de données effectuée(s) par les moyens d'analyse et/ou de valeur(s) de paramètre(s) du réseau stockées dans la MIB. Par ailleurs, les moyens d'alarme peuvent être configurables, - des moyens de gestion comprenant des moyens d'observation du réseau 15 définissant un agent de mesure de flux de type " bout-en-bout " (ou " endto-end "), et délivrant des données d'informations. Dans ce cas, les moyens d'observation du réseau peuvent être configurables, - des moyens de gestion comprenant des moyens de gestion d'accords de niveau de service (ou SLA pour " Service Level Agreement ") délivrant des 20 données d'informations. Dans ce cas, les moyens de gestion d'accords de niveau de service peuvent être configurables, -des moyens de gestion capables d'effectuer des tests, par exemple de mesure(s) active(s) ou d'aide au diagnostic. Ces tests peuvent notamment permettre de faire remonter une information agrégée ou le résultat du test 25 (par exemple le temps pris pour une opération de type TCP) au niveau de la couche NMS, -des moyens de gestion capables d'assurer leur gestion en fonction d'un calendrier, de sorte que certaines (ou toutes les) fonctions d'assurance ou tests ne soient effectuées que certains jours de la semaine ou du mois ou à 3 0 certaines heures, par exemple, - des moyens de gestion comprenant des moyens de contrôle chargés de gérer le fonctionnement (et notamment la configuration) des moyens d'analyse, des moyens d'alarme, des moyens d'observation du réseau et des moyens de gestion d'accords de niveau de service, en fonction des règles d'assurance choisies et des données d'informations qu'ils délivrent. 5 De tels moyens de contrôle peuvent se présenter sous la forme d'un moteur de règles (ou " rule engine ") dans lequel sont stockées les règles d'assurance choisies. Par ailleurs, ces moyens de contrôle peuvent être configurables, - des moyens de gestion configurables, - des moyens de gestion et/ou des moyens d'analyse et/ou des moyens et/ou des moyens de contrôle et/ou des moyens d'observation du réseau et/ou des moyens de gestion d'accords de niveau de service agencés de manière à pouvoir être configurés par le NMS via une interface de langage de programmation (ou API pour " Application Programming Interface ") et 15 éventuellement via la MIB. Dans ce cas, la MIB peut être configurée ou programmée par le NMS via l'API, -des moyens de gestion et/ou des moyens d'analyse et/ou des moyens d'alarme et/ou des moyens d'observation du réseau et/ou des moyens de gestion d'accords de niveau de service et/ou des moyens de contrôle 2 0 agencés de manière à pouvoir être configurés par le NMS via des commandes dédiées, telles que des " Command Line Interface " (ou CLI). L'invention concerne également un équipement de réseau muni d'un dispositif du type de celui présenté ci-avant. L'invention convient plus particulièrement, bien que de façon non restrictive, aux équipements de 25 réseau tels que les routeurs, les commutateurs (ou " switchs ") et les parefeux (ou " firewalls "). L'invention propose également un réseau de communications équipé d'un système de gestion de réseau (NMS) et d'une multiplicité d'équipements de réseau du type de celui présenté ci-avant. Dans un mode de réalisation de 30 type distribué, chaque équipement de réseau peut être agencé de manière à délivrer au système de gestion de réseau des alarmes et/ou des données d'information de types différents. L'invention peut notamment être mise en oeuvre dans toutes les technologies réseaux qui doivent être gérées, et notamment dans les réseaux de transmission (par exemple de type WDM, SONET, SDH), de données (par exemple de type Internet-IP ou ATM) ou de voix (par exemple de type classique, mobile ou NGN). D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels: - la figure 1 illustre de façon schématique un réseau de communications 1i comprenant un système de gestion de réseau (NMS) et des équipements de réseau selon l'invention, et - la figure 2 illustre de façon schématique un exemple de réalisation d'un équipement de réseau selon l'invention. Les dessins annexés pourront non seulement servir à compléter 15 l'invention, mais aussi contribuer à sa définition, le cas échéant. L'invention a pour objet de permettre la gestion locale, par des équipements de réseau, d'une partie du procédé d'assurance géré par le système de gestion de réseau (ou NMS pour " Network Management System ") d'un réseau de communications. Comme cela est illustré sur la figure 1, un réseau de communications N comporte schématiquement une multiplicité d'équipements de réseau NEi (ici i = 1, 2, mais il peut prendre n'importe quelle valeur), comme par exemple des serveurs équipés d'un pare-feu ou (" firewall "), des commutateurs (ou " switchs "), des routeurs périphériques (ou " edge routers ") ou des routeurs 25 de coeur (ou " core routers "), pouvant échanger des données, selon un protocole de gestion de réseau, avec un système de gestion de réseau, et notamment avec son serveur de gestion NMS. Chaque équipement NEi comporte classiquement une base d'informations de gestion MIB (" Management Information Base "), 30 également appelée base d'instances d'objets. Chaque MIB stocke des données de gestion représentatives de valeurs de champs d'information qui caractérisent l'équipement NEi associé. Certains de ces champs d'information désignent des paramètres du réseau dont les valeurs instantanées sont mesurées par des sondes MM implantées dans, ou gérées par, l'équipement NEi. Par ailleurs, chaque MIB est associée à une définition de base 5 d'informations de gestion (non représentée), également appelée définition de MIB, stockée dans le système de gestion de réseau et accessible au serveur de gestion NMS. Dans ce qui suit, on considère à titre d'exemple non limitatif que le réseau de communications N est de type Internet (IP) et que le protocole de 10 gestion du réseau est le protocole SNMP (pour " Simple Network Management Protocol " RFC 2571-2580). Bien entendu, l'invention s'applique à d'autres types de réseau, comme par exemple aux réseaux de transmission de type WDM, SONET ou SDH, de données de type ATM, ou de voix de type classique, mobile ou NGN, et à d'autres protocoles de gestion de réseau, 15 comme par exemple TL1, CORBA ou CMISE/CMIP. Par ailleurs, on considère dans ce qui suit que les équipements de réseau NEi sont des routeurs périphériques (ou de bordure) agissant en tant qu'agents d'observation de flux de type " bout-en-bout " (ou " end-to-end "). Ces routeurs sont généralement placés aux frontières du réseau et 20 permettent l'établissement de liens avec d'autres réseaux. Ces agents sont généralement destinés à effectuer des mesures de bout en bout pour des problèmes d'échelle (ou " scalability "). Mais, bien entendu, l'invention n'est pas limitée à ce seul type d'équipement de réseau. Elle concerne tous les équipements de réseau capables d'échanger des données de gestion avec le 25 NMS, et notamment les routeurs périphériques qui n'agissent pas en tant qu'observateurs, les routeurs de coeur, les commutateurs et les pare-feux. Chaque équipement de réseau NEi est généralement configuré spécifiquement de manière à transmettre au NMS (ou couche NMS) des données d'information représentatives de mesures qu'il a effectuées avec sa:30 ou ses sondes MM et qu'il a stockées dans sa MIB, ainsi que des alarmes signalant des problèmes ou des pannes. La configuration est généralement définie par une ou plusieurs politiques. Par exemple, une première politique est relative aux conditions d'envoi (ou " reporting ") de valeurs mesurées par l'équipement NEi à l'aide de ses sondes MM. Une deuxième politique peut concerner la ou les mesures de paramètre(s) que l'équipement NEi doit effectuer avec sa ou ses sondes MM. Une troisième politique peut concerner 5 le mode de fonctionnement de l'équipement NEi. Ces politiques sont habituellement définies pour chaque équipement NEi par un module de configuration MC du NMS. Elles sont transmises aux équipements NEi, via le réseau N, à l'aide du protocole de gestion (ici SNMP). Mais, le NMS, et notamment son module de collection MCC (ou 10 " collector "), peut également, lorsqu'il l'estime nécessaire, adresser à un équipement de réseau NEi des requêtes pour qu'il lui transmette les valeurs de certains des champs d'information qui sont stockés dans sa MIB. C'est ce que l'homme de l'art appelle, en anglais, le " polling ". Comme cela est mieux illustré sur la figure 2, l'invention propose un 15 dispositif de gestion locale d'assurance D destiné à être soit implanté (ou embarqué) dans un équipement NEi, soit intégré dans un boîtier externe raccordé directement à un équipement NEi. Dans ce qui suit, on considère que le dispositif D est embarqué dans un équipement NEi. Ce dispositif D selon l'invention comporte un module d'assurance 20 MAE (ou module de gestion locale d'assurance) chargé d'adapter la configuration de l'équipement NEi, dans lequel il est embarqué, en fonction de règles, dites d'assurance, choisies, des données de gestion stockées dans sa MIB, et d'éventuelles données d'information qu'il reçoit des autres équipements de réseau. On entend ici par " adapter ", le fait de modifier une politique de mesure de paramètre(s) (voire mettre en place une nouvelle politique de mesure(s) ou re-configurer la politique de mesure(s)) et/ou une politique d'envoi de rapport (ou " reporting ") au NMS et/ou le mode de fonctionnement de l'équipement NEi, initialement défini(s) par le module de 30 configuration MC du NMS. Par ailleurs, on entend par " règles d'assurance ", des règles définissant la politique d'assurance locale de l'équipement compte tenu des valeurs prises par certains paramètres du réseau, stockées dans sa MIB, ou d'événements extérieurs, tels qu'une action de la couche NMS ou d'un autre routeur. Le module d'assurance embarqué MAE permet ainsi d'embarquer 5 dans un équipement NEi certaines fonctions d'assurance de manière à le rendre " plus intelligent ", à limiter le nombre d'informations qui transitent dans le réseau, et éventuellement à permettre sa reconfiguration partielle, en fonction de règles d'assurance. Afin de gérer localement la politique d'assurance, le module le d'assurance MAE comporte préférentiellement un premier sous-module SM1 chargé d'appliquer un ou plusieurs traitements aux valeurs de certains champs d'information stockés dans la MIB. Plus précisément, ces traitements consistent à appliquer aux valeurs des champs d'information choisis, en fonction de règles d'assurance dédiées, des formules ou des équations, 15 définies par le module de configuration MC du NMS, afin de délivrer des données d'information. Par exemple, le premier sous-module SM1 est chargé d'effectuer des analyses de tendance sur un intervalle choisi (ou suivant un calendrier prédéfini), utiles aux anticipations de problèmes ou de pannes. Il peut 20 notamment signaler que le pourcentage d'utilisation d'un CPU d'un routeur va atteindre un seuil critique dans une heure, ou que la bande passante d'un LSP va dépasser le seuil choisi dans deux heures. Il peut être également chargé d'effectuer des analyses de profils ou de signatures (ou " baselines "). Cela est notamment utile lorsque l'on 25 cherche, par exemple, à reconnaître ou identifier un profil caractéristique d'utilisation, tel qu'une attaque spécifique d'un routeur, ou un mode de facturation (ou " billing "). Il peut être également chargé d'effectuer des analyses de discontinuité de flux ou de trafic. Par exemple, en cas de surcharge d'un 30 réseau, des paquets sont supprimés (ou " dropped "), si bien que la détection d'une discontinuité sur le paramètre de suppression (de O à x) permet d'informer que l'on a effectivement des paquets supprimés. 9 2853109 Il peut encore être chargé d'effectuer des agrégations de valeurs de paramètres du réseau, par exemple pour appliquer des formules du module de collection de données MCC dans le routeur ou pour calculer une moyenne sur une période donnée (par exemple la bande passante moyenne utilisée au 5 cours de la dernière semaine). Dans ce cas, les valeurs agrégées peuvent être stockées dans la MIB et en être extraites sur requête de polling issue du module de collection MCC du NMS. A titre d'exemple illustratif, le premier sous-module SM1 peut être chargé d'estimer l'évolution prévisionnelle (ou tendance) du nombre de 10 paquets abandonnés (" dropped "), ainsi que l'évolution prévisionnelle de la bande passante utilisée et/ou de la charge de calcul (CPU) de l'équipement NEi. Il peut être également agencé pour effectuer des tests, par exemple de mesure(s) active(s) ou d'aide au diagnostic. Ces tests peuvent notamment permettre de faire remonter une information agrégée ou le résultat du test (par 15 exemple le temps pris pour une opération de type TCP) au niveau de la couche NMS. Préférentiellement, le premier sous-module SM1 délivre des données d'informations représentatives du résultat de ses analyses (ou estimations) à un (cinquième) sous-module de gestion (SM5), qui décide des actions à 20 entreprendre en fonction de la politique d'assurance locale de son équipement NEi. Le module d'assurance MAE comporte également de préférence un deuxième sous-module SM2 chargé de déclencher l'envoi d'alarme(s) et/ou de données d'information (ou rapports) sur ordre du cinquième sous-module 25 SM5, en fonction de règles d'assurance qui lui sont dédiées. Mais, on peut également envisager que le premier sous-module SM1 alimente le deuxième sous-module SM2 en données d'information, de sorte qu'il leur applique certaines des règles d'assurance et décide soit de leur envoi, soit de l'émission d'une alarme, à destination du NMS, et plus 30 précisément d'un module de réception d'événements MRE, et/ou d'au moins un autre équipement de réseau. Dans l'exemple illustré d'un routeur périphérique de type " bout-en- bout ", le module d'assurance MAE comporte également de préférence un troisième sous-module SM3 chargé d'observer le réseau, et notamment le trafic de type " bout-en-bout ", en fonction de règles d'assurance qui lui sont dédiées. Par exemple, on dispose d'une sonde embarquée, pour effectuer les 5 mesures de bout-en-bout. Cette sonde embarquée est alors configurée de manière à déterminer le flux à étudier et les résultats des mesures alimentent des règles d'assurance dédiées. Par exemple, l'une de ces règles peut être: " si entre deux routeurs périphériques on mesure deux flux différents, alors on agrège la mesure des deux flux pour limiter le calcul ". Dans ce cas, le troisième sous-module SM3 définit ce que l'homme de l'art appelle un agent de mesure de flux " bout-en-bout " (ou " end-toend "). Préférentiellement, le troisième sous-module SM3 délivre des données d'informations représentatives du résultat de ses observations (ou 15 mesures) au (cinquième) sous-module de gestion (SM5), qui décide des actions à entreprendre en fonction de la politique d'assurance locale de son équipement NEi. Mais, on pourrait également envisager que le troisième sous-module SM3 alimente le deuxième sous-module SM2 en données d'informations, de sorte qu'il leur applique certaines des règles d'assurance et 20 décide soit de leur envoi, soit de l'émission d'une alarme, à destination du NMS, et plus précisément d'un module de réception d'événements MRE, et/ou d'au moins un autre équipement de réseau. Par ailleurs, et comme illustré sur la figure 2, le module d'assurance MAE peut comporter un quatrième sous-module SM4 chargé de gérer 25 localement certains accords de niveau de service (ou SLA pour " Service Level Agreement "), en fonction de règles d'assurance qui lui sont dédiées. Par exemple, le sous-module SM4 connaît l'accord de niveau de service (SLA) d'un client, de sorte qu'il peut être chargé de vérifier si ce SLA est bien respecté, et générer une alarme (ou données d'informations) si ce n'est pas le 30 cas (ou si la situation se dégrade). Préférentiellement, le quatrième sous-module SM4 délivre des données d'informations représentatives de comptes-rendus de gestion au il 2853109 cinquième sous-module SM5, qui décide des actions à entreprendre en fonction de la politique d'assurance locale de son équipement NEi. Mais, on pourrait également envisager que le quatrième sous-module SM4 alimente le deuxième sous-module SM2 en données d'information, de sorte qu'il leur 5 applique certaines des règles d'assurance et décide soit de leur envoi, soit de l'émission d'une alarme, à destination du NMS, et plus précisément d'un module de réception d'événements MRE, et/ou d'au moins un autre équipement de réseau. Comme indiqué plusieurs fois ci-avant, le module d'assurance MAE 1o comporte un cinquième sous-module SM5 (ou module de contrôle) chargé de contrôler le fonctionnement des autres sous-modules (ici SM1 à SM4). Plus préférentiellement, ce cinquième sous-module SM5 se présente sous la forme d'un moteur de règles (ou " rule engine ") dans lequel sont stockées toutes les règles d'assurance dédiées aux autres sous-modules. Il s'agit par exemple 15 d'un " Java expert System ShelI ". Alors que chaque sous-module SM1 à SM4 effectue des calculs et/ou des analyses et/ou des rapports définis à partir de règles d'assurance dédiées, le cinquième sous-module SM5 gère préférentiellement l'ensemble desdites règles d'assurance dédiées. Par " gérer l'ensemble des règles ", on 20 entend ici gérer les conditions et les actions définies par les différentes règles. Le cinquième sous-module SM5 a plus précisément deux fonctions principales. Une première fonction consiste à ordonner au deuxième sous-module SM2 de générer une alarme, ou d'adresser un rapport, à destination de la 25 couche NMS (ou d'un autre équipement du réseau), parce qu'en appliquant une règle d'assurance à des données délivrées par l'un des autres sousmodules SM1 à SM4, il s'est aperçu que la condition correspondante n'était pas satisfaite. Par exemple, il ordonne la génération d'une alarme parce que les 3o données d'analyse délivrées par le premier sous-module SM1 ne satisfont pas la condition qui leur est associée par la politique locale d'assurance, ou parce que le quatrième sous-module SM4 l'a averti qu'un SLA qu'il gérait localement n'était pas respecté. Une seconde fonction consiste à décider de l'adaptation de la configuration de l'équipement NEi, et notamment du module d'assurance embarqué MAE, en fonction des données d'informations qu'il reçoit des autres 5 sous-modules SM1 à SM4 et des règles d'assurance qui définissent la politique locale d'assurance. Par exemple, compte tenu des résultats d'analyse de certains paramètres du réseau, fournis par le premier sous-module SM1, le cinquième sous- module SM5 peut décider de modifier son mode d'analyse ou bien 10 demander au deuxième sous-module SM2 d'adresser une alarme à la couche NMS de sorte qu'elle adresse de nouvelles formules d'analyse. Il peut également décider de modifier un calendrier d'analyses, par exemple effectuées par le premier sous-module SM1. Lorsque le cinquième sous-module SM5 décide de modifier le 15 fonctionnement (ou la configuration) de l'un des sous-modules SM1 à SM4, il lui adresse les instructions correspondantes, ce qui revient à lui demander de modifier ses calculs et/ou analyses et/ou rapports. De même, le cinquième sous-module SM5 peut, lorsque la politique locale l'y autorise, être chargé de rétroagir sur la configuration du routeur via un module de reconfiguration 2 0 embarqué. Il est important de noter que les actions de reconfiguration (ou de modification de fonctionnement) décidées par le cinquième sous-module SM5 sont définies par les règles d'assurance de la politique locale. En d'autres termes, le cinquième sous-module SM5 ne fait qu'ordonner l'exécution 25 d'actions prédéfinies. Le cinquième sous-module SM5 peut également appliquer des règles d'assurance choisies à des données d'information provenant d'autres équipements de réseau NEj. En effet, un équipement NEj peut être chargé de transmettre des valeurs qu'il a mesurées et/ou agrégées à un autre 30 équipement NEi équipé d'un dispositif D chargé de traiter ces valeurs de manière à générer de nouvelles données d'information qui peuvent être ensuite remontées au NMS ou envoyées à un autre équipement NEj. La politique d'assurance locale peut être par exemple définie comme suit: - si la tendance, estimée par le premier sous-module SM1, du nombre de paquets abandonnés augmente de plus de 5%, alors une alarme de tendance doit être émise, - si la bande passante utilisée, analysée par le premier sous-module SM1, demeure inférieure à un premier seuil, alors la valeur de la bande passante utilisée doit être transmise chaque jour au module de collection MCC du NMS, - si la bande passante utilisée, analysée par le premier sous-module SM1, est comprise entre un premier et un second seuils, alors la valeur moyenne de la bande passante utilisée doit être transmise toutes les heures au module de collection MCC du NMS, - si l'intervalle de temps, estimé par le premier sous-module SM1, pour que la 1 5 bande passante utilisée atteigne le second seuil, est inférieur à deux heures, alors une alarme de tendance doit être émise, - si la charge de calcul (CPU) de l'équipement NEi, estimée par le premier sous-module SM1, est supérieure à 80%, alors les analyses de tendances ne doivent plus être effectuées, - si la perte de paquets, estimée par le premier sous-module SM1, augmente de 5%, alors la taille des mémoires tampons (" buffers ") doit être augmentée de 5%. En d'autres termes la politique d'assurance locale consiste ici, d'une première part, à transmettre chaque jour la mesure de la bande passante si le 25 comportement de l'équipement NEi est normal, mais à activer les analyses de tendance et à augmenter la fréquence d'envoi des rapports si le comportement change, d'une deuxième part, à interrompre toutes les tâches impliquant un paramètre si la valeur de ce paramètre devient critique, et d'une troisième part, à modifier le fonctionnement interne de l'équipement NEi, 30 représenté par un paramètre, en fonction de la variation dudit paramètre. De préférence, le module d'assurance MAE est configurable à 1 4 2853109 distance, via le réseau N, par le module de configuration MC du NMS. Plus précisément, chaque sous-module SM1 à SM5 est préférentiellement configurable. Cela permet en effet d'adapter à distance, le fonctionnement de chaque sous-module SM en fonction des circonstances, par exemple du fait 5 de l'évolution du réseau N, et/ou en fonction des besoins, par exemple lorsque le gestionnaire d'assurance centralisé du NMS a besoin de disposer des valeurs de nouveaux paramètres, ou de paramètres agrégéscomplémentaires, ou encore de nouvelles analyses réelles ou prospectives (envoi de nouvelles formules ou équations). Deux modes de configuration peuvent être envisagés. Un premier mode consiste à transmettre indirectement les données de configuration au module d'assurance MAE via une interface de langage de programmation (ou API pour " Application Programming Interface ") implantée dans l'équipement NEi, ainsi qu'éventuellement via la MIB. Cette interface API peut également, 15 et avantageusement, permettre au module de configuration MC du NMS de configurer ou de programmer la MIB, de sorte qu'elle ne soit pas de type statique. Le module d'assurance MAE peut en effet coopérer avec la MIB pour se configurer et définir de nouvelles entrées dans la MIB, afin de pouvoir accéder à ces nouvelles entrées. Dans ce cas, on accède à la MIB via des 20 requêtes SNMP (" GET " et " SET "), ce qui permet une configuration aisée (voire même une gestion des droits et de la sécurité des échanges avec SNMP 3); la MIB permet d'avoir une interface " normalisée " du fait que ses champs sont accessibles via des OlDs (pour " Object Identifiers ") bien définis. On entend ici par " Object Identifier ", un identifiant objet d'une 25 variable MIB que l'on souhaite récupérer. Un tel identifiant est généralement normalisé, par exemple par le standard RFC 1213 pour la MIB Il. Un second mode consiste à transmettre directement les données de configuration au module d'assurance MAE à l'aide de commandes dédiées, telles que des " Command Line Interface " (ou CLI). Le module d'assurance MAE peut être réalisé sous la forme de circuits électroniques, de modules logiciels (ou informatiques), ou d'une combinaison de circuits et de logiciels. L'invention ne se limite pas aux modes de réalisation de dispositif de gestion locale d'assurance et d'équipement de réseau décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ciaprès. Ainsi, dans ce qui précède on a décrit des équipements de réseau capables de gérer localement le procédé d'assurance supervisé par le NMS. Mais, on peut envisager un fonctionnement distribué dans lequel certains au moins des équipements de réseau sont équipés de dispositifs de gestion locale d'assurance simplifiés, chargés de transmettre des alarmes et/ou des io données d'informations spécifiques et complémentaires à un serveur d'assurance du NMS. Bien entendu, dans ce cas les équipements de réseau demeurent capables d'adapter leur configuration en fonction des valeurs des données de gestion stockées dans leur MIB. Par ailleurs, on a décrit un mode de réalisation dans lequel le 15 dispositif selon l'invention était implanté ou embarqué dans l'équipement de réseau. Mais, le dispositif selon l'invention peut être agencé sous la forme d'un élément externe implanté dans un boîtier directement raccordé à l'équipement de réseau. REVENDICATIONS 1. Dispositif (D) de gestion locale d'assurance pour un équipement de réseau (NE) d'un réseau de communications (N) équipé d'un système de 5 gestion de réseau (NMS), ledit équipement (NE) présentant une configuration choisie et comportant des moyens (MM) de mesure de valeurs de paramètre(s) du réseau et une base d'informations de gestion (MIB) propre à stocker des données de gestion représentatives desdites valeurs mesurées, caractérisé en ce qu'il comprend des moyens de gestion (MAE) agencés pour 10 adapter la configuration dudit équipement (NE) en fonction d'au moins lesdites données de gestion stockées dans ladite base d'informations de gestion (MIB) et de règles, dites d'assurance, choisies, définissant une politique locale d'assurance. 2. Dispositif selon la revendication 1, caractérisé en ce que lesdits 15 moyens de gestion (MAE) sont agencés pour adapter ladite configuration en fonction de données d'informations provenant d'au moins un autre équipement de réseau (NE). 3. Dispositif selon l'une des revendications 1 et 2, caractérisé en ce que ladite adaptation consiste en une modification d'une politique de mesure 20 de paramètre(s) et/ou une modification d'une politique d'envoi de rapport audit système de gestion de réseau (NMS). 4. Dispositif selon l'une des revendications 1 à 3, caractérisé en ce que ladite adaptation consiste en une modification de son mode de fonctionnement. 5. Dispositif selon l'une des revendications 1 à 4, caractérisé en ce que lesdits moyens de gestion (MAE) comprennent des moyens d'analyse (SM1) agencés pour déterminer, en fonction de certaines desdites règles d'assurance choisies, des données d'information représentatives de l'évolution temporelle, sur un intervalle choisi, de valeurs de paramètre(s) du 30 réseau stockées dans ladite base d'informations de gestion (MIB). 6. Dispositif selon la revendication 5, caractérisé en ce que lesdits 1 7 2853109 moyens d'analyse (SM1) sont agencés pour délivrer des données d'information représentatives d'une analyse de tendance et/ou d'une analyse de profils ou de signatures et/ou d'une analyse de discontinuité et/ou d'une agrégation de valeurs de paramètres du réseau. 7. Dispositif selon l'une des revendications 5 et 6, caractérisé en ce que lesdits moyens d'analyse (SMI1) sont configurables. 8. Dispositif selon la revendication 7, caractérisé en ce que lesdits moyens d'analyse (SM1) sont agencés pour mettre en oeuvre de nouveaux calculs, relatifs aux paramètres du réseau, reçus dudit système de gestion de 10 réseau (NMS). 9. Dispositif selon l'une des revendications 1 à 8, caractérisé en ce que lesdits moyens de gestion (MAE) comprennent des moyens d'alarme (SM2) propres à déclencher l'envoi d'une alarme et/ou de données d'information audit système de gestion de réseau (NMS) et/ou à au moins un autre 15 équipement de réseau (NE), en fonction de certaines desdites règles d'assurance choisies. 10. Dispositif selon la revendication 9, caractérisé en ce que lesdits moyens d'alarme (SM2) sont configurables. 11. Dispositif selon l'une des revendications 9 et 10, caractérisé en ce 20 que lesdites données d'information et lesdites alarmes sont représentatives d'un résultat d'analyse, effectuée par lesdits moyens d'analyse (SMI), et/ou d'une agrégation de données, effectuée par lesdits moyens d'analyse (SMV1), et/ou d'une valeur de paramètre du réseau stockée dans ladite base d'informations de gestion (MIB). 12. Dispositif selon l'une des revendications 1 à 11, caractérisé en ce que lesdits moyens de gestion (MAE) comprennent des moyens d'observation du réseau (SM3) définissant un agent de mesure de flux de type " boutenbout "), et agencés pour déterminer des données d'information représentatives dudit flux de type bout-en-bout en fonction de certaines 30 desdites règles d'assurance choisies. 13. Dispositif selon la revendication 12, caractérisé en ce que lesdits 18 2853109 moyens d'observation du réseau (SM3) sont configurables. 14. Dispositif selon l'une des revendications 1 à 13, caractérisé en ce que lesdits moyens de gestion (MAE) comprennent des moyens de gestion d'accords de niveau de service (SM4) agencés pour déterminer des données 5 d'information représentatives de ladite gestion des accords en fonction de certaines desdites règles d'assurance choisies. 15. Dispositif selon la revendication 14, caractérisé en ce que lesdits moyens de gestion d'accords de niveau de service (SM4) sont configurables. 16. Dispositif selon l'une des revendications 2 à 15, caractérisé en ce 1o que lesdits moyens de gestion (MAE) comprennent des moyens de contrôle (SM5) propres à gérer le fonctionnement desdits moyens d'analyse (SM1), desdits moyens d'alarme (SM2), desdits moyens d'observation du réseau (SM3) et desdits moyens de gestion d'accords de niveau de service (SM4), en fonction de certaines au moins desdites règles d'assurance choisies. 1 5 17. Dispositif selon la revendication 16, caractérisé en ce que lesdits moyens de contrôle (SM5) sont alimentés en données d'information par lesdits moyens d'analyse (SM1) et/ou lesdits moyens d'observation du réseau (SM3) et/ou lesdits moyens de gestion d'accords de niveau de service (SM4), et sont agencés pour ordonner auxdits moyens d'alarme (SM2) de générer 20 des alarmes et/ou des rapports en cas de détection du non respect d'une règle d'assurance par des données d'information reçues. 18. Dispositif selon l'une des revendications 16 et 17, caractérisé en ce que lesdits moyens de contrôle (SM5) sont agencés sous la forme d'un moteur de règles (" rule engine ") stockant lesdites règles d'assurance 25 choisies. 19. Dispositif selon l'une des revendications 16 à 18, caractérisé en ce que lesdits moyens de contrôle (SM5) sont configurables. 20. Dispositif selon l'une des revendications 1 à 19, caractérisé en ce que lesdits moyens de gestion (MAE) sont propres à être configurés par ledit 30 système de gestion de réseau (NMS) via une interface de langage de programmation (API) dudit équipement (NE). 1 9 2853109 21. Dispositif selon l'une des revendications 1 à 20, caractérisé en ce que lesdits moyens de gestion (MAE) sont propres à être configurés par ledit système de gestion de réseau (NMS) via une interface de langage de programmation (API) dudit équipement (NE) et via ladite base d'informations de gestion (MIB). 22. Dispositif selon l'une des revendications 20 et 21, caractérisé en ce que lesdits moyens d'analyse (SM1) et/ou lesdits moyens d'alarme (SM2) et/ou lesdits moyens d'observation du réseau (SM3) et/ou lesdits moyens de contrôle (SM5) et/ou lesdits moyens de gestion d'accords de niveau de 1a0 service (SM4) sont propres à être configurés par ledit système de gestion de réseau (NMS), via ladite interface de langage de programmation (API). 23. Dispositif selon l'une des revendications 20 et 21, caractérisé en ce que lesdits moyens d'analyse (SM1) et/ou lesdits moyens d'alarme (SM2) et/ou lesdits moyens d'observation du réseau (SM3) et/ou lesdits moyens de 15 contrôle (SM5) et/ou lesdits moyens de gestion d'accords de niveau de service (SM4) sont propres à être configurés par ledit système de gestion de réseau (NMS), via ladite interface de langage de programmation (API) et via ladite base d'informations de gestion (MIB). 24. Dispositif selon l'une des revendications 1 à 23, caractérisé en ce 20 que lesdits moyens de gestion (MAE) sont propres à être configurés par ledit système de gestion de réseau (NMS) via des commandes dédiées. 25. Dispositif selon la revendication 24, caractérisé en ce que lesdits moyens d'analyse (SM1) et/ou lesdits moyens d'alarme (SM2) et/ou lesdits moyens d'observation du réseau (SM3) et/ou desdits moyens de gestion 25 d'accords de niveau de service (SM4) et/ou lesdits moyens de contrôle (SM5) sont agencés pour être configurés par ledit système de gestion de réseau (NMS) via des commandes dédiées. 26. Dispositif selon l'une des revendications 24 et 25, caractérisé en ce que lesdites commandes sont de type " Command Line Interface ". 27. Equipement de réseau (NE) pour un réseau de communications (N) équipé d'un système de gestion de réseau (NMS), ledit équipement (NE) 2853109 présentant une configuration choisie et comportant des moyens (MM) de mesure de valeurs de paramètre(s) du réseau et une base d'informations de gestion (MIB) propre à stocker des données de gestion représentatives desdites valeurs mesurées, caractérisé en ce qu'il comprend un dispositif (D) selon l'une des revendications précédentes. 28. Equipement selon la revendication 27, caractérisé en ce qu'il comprend une interface de langage de programmation (API), et en ce que ladite base d'informations de gestion (MIB) est propre à être configurée par ledit système de gestion de réseau (NMS) via ladite interface de langage de 'o programmation (API). 29. Equipement selon l'une des revendications 27 et 28, caractérisé en ce qu'il comprend une interface de langage de programmation (API), et en ce que ladite base d'informations de gestion (MIB) est propre à être programmée par ledit système de gestion de réseau (NMS) via ladite interface de langage 15 de programmation (API). 30. Equipement selon l'une des revendications 27 à 29, caractérisé en ce qu'il est choisi dans un groupe comprenant au moins les routeurs, les commutateurs et les pare-feux. 31. Réseau de communications (N) comportant un système de gestion 20 de réseau (NMS), caractérisé en ce qu'il comprend une multiplicité d'équipements de réseau (NE) selon l'une des revendications 27 à 30. 32. Réseau selon la revendication 31, caractérisé en ce que chaque équipement (NE) est agencé pour délivrer audit système de gestion de réseau (NMS) des alarmes et/ou des données d'information de types 25 différents. 33. Utilisation des dispositif, équipement et réseau de communications selon l'une des revendications précédentes dans les technologies réseaux devant être gérées. 34. Utilisation selon la revendication 33, caractérisé en ce que lesdites 30 technologies réseaux sont choisies dans un groupe comprenant les réseaux de transmission, en particulier de type WDM, SONET et SDH, de données, en 21 2853109 particulier de type Internet-IP et ATM, et de voix, en particulier de type classique, mobile et NGN.