Brevet FR2835987A1 — publié le 20030815

central de commutation. 1 2835987 CONTROLE D'ADMISSION A UN RESEAU DE DONNEES POUR L' ASSURANCE DE LA QUALITE DE SERVICE La présente invention concerne la gestion de la qualité de service sur un réscau de donnces. Elle s'applique tout particulièrement aux réseaux de donnces permettant la fourniture de di*érents services, comme la transmission de la voix, de données, vidéo, etc. Un tel réseau peut par exemple être un réseau basé sur les protocoles de la famille TCP/IP (Transporf Control Protocol / Internet Protocol), c'est à dire du type communément appelé Internet. Certains services nacessitent une réservation expresse de ressources au sein du résacu. En effet, certains réscaux, tels Internet, ont été prévus pour transmettre des donnces, mais ni de la voix, ni de la vidéo. Au sein d'lnternet, les transmissions de données sont effectuées sous la forme de paquets, chaque paquet étant acheminé vers sa destination indépendamment des autres paquets. Chaque paquet est classiquement identifié par un entête IP, un 5-tuple: protocole utilisé, adresse et port de I'émetteur, adresse et port du destinataire. L'entête Ip peut comprendre d'autres informations plus spécifiques, concernant le paquet lui-même (longueur). On entend habituellement par microllux, un ensemble de paquets qui ont le même 5-tupie ou au moins le même 4-tuple. En effet, I'entête IP peut ne pas comporter 1'identification du port de 1'émetteur. Dans la suite, le terme microflux englobe ces deux possibilités. On entend par flux, un ensemble de paquets ou de microilux qui ont au moins un paramètre commun de l'entête IP. Pour transmettre des flux de paquets correspondant à de la voix ou des images par de tels réscaux, il est nocessaire de rébuire le taux de pertes des paquets ainsi que le délai de transmission, afin d'assurer un confort L 2 2835987 d'écoute ou de vision suffisant au destinataire de la transmission. Cette minimisation du taux de perte de paquets et du délai de transmission se fait classiquement par la réservation de ressources internes au sein des n_uds du réseau (ou routeurs). En pratique, et de manière résumée, le terminal qui souhaite une certaine qualité de service pour un flux déterminé, transmet une requête en qualité de service pour ce flux, avant d'envoyer les paquets correspondants. Généralement, la requête en qualité de service est une requête en réservation de ressources, par exemple conforme au protocole RSVP (ReSerVation Protocol), tel que défini par le RFC 2205 de 1'IETF (Internet Engineering Task Force). Selon ce protocole RSVP, chaque routeur recevant une requête en réservation de ressources doit, dans un premier temps, vérifier qu'il dispose des ressources demandées et acheminer la requête selon des algorithmes de routage classique. La requête en réservation de ressources parcourt ainsi un chemin qui sera normalement celui des paquets du flux concerné, jusqu'au destinataire. Ce dernier transmet alors une réponse à l'émetteur initial qui va remonter le chemin inverse. Lors de ce second passage, chaque routeur doit effectivement réserver les ressources demandées. Avec un tel protocole, chaque routeur doit assurer la maintenance du contexte de traitement correspondant à la requête en qualité de service pour laquelle il a été sollicité. Notamment, si un routeur du réseau traite quatre flux, il doit gérer quatre files d'attente correspondantes, une par flux. L'architecture DiffServ (Differentiated Services model) telle que déTinie par le RFC 2475 de 1'IETF offre un mécanisme de réservation de ressources différent. Ce mécanisme est basé sur un marquage de priorité des paquets des flux IP. Selon cette architecture, la gestion de la qualité de service est mise en _uvre par l'affectation de priorités, appelées, dans ce contexte, couleurs, à chaque paquet d'un flux. Les paquets ainsi colorés doivent être 3 2835987 traités selon leur priorité par le routeur qui les reçoit. Le routeur n'a plus à gérer de files d'attente par flux, mais une seule file d'attente. En pratique, les niveaux de priorité correspondent généralement à la nature du flux. Un trafic voix devrait avoir la précédence la plus forte, appelée "Expeditod Forwerding" dans l'architecture Diffserv, tandis qu'un trafic Web devrait avoir la précédence la plus faible, appelée "Best Effort" dans l'architecture Diffserv. En pratique, les solutions RSVP et DiffServ se complètent, en sorte que les architectures réseaux de l'état de la technique mettent généralement en _uvre les deux protocoles simultanément, afin de tirer parti de leurs avantages respectifs. Un exemple de mise en _uvre d'une telle architecture de l'état de la technique est représenté sur la figure 1. Une description d'un tel état de l'art peut être trouvée dans le RFC 2998 intitulé "A Framework for Integrated Services Operation over Diffserv Networks". Le réseau de donnses N comporte des routeurs R, R2, R3, R4, R5, R6. Certains de ces routeurs sont des routeurs frontières (Edge Routers, dans la littérature anglo-saxonne) R., R2, R3, c'est à dire qu'ils disposent de moyens de communication avec des terminaux, des applications bureautiques ou des routeurs extérieurs à ce réseau de donnces N. Les autres routeurs R4, R5, R6 sont des routeurs internes, qui ne disposent de moyens de communication qu'avec d'autres routeurs internes du réseau de données N. Le réscau peut comporter, outre les routeurs frontières, d'autres types d'équipements frontières. il peut par exemple s'agir de passerelles dont la fonction est de transmettre et mettre en forme des flux, sans pour autant faire de routage IP (Internet Protocol). Selon cet état de l'art, les équipements frontières (routeurs, passerelles,...) peuvent mettre en oeuvre le protocole RSVP, tandis que les routeurs internes mettent principalement en _uvre le mécanisme Diffserv. Mais on peut aussi avoir certains routeurs internes qui mettent en _uvre le 4 2835987 protocole RSVP, seul un réscau noyau mettant en _uvre le protocole Diffserv. On peut aussi avoir des résacux "tout" Diffserv. Dans un réscau tel que représenté sur la figure 1, si un terminal T7 initie un flux qui nécessite une certaine qualité de service, avec le terminal T3, par exemple une communication vocale qui nocessite entre autres un délai de transmission minimal, il émet une requ8te en réservation de ressources selon le protocole RSVP. Cette requête en réservation de ressources est reçue puis traitée par l'équipement frontière R7. Ce dernier vérifie qu'il dispose effectivement des ressources internes nocessaire (bande passante notamment) pour fournir la qualité de service demandée. Il vérifie notamment que l'agrégation actuelle des flux à sa sortie permet d'accepter ce nouveau flux. Le cas échéant, I'équipement frontière R7 peut transmettre une réponse au terminal T7 lui indiquant que la réservation de ressources a été effectivement réclisée. Le terminal T7 transmet alors les paquets du flux vers le terminal destinataire T3. Conformément au mécanisme Diffserv, le routeur R7 marque chacun des paquets du flux qu'il reçoit, avec la précédence affectée au flux, en fonction de la requête en réservation de ressources précédemment reçue. C'est le point code ("Code Point" dans la littérature anglosaxone). Les paquets sont acheminés au sein du réseau de données N. au travers des routeurs R7, R4, R5, R6 et R3 Le routeur R3 transmet alors le flux de paquets au terminal T3 et la requête en qualité de service selon le protocole RSVP est transmise à ce terminal T3. Plus généralement, chacun des routeurs du réseau reçoit des paquets qui peuvent correspondre à di*érents flux initiés dans le résacu N. Tous ces paquets sont marqués d'une précédence, selon le mécanisme Di*serv. 2835987 Chaque routeur traite les paquets qu'il recoit en fonction des précédences (comme "Expeditod Forwarding", "Best Effort",...) qui leur sont affectées. Cette solution de l'état de l'art présente un problème, puisque la vérification des ressources disponibles n'est effectuée que par les équipements frontières. Si deux requ8tes en qualité de service sont par exemple initiées sur deux équipements frontières distincts, il peut en résulter, pour un routeur interne du réseau, une impossibilité de satisfaire la qualité de service demandée. Les deux requCtes en qualité de service pourront 8tre accordées, alors qu'une ou même les deux, ne pourront être satisfaites. En outre, le nombre de niveaux de précédence qui peuvent être accordées selon le mécanisme Diffserv est limité. Ainsi, tous les flux correspondant à du trafic voix auront généralement la même précédence Diffserv, typiquement, la précédence appelée "Expeditod Forwarding". Ainsi, chaque routeur traitera les paquets de type "qualité voix" avec la même précédence. Si un problème de congestion arrive sur un routeur recevant plusieurs flux de ce-type, il s'en suivra la dégradation arbitraire de la qualité de service pour au moins l'un de ces flux. Pour illustrer ce problème, si on revient au réseau N représenté sur la figure 1, dans le cas o le terminal T2 initie une deuxième requ8te en qualité de service auprès de l'équipement frontière R2 pour un nouveau flux de paquets. Cette deuxième requête fait l'objet du même traitement que la requ8te initice par le terminal T, et est de même, destinée au terminal T3. Ce nouveau flux de paquets initié par le terminal T2 suit un chemin R2, R6, R5 et R3, jusqu'au terminal T3. Une partie de ce chemin, R5, R3 est commune avec le chemin emprunté par le flux de paquets issu du terminal T. Si l'on se place dans le cas d'une configuration économe du réseau, les liens R5-R3 auront été dimensionnés de facon à accepter un certain - 6 2835987 volume de communications simultances, volume qui en pratique ne devrait étre dépassé que dans des situations statistiquement rares. Ainsi, si la somme des débits des deux flux de paquets initiés par les terminaux T et T2 est supérieure au débit maximum possible sur le chemin R5-R3, le routeur R5 ne sera pas en mesure de satisfaire la qualité de service demandée par au moins l'un des terminaux T ou T2. Comme les deux flux se sont vus attribuer des précédences Diffserv, "Expedited Forwurding", ces deux flux de paquets seront dogradés. Il résulte de ce mécanisme qu'il peut y avoir un écart significatif entre 1a qualité de service demandée par les terminaux et acceptée par le réseau et celle effectivement fournie, due à une congestion du trafic au niveau d'un n_ud interne. Une solution est d'ovoir un serveur qui va mettre en _uvre des calcuis (des algorithmes) afin de déterminer les congestions au sein du réseau et d'accepter ou non une nouvelle demande de flux. Dans la présente invention, on se place dans le cas o il existe de tels réscaux avec un serveur de ce type, apte à déterminer si l'acceptation d'un nouveau microflux pourrait entraner une congestion sur au moins un n_ud du réseau. Le but de la présente invention est alors de déterminer quel microflux devrait étre arrété ou refusé dans le réseau, pour empécher la congestion. Si un microllux déjà initié dans le réscau est arrété, on libère des ressources internes, ce qui peut permettre d'accepter un nouveau microflux. Ou bien, le nouveau microllux est refusé. Selon l'invention, un mécanisme d'affectation d'une priorité logique à chaque microflux est mis en _uvre par l'application demandeuse de qualité de service. Cette priorité logique permet à chaque réscau concerné par le transport d'un microilux, de mettre en _uvre une logique de préemption de microllux, dans un contrôleur d'admission associé. - - De cette façon, on peut concevoir des réseaux de données de façon économe, basce sur une analyse statistique des flux à traiter, avec une gestion optimum de la qualité de service. Plus précisément, I'invention a pour objet un système de contrôle d'admission dans un réseau posséJant un certain nombre d'équipements frontières pour recevoir des microllux à transmettre dans ledit réseau, système caractérisé en ce qu'une application demandeuse de qualité de service pour la transmission d'un microflux dans le réseau comprend des moyens d'affectation d'une priorité logique au dit microflux, ledit réseau comprenant un contrôleur d'admission comportant des moyens pour recevoir une requête en qualité de service associée au dit microflux à transmettre et la priorité logique qui lui a été affectée et des moyens pour accepter ou interdire ladit microllux. Les moyens pour accepter ledit microflux comprennent des moyens de détermination d'un ordre de préemption de microflux dans le réseau, en fonction de leur priorité logique, pour libérer des ressources internes du réseau dans le but d'assurer la qualité de service demandée par ledit microflux par prcemption de microflux de priorité logique plus basse. Dans une mise en _uvre de l'invention, le contrôleur d'admission associé à un réseau détermine selon ses règles de préemption, le ou les microflux à préempter et en informe l'application. Dans une autre mise en _uvre de l'invention, le contrôleur d'admission est apte à collaborer avec ladite application, pour la détermination des flux à préempter, en lui fournissant une liste de microflux qui pourraient être préemptés. Selon l'invention, pour chaque réscau qu'un microllux va traverser, le contrBleur d'admission associé à ce réseau est informé par le contrôleur d'admission associé au réseau précédent de la priorité logique qui a été affectée au microflux. j 8 2835987 Ainsi, por l'utilisation dun contrBleur d'admission selon l'invention, un nouveau microflux peut n'être admis dans le réseau que si la qualité de service demandée peut effectivement être satisfaite, en interrompant, si nécessaire, par un mécanisme préemption, un ou des microflux de paquets déjà initiés dans le réseau, affectés d'une priorité logique plus basse. On peut ainsi éviter tout sur-approvisionnement des ressources du résaou de donnces, et obtenir des architectures économes, basoes sur leur utilisation statistique. L'invention et ses avantages vont être décrits de facon plus claire dans la description suivante de mises en _uvre, en relation avec les dessins annexés dans lesquels: - la figure 1, déjà commentée, représente une architecture réseau de l'état de la technique, mettant en _uvre des mécanismes de réservation de ressources; - la figure 2 illustre le principe général d'un système de contrôle d'admission selon l'invention; la figure 3 illustre un premier exemple de mise en _uvre de l'invention dans un réseau d'architecture de type tout Diffserv; - la figure 4 illustre une variante du mécanisme de contrBle d'admission pour cette architecture réseau; et - la figure 5 illustre un deuxième exemple de mise en _uvre de l'invention, pour une architecture réscau de type mixte RSVP/Diffserv. La figure 2 représente de facon schématique, le principe de contrBle d'admission effectué sur un microllux A émis par un émetteur, qui peut être un terminal quelconque, une application de bureautique, un routeur externe..., à transmettre à travers un premier réssau de donnces N et un deuxième réseau de données N2. Chaque réseau de données N comporte 9 2835987 un ensemble d'équipements frontières et de ressources internes (non représentéss), pour transmettre le microllux. Selon le principe général de l'invention, I'émetteur du microflux A transmet une requête de service Req [A] vers une application AP. Selon I'invention, I'application lui affecte un niveau de qualité de service et un niveau de priorité logique. Par exemple, s'agissant d'un trafic voix, émanant d'un poste identifié comme de la plus haute importance (par exemple, du Directeur d'une société), I'application AP va affecter un niveau de priorité logique très élevé, noté *** dans l'exemple. Cette application transmet alors la requête en qualité de service QoS [A], ***, et la priorité logique qu'elle a affecté au contrôleur d'admission AC du premier réssau. Si ce contrôleur d'admission comprend des moyens de détection de congestion dans le réseau N ets'il a calculé qu'il va y avoir une congestion, il va soit refuser le microll ux A, soit l'a utoriser ma is en arrêta nt d'autre(s) microflux déjà initié(s) dans le réscau, mais affecté(s) d'une priorité logique inférieure. On a ainsi une libération de ressources internes par préemption de microflux, basés sur les priorités logiques associées aux microllux. Par ailleurs, le contrôleur d'admission transmet au contrôleur d'admission Ac2 du réseau suivant N2, la requête en qualité de service et la priorité logique affectée au microilux. D'une manière générale, par un système de contrôle d'admission selon l'invention, la priorité logique affectée au microllux, est transmise à chacun des contrôleurs d'admission associés aux réseaux par lesquels le microllux doit passer. Des moyens de préemption peuvent alors être mis en _uvre le cas échéant dans le contrôleur d'admission si ce dernier est apte à détecter si l'admission du nouveau microflux pourrait entraner un problème dans un n_ud ou plusieurs n_ubs du réseau. Dans les réseaux largement 1 0 2835987 dimensionnés ou d'une manière plus générale, dans les réseaux dans lesquels on est sûr qu'il ne peut y avoir de problèmes de congestion, le contrôleur d'admission va simplement transmettre au contrôleur d'admission suivant, la requête en qualité de service et la priorité logique associse au microflux. Dans le cas d'une architecture de type Diffserv, le microflux se voit affecter (ou est déjà affecté) d'un niveau de priorité du trafic IP, appelé précédence. Par exemple, un trafic voix se voit habituellement affecter une précédence maximale, "Expeditod Forwurding" et un trafic web, une précédence basse, "Best Effort". La priorité logique affectée par le système de contrôle d'admission selon l'invention permet d'affecter à des microflux de même précédence, une priorité logique différente, qui permet la préemption d'un flux sur un autre, selon des critères logiques délinis dans l'application, et non en fonction du trafic IP. Par exemple, le niveau de priorité logique ajouté sur les microilux pourra dépendre de l'identité de l'utilisateur du terminal. Le contrôleur d'admission selon l'invention conna^'t la liste des flux initiés par chacun des équipements frontières et la priorité logique qui leur a 2 0 été a*ectée. De par la connaissance de ces informations, le contrôleur d'admission peut déterminer si le réssau peut ou non satisfaire la nouvelle requête en qualité de service initiée par un terminal. Dans le cas o le contrôleur d'admission effectue des calcuis (met en _uvre des algorithmes) pour déterminer si 1'utilisation actuelle du réscau permet d'assurer la qualité de service demandée pour le nouveau microllux, le contrôleur d'admission recherche le cas échéant, la liste des microflux de priorité logique plus basse initiés dans le réseau. 1 1 2835987 Un exemple de mise en _uvre de l'invention, dans un réssau N d'architecture de type "tout Diffserv" est représenté sur la figure 3. Un émetteur d'un nouveau microllux A, le terminal T dans l'exemple, transmet une requête de service (9 sur une application AP, qui peut être en pratique, un serveur d'appel, un SlP-proxy, une application intermédiaire, une passerelle,...Cette requête est effectuée selon un protocole adapté à l'application. Ce protocole peut typiquement être du type SIP, acronyme anglais pour "Session Initiation Protocol", ou encore du type H.323 de l'ITU-T (International Telecommunication Union). Cette application AP peut effectuer de la mise en forme, des hypothèses, de la corrélation de plusieurs requ8tes en qualité de services,...etc. Selon l'invention, cette application affecte une priorité logique. En effet, cette application a une connaissance fine du microllux à transmettre, notamment de I'émetteur et du destinataire, et pas seulement des adresses IP. Cette application transmet alors la requete en qualité de service () avec l'affectation d'une priorité logique, dans l'exemple, une priorité élevée notée ***, pour le flux A, au contrôleur d'admission AC. Dans l'exemple illustré sur la figure 3, un microflux B est déjà initié dans le réseau, sur l'équipement frontière (routeur) R2. Ce microflux a été affecté par une application (pas nécessairement par l'application AP), d'une priorité logique basse, notée *. Deux cas de figure se présentent: dans le premier cas, le réseau a les ressources internes suffisantes pour accepter le nouveau microflux A. Soit qu'il est dimensionné de facon très large, ou que l'environnement applicatif est tel qu'il ne se pose pas de problèmes de congestion. Dans le deuxième cas, I'acceptation du microllux A entranerait des problèmes de congestion en au moins un n_ud du résacu. Et le contrôleur d'admission a des moyens de calcul qui lui permettent de détecter ce problème. 1 2 2835987 Deux variantes d'un système de contrôle selon l'invention peuvent alors étre mises en _uvre. Dans une première variante représentée sur la figure 3, le contrôleur d'admission sélectionne dans sa liste de microflux initiés dans le résacu, un microflux de priorité moindre, B dans l'exemple, et stoppe ce microflux, en envoyant un message correspondant, Stop B. sur l'équipement frontière qui l'a initié, R2 dans l'exemple. Il envoie un message () à l'application, pour lui indiquer que le flux A a été accepté, et quels flux ont été préemptés. Dans l'exemple, seul le flux B est prsempté. Le contrôleur d'admission peut alors renvoyer un message d'acceptation du microflux A sur le routeur frontière R selon le protocole COPS Ce message contient les règles d'ouverture habituelles (bande passante, débits minimum et maximum) lices à la précédence du microflux, par exemple "expeditod Forwurding". Le routeur R. peut alors transmettre le microlluxA. Dans une deuxième variante représentée sur la figure 4, le contrôleur d'admission met en _uvre une collaboration avec l'application AP. il envoie G) à cette application une liste de préemptés possibles. Cette liste peut comprendre tous les microllux initiés dans le résacu avec une priorité moindre, ou seulement une partie d'entre eux, selon des règles logiques prédéterminées. C'est l'application AP qui effectue alors le choix de préemption, et en informe le contrôleur d'admission. Le contrôleur d'admission AC peut signifier () à l'application, le microilux (ou les microflux) qu'il a effectivement stoppé. Sur la figure 5, une autre mise en _uvre de l'invention est représentée, pour une architecture mixte RSVP/Diffserv. Dans une telle architecture, le terminal T transmet O une requête de service (protocole SIP, ou H.323) à l'application, et transmet () une requête en réservation de 3 2835987 ressources selon le protocole RSVP à l'équipement frontière T. Ce dernier tra nsmet () cette requete au contrôleur d'ad mission AC. Par a il leu rs, I'application AP affecte au microllux A une priorité logique, *** dans l'exemple, selon le mécanisme déjà détaillé en relation avec la figure 3. Il transmet au contrôleur d'admission AC cette requete et la priorité logique du microllux A. Si le contrôleur d'admission AC recoit la requete en réservation de ressources avant de recevoir le message par l'application AP de la requete en qualité de service correspondante, il informe cette dernière de la requête en réservation de ressources (), et attend en retour (9 la confirmation de la requête et l'affectation de la priorité. Dans tous les cas, le contrôleur d'admission selon l'invention comprend des moyens pour vérifier que les paramètres de la requête en réservation de ressources C) correspondent bien à ceux contenus dans la requete en qualité de service transmise par 1'application AP. Dans le cas o il ne correspondrait pas, le contrôleur d'admission met en _uvre une collaboration avec l'application pour décider s'il faut accepter ou dograder la qualité de service demandée ( par l'équipement frontière, ce qui se traduit dans les règles d'ouvertures à appliquer. Ensuite, si un problème de congestion est à résoudre, on retrouve les deux variantes de mise en _uvre du système de contrôle selon l'invention, vues en relation avec la figure 3 (première variante) et la figure 4 (deuxième varia nte). Da ns la première va ria nte, le contrôleur d'ad mission effectue le choix du ou des flux à préempter en fonction de la priorité logique des microflux déjà initiés dans le réseau, stoppe ces flux (Stop B), en informe l'application AP et envoie un message d'acceptation du microllux A à l'équipement frontière correspondant R. 1 2835987 Dans la deuxième variante illustrée sur la figure 5, le contrôleur d'admission met en _uvre une collaboration avec l'application AP. Il envoie (9 à cette application une liste de préemptés possibles. Cette liste peut comprendre tous les microllux initiés dans le réseau avec une priorité moindre, ou seulement une partie d'entre eux, selon des règles logiques prédéterminées. C'est l'application AP qui effectue alors le choix de préemption, et en informe) le contrôleur d'admission. Dans tous les cas, le contrôleur d'admission AC signifie ( à l'application, le microflux (ou les microllux) qu'il a effectivement stoppé. Le contrôleur d'admission envoie alors le message d'acceptation du microllux A, OK A, avec des règles d'ouvertures correspondant à la qualité de service. Dans une telle architecture mixte RSVP/Diffserv, le contrôleur d'admission peut mettre en _uvre le protocole COPS avec les équipements 1 5 frontières. Avec un système de contrôle d'admission selon l'invention, le réseau peut accepter un microflux exigeant un certain niveau de qualité de service (bande passante, débits) et la satisfaire en permettant la libération de ressources internes du réseau en préemptant des microflux selon des critères donnés. Par exemple, une requete en qualité de service pour un trafic Voix émanant d'un émetteur correspondant à un client important pourra bénélicier d'une priorité plus élevée qu'une requete en qualité de service émanant d'un tiers. C'est l'application qui met en _uvre les règles d'affectation des priorités logiques. Ces règles sont basées sur l'intelligence du service dans l'application. Dans le cas o le contrôleur d'admission d'un réseau n'a pas les moyens de détecter un problème de congestion, ou qu'on sait qu'il n'y a pas de problèmes de congestion possibles dans le réscau, le contrôleur d'admission assure la transmission de la priorité logique affectée par l'application au microflux qui traverse le réseau. 1 6 2835987 REVENDICATIONS 1. Système de contrôle d'admission dans un réscau (N) posséJant un certain nombre d'équipements frontières (R, R2) pour recevoir des microllux à transmettre dans ledit réseau, système caractérisé en ce qu'une application demandeuse de qualité de service (AP) pour la transmission d'un microilux (A) dans le réssau comprend des moyens d'affectation d'une priorité logique (***) au dit microflux, ledit réseau comprenant un contrôleur d'admission (AC3) comportant des moyens pour recevoir une requete en qualité de service associce au d it microllux à tra nsmettre et la priorité log ique qui lui a été affectée et des moyens pour accepter ou interdire ledit microflux. 2. Système de contrôle selon la revendication 1, caractérisé en ce que les moyens pour accepter ledit microflux (A) comprennent des moyens de détermination d'un ordre de préemption de microflux dans le réseau, en fonction de leur priorité logique, pour libérer des ressources internes du réseau dans le but d'assurer la qualité de service demandée par ledit microllux (A) par prsemption de microilux de priorité logique plus basse. 3. Système selon la revendication 1 ou 2, caractérisé en ce que le contrôleur d'admission (AC) d'un réseau est apte à émettre des messages d'acceptation, d'interdiction ou d'arrét de microllux vers un équipement frontière correspondant dudit réseau conformément au protocole COPS. 4. Système selon l'une quelconque des revendications 1 à 3 précédentes, caractérisé en ce que les moyens de détermination de préemption sont aptes à transmettre à l'application demandeuse de qualité de service (AP), une liste de flux initiés dans le réseau et affectés d'une 1 7 2835987 priorité logique plus basse, et à recevoir de ladite application une sélection d'un microflux ou de microflux à préempter. 5. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que les moyens de détermination de prcemption sont aptes à transmettre à l'application (AP) demandeuse de qualité de service une information indiquant le ou les microilux pré-emptés. 6. Système de contrôle d'admission, selon l'une quelconque des revendications précédentes, appliqué à un résacu comportant des équipements frontières mettant en _uvre le protocole RSVP, caractérisé en ce que le contrôleur d'admission (AC) est apte à recevoir une requête en réservation de ressources desHits équipements frontières. 7. Système selon la revendication 6, caractérisé en ce que le contrôleur d'admission est apte à recevoir d'un équipement frontière une requête en réservation de ressources associée à un microilux, et en ce que le contrôleur d'admission comprend des moyens aptes à informer l'application demandeuse de qualité de service (AP) de la réception d'une telle requête. 8. Système selon l'une quelconque des revendications précédentes, caractérisé en ce que le contrôleur d'admission (AC,) associé à un réseau (N) comprend des moyens pour informer un contrôleur d'admission (AC2) associé à un autre réscau (N2), de la priorité logique affectée à un microflux.