FR 2873879 A1 20060203 FR 0408505 A 20040730 Système de gestion de réseau de communication pour réparation automatique de pannes La présente invention est relative aux réseaux de communication et s'applique notamment mais non exclusivement aux réseaux de communication orientés paquets. Elle concerne plus particulièrement la gestion des réseaux de communication. Il est connu d'associer aux réseaux de communication, des systèmes de gestion de réseau (ou NMS pour Network Management System ) dont le but est de récolter des alarmes provenant des équipements du réseau, d'en réaliser une synthèse, notamment au moyen de procédés de corrélation, et d'afficher cette synthèse ou ses alarmes à l'intention d'un opérateur afin que celui-ci puisse mettre en oeuvre une action corrective en cas de panne d'un ou plusieurs de ces équipements. La notion de panne doit être comprise dans un sens très général signifiant tout type de dysfonctionnement qu'il soit matériel ou logiciel. Ainsi, une mauvaise configuration d'un élément de réseau peut être assimilée à une panne (logicielle), de même qu'une erreur dans une table de routage d'un routeur IP ou qu'un port malencontreusement fermé. Les systèmes de gestion de réseau peuvent également configurer les équipements de réseau. L'opérateur peut saisir de nouveaux paramètres grâce à une interface homme-machine et le système de gestion de réseau répercute ces nouveaux paramètres sur les équipements. De cette façon, l'opérateur peut corriger une panne du réseau, en réaction à l'affichage d'alarmes. Une telle analyse centralisée repose toutefois sur la collection d'un 30 grand nombre de données d'information et d'alarmes auprès des nombreux 105480/SYC/IPD éléments du réseau de communication. Ces éléments peuvent être des équipements comme des routeurs dans le cadre d'un réseau de communication IP (Internet Protocol), mais il peut s'agir aussi de commutateurs voix, optiques, de PABX (Private Branch Exchange), de passerelles médias (Media Gateway) dans un réseau dit NGN (Next Generation Network) etc. Un élément de réseau peut aussi être une partie d'un tel équipement, comme une carte par exemple. Du fait des nombreuses interactions entre les éléments d'un réseau, une unique panne peut générer un grand nombre d'alarmes. Ainsi, une panne sur une carte d'un équipement peut générer une alarme de la part de l'ensemble des cartes d'autres équipements, connectés à un des ports de cette carte, ainsi que par les cartes de l'équipement dans lequel la panne a eut lieu. Aussi, il est difficile pour l'opérateur de déterminer quelle est la panne véritable à partir du grand nombre d'alarmes générées, et a fortiori de déterminer l'action corrective à entreprendre. Un progrès a été effectué grâce aux systèmes de diagnostic qui, à partir de ce grand nombre d'alarmes, déterminent la ou les causes les plus probables. Ces systèmes de diagnostic se basent par exemple sur des ensembles de règles, comme par exemple ceux basés sur le produit IlogRulesïM de la société Ilog. Ils peuvent aussi se baser sur des réseaux de neurones, sur des réseaux bayesiens, sur des systèmes experts ou d'autres techniques, notamment d'intelligence artificielle. Comme autres produits, on peut citer aussi le produit Fault Detective for Data Communications (FDDC) de la société Agilent, les produits Network Note Manager et Network Node Manager Extended Topology de Hewlett-Packard, ou les produits Output Interpreter et Troubleshooting Assistant (TAC) de la société Cisco. 105480/SYC/IPD Néanmoins, ces outils nécessitent l'opérateur d'intervenir à chaque panne pour déterminer la ou les actions correctives à entreprendre et pour les déclencher. Il lui faut alors reconfigurer le réseau à travers le système de gestion de réseau ou bien se connecter manuellement sur un ou plusieurs équipements et envoyer les commandes CLI (Command Line Interface) adéquates. Quoique aidée par les systèmes de diagnostic de l'état de l'art, cette tâche demeure difficile et donc coûteuse, et sujette à erreurs. En effet, la phase de reconfiguration et de connexion manuelle aux équipements est longue et fastidieuse. Il est de plus facile de se tromper dans un paramètre d'une commande CLI et de provoquer ainsi une nouvelle panne du réseau. La phase de détermination des actions correctives est aussi délicates pour l'opérateur, car s'il veut que celles-ci soient optimales, il faut qu'il prenne en compte des informations de performance du réseau ou d'autres paramètres encore. Avec l'accroissement de la complexité des réseaux, du nombre de types d'équipements disponibles et de leur complexité, ces tâches seront de plus en plus délicates et coûteuses. Le but de l'invention est d'automatiser la correction des pannes du réseau de communication géré. Pour ce faire, l'invention a pour premier objet un système de gestion d'un réseau de communication comportant un module de diagnostic apte à déterminer un diagnostic à partir d'informations fournies par des éléments du réseau de communication. Ce diagnostic identifie une panne au sein du réseau de communication. Ce système de gestion se caractérise en ce qu'il comporte en outre un module de réparation agencé 105480/SYC/IPD - pour déterminer une ou plusieurs actions correctives à partir au moins du diagnostic reçu du module de diagnostic et - pour transmettre une ou plusieurs commandes correspondants à la ou aux actions correctives, à un ou plusieurs des éléments du réseau de communication, en vue de corriger la panne. Selon des modes de réalisation de l'invention, le système de gestion peut comporter les caractéristiques suivantes, individuellement ou en combinaison: Le module de réparation est agencé pour transmettre une demande de diagnostic au module de diagnostic pour déclencher la détermination d'un nouveau diagnostic par le module de diagnostic. - un compteur d'itération est incrémenté à chaque déclenchement d'un nouveau diagnostic, et le système de gestion stoppe les modules de diagnostic et de réparation lorsque le compteur d'itération a atteint un seuil prédéterminé. - la ou les commandes sont transmises par l'intermédiaire d'un module de médiation apte à transformer la ou les commandes formulées dans un langage générique, en des commandes spécifiques conformes à des langages de commandes propres aux différents équipements du réseau de communication. - le module de réparation est agencé pour communiquer avec un module d'optimisation du trafic si des actions correctives ne peuvent être déterminées de façon satisfaisante pour corriger le panne, ceci afin de supprimer ou limiter l'influence de cette panne sur le comportement du réseau de communication. - le module de diagnostic met en oeuvre un réseau bayesien afin de déterminer le diagnostic. 105480/SYC/IPD le diagnostic contient au moins la désignation de le panne, la localisation de le panne, et éventuellement une estimation de la probabilité associée au diagnostic. le module de diagnostic communique le diagnostic au module de réparation au moyen d'un message conforme au protocole SNMP. - le module de réparation dispose d'une base de règles de réparation. - Les règles peuvent dépendre du compteur d'itérations. - Le module de réparation dispose d'un historique des diagnostics et des actions correctives déterminées à chaque itération et est apte à revenir à l'état du réseau de communication pour une itération donnée, si lorsque le seuil est atteint, le diagnostic est moins bon que ce qu'il était pour cette itération donnée. L'invention a par ailleurs pour second objet un procédé de gestion d'un réseau de communication comportant une première étape de détermination d'un diagnostic à partir d'informations fournies par des éléments du réseau de communication. Ce procédé se caractérise en ce qu'il comporte en outre une seconde étape de détermination, si le diagnostic identifie une panne, d'une ou de plusieurs actions correctives à partir au moins du diagnostic et de transmission d'une ou de plusieurs commandes (C) correspondants à cette ou ces actions correctives, à un ou plusieurs des éléments du réseau de communication, en vue de corriger la panne. Selon des modes de réalisation de l'invention, le procédé de gestion peut comporter les caractéristiques suivantes, individuellement ou en combinaison: - La première étape est automatiquement déclenchée à l'issue de la seconde étape, afin de former un cycle de traitement. 105480/SYC/IPD - un compteur d'itération est incrémenté à chaque déclenchement d'un nouveau diagnostic, le cycle de traitement s'interrompant lorsque ce compteur d'itération a atteint un seuil prédéterminé. - la ou les commandes sont transmises par l'intermédiaire d'un module de médiation apte à transformer la ou les commandes formulées dans un langage générique, en des commandes spécifiques conformes à des langages de commandes propres aux différents équipements du réseau de communication. - une commande peut être transmise à un module d'optimisation du trafic si des actions correctives ne peuvent être déterminées de façon satisfaisante pour corriger la panne, afin de supprimer ou limiter l'influence de cette panne sur le comportement du réseau de communication. - la première étape met en oeuvre un réseau bayesien afin de déterminer le diagnostic. - le diagnostic contient au moins la désignation de la panne, la localisation de la panne, et éventuellement une estimation de la probabilité associée au diagnostic. un historique des diagnostics et des actions correctives déterminées à chaque itération est constitué et si lorsque le seuil est atteint le diagnostic est moins bon que ce qu'il était pour une itération antérieure, on revient à l'état du réseau de communication pour cette itération antérieure. Ainsi, selon l'invention, le module de réparation permet de réparer automatiquement (ou semi-automatiquement, après validation de l'opérateur) les pannes du réseau de communication et/ou d'entreprendre des actions correctives limitant les conséquences des pannes, et notamment leurs impacts sur les SLA (Service Level Agreements) déployés sur le réseau de communication. 105480/SYC/IPD Après correction, un nouveau diagnostic est demandé au module de diagnostic afin de s'assurer que cette réparation n'a pas engendré de nouvelle panne, et si oui, de les corriger à leur tour. Un cycle de traitement peut ainsi être mis en oeuvre qui doit converger vers la réparation de la panne diagnostiquée. Afin d'éviter des boucles de réparation trop longues, un seuil peut être fixé pour le nombre d'itérations de la boucle. L'invention, ses caractéristiques et ses avantages apparaîtront de 10 façon plus claire dans la description qui va suivre en liaison avec les figures annexées. La figure 1 schématise le système de gestion selon l'invention. La figure 2 représente une architecture interne du module de réparation selon une mise en oeuvre de l'invention. La figure 3 illustre l'enchaînement des étapes du procédé selon l'invention. Ces dessins annexés pourront non seulement servir à compléter l'invention, sans que celle-ci y soit limitée, mais aussi contribuer le cas échéant 20 à sa définition. Selon l'invention, le système de gestion de réseau comporte deux modules principaux qui sont d'une part un module de diagnostic MD et d'autre part un module de réparation MR. Le module de diagnostic reçoit en entrée des plaintes des clients CC et des informations du réseau A. Les plaintes du client peuvent être provoquées par une baisse des performances du réseau ou des services mis en oeuvre sur le réseau. À la réception d'une telle plainte, le système de diagnostic MD peut déclencher une recherche de diagnostic afin de 105480/SYC/IPD déterminer la cause technique ayant amenée cette plainte. II peut alors tirer profit des informations issues des éléments du réseau. Une recherche de diagnostic peut aussi être déclenché par ces informations issues des éléments du réseau de communication elles-mêmes (c'est-à-dire indépendamment de la présence d'une plainte de client). Les informations A issues des éléments du réseau peuvent être principalement de deux natures: É Il peut s'agir d'alarmes, c'est-à-dire de notifications asynchrones transmises par les éléments du réseau vers le système de gestion de réseau. Ces alarmes sont transmises lorsqu'une anomalie est détectée par l'élément, lorsqu'une valeur mesurée atteint un seuil prédéterminé ou, d'une façon plus générale, lors de n'importe quel type d'événement dont on a prévu, par configuration, que l'apparition devait déclencher une alarme. Ces alarmes peuvent donc indiquer une panne, que celle-ci soit logicielle ou matérielle. É Il peut aussi s'agir de données de configuration ou de performances, qui ne sont pas notifiées au système de gestion de réseau NMS, mais que celui-ci doit aller chercher dans une base d'information de gestion (MIB pour Management Information Base, en anglais). É II peut aussi s'agir de la mise en place de tests actifs, de mesures actives ou passives, et notamment de mesures de bout en bout. Notamment à la réception d'alarmes, le module de diagnostic MD 25 peut déterminer que celles-ci représentent une panne ou une panne probable. À la suite d'une telle détermination, il déclenche alors la détermination du diagnostic, c'est-à-dire la recherche de la panne. Comme on a dit précédemment, lorsqu'une panne a lieu, elle peut provoquer des alarmes provenant non seulement de l'élément de réseau en panne, mais aussi d'éléments de réseau voisins . La détermination du 105480/SYC/IPD diagnostic consiste justement à identifier l'élément de réseau en panne (c'est la localisation de la panne), ainsi que le type de panne (l'intitulé de la panne), à partir de cet ensemble d'alarmes provenant d'une multitude d'éléments de réseau. Généralement, le diagnostic ne peut être certain, et le module de diagnostic MD fournira alors le diagnostic D le plus probable en y associant une valeur de probabilité. Il peut aussi fournir une liste de plusieurs diagnostics, chacun étant associé à une valeur de probabilité, et chacun identifiant une panne au sein du réseau de communication N. Le module de diagnostic peut être un module connu de l'état de l'art. Comme décrit précédemment, les technologies mises en oeuvre peuvent être diverses: réseaux de neurones, systèmes experts, systèmes à base de règles etc. II peut s'agir des produits commerciaux précédemment évoqués. Le module de diagnostic MD doit préférentiellement toutefois respecter deux critères: É Il doit être proactif , c'est-à-dire que la recherche de diagnostic peut être déclenchée autrement que par la réception d'alarmes A du réseau de communications. Notamment, cette recherche doit pouvoir être déclenchée par un événement extérieur qui peut être soit une plainte client CC, soit une demande de diagnostic (CD), transmise par le module de réparation MR et qui sera explicité ultérieurement. É Il doit pouvoir fournir le diagnostic le plus probable et si possible y attacher une probabilité. Préférentiellement, ce module de diagnostic met en oeuvre des réseaux bayésiens et est similaire au produit 5530 Network Analyzer de la société Alcatel. Le fonctionnement d'une mise en oeuvre de ce module est par conséquent décrit dans la document technique du produit 5530 . La technologie des réseaux bayésiens et son application à la détermination de 105480/SYC/IPD diagnostics sont par exemple décrits dans l'ouvrage An introduction to Bayesian Networks de F. Jensen, UCL Press, 1996 ou dans l'article IP VPN Network Diagnosis: Technologies and Perspectives de Gérard Delègue, Stéphane Betgé-Brezetz, Emmanuel Marilly et Olivier Martinot, 3rd International Conference on Networking, Mars 2004. Le principe des réseaux bayesiens utilise la théorie des probabilités qui définit une règle pour raffiner une hypothèse en prenant en compte des éléments de preuve additionnels et des informations d'arrière-plan et ainsi conduire à un nombre représentant le degré de probabilité que l'hypothèse soit vraie. Un diagramme bayesien définit donc toutes les actions de test à entreprendre, associées à une probabilité et à un coût, le coût servant par exemple pour définir quels tests demandent plus de temps que les autres. La figure 3 illustre un exemple extrêmement simplifié de diagramme bayesien. Il montre que l'entité LossPacket (perte de paquets) dépend de plusieurs autres entités, HighCPUUtilization (haut taux d'utilisation du CPU), InterfacelNStatus (Statut de l'interface entrante), InterfaceOutStatus (Statut de l'interface sortante). Ce modèle permet donc au système d'une part de représenter les chaînes de causalité et donc de lui indiquer les tests à effectuer, et d'autre part de calculer une valeur de probabilité pour chaque diagnostic possible et de déterminer un diagnostic le plus probable. Dans la pratique, les diagrammes bayesiens sont bien évidemment 25 plus complexes et peuvent comporter plusieurs niveaux hiérarchiques. De plus, il faut de nombreux diagrammes pour modéliser un élément de réseau. Une fois un diagnostic D déterminé, celui-ci est transmis au module de réparation MR, sous la forme d'un ou de plusieurs message. Ces messages 30 sont par exemple conformes au protocole SNMP (Simple Network 105480/SYC/IPD Management Protocol) défini par I'IETF (Internet Engineering Task Force) dans les RFC 1 157 et 1592 pour les versions 1 et 2 respectivement. Il peut s'agir d'un unique message (ou trop ) SNMP ou de plusieurs messages. Dans ce dernier cas, les messages doivent être clairement identifiés pour que le module de réparation MR puisse aisément déterminer qu'ils sont relatifs à un même diagnostic D. Selon un mode de réalisation, le premier message contient les informations générales sur le diagnostic, tandis que le ou les messages suivants contiennent des informations de détails. Si, par exemple, le diagnostic concerne un LSP (Label Switching Point), le premier message peut contenir les informations de diagnostic relatives au LSP lui-même, tandis que les messages subséquents contiennent des informations relatives aux équipements (ou routeurs) traversés par le LSP. Cette détermination peut être réalisée au moyen du ticket qui sera explicité plus bas: tous les messages SNMP transportant un même diagnostic 15 D auront le même ticket. Toutefois, d'autres mises en oeuvre sont possibles, notamment les deux modules peuvent communiquer via un bus logiciel de type CORBA (Common Object Request Broker Architecture) tel que défini par l'OMG (Open Management Group) ou COM/DCOM de la société Microsoft. Ce message D doit contenir préférentiellement les informations suivantes: É l'intitulé de la panne diagnostiqué. Par exemple, Interface hors service , mauvaise configuration de BGP (Border Gateway Protocol) etc. É la localisation de la panne, c'est-à-dire un identificateur de l'élément de réseau, de la carte, de l'interface, du réseau virtuel (VPN pour Virtual Private Network en anglais) etc. concerné. É Une valeur de probabilité, qui détermine à quel niveau de confiance on doit considérer le diagnostic établi. 105480/SYC/IPD É Un ticket, c'est-à-dire un numéro qui identifie une session de recherche du bon diagnostic pour un problème donné). Comme dit précédemment, si un même diagnostic est transporté par plusieurs messages, notamment parce que le volume d'information est trop important, chacun de ces messages aura le même ticket. É Un numéro d'itération qui identifie le nombre d'occurrence d'une recherche de diagnostic pour un ticket donné. On verra ultérieurement qu'un problème peut engendrer une boucle entre le module de diagnostic MD et le module de réparation MR, de sorte que plusieurs itérations peuvent être nécessaires pour aboutir à la résolution du problème. Dans le cas d'une mise en oeuvre basée sur le protocole SNMP, la 15 table suivante donne un exemple d'un trap SNMP : Nom du champ Description OID (SNMP object ASN Applic de la trop identifier) 1 ation SNMP Type format Type de Panne Description de l'alarme 1.3.6.1.4. 1.637.4.1 String String SNMP; Description de la panne pour laquelle la "trop" SNMP a été générée. Localisation VPN ID 1.3.6.1.4.1.637.4.2.1 String String LSP LSP ID; identificateur du LSP 1.3.6.1.4.1.637.4.2.2 String Int Router Router ID; Adresse IP du 1.3.6.1.4.1.637.4.2.3 String String routeur Interface Interface index. 1.3.6.1.4.1.637.4.2.4 String Int SNMP Interface index Ticket Ticket ID; Ticket unique 1.3.6.1.4.1.637.4. 3 String Int identifiant la panne. Reliability Probabilité du diagnostic. 1.3.6.1.4.1.637.4.4 String Float Iteration Itération dans la boucle de 1.3.6.1.4.1.637.4.5 String Int diagnostic. Diagnostics Description du scénario de 1.3.6.1.4.1.637.1.6 String String scenario diagnostic. 105480/SYC/I PD Ces OlDs (SNMP Object IDentifiers) se décomposent en trois parties: La partie gauche (1.3.6.1.4.1.637.) correspond à l'identifiant Alcatel, la partie suivante (4.) correspond à l'application (i.e. le module de diagnostic MD) et la dernière partie correspond aux attributs propres aux champs du trop SNMP . À la réception d'un message contenant un diagnostic D, le module de réparation D va chercher à déterminer une ou plusieurs actions correctives. La figure 2 représente une architecture fonctionnelle possible du module de réparation MR. Cette architecture étant fonctionnelle, elle peut donner lieu à différentes réalisations. Selon cette mise en oeuvre, le module de réparation MR comporte un module principal MP, une interface homme-machine IHM, une base de données B et un module de configuration MC. Les diagnostics D sont reçus par le module principal MP, dont le but est de déterminer les actions correctives et de transmettre les commandes correspondant à ces actions correctives soit vers un module de médiation MED, soit directement vers les éléments du réseau, non représentés sur la figure. Cette détermination est donc réalisée à partir du diagnostic D et des informations qu'il comporte et que nous avons vu précédemment. Il peut toutefois aussi dépendre d'autres informations telles - une logique interne, c'est-à-dire une formalisation dans un langage particulier, de la politique qui permet de déterminer une action corrective à partir d'au moins un diagnostic. Cette logique interne est mémorisée dans une base de données B. - des paramètres déterminés par l'utilisateur, notamment au moyen de l'interface IHM et du module de configuration MC 105480/SYC/IPD 30 et mémorisés dans la base de données B (ou éventuellement dans une autre base de données distincte). - Des informations transmises par l'utilisateur par l'interface IHM, durant l'élaboration du diagnostic, notamment en réponse à une proposition effectuée par le module principal MP. Selon un mode de réalisation préférentiel de l'invention, la logique interne est formalisée sous la forme d'un ensemble de règles. Ces règles permettent d'associer les diagnostics C qui peuvent être reçus du module de diagnostic MD à des actions correctives. Elles peuvent être entrées dans la base B par l'intermédiaire du module de configuration MC et de l'interface IHM. Ces règles peuvent typiquement s'exprimer sous la forme: SI prémisses ALORS actions dans laquelle prémisses est une liste de conditions qui doivent être remplies pour que la ou les actions soient déclenchées. Cette liste peut contenir plusieurs conditions liées entre elles de façon conjonctives (par l'opérateur logique ET) ou disjonctives (par l'opérateur logique OU). De telles règles peuvent par exemple être: o If (Router=Alcatel/192.128. 12.52, Interface= FastEthernetl /0) && ((Iteration=1) o If (Router=Alcatel/192.128.12.52, Interface= FastEthernetl /0) && ((Iteration=1) o (Corrective Action 2) = Put (Router=Cisco/192.128.12.52, Interface=FastEthernetl/0) Interface Up. 105480/SYC/IPD o (Corrective Action 3) = Configure (Router=Alcatel/192.128.12.52, Interface= FastEthernetl /0) With BGP Configuration_Script_1 Dans le formalisme de ces règles, ou bien dans des paramètres associées à ces règles, on peut associer un indicateur pour préciser si les actions correctives peuvent être directement transmises aux éléments du réseau de communication, éventuellement au travers du module de médiation MED, ou si une validation de l'opérateur est nécessaire. Dans ce dernier cas, les actions correctives sont transmises à l'interface homme-machine IHM pour affichage sur un écran. Ces indicateurs peuvent être mémorisés dans la base B grâce au module de configuration MC, accessible par l'opérateur au travers de l'interface homme-machine IHM. Outre ces actions correctives, d'autres informations peuvent être affichées afin d'aider l'opérateur dans sa décision, notamment les informations relatives au diagnostic D transmises par le module de diagnostic MD. L'opérateur peut alors valider la proposition du module de réparation MR avant que celui-ci ne transmette les commandes C vers les éléments de 20 réseau. Dans la situation où plusieurs actions correctives sont possibles, l'interface IHM peut les afficher sur l'écran et permettre à l'utilisateur de choisir celle qui lui semble la plus appropriée. Le module de réparation MR transmettra alors vers les éléments du réseau de communication, les commandes C correspondant aux actions correctives choisies par l'opérateur. Outre la mise en oeuvre préférentielle à base de règles, d'autres mises en oeuvre sont également possibles. On peut par exemple utiliser des réseaux bayésiens ou bien des 30 réseaux neuronaux. L'avantage de l'utilisation des réseaux de neurones est 105480/SYC/IPD leur faculté d'apprentissage et de fonctionnement dans l'incertain. Par exemple, ils peuvent être capables d'appliquer l'action corrective la plus probable à la panne la plus probable, même si un certain nombre d'informations sont manquantes. Toutefois, à la date de dépôt de la présente demande, le problème est la difficulté d'appréhension d'une telle technologie par les opérateurs des réseaux de communication. Comme évoqué précédemment, les commandes C peuvent être transmises vers les éléments du réseau de communication N, par l'intermédiaire d'un module de médiation MED. Le but de ce module de médiation est de transformer des commandes C formulées dans un langage générique par le module de réparation MR, en des commandes spécifiques C1, C2 conformes en des langages de commandes propres aux différents équipements du réseau de communication. Ainsi, sur la figure 1, les équipements N1 et N2 peuvent être de type différent, par exemple un routeur IP et une passerelle média (Media gateway) permettant de relier ce réseau de communication N à un autre réseau, non représenté. Il peut aussi s'agir d'équipements de types similaires mais fabriqués par des fournisseurs différents. Dans ces deux situations, les commandes à utiliser pour les configurer doivent être adaptées au langage de commandes compris par l'équipement. Une même commande C générique (par exemple, ouvrir une interface ) donnera donc lieu à des commandes spécifiques différentes pour les deux équipements N1et N2, chacune de ces commandes spécifiques étant conforme au langage propre des équipements, et notamment de leur interface CLI (Command Line Interface). Différents produits et technologies peuvent être utilisés pour réaliser ce module de médiation MED. Une architecture de gestion à base de règles de politique (PBM pour 30 Policy-based Management en langue anglaise) peut notamment être 105480/SYC/IPD utilisée. Les demandes de brevet EP1335524 intitulée Déploiement des règles par une dispositif de gestion de services, en fonction d'informations sur les équipements du réseau ou EP1387526 intitulée Système de gestion de réseau par règles comportant un moteur d'inférence par exemples, décrivent de telles architectures. Ainsi, par la détermination des actions correctives, le module de réparation MR selon l'invention permet d'automatiser la réparation du réseau de communication ou de le semi-automatiser dans le cas où une intervention de l'opérateur est demandée. Toutefois, la complexité des réseaux de communication est telle qu'il est pratiquement impossible de maîtriser complètement l'impact des actions correctives. D'une part, la réparation peut s'avérer inefficace pour résoudre le problème (par exemple, parce que le diagnostic n'était pas bon, mais aussi parce que les actions correctrices n'étaient pas entièrement adaptées), et d'autre part, il est aussi possible que la réparation réelle de la panne puisse engendrer une nouvelle panne. Par exemple, en réparant une première panne, on permet la transmission de trafic vers des éléments de réseau qui jusqu'alors étaient isolés, et ce faisant, on peut mettre en évidence une panne parmi ces éléments de réseau. La demanderesse a donc considéré le problème technique additionnel de minimiser les impacts insuffisants ou non désirés sur le réseau de communication. Pour ce faire, après transmission des commandes C vers les éléments du réseau de communication, une demande de diagnostic CD est transmise au module de diagnostic MD, afin que celui-ci détermine un nouveau diagnostic. Cette demande de diagnostic CD peut contenir la valeur du ticket, afin que ce nouveau diagnostic (ainsi que les éventuels suivants) soit lié au premier diagnostic au sein d'une session déterminée par un même ticket. 105480/SYC/IPD Grâce à ce re-bouclage vers le module de diagnostic MD, celui-ci peut vérifier la correction de la panne et détecter l'apparition d'une nouvelle panne. II pourra alors déclencher une nouvelle réparation par le module de réparation MR, et ainsi de suite. Ce mode de réalisation préférentiel de l'invention permet donc de réaliser une boucle de contrôle des actions faites sur le réseau de communication géré. Toutefois ce mode de réalisation peut poser le problème additionnel de provoquer des boucles infinies, c'est-à-dire que chaque réparation 10 engendre une nouvelle panne de façon cyclique. Afin d'éviter ces boucles infinies, un compteur d'itération peut être mis en oeuvre. Par exemple, ce compteur d'itération est incrémenté à chaque déclenchement d'un nouveau diagnostic. Lorsque ce compteur d'itération atteint un certain seuil, prédéfini, la boucle est stoppée et le système peut indiquer à l'opérateur grâce à l'interface IHM qu'aucune solution n'a été trouvée. De façon équivalent pour l'homme du métier, le compteur peut être initialisé à la valeur de ce seuil et décrémenté à chaque déclenchement de nouveau diagnostic. Le critère d'arrêt est alors le passage à 0 de ce compteur d'itération. Selon un mode de réalisation de l'invention, ce compteur d'itération peut influer sur la logique interne du module de réparation. Par exemple, dans la situation où cette logique interne est implémentée sous la forme d'un ensemble de règles, ces règles peuvent dépendre de la valeur du compteur d'itération. L'opérateur peut configurer ces dépendances en fonction des contraintes qu'il se fixe. Par exemple, sur un LSP sans importance, l'opérateur peut y associer un seuil d'itération élevé (notamment car le coût résultant est moindre que le déclenchement du module d'optimisation du trafic, dont nous 105480/SYC/IPD verrons le fonctionnement ultérieurement). Pour un LSP très important avec un SLA comportant des fortes pénalités, le seuil d'itération peut être très faible et l'opérateur souhaite avant tout maintenir le service même s'il faut déclencher le module d'optimisation du trafic. Éventuellement, si in fine, les diagnostics relèvent des problèmes plus graves sur le réseau de communication que ce qu'ils étaient à un moment donné, un mécanisme de retour arrière (bock Cracking) peut être mis en oeuvre pour revenir à cette configuration du réseau. Pour ce faire, le module de réparation contient un historique des actions correctives et/ou des commandes émises et des diagnostics reçus. Si lorsque le seuil est atteint, le nouveau diagnostic est moins bon que ce qu'il était pour une itération antérieure, alors le module de réparation peut utiliser cet historique pour faire revenir le réseau dans l'état correspond à cette itération. Il suffit de transmettre alors les commandes inverses pour rétablir cette situation antérieure. À défaut de résoudre véritablement la panne, cette mise en oeuvre permet un compromis en améliorant l'état du réseau. À l'issue d'un tel retour arrière, un message est envoyé à l'opérateur via l'interface homme-machine IHM pour lui indiquer que le problème n'a pas 20 pu être résolu et la situation du réseau. Selon un autre mode de réalisation, si un problème ne peut être résolu par le module de diagnostic, un module d'optimisation du trafic TE (ou Traffic Engineering, en langue anglaise) peut être utilisé. Le but de ce module d'optimisation du trafic est de rediriger le trafic afin qu'il évite le problème, plutôt que de résoudre véritablement le problème. Ainsi, si un problème au sein d'un routeur ne peut être résolu (un problème matériel, par exemple), le module TE peut modifier les tables de routage des autres routeurs, les LSP passant par ce routeur, etc. afin que plus aucun trafic ne soit dirigé vers ce 105480/SYC/IPD routeur. Ainsi, même si l'équipement en question demeure inopérant, le comportement du réseau peut devenir totalement opérationnel. Pour résumer, un diagnostic identifiant une panne peut aboutir à 4 conclusions: soit il a réparation, soit il n'y a pas réparation et l'opérateur est averti, soit il n'y a pas réparation mais déclenchement de l'outil d'optimisation du trafic, soit le module de réparation MR place le réseau dans l'état le moins mauvais en utilisant la fonction de retour-arrière et prévient l'opérateur. La figure 3 schématise le déroulement des étapes du procédé selon l'invention. Une première étape Diag consiste à déclencher la détermination d'un diagnostic. Cette étape est déclenchée, typiquement, à la suite de la réception d'une alarme du réseau de communication ou d'une plainte d'un client. Puis, le système détermine si le diagnostic identifie une panne (case P ? ). S'il n'y a pas de panne, le procédé s'arrête (case F1 ) S'il y a une panne, le procédé consiste à déterminer certains critères d'arrêts ( Stop ? ). II s'agit de déterminer si le nombre d'itération a atteint le seuil prédéfini, ou bien si le diagnostic correspond à un diagnostic déjà établi lors d'une itération antérieure. Si ces critères d'arrêts sont remplis, le système s'arrête (case F2 ). Si non, le procédé met en oeuvre une étape Rep consistant à 25 déterminer des actions correctives et à déployer des commandes associées à ces actions correctives vers le réseau de communication. Puis, selon une mise en oeuvre préférentielle de l'invention, une nouvelle étape de diagnostic Diag est déclenchée et le procédé repasse alors par les différentes étapes et tests décrits ci-dessus. 105480/SYC/IPD Le procédé forme alors un cycle de traitement, dont la résolution de la panne et la rencontre des critères d'arrêts lors des tests P ? et Stop ? , respectivement, permettent de sortir. L'invention et l'enchaînement de ses différentes étapes peuvent être rendus plus clairs au travers des 3 exemples de cas concrets suivants. Dans chacun de ces exemples le module de diagnostic est mis en fonctionnement par la réception d'alarmes du réseau de communication ou par une plainte d'un client. Dans un premier exemple, une plainte d'un client CC ou des alarmes A reçues du réseau de communication ont mis en évidence un problème au sein de ce réseau. Un premier diagnostic révèle que l'interface X d'un routeur Y est hors service ( down en anglais). Le module de diagnostic MD transmet ce diagnostic au module de réparation, avec une valeur de ticket et une valeur d'itération de 1. Le module de réparation MR détermine alors l'action corrective associée à ce diagnostic. L'action corrective est, dans cet exemple, de remettre l'interface X en service ( up en anglais). Une commande générique associée à cette action corrective est transmise au module de médiation MED, qui détermine la commande appropriée dans le langage propre au routeur Y. Le module de réparation MR transmet une demande de diagnostic CD au module de diagnostic MD, en précisant la même valeur de ticket. Le module de diagnostic MD refait un diagnostic du réseau de communication et détermine que l'interface X du routeur Y est effectivement opérationnelle ( up ) et que le réseau fonctionne normalement. II peut alors transmettre un diagnostic D au module de réparation pour signaler que le réseau fonctionne normalement. À la suite de quoi, le problème étant résolu, le module de réparation MR ne déclenche aucune action et le procédé de l'invention se termine. 105480/SYC/IPD Dans un deuxième exemple, le module de diagnostic détermine aussi que l'interface X du routeur Y est hors service ( down ) . De la même façon que dans le premier exemple, le diagnostic D est transmit au module de réparation avec un ticket, et le module de réparation MR détermine une action corrective. La commande générique associée à cette action corrective est transmise au module de médiation MED qui la convertit en une commande conforme au langage spécifique du routeur Y. Le module de réparation MR transmet une demande de diagnostic CD au module de diagnostic MD, avec le même ticket. Le module de diagnostic MD déclenche une nouvelle détermination de diagnostic. Le nouveau diagnostic D relève que l'interface X du routeur Y est toujours hors-service ( down ). Ce diagnostic D est transmis au module de réparation MR avec le même ticket, et une valeur d'itération égale à 2. Le module de réparation MR peut constater que bien que l'itération soit égale à 2, le problème demeure le même. Il peut alors décider de transmettre une commande au module d'optimisation du trafic TE (Traffic Engineering). Ce module d'optimisation du trafic TE peut alors modifier les chemins en place dans le réseau de communication afin que ceux-ci évite l'interface X du routeur Y. De cette façon, bien que l'interface en question soit hors-service, le réseau de communication pourra se comporter normalement. Dans un troisième exemple, le module de diagnostic MD détermine également que l'interface X du routeur Y est hors-service ( down ). Le diagnostic D est transmit au module de réparation avec un numéro de ticket et une valeur d'itération égale à 1. Comme précédemment, le module de réparation détermine la commande générique à transmettre au module de médiation MED qui la 105480/SYC/I PD convertit en une commande conforme au langage propre au routeur Y afin de mettre l'interface X en service ( up ). Le module de réparation MR transmet une demande de diagnostic CD au module de diagnostic MD, avec le même numéro de ticket. Le module de diagnostic déclenche alors une nouvelle détermination de diagnostic et il en ressort un nouveau problème, par exemple une mauvaise configuration du protocole de routage BGP (Border Gateway Protocol). Ce diagnostic D est transmis au module de réparation avec un numéro d'itération égal à 2 et la même valeur de ticket. Le module de réparation MR détermine alors les actions correctives adéquates, qui peuvent être ici de reconfigurer le protocole BGP. Des commandes génériques sont alors transmises au module de médiation MED qui les convertit en des commandes spécifiques. Une nouvelle fois, le module de réparation MR transmet une demande de diagnostic CD au module de diagnostic MD, en précisant le même numéro de ticket. II ressort du nouveau diagnostic D que la même interface X du routeur Y est hors-service ( clown ). Ce diagnostic D est transmis au module de réparation MR avec une valeur d'itération égale à 3 et toujours la même valeur de ticket. Le module de réparation peut constater que la valeur d'itération est égale à 3 et que le diagnostic est le même que celui de l'itération 1. Il peut alors déterminer qu'il est incapable de résoudre le problème et transmettre à l'interface homme-machine IHM une commande provoquant l'affichage d'un message exprimant cette incapacité ainsi que des informations relatives au diagnostic. On voit au travers de ces exemples, les différents modes de fonctionnement de l'invention, et notamment que par la configuration de la base de règles B, le module de réparation MR de l'invention peut adopter 105480/SYC/IPD différents comportements, comme avertir l'opérateur, déclencher un module d'optimisation du trafic, déclencher des commandes de réparation etc. 105480/SYC/IPD REVENDICATIONS 1) Système de gestion (NMS) d'un réseau de communication (N) comportant un module de diagnostic (MD) apte à déterminer un diagnostic (D) à partir d'informations (A) fournies par des éléments (N,, N2, N3, N4) dudit réseau de communication, ledit diagnostic identifiant une panne au sein dudit réseau de communication, ledit système étant caractérisé en ce qu'il comporte en outre un module de réparation (MR) agencé pour déterminer une ou plusieurs actions correctives à partir au moins dudit diagnostic reçu dudit module de diagnostic (MD) et pour transmettre une ou plusieurs commandes (C) correspondants à ladite ou auxdites actions correctives, à un ou plusieurs des éléments dudit réseau de communication, en vue de corriger ladite panne. 2) Système de gestion selon la revendication précédente, dans lequel ledit module de réparation (MR) est agencé pour transmettre une demande de diagnostic (CD) au module de diagnostic (MD) pour déclencher la détermination d'un nouveau diagnostic par ledit module de diagnostic. 3) Système de gestion selon la revendication précédente, dans lequel un compteur d'itération est incrémenté à chaque déclenchement d'un nouveau diagnostic, ledit système de gestion stoppant les modules de diagnostic et de réparation lorsque ledit compteur d'itération a atteint un seuil prédéterminé. 4) Système de gestion selon l'une des revendications précédentes, dans lequel la ou les commandes sont transmises par l'intermédiaire d'un module de médiation (MED) apte à transformer la ou lesdites commandes 105480/SYC/IPD formulées dans un langage générique, en des commandes spécifiques (C,, C2) conformes à des langages de commandes propres aux différents équipements dudit réseau de communication. 5) Système de gestion selon l'une des revendications 3 ou 4, dans lequel le module de réparation (MR) dispose d'un historique des diagnostics et des actions correctives déterminées à chaque itération et est apte à revenir à l'état du réseau de communication pour une itération donnée, si lorsque ledit seuil est atteint, le diagnostic est moins bon que ce qu'il était pour ladite itération donnée. 6) Système de gestion selon l'une des revendications précédentes, dans lequel ledit module de réparation est en outre agencé pour communiquer avec un module d'optimisation du trafic (TE) si des actions correctives ne peuvent être déterminées de façon satisfaisante pour corriger ladite panne, afin de supprimer ou limiter l'influence de ladite panne sur le comportement dudit réseau de communication. 7) Système de gestion selon l'une des revendications précédentes, 20 dans lequel ledit module de diagnostic (MD) met en oeuvre un réseau bayesien afin de déterminer ledit diagnostic. 8) Système de gestion selon l'une des revendications précédentes, dans lequel ledit diagnostic (D) contient au moins la désignation de ladite panne, la localisation de ladite panne, et éventuellement une estimation de la probabilité associée audit diagnostic. 9) Système de gestion selon l'une des revendications précédentes, dans lequel ledit module de diagnostic communique ledit diagnostic audit 30 module de réparation au moyen d'un message conforme au protocole SNMP. 105480/SYC/IPD 10) Système de gestion selon l'une des revendications précédentes, dans lequel ledit module de réparation dispose d'une base de règles de réparation. 11) Système de gestion selon la revendication précédente et la revendication 3, dans lequel lesdites règles peuvent dépendre dudit compteur d'itérations. 12) Procédé de gestion d'un réseau de communication (N) comportant une première étape de détermination d'un diagnostic (D) à partir d'informations (A) fournies par des éléments (N N2, N3, N4) dudit réseau de communication, caractérisé en ce qu'il comporte en outre une seconde étape de détermination, si ledit diagnostic identifie une panne, d'une ou de plusieurs actions correctives à partir au moins dudit diagnostic et de transmission d'une ou de plusieurs commandes (C) correspondants à cette ou ces actions correctives, à un ou plusieurs des éléments dudit réseau de communication, en vue de corriger ladite panne. 13) Procédé de gestion selon la revendication précédente, dans lequel ladite première étape est automatiquement déclenchée à l'issue de ladite seconde étape, afin de former un cycle de traitement. 14) Procédé selon la revendication précédente, dans lequel un compteur d'itération est incrémenté à chaque déclenchement d'un nouveau diagnostic, ledit cycle de traitement s'interrompant lorsque ledit compteur d'itération a atteint un seuil prédéterminé. 15) Procédé selon la revendication précédente, dans lequel un 30 historique des diagnostics et des actions correctives déterminées à chaque 105480/SYC/IPD itération est constitué et dans lequel si lorsque ledit seuil est atteint, le diagnostic est moins bon que ce qu'il était pour une itération antérieure, on revient à l'état du réseau de communication pour cette itération antérieure. 16) Procédé selon l'une des revendications précédentes, dans lequel la ou les commandes sont transmises par l'intermédiaire d'un module de médiation (MED) apte à transformer la ou lesdites commandes formulées dans un langage générique, en des commandes spécifiques conformes à des langages de commandes propres aux différents équipements dudit réseau de communication. 17) Procédé selon l'une des revendications précédentes, dans lequel une commande peut être transmise à un module d'optimisation du trafic (TE) si des actions correctives ne peuvent être déterminées de façon satisfaisante pour corriger ladite panne, afin de supprimer ou limiter l'influence de ladite panne sur le comportement dudit réseau de communication. 18) Procédé selon l'une des revendications précédentes, dans lequel ladite première étape met en oeuvre un réseau bayesien afin de déterminer 20 ledit diagnostic. 19) Procédé selon l'une des revendications précédentes, dans lequel ledit diagnostic (D) contient au moins la désignation de ladite panne, la localisation de ladite panne, et éventuellement une estimation de la probabilité associée audit diagnostic. 105480/SYC/IPD