Brevet FR2835674A1 — publié le 20030808

Déploiement des règles par un dispositif de gestion de services, en fonction d'informations sur les équipements du réseau La présente invention est relative à la gestion de réscaux de données, tels les réscaux de télécommunication, et à la gestion de services mis en _uvre sur ces réssaux. El le concerne plus particulièrement la gestion de services par règles de politique (policy rales, en anglais) et un dispositif et un procédé pour faciliter la mise en _uvre de ces règles de politique (appelées aussi, plus simplement, règles, dans la suite). Les réseaux de donnces peuvent mehre en _uvre des services très divers, nacessitant des fonctionnalités très diverses des éléments de réseau. Une des fonctions de la gestion de réseau consiste à déterminer les éléments de réseau qui peuvent mettre en _uvre ces services, en fonction des fonctionnalités requises par les services et des fonctionnalités offertes par chacun des éléments de réseau. La figure 1 illustre une situation classique. Un terminal X est lié à un réseau d'accès NA et veut établir une session de service avec un terminal Y lié à un réssau c_ur NC. Quatre routeurs, A, B. C et D permettent de relier le réseau d'accès NA au réseau c_ur NC. Chaque routeur peut mettre en _uvre un ensemble limité de fonctionnalité. Le routeur A peut mettre en _uvre les fonctionnalités F7 (par exemple, de la qualité de service), F2 (par exemple, de la sécurisation de transmission de type " Firewall >>) et F3 (par exemple, de la cryptographie des données transmises). Le routeur B peut mettre en _uvre des fonctionnalités F7 et F2. Le routeur C peut mettre en _uvre les fonctionnalités F7 et F4 (par exemple, de la traduction d'adresses de type NAT (Network Address Translafion)). Enfin, le routeur D peut mettre en _uvre les fonctionnalités F7 et F2. 1 04069/SYC/NNAD \\kleTilO 1 \DPI$\Salle\F1 04069\PREA4DEP\Fll\projelbr.doc / Afin de mettre en _uvre ce service, il faut donc déterminer quel routeurs vont être utilisé pour véhiculer le flot de donnces entre les terminaux X et Y. Ce choix doit étre fait en com pa ra nt l es fonction nalités req uises pa r le service (par exemple, F, F2 et F4), et les fonctionnalités offertes par les routeurs. Dans la situation illustrée par l'exemple, on a donc deux possibilités: soit on choisit les routeurs C et B. soit on choisit les routeurs C et D. Selon l'état de la technique, ce choix est fait par un opérateur, par comparaison visuelle des fonctionnalités requises par le service et d'une carte topologique du réseau, qui comporte les fonctionnalités offertes par les routeurs. Une fois le choix établi, il doit étre informations nocessaires à la mise en place de ce service. Ainsi, si les routeurs C et B sont choisis, il faut transmettre à ces routeurs les informations nocessaires pour remplir les fonctionnalités requises par le service, c'est-à-dire F., F2 et F4. Cette phase d" peut être effectuce par la transmission de règles approprises. Par exemple, la fonctionnalité requise F2 peut déclencher la transmission au routeur B d'une règle consistant à ne laisser passer les flots de données qu'uniquement entre 8hOO et 1 9hOO. Actuellement, les dispositifs de gestion de service ne permettent pas de mettre facilement en correspondance les fonctionnalités offertes par les équipements de réssau et les fonctionnalités requises par les services. La phase de comparaison manuelle est pénalisante dans la mesure o d'une 1 04069/SYC/NNAD \\klelilO1\DPl$\Salle\F1 04069\PREMDEP\FIT\projetbr.doc part, elle est coûteuse en temps et d'autre part, elle est sujette à erreurs de la part de l'opérateur. De la méme facon, il n'existe pas de mécanisme simple de mise en correspondance des fonctionnaiités requises par ies services et ies règies a mettre en _uvre sur les équipements de réseau. Le but de l'invention est de pallier ce manque de l'état de la technique. Plus précisément, I'invention a pour objet un dispositif de gestion de services pour permettre le déploiement de règles sur un ensemble d'éléments d'un résaou de données, notamment de télécommunication, ces règles permettant la mise en _uvre de services. Ce dispositif de gestion de services se caractérise en ce qu'il dispose de moyens d'accès à une base de donnses contenant des informations relatives à l'ensemble d'éléments de réscau, et en ce que le déploiement est fonction de ces informations. Selon une mise en _uvre de l'invention, le dispositif de gestion de services comporte de surcro^'t des moyens pour stocLer les informations dans la base de donnces, à partir de données contenues dans des messages d'enregistrement rec,us d'éléments de réscau. Ces messages d'enregistrement peuvent par exemple être transmis par l'intermédiaire de point de décision de règles. Ainsi, la mise en correspondance peut étre faite de facon automatique par le gestionnaire de règles. Cela permet donc de masquer à l'opérateur, toutes les informations relatives au réscau, à sa topologie et aux fonctionnalités offertes par chacun de ses éléments. La tache de l'opérateur et donc grandement facilitée et les risques d'erreurs réduit au minimum. 104069/SYC/NNAD \\klefilOl\DPl$\Salle\Fl04069\PREMDEP\FIT\projelbr.doc L'invention et ses avantages appara^'tront de façon plus claire dans la description qui va suivre en liaison avec les figures annexées. La figure l, déjà commentée, illustre un exemple de réseau de données. La figure 2 représente de fac,on schématique, le contexte dans lequel peut s'insérer le dispositif de gestion de services de l'invention. La figure 3 est un diagramme UML représentant le modèle qui peut être utilisé par le dispositif de gestion de services. Sur la figure 2, on a représenté deux terminaux X et Y connectés, respectivement, à un réscau d'accès NA et à un réseau c_ur NC. Les deux réseaux NA et NC sont eux-mêmes connectés par l'intermédiaire de 4 routeurs, A, B. C, D, connectés entre eux. Au moins ces 4 éléments de réseau sont associés à un gestionnaire de règles PM, par l'intermédiaire d'un point de décision de règles PDP (pour Policy Decision Point, en anglais). Le gestionnaire de règles PM (pour Policy Manager, en anglais) peut faire partie d'un dispositif de gestion de services plus important. En pratique, ce gestionnaire de règles peut n'être qu'une fonctionnalité du dispositif de gestion de services, ou bien être un module indépendant qui, avec d'autres modules indépendants, participe à ce dispositif de gestion de services. De même, le gestionnaire de règles PM peut être directement connecté aux éléments de résaou A, B. C et D, c'est-à-dire sans l'intermédiaire du point de décision de règles PDP. Lors de la mise en marche du réscau, ou tout du moins d'un ou plusieurs des éléments de réseau le constituant, les éléments de réseau adressent des messages d'enregistrement au point de décision de règles PDP. 104069/SYC/NNAD \\klefilOl\DPl$\Salle\Fl04069\PREMDEP\FIT\projelbr.doc Selon une mise en _uvre de l'invention, ces messages d'enregistrement contiennent des données relatives aux capacités des équipements de réssau. Il peut par exemple s'agir: 5. de la version du logiciel embarqué par l'équipement, de la version du matériel de l'équipement, Ie nombre d'interfaces de l'équipement, etc. Le point de décision de règles PDP collecte ces donnces et les transmet au gestionnaire de règles PM, avec des informations le concernant, comme par exemple son adresse IP (Internet Protocol). Le gestionnaire de règles PM ou le dispositif de gestion de service le contenant, mémorise alors ces données dans une base de données DB. Une des fonctions principales du gestionnaire de règle PM est de déployer des règles vers les éléments de réseau, le plus souvent par l'intermédiaire de points de décision de règles. Selon l'invenJion, le gestionnaire de règles dispose de moyens d'accès à la base de données DB qui contient les informations relatives aux éléments de réseau. Ces informations ont pu être mémorisés selon le procédé décrit ci dessus consistant à faire remonter des donnces par les messages d'enregistrement issus des éléments de réseau, ou par tout autre moyen (notamment manuellement, lors de la configuration du réseau). Selon l'invention, le déploiement des règles est fonction de ces informations. Ainsi, afin de déterminer quelles règles doivent être transmises à quels éléments de réscau, le gestionnaire de règles PM consulte les informations contenues dans la base de données DB. Cette détermination peut notamment 8tre réclisée par la mise en correspondance: 1040 69/SYC/N NAD \\klefi lO 1 \DPI $\5cl le\F 1 04069\PREMD EP\FIT\proj elbr. doc Des fonctionnalités offertes par les éléments de résacu (c'est-à dire, les informations contenues dans la base de donnces DB), Des fonctionnalités requises par le service à mettre en _uvre, et Des fonctionnalités nécessaires aux règles. Par cette mise en correspondance, le gestionnaire de règles PM est à même de déterminer de facon automatique, les règles approprices à la mise en _uvre du service en question, et de la façon dont elles doivent 8tre déployées. La figure 3 illustre, sous la forme d'un schéma UML (Unified Modeling Language), cette mise en correspondance. Un tel schéma peut être compris par l'homme du métier pour la réclisation d'un programme d'ordinateur capable de mettre en _uvre l'invention au sein du gestionnaire de règles PM. Ce schéma UML est composé de différentes bo'^tes, chacune représentant une classe d'objets. La classe " PolicyRule " représente les règles de politique. Elles peuvent être conformes au RFC 3060 de l'IETF (Internet Engineering Task Force), intitulé > et publié en février 2001. Ces règles peuvent être stocLées dans une base de données, non représentée sur la figure 2. A chaque règle est associé un ensemble de paramètres: un drapeau indique si la règle est validée, une priorité, une liste de conditions, une liste d'actions à déclencher De ces paramètres, on peut tirer les fonctionnalités nécessaires pour mettre en _uvre chaque règle. Ces fonctionnalités nécessaires sont représentées par la classe En effet, chaque règle est associce à au moins une condition et au moins une action. Afin de mettre en _uvre cette action, et même pour déterminer la condition, I'élément de réseau doit posséder les fonctionnalités nécessaires. Ainsi ne peut-on pas, par exemple, mettre en _uvre une règle de traduction d'adresses de type NAT (Network Address Translation) sur un routeur ne posséJant pas de fonctionnalités NAT. 1 04069/SYC/NNAD \\klelil O 1 \DPI $\Salle\F 1 04069\PREMD EP\FIT\proj elbr.doc Par ailleurs, la classe " Required Capability>> représente les fonctionnalités requises pour la mise en _uvre des services. La classe > représente les profils des différents éléments de réseau. Elle peut contenir un ensemble de paramètres associés à ces éléments de réseau. De ces paramètres, on peut tirer les fonctionnalités offertes par les éléments de réscau. Ces fonctionnalités offertes sont représentées par la classe . Les trois classes " Device relatod Capability >>, " Required Capability >> et correspondance décrite précédemment. Ainsi, la relation entre les classes > et > peut permettre de déterminer, pour un service donné, quels sont les éléments de réseau qui peuvent les mettre en _uvre. La relation entre les classes > peut alors permettre de déterminer quelles règles doivent être déployées vers ces éléments de réseau. .. 104069/SYC/NNAD \\klefilOl\DPl$\Sclle\F104069\PREMDEP\FIT\projelbr.doc REVENDICATIONS 1) Dispositif de gestion de services (PM) pour permettre le déploiement de règles sur un ensemble d'éléments (A, B. C, D) d'un réseau de données, notamment de télécommunication, lesUites règles permettant la mise en _uvre de services, caractérisé en ce qu'il dispose de moyens d'accès à une base de donnéss (DB) contenant des informations relatives audit ensemble d'éléments de résaou, et en ce que le déploiement est fonction desUites informations. 2) Dispositif de gestion de services selon la revendication 1, comportant de surcro^'t des moyens pour stocLer lesHites informations dans ladite base de données, à partir de données contenues dans des messages d'enregistrement reçus d'éléments de réseau. 3) Dispositif de gestion de services selon la revendication 2, dans lequel lesUits messages d'enregistrement sont transmis par l'intermédiaire de point de décision de règles (PDP).