FR 2823394 A1 20021011 FR 0104791 A 20010409 Point de décision d'autorisation modulaire pour traiter des requêtes de réservations de ressources, au sein d'un réseau de données La présente invention concerne la gestion de la qualité de service sur un réseau de données. Elle s'applique tout particulièrement aux réseaux de données permettant la fourniture de différents services, comme de la transmission de voix, de données, de vidéo etc. Un tel réseau peut par exemple être un réseau basé sur les protocoles de la famille TCP/IP (Transport Contro/Protocol/Internet Protoco), c'est-à-dire du type communément appelé Internet. Certains services nécessitent une réservation expresse de ressources au sein du réseau. En effet, certains réseaux, tels Internet, ont été prévus pour transmettre des données, mais ni de la voix, ni de la vidéo. Au sein d'Internet, les transmissions se font sous la forme de paquets, chaque paquet étant acheminé indépendamment des autres. Or, par exemple, la transmission de la voix et de la vidéo nécessite de minimiser la gigue, c'est-à-dire l'écart moyen entre deux paquets d'une même transmission, ainsi que le délai de transmission, ceci afin d'assurer un confort d'écoute ou de vision suffisant au destinataire de la transmission. Cette minimisation de la gigue et du délai se fait classiquement par la réservation de ressources dédiées au sein des noeuds de réseau (ou routers, selon la terminologie en langue anglaise communément utilisée). Toutefois, il est clair qu'il est nécessaire de contrôler ces réservations de ressources. Il faut en effet vérifier que le demandeur de la réservation de ressources a bien les autorisations suffisantes pour faire une telle requête, notamment s'il a souscrit à un abonnement suffisant d'utilisation du réseau. Eventuellement, ceci peut déboucher sur une gestion de priorité lorsque plusieurs requêtes en réservation de ressources sont incompatibles entre elles, par exemple, parce qu'elles nécessitent la réservation du même élément de réseau au même moment. Pour ce faire, les requêtes en réservations de ressources doivent aboutir à un gestionnaire d'autorisation, communément appelé point de décision d'autorisations, chargé de ce contrôle. La figure 1 schématise un exemple de réseau conforme à l'invention, et le contexte dans lequel s'inscrit un tel point de décision d'autorisation. Un utilisateur A désire créer une communication vocale avec l'utilisateur B, au travers d'un réseau de données N. L'utilisateur A est connecté au réseau N par l'intermédiaire d'un noeud d'accès RA (ou Edge router an anglais) et l'utilisateur B est connecté à ce même réseau N par le noeud d'accès Rg. La requête de réservation de ressources est acheminée à un point de décision d'autorisations M (ou PDP pour Policy Decision Point, selon le vocabulaire en langue anglaise consacré). Cette requête peut par exemple provenir directement de l'utilisateur A, selon la flèche référencée Ru, ou du noeud d'accès RA, suivant la flèche référencée R2. Si la requête provient de l'utilisateur, elle peut être par exemple conforme au protocole SIP (Session Initiation Protocol), conforme au RFC (Request for Comments) 2543 de l'IETF (Internet Engineering Task Force). Si la requête provient du noeud d'accès RAI elle peut être conforme au protocole COPS (Common Open Policy Service) selon le RFC 2748 de l'tETF publié en janvier 2000. Le rôle du point de décision d'autorisations M est alors : De vérifier que la requête peut effectivement être autorisée. Cette vérification peut par exemple être effectuée, d'une part compte tenu des ressources encore disponibles dans le réseau N, et d'autre part en tenant compte de l'abonnement souscrit par l'utilisateur A. . Le cas échéant, d'effectuer les réservations de ressources correspondant à la requête, auprès de chacun des noeuds concernés, dans le réseau N. Par conséquent, selon ce mécanisme, toute requête en réservation de ressource aboutit au point de décision d'autorisations M. Cela pose plusieurs problèmes : . Ce point de décision d'autorisation doit gérer des requêtes de réservation de ressources de nature différente (vidéo, voix...) et de caractéristiques différentes (faible débit/haut débit...). Il doit donc contenir toute la logique nécessaire à leur traitement, ce qui est pratiquement impossible compte tenu de l'évolution rapide des types de services disponibles sur ce genre de réseau. Lors d'une évolution du point de décision d'autorisations (livraison d'une nouvelle version), les éventuelles personnalisations ou paramétrages demandées par l'opérateur possesseur de ce point de décision d'autorisations ne peuvent pas être prises en compte. Le but de l'invention est de proposer une architecture pour un point de décision d'autorisations, permettant son évolution de façon aisée, et sa modularité. Pour ce faire, l'invention a pour objet un point de décision d'autorisations pour traiter des requêtes de réservation de ressources au sein d'un réseau de données. Ce point de décision d'autorisation se caractérise en ce qu'il comporte des moyens de communication avec des modules de gestion pour traiter les requêtes de réservation de ressources et, . des moyens pour transmettre chaque requête de réservation de ressources vers un ou plusieurs modules de gestion, suivant un ensemble de règles. Selon une mise en oeuvre de l'invention, une partie de cet ensemble de règles peut être transmise par les modules de gestion eux-mêmes, notamment lors d'une phase d'enregistrement de ces modules de gestion auprès du point de décision d'autorisation. L'invention a aussi pour objet un noeud d'accès à un réseau de données comportant un tel point de décision d'autorisation. Ainsi, il est possible d'ajouter, éventuellement de façon dynamique, des nouveaux modules de gestion. Il est aussi possible de conserver indéfiniment d'anciens modules de gestion, personnalisés pour ou par l'opérateur, tout en ne bloquant pas l'évolution du point de décision d'autorisations dans son ensemble. Un module de gestion est typiquement un code logiciel, mais il peut aussi s'agir d'un système complet constitué d'un système de traitement de l'information et d'un code logiciel s'exécutant dessus. L'invention et ses avantages apparaîtront de façon plus claire dans la description d'une mise en oeuvre qui va suivre, en liaison avec les figures annexées. La figure 1, déjà commentée, représente le contexte dans lequel s'inscrit le point de décision d'autorisations selon l'invention. La figure 2 schématise une mise en oeuvre d'un tel point de décision d'autorisations. La figure 3 illustre une mise en oeuvre alternative du point de décision d'autorisations selon l'invention. Selon la mise en oeuvre illustrée par la figure 2, le point de décision d'autorisations M reçoit des requêtes de réservation de ressources R, provenant d'un noeud d'accès RA, Ces requêtes de réservation de ressources sont par exemple conformes au protocole COPS évoqué précédemment. Toutefois, le mécanisme décrit serait similaire si la requête provenait des utilisateurs à l'origine des requêtes en réservation de ressources et/ou était conforme à un autre protocole (notamment SIP). Une autre possibilité, décrite plus loin, est d'intégrer le point de décision d'autorisations au noeud d'accès lui-même. Ce point de décision d'autorisations M dispose de moyens de communication avec un ensemble (éventuellement réduit à un singleton) de modules de gestion Al, AA3... An. Les requêtes de réservation de ressources sont réceptionnées par le point de décision d'autorisations M, dont le rôle est alors : . D'analyser le contenu des requêtes de réservations de ressources, * De déterminer lequel des modules de gestion doit traiter la requête, et de la lui transmettre. Il est possible qu'une requête de réservation de ressources soit dupliquée, par le point de décision d'autorisations, vers plusieurs modules de gestion. En effet, les règles utilisées par le point de décision d'autorisations pour déterminer les transmissions à effectuer peuvent être telles que plusieurs modules de gestion sont compétents pour traiter une même requête de réservations de ressources. Il est aussi possible qu'une requête de réservation de ressources soit modifiée, par le point de décision d'autorisations, avant transmission vers le ou les modules de gestion. Un exemple d'application est la simplification des requêtes de réservation de ressources, afin de simplifier le développement des modules de gestion. La requête de réservation de ressources telle que reçue par le point de décision d'autorisation, par exemple conformément au protocole COPS, décrit de façon très précise la qualité de service demandée (gigue, délai, débit...). Sa transmission vers le ou les modules de gestion peut faire l'objet d'une simplification, et la requête de réservation de ressources peut être présentée selon une échelle plus compréhensible des développeurs de modules de gestion. Cette échelle pourrait être du type : service platine, or, argent, bronze, normal, ou encore : interactif, audio haute fidélité, audio normal, vidéo normale, vidéo haute fidélité, etc. Dans le cas où une requête est transmise pour traitement à plusieurs modules de gestion, ce traitement peut éventuellement être fait en parallèle, notamment dans le cas où les résultats de l'un ne sont pas nécessaires au traitement d'un autre. Une autre possibilité est de réaliser le traitement de la requête en séquence, par les modules de gestion concernés. Autrement dit, selon cette mise en oeuvre, le point de décision d'autorisations attend la réponse d'un module de gestion, avant d'éventuellement transmettre la requête de réservation de ressources vers un autre module de gestion. Les règles utilisées par le point de décision d'autorisations pour déterminer vers quel (s) module (s) de gestion il va transmettre les requêtes de réservation de ressources, peuvent être fixées à l'avance, modifiée en cours de fonctionnement ou bien indiquées par les modules de gestion eux-mêmes. Comme dit précédemment, il peut être prévu que les modules de gestion puissent s'enregistrer auprès du point de décision d'autorisations M, en cours de fonctionnement de celui-ci. Auquel cas, lors de l'enregistrement d'un nouveau module de gestion auprès du point de décision d'autorisations M, ce nouveau module peut indiquer un ensemble de règles qui seront utilisées par le point de décision d'autorisations M pour déterminer quelles requêtes de réservation de ressources doivent lui être transmises. Ces règles peuvent être : La précision de la nature du trafic concerné. Un module de gestion peut n'être apte qu'à traiter un certain type de trafic : vidéo, voix etc. Comme dit précédemment, ce type de trafic peut impliquer des modes de traitement particulier par les éléments de réseau et donc des politiques de réservation de ressources spécifiques (prise en compte de la minimisation de la gigue, par exemple). La précision d'une (ou plusieurs) caractéristiques de qualité de service. Un module de gestion peut être plus particulièrement prévu pour traiter les requêtes de réservation de ressources correspondant à des caractéristiques de qualité de services particulières (débit etc. ), et les problèmes de réservation de ressources particuliers qui s'y rattache. La précision d'un temps de réponse du module de gestion. Certains modules de gestion peuvent être architecturés de sorte que leur temps de réponse (c'est-à-dire le temps entre la réception de la requête de réservation de ressources et, le cas échéant, la réservation effective des ressources) soit garanti inférieur à un seuil, ou bien présente des performances moyennes d'une certaine valeur, etc. En ce cas, les modules de gestion peuvent préciser ce seuil ou cette valeur moyenne, au point de décision d'autorisations M. Précision d'une zone topologique Un autre exemple est la précision, par des modules de gestions, d'une zone topologique du réseau qu'ils peuvent traiter. Cette zone topologique peut par exemple être un domaine du réseau de télécommunication, ou bien un ensemble d'éléments de réseau défini par leur appartenance à une même zone géographique. . La précision d'un identificateur d'un module de gestion. On peut prévoir que les requêtes de réservation de ressources contiennent un identificateur (appelé jeton ) du module de gestion à utiliser. Ceci peut par exemple être intéressant dans le cas où une corrélation doit être recherchée entre plusieurs requêtes (par exemple une requête conforme au protocole COPS et une requête conforme au protocole SIP), et qu'il est important que ces deux requêtes soient traitées par un seul et même module de gestion. En addition de ces règles, le point de décision d'autorisations peut disposer d'un mécanisme de priorité ou d'ordonnancement lui permettant de choisir le ou les module (s) de gestion vers lequel envoyer chaque requête de réservation de ressources. Par exemple, il peut disposer d'un ordre d'invocation. En effet, comme dit précédemment, pour une même requête de réservation de ressources, il peut exister plusieurs modules de gestion à même de la traiter. Cet ordre d'invocation permet alors d'établir des priorités entre ces différents modules de gestion, et de choisir vers quel module de gestion, la requête de réservation de ressources sera envoyée en premier. Les modules de gestion Al, A2, Ag... A sont à même de traiter les requêtes de réservation de ressources qui leur sont transmis et qui, donc, correspondent à des règles leur correspondant. La façon exacte dont un module de gestion décide ou non d'accepter une requête en réservation de ressources n'entre pas dans l'objet de l'invention, et peut être conforme à tout système de gestion de ressources de l'état de l'art. A titre d'exemple, on peut citer le cas où les modules de gestion effectuent une corrélation entre la requête de réservation de ressources (typiquement conforme au protocole COPS) et une requête pour réserver un canal de voix, par exemple selon le protocole SIP, afin de vérifier que ce qui est décrit dans la première requête avait bien été dit aussi dans la seconde requête. Les modules de gestion ayant reçus une requête de réservation de ressources peuvent décider de l'autoriser ou de l'interdire, ou bien encore de refuser de se prononcer (ce qui correspond au cas où, finalement, le module de gestion en question n'était pas vraiment compétant pour décider de cette requête de réservation de ressources). Le point de décision d'autorisations M a alors la tâche d'éventuellement fédérer les réponses des modules de gestion, lorsqu'une même requête de réservation de ressources a été transmise à plusieurs modules de gestion. Typiquement, ce point de décision d'autorisation peut simplement attendre d'avoir une (et une unique) réponse autorisant la requête pour transmettre une réponse d'autorisation vers le noeud d'accès RA, La référence CM, sur la figure 2, représente le moyen de communication utilisé pour permettre la communication entre d'une part le point de décision d'autorisations M et d'autre part les modules de gestion Al, A2, A3--. An- Ce moyen de communication peut par exemple être un bus logiciel comme CORBA (Common Object Request Broker Architecture) de l'OMG (Open Management Group) ou COM (Component Object Model) de la société Microsoft. L'utilisation d'un tel bus logiciel permet, entre autres, de mettre en oeuvre l'ajout de nouveaux modules de gestion en cours de fonctionnement, évoqué précédemment. D'autres mises en oeuvre sont possibles, comme notamment la possibilité d'utiliser un protocole inspiré de COPS pour permettre aux modules de gestion et au point de décisions d'autorisations de communiquer ensemble. La figure 3 illustre une mise en oeuvre alternative de l'invention. Selon cette mise en oeuvre, le point de décision d'autorisations M est inclus dans le noeud d'accès RA lui-même. Il dispose alors de moyens de communication avec des modules de gestion Al, A2, A3... An qui peuvent alors être implémentés sur d'autres systèmes de traitement de l'information ou bien éventuellement eux aussi dans le même noeud d'accès RA. REVENDICATIONS 1) Point de décision d'autorisations (M) pour traiter des requêtes de réservation de ressources (R) au sein d'un réseau de données, caractérisé en ce qu'il comporte des moyens de communication avec des modules de gestion (A1, A2, A3... An) pour traiter lesdites requêtes de réservation de ressources et des moyens pour transmettre chaque requête de réservation de ressources vers un ou plusieurs modules de gestion, suivant un ensemble de règles. 2) Point de décision d'autorisations selon la revendication précédente, dans lequel les modules de gestion sont prévus pour transmettre audit point de décision d'autorisation (M) une partie le concernant dudit ensemble de règles. 3) Point de décision d'autorisations selon l'une des revendications 1 ou 2, comportant un moyen pour permettre l'enregistrement d'un nouveau module de gestion, en cours de fonctionnement. 4) Point de décision d'autorisations selon les revendications 2 et 3, dans lequel ledit nouveau module de gestion transmet audit point de décision d'autorisations ladite partie le concernant de l'ensemble de règles, lors de l'enregistrement. 5) Point de décision d'autorisations selon l'une des revendications 1 à 4, dans lequel lesdits moyens de communication comprennent un bus logiciel (CM), comme CORBA ou COM. 6) Point de décision d'autorisations selon l'une des revendications précédentes, dans lequel les moyens pour transmettre les requêtes de réservation de ressources sont aptes à modifier lesdites requêtes de réservations de ressources, notamment en les simplifiant. 7) Noeud d'accès à un réseau de données, caractérisé en ce qu'il comporte un point de décision d'autorisation selon l'une des revendications précédentes.