FR2835989A1 - Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service - Google Patents

Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service Download PDF

Info

Publication number
FR2835989A1
FR2835989A1 FR0201624A FR0201624A FR2835989A1 FR 2835989 A1 FR2835989 A1 FR 2835989A1 FR 0201624 A FR0201624 A FR 0201624A FR 0201624 A FR0201624 A FR 0201624A FR 2835989 A1 FR2835989 A1 FR 2835989A1
Authority
FR
France
Prior art keywords
network
microflux
rate
microflows
controller according
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR0201624A
Other languages
English (en)
Inventor
Alban Couturier
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Alcatel CIT SA
Alcatel Lucent SAS
Original Assignee
Alcatel CIT SA
Alcatel SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Alcatel CIT SA, Alcatel SA filed Critical Alcatel CIT SA
Priority to FR0201624A priority Critical patent/FR2835989A1/fr
Publication of FR2835989A1 publication Critical patent/FR2835989A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation
    • H04L47/82Miscellaneous aspects
    • H04L47/822Collecting or measuring resource availability data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/11Identifying congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/26Flow control; Congestion control using explicit feedback to the source, e.g. choke packets
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/70Admission control; Resource allocation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Un contrôleur d'admission détermine pour chaque microflux associé à une requête en qualité de service, un débit moyen statistique compris entre le débit moyen et le débit maximum de ce microflux. Cette valeur est choisie en fonction d'un facteur de risque de congestion, défini statistiquement. Ce débit moyen statistique est utilisé pour calculer les risques de congestion en un noeud du réseau.

Description

<Desc/Clms Page number 1>
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éseau de données. Elle s'applique tout particulièrement aux réseaux de données permettant la fourniture de diffé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 (Transport Contre 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 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 l'é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 microflux, un ensemble de paquets qui
Figure img00010001

ont le même 5-tuple ou au moins le même 4-tuple. En effet, l'entête IP peut ne pas comporter l'identification du port de l'émetteur. Dans la suite, le terme microflux englobe ces deux possibilités. On entend par flux, un ensemble de paquets ou de microflux qui ont au moins un paramètre commun de l'entête
Figure img00010002

IP.
Pour transmettre des flux de paquets correspondant à de la voix ou des images par de tels réseaux, il est nécessaire de réduire le taux de pertes des paquets ainsi que le délai de transmission, afin d'assurer un confort
<Desc/Clms Page number 2>
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 noeuds 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 l'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.
L'architecture DiffServ (Differentiated Services model) telle que définie par le RFC 2475 de l'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 oeuvre par l'affectation de priorités à chaque paquet d'un flux. Les paquets doivent être traités selon leur priorité par le routeur qui les reçoit. 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 "Expedited Forwarding"dans l'architecture Diffserv, tandis qu'un trafic Web
<Desc/Clms Page number 3>
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 oeuvre les deux protocoles simultanément, afin de tirer parti de leurs avantages respectifs. Une architecture de ce type est représentée sur la figure 1. Une description d'un état de l'art correspondant peut être trouvé dans le RFC 2998 intitulé"A Framework for Integrated Services Operation over Diffserv Networks".
Le réseau de données N comporte des routeurs R, R, Rg, R, Rg, R.
Certains de ces routeurs sont des routeurs frontières (Edge Routers, dans la littérature anglo-saxonne) R1, 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 données 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éseau 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 oeuvre le mécanisme Diffserv. Mais on peut aussi avoir certains routeurs internes qui mettent en oeuvre le protocole RSVP, seul un réseau noyau mettant en oeuvre le protocole Diffserv. On peut aussi avoir des réseaux"tout"Diffserv.
Dans un réseau tel que représenté sur la figure 1, si un terminal Tl initie un flux qui nécessite une certaine qualité de service avec le terminal Tg, par exemple une communication vocale qui nécessite entre autres un délai
<Desc/Clms Page number 4>
de transmission minimal, il émet une requête 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 R. Ce dernier vérifie qu'il dispose effectivement des ressources internes nécessaire (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, l'équipement frontière R peut transmettre une réponse au terminal Tl lui indiquant que la réservation de ressources a été effectivement réalisée.
Le terminal T transmet alors les paquets du flux vers le terminal destinataire Tg.
Conformément au mécanisme Diffserv, le routeur Ri 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 alors acheminés au sein du réseau de données N, au travers des routeurs R, R, Ret Rg
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
Figure img00040001

terminal Tg.
Plus généralement, chacun des routeurs du réseau reçoit des paquets qui peuvent correspondre à différents flux initiés dans le réseau N. Tous ces paquets sont marqués d'une précédence, selon le mécanisme Diffserv. Chaque routeur traite les paquets qu'il reçoit en fonction des précédences (comme "Expedited 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 requêtes en qualité de service sont par
<Desc/Clms Page number 5>
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 requêtes en qualité de service pourront être accordées, alors qu'une ou même les deux, ne pourront être satisfaites. Il s'en suivra la dégradation arbitraire de la qualité de service pour au moins l'un de ces flux.
Si l'on se place dans le cas d'une configuration économe du réseau, les liens sont dimensionnés de façon à accepter un certain volume de communications simultanées, volume qui en pratique ne devrait être dépassé que dans des situations statistiquement rares.
Il résulte de ce mécanisme qu'il peut y avoir un écart significatif entre la 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 noeud interne.
Pour résoudre ces problèmes de congestion, on peut prévoir d'associer au réseau un serveur apte à mettre en oeuvre des calculs (des algorithmes) afin de déterminer les congestions au sein du réseau et d'accepter ou non une nouvelle demande de flux. Ce serveur effectue ainsi un contrôle d'admission centralisé des requêtes en qualité de service. Dans la suite, on l'appelle contrôleur d'admission.
Dans la présente invention, on se place dans le cas d'un réseau avec un contrôleur d'admission de ce type, apte à déterminer si l'acceptation d'un nouveau microflux pourrait entraîner une congestion sur au moins un noeud du réseau. Plus particulièrement, dans l'invention, on cherche à déterminer si une requête en qualité de service pour un nouveau microflux peut être ou non acceptée par un réseau, selon l'occupation de la bande passante sur un élément du réseau, correspondant à tout ou partie du chemin de données que devrait parcourir le nouveau microflux dans le réseau. On entend par
<Desc/Clms Page number 6>
élément de réseau, un noeud ou un lien du réseau, ou un ensemble de noeuds et/ou de liens du réseau.
Un élément de réseau est notamment défini par une bande passante.
Cet élément peut passer un certain nombre de microflux en même temps, sous réserve que la somme des débits de ces microflux reste comprise dans la largeur de bande de cet élément de réseau.
Dans le cas de données correspondant à de la voix ou des images, le débit de données est variable. Il est habituellement défini par un débit moyen, et par un débit maximum. Il est fonction du type de codage (compression) qui est appliqué pour obtenir le microflux de données.
Ainsi, les ressources demandées et mobilisées dans le réseau pour transmettre de tels microflux ne sont pas utilisées en continu, de façon uniforme. Par exemple, si les données à transmettre sont de type vidéo (avec compression d'images), la bande passante utilisée réellement pour ce trafic peut être très irrégulière, selon le type d'images : plans fixes ou au contraire, mouvements. On peut avoir à certains moments des pics de transmission, nécessitant une large bande passante, et à d'autres moments des"trous"de transmission (correspondants, à des silences (voix) ou des images fixes), utilisant une bande passante faible, inférieure au débit moyen du microflux.
Avec de tels microflux à débit variable, l'agrégation des microflux aux différents éléments du réseau est aussi variable.
Dans tous ces exemples, en fonction des moyens ou formats de codage utilisés, le microflux de données peut être défini par un débit moyen et un débit maximum. Dans la table ci-dessous, un certain nombre de valeurs de débits moyen et maximum pour différents formats et qualités d'images dans différents systèmes opérationnels sont donnés à titre d'exemples, reproduits à partir d'informations communiquées par la société MICROSOFT sur le site suivant :
<Desc/Clms Page number 7>
http : \\www. microsoft. com\ windows\NetMeeti ng\Corp \reskit\Chapter 7\defa ult. asp.
Figure img00070001
<tb>
<tb>
Format <SEP> Qualité <SEP> Système <SEP> Débit <SEP> moyen <SEP> Débit <SEP> max
<tb> d'image <SEP> d'image <SEP> opérationnel <SEP> Kbits/s <SEP> Kbits/s
<tb> SQCIF <SEP> basse <SEP> Windows <SEP> 98 <SEP> 49 <SEP> 162
<tb> SQCIF <SEP> basse <SEP> Windows <SEP> NT <SEP> 4. <SEP> 0 <SEP> 75 <SEP> 152
<tb> QCIF <SEP> moyenne <SEP> Windows <SEP> 98 <SEP> 130 <SEP> 230
<tb> QCIF <SEP> moyenne <SEP> Windows <SEP> NT <SEP> 4.0 <SEP> 130 <SEP> 245
<tb> QCIF <SEP> haute <SEP> Windows <SEP> 98 <SEP> 540 <SEP> 710
<tb> QCIF <SEP> haute <SEP> Windows <SEP> NT <SEP> 4. <SEP> 0 <SEP> 600 <SEP> 820
<tb> QCIF <SEP> haute <SEP> Windows <SEP> 98 <SEP> 625 <SEP> 775
<tb> QCIF <SEP> haute <SEP> Windows <SEP> NT <SEP> 4.0 <SEP> 775 <SEP> 880
<tb> CIF <SEP> haute <SEP> Windows <SEP> 98 <SEP> 700 <SEP> 900
<tb> CIF <SEP> haute <SEP> Windows <SEP> NT <SEP> 4. <SEP> 0 <SEP> 790 <SEP> 900
<tb>
Prenons l'exemple d'un microflux du type Windows 98, au format SQCIF, en qualité basse. Il a un débit moyen de 49 kilobits/s, avec des pointes à 162 kilobits/s. Dans une analyse statique de l'utilisation des ressources du réseau, on considère que pour admettre un microflux, il faut que les éléments concernés dans le réseau aient une disponibilité de bande passante au moins égale au débit maximum spécifié pour ce microflux, soit 162 Kbits/s dans l'exemple, pour qu'il n'y ait pas de risque de congestion.
Avec un élément du réseau défini avec une bande passante de 1000 Kilobits/s, on ne peut alors accepter de ne passer par ce lien que 6 microflux de ce type au maximum. Dans cette analyse statique, les éléments du réseau sont ainsi dimensionnés par rapport à l'agrégation des débits maximum. En contrepartie, on a alors des ressources qui peuvent être sous utilisés par rapport à leur capacité de transmission.
<Desc/Clms Page number 8>
L'idée à la base de l'invention repose sur une analyse statistique de l'utilisation des ressources internes du réseau pour la transmission de microflux à débit variable : plusieurs microflux utiliseront une partie du temps moins de bande passante que celle correspondant à leur débit moyen, laissant ainsi une réserve de bande passante utilisable par quelques microflux à certains moments pour des pics de transmission.
Selon l'invention, le contrôleur d'admission peut considérer un microflux à débit variable, comme s'il avait un débit continu (constant), en prenant pour ce débit une valeur moyenne statistique comprise entre la valeur moyenne et la valeur maximum du débit de ce microflux. Cette valeur est choisie en fonction d'un facteur de risque de congestion, défini statistiquement. Pour un risque nul, la valeur prise pour le débit moyen statistique est la valeur maximum. Pour un risque maximum, et la valeur prise pour le débit moyen statistique est la valeur moyenne.
Pour un risque intermédiaire, on a un facteur de risque intermédiaire et la valeur de débit moyen statistique est une valeur intermédiaire entre la valeur maximum et la valeur moyenne, dans le rapport donné par le facteur de risque.
Le facteur de risque peut par exemple être exprimé en pourcentage, par exemple 0% pour un risque nul et 100% pour un risque maximum.
D'autres représentations peuvent être utilisées. Par exemple, le facteur de risque peut être exprimé sur une échelle allant de-10 à + 1 O. Ces exemples ne sont pas limitatifs.
Si on reprend l'exemple d'un élément de réseau défini pour passer
1000 kbits/s, le système de contrôle d'admission selon l'invention permet ainsi d'admettre 15 microflux en même temps (au lieu de 6 précédemment).
Pour qu'une telle analyse statistique puisse être appliquée efficacement, elle doit de préférence concerner des éléments de réseau aptes à passer un certain nombre de microflux (grande bande passante), pour que
<Desc/Clms Page number 9>
l'effet de moyenne recherché s'applique effectivement. Ainsi, on prévoit de préférence un seuil, en dessous duquel le facteur de risque selon l'invention ne s'applique pas.
Ainsi l'invention concerne le contrôle d'admission des requêtes en qualité de service associées à des microflux. Le contrôleur d'admission vérifie si l'agrégation d'un nouveau microflux avec les microflux déjà initiés sur au moins un élément de réseau sur le chemin de données du nouveau microflux reste dans les limites de bande passante définie pour cet élément. Ce calcul consiste à effectuer la somme des débits de ces microflux.
Selon l'invention, on peut prendre comme valeur de débit pour les microflux d'un type donné, une valeur moyenne statistique définie en fonction du risque de congestion que l'on est prêt à accepter.
De préférence, on applique cette optimisation statistisque lorsque l'on a au moins un nombre déterminé de microflux sur ledit élément de réseau considéré. En dessous de ce nombre de microflux, on applique les méthodes de calcul habituelles, basées sur le débit maximum de ces microflux. En effet, on a vu que plus le nombre de microflux à passer par un élément de réseau est grand, plus il y a un effet de moyenne qui permet l'application du principe d'optimisation selon l'invention sur ce noeud.
Ces considérations d'optimisation peuvent être appliquées sur tout le chemin de données à l'intérieur du réseau, ou seulement à une partie de celui-ci.
La présente invention se propose donc de résoudre un problème d'optimisation de l'utilisation des ressources d'un réseau de données.
Telle que caractérisée, l'invention concerne un contrôleur d'admission à un réseau de données, caractérisé en ce qu'il comprend : des moyens pour recevoir des requêtes en qualité de service associées à des microflux, lesdites requêtes en qualité de service comprenant une
<Desc/Clms Page number 10>
information relative au débit moyen et au débit maximum du microflux associé, des moyens d'association d'un facteur de risque prédéterminé à des microflux de même type, et de détermination d'un débit moyen statistique compris entre le débit moyen et le débit maximum pour lesdits microflux, en fonction du facteur de risque prédéterminé.
* des moyens de calcul du débit de l'agrégation des microflux sur au moins un élément du réseau, sur la base d'un débit équivalent de microflux, ledit débit équivalent étant soit le débit maximum soit ledit débit moyen statistique, des moyens de décision d'acceptation ou de refus d'un microflux associé à une requête en qualité de service, en fonction du résultat dudit calcul de débit.
De préférence, le contrôleur d'admission comprend en outre des moyens de comptabilisation du nombre de microflux par type de microflux sur ledit élément du réseau. Pour les microflux d'un type donné auquel est associé un facteur de risque prédéterminé, les moyens de calcul peuvent alors utiliser comme débit équivalent, le débit maximum ou ledit débit moyen statistique selon que le nombre des microflux comptabilisés de ce type est en dessous ou au-dessus d'un seuil prédéterminé.
Selon une autre caractéristique de l'invention, le facteur de risque associé à un type de microflux est transmis sur une interface de gestion du contrôleur d'admission, par un serveur de gestion du réseau, et peut être modifié par ce dernier, par exemple suite à la mise à jour de critères statistiques d'utilisation du réseau.
<Desc/Clms Page number 11>
D'autres particularités et avantages de l'invention sont détaillés dans la description suivante, en référence aux dessins annexés dans lesquels : - la figure 1, déjà décrite illustre une architecture réseau de l'état de la technique ; - la figure 2 illustre un exemple de mise en oeuvre de l'invention dans une architecture réseau avec un contrôleur d'admission.
La figure 2 représente un réseau de données N1 comportant un ensemble d'équipements frontières et de ressources internes. Un contrôleur d'admission AC1 associé au réseau reçoit toutes les requêtes en qualité de service pour déterminer si elles peuvent être satisfaites ou non par le réseau.
Le contrôleur d'admission a ainsi des interfaces opérationnelles avec des moyens du réseau par lesquelles il reçoit les requêtes en qualité de service associées aux microflux à transmettre par le réseau. Ces interfaces opérationnelles dépendent notamment de l'architecture du réseau considéré, et du chaînage de ce réseau à d'autres réseauX.
On peut ainsi avoir une interface opérationnelle avec d'autres contrôleurs d'admission associés à d'autres réseaux, pour recevoir des requêtes en qualité de service associées à des microflux qui doivent transiter par différents réseaux. Dans l'exemple de la figure 2, on a ainsi représenté un contrôleur d'admission ACo associé à un réseau No. Ce contrôleur d'admission peut transmettre une requête en qualité de service pour un microflux Fo, qui doit transiter par les réseaux No et N1. Cette requête est notée QoS [Fo] sur la figure 2. Elle permet au contrôleur d'admission ACo associé au réseau No de savoir si le réseau N1 pourra assurer la qualité de service demandée pour le microflux Fo.
Le contrôleur d'admission peut recevoir des requêtes en qualité de service par d'autres interfaces opérationnelles, selon l'architecture réseau.
<Desc/Clms Page number 12>
Par exemple, dans un exemple d'architecture réseau de type tout Diffserv (non représenté), cette requête peut être directement transmise par l'émetteur du microflux. Cet émetteur peut être par exemple un terminal, une application de bureautique, etc. Le protocole de transmission entre l'émetteur et le contrôleur d'admission suit un protocole adapté, typiquement un protocole de type SIP (Session Initiation Protocol), ou H. 323 de l'ITU. T (International Telecommunication Union). La requête en qualité de service peut aussi être transmise par une application intermédiaire, qui peut être un serveur d'application, une passerelle ou un autre contrôleur d'admission.
Dans un autre exemple d'architecture réseau comprenant des équipements frontières mettant en oeuvre le protocole COPS, le contrôleur d'admission peut recevoir des requêtes en qualité de service selon le protocole COPS, défini par le RFC 2748 intitulé"The COPS (Common Open Policy Service) Protocol" et adopté en janvier 2000.
Sur la figure 2, on note de façon schématique la requête en qualité de service QoS 1 reçue par le contrôleur d'admission Ac, du réseau Nu par une interface opérationnelle quelconque du réseau (application intermédiaire, soft switch, routeur...). Cette requête correspond à un microflux Fl initié par le terminal T, sur l'équipement frontière Rl.
Les requêtes en qualité de service comportent habituellement les informations contenues dans l'entête IP (4 ou 5-tuple). Ces informations vont notamment permettre au contrôleur d'admission de déterminer le chemin de données du microflux dans le réseau N, en utilisant les tables de routage du réseau.
Selon l'invention, ces requêtes doivent en outre comporter des informations relatives au débit moyen et au débit maximum pour le microflux associé à la requête en qualité de service. Dans un exemple pratique de mise en oeuvre de l'invention, la requête en qualité de service transmet directement ces informations de débit moyen et de débit maximum. Dans un
<Desc/Clms Page number 13>
autre exemple, on prévoit que le contrôleur d'admission contient les caractérisation des codage des données (codec (s)). La requête en qualité de service peut alors fournir une information d'identification du codage des données du microflux, par exemple, dans un exemple de trafic vidéo, un codage d'image au format JPEG. Le contrôleur d'admission va alors trouver dans sa table de codage les informations de débit moyen et maximum correspondantes.
Le contrôleur d'admission AC, comprend aussi une interface de gestion IG par laquelle il reçoit : une description des différents routeurs et des liens du réseau, typiquement leur bande passante, le retard de transmission qu'ils induisent,... etc ; les tables de routage, c'est à dire les informations qui déterminent le chemin de données dans le réseau (routeurs, liens) qu'un microflux va suivre.
Il peut aussi recevoir par cette interface de gestion, les différentes caractérisations des codeurs des données des microflux transitant par le réseau. Ces informations permettent alors au contrôleur d'admission de déterminer les débits moyen et maximum d'un microflux donné, dont il connaît le codeur (par la requête en qualité de service).
Le contrôleur d'admission reçoit par cette interface de gestion IG un facteur de risque associé à au moins un type de microflux, par exemple associé aux microflux de type trafic voix. Ce facteur de risque va permettre l'optimisation de l'utilisation de la bande passante selon l'invention, dans certaines conditions. Ce facteur de risque est déterminé statistiquement à partir notamment de l'utilisation du réseau. Il peut être modifié en cours d'utilisation du réseau.
De préférence, et comme représenté sur la figure 2, cette interface de gestion IG est une interface avec un serveur de gestion du réseau, désigné habituellement par l'acronyme anglais NMS pour"Network Management Server". Mais cette interface de gestion peut très bien être directement
<Desc/Clms Page number 14>
contrôlée"manuellement"par un opérateur humain, pour l'administration du réseau (exemple non représenté).
Prenons un exemple pratique de mise en oeuvre de l'invention, représenté sur la figure 2. On prend une microflux Fl d'un type associé un facteur de risque prédéterminé-cl (par exemple, du type trafic voix). Lorsque le contrôleur d'admission reçoit la requête en qualité de service QoS [F], il détermine le chemin de données correspondant au microflux associé F, à partir de sa connaissance de la topologie du réseau, notamment à partir des tables de routage. Le facteur de risque-il s'applique à un élément du réseau qui peut correspondre à tout ou partie de ce chemin de données. Le contrôleur d'admission peut déterminer pour le microflux F, une valeur de débit moyen statistique comprise entre le débit moyen et le débit maximum de ce microflux, en fonction de ce facteur de risque r,.
Pour les microflux du type à facteur de risque associé, le contrôleur d'admission peut utiliser ce débit moyen statistique, dans le calcul de l'agrégation des microflux sur l'élément de réseau considéré. Pour les microflux auquel aucun facteur de risque n'est associé, il utilise le débit maximum pour le calcul de l'agrégation des microflux.
De préférence, le contrôleur d'admission n'utilise le débit moyen statistique des microflux auquel correspond un facteur de risque selon l'invention, qu'à partir d'un certain nombre de microflux de ce type. En effet, on a vu que l'effet de moyenne statistique recherché ne s'observe qu'à partir d'un certain nombre de microflux En dessous de ce seuil, le contrôleur d'admission prendra le débit maximum des microflux de ce type pour le calcul de l'agrégation des microflux.
Le contrôleur d'admission calcule donc la somme des valeurs moyennes statistiques et/ou des débits maximum des microflux déjà initiés et du microflux F] associé à la nouvelle requête en qualité de service. Selon que cette somme dépasse ou reste dans la bande passante de l'élément de
<Desc/Clms Page number 15>
réseau considéré, il refuse ou accepte la transmission du microflux F, associé à la requête en qualité de service considérée QoS [F].
Le facteur de risque correspond au risque statistique qu'à un moment donné, l'agrégation des flux sur l'élément de réseau considéré, dépasse la bande passante effective allouée à cet élément.
En pratique, selon le réseau, et en fonction de la complexité des moyens de vérification (moyens de calcul) que l'on peut accepter de mettre en oeuvre dans le contrôleur d'admission, on peut prévoir la définition de plusieurs facteurs de risque associés à différents types de microflux (vidéo, voix,...). Les moyens de vérification peuvent aussi s'appliquer sur plusieurs éléments du réseau, selon son architecture.
On peut aussi prévoir que le contrôleur d'admission peut transmettre par l'interface de gestion des informations concernant l'utilisation réelle du réseau dans une configuration donnée (table de routage...). Le système de gestion NMS peut alors reconfigurer au mieux le réseau, et éventuellement modifier en conséquence le ou les facteurs de risque selon l'invention.
Optionnellement, le contrôleur d'admission AC, a une interface opérationnelle avec les équipements frontières du réseau, pour transmettre sa décision d'accepter ou de refuser un microflux initié sur cet équipement frontière. Dans l'exemple représenté sur la figure 2, ce contrôleur envoie sur le routeur R, un message d'acceptation (OK [F1]) ou de refus (NO [F1]) du microflux F, associé à la requête en qualité de service considérée.
Typiquement, cette transmission sera conforme au protocole COPS.

Claims (12)

REVENDICATIONS
1. Contrôleur d'admission à un réseau de données, caractérisé en ce qu'il comprend : des moyens pour recevoir des requêtes en qualité de service associées à des microflux, lesdites requêtes en qualité de service comprenant une information relative au débit moyen et au débit maximum du microflux associé, . des moyens d'association d'un facteur de risque prédéterminé à des microflux de même type, et de détermination d'un débit moyen statistique compris entre le débit moyen et le débit maximum pour lesdits microflux, en fonction du facteur de risque prédéterminé, des moyens de calcul du débit de l'agrégation des microflux sur au moins un élément du réseau, sur la base d'un débit équivalent de microflux, ledit débit équivalent étant soit le débit maximum soit ledit débit moyen statistique, des moyens de décision d'acceptation ou de refus d'un microflux associé à une requête en qualité de service, en fonction dudit calcul de débit.
2. Contrôleur d'admission selon la revendication 1, caractérisé en ce que ledit débit moyen statistique d'un microflux est égal à une valeur comprise entre le débit maximum et le débit moyen dans le rapport donné par le facteur de risque.
3. Contrôleur d'admission selon la revendication 1 ou 2, caractérisé en ce qu'il comprend en outre des moyens de comptabilisation du nombre de microflux par type de microflux sur ledit élément du réseau.
<Desc/Clms Page number 17>
4. Contrôleur d'admission selon la revendication 3, caractérisé en ce que pour les microflux d'un type donné auquel est associé un facteur de risque prédéterminé, les moyens de calcul utilisent comme débit équivalent, le débit maximum ou ledit débit moyen statistique selon que le nombre de microflux de ce type comptabilisés est en dessous ou au-dessus d'un seuil prédéterminé.
5. Contrôleur d'admission selon l'une des revendications précédentes, caractérisé en ce que les requêtes en qualité de service transmettent le débit moyen et le débit maximum du microflux associé.
6. Contrôleur d'admission selon l'une des revendications précédentes, caractérisé en ce que dans les requêtes en qualité de service, l'information relative au débit moyen et maximum est une information de codage des données du microflux associé.
7. Contrôleur d'admission selon l'une quelconque des revendications précédentes, caractérisé en ce qu'il comprend une interface de gestion (IG) par laquelle il reçoit ledit facteur de risque.
8. Contrôleur d'admission selon la revendication 7, caractérisé en ce que ledit facteur de risque peut être mis à jour par ladite interface de gestion.
9. Contrôleur d'admission selon la revendication 7 ou 8, caractérisé en ce que ladite interface de gestion est reliée à un serveur de gestion du réseau (NMS).
<Desc/Clms Page number 18>
10. Contrôleur d'admission selon la revendication 9, caractérisé en ce qu'il transmet audit serveur par ladite interface de gestion, des informations relatives à l'utilisation du réseau.
11. Contrôleur d'admission selon l'une quelconque des revendications précédentes, les microflux à transmettre dans le réseau étant reçus par des équipements frontières, caractérisé en ce qu'il comprend des moyens d'émission vers lesdits équipements frontières, de messages d'autorisation ou d'interdiction de transmettre les microflux.
12. Contrôleur d'admission selon la revendication 11, caractérisé en ce qu'il admet le protocole COPS avec les équipements frontières.
FR0201624A 2002-02-11 2002-02-11 Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service Withdrawn FR2835989A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0201624A FR2835989A1 (fr) 2002-02-11 2002-02-11 Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0201624A FR2835989A1 (fr) 2002-02-11 2002-02-11 Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service

Publications (1)

Publication Number Publication Date
FR2835989A1 true FR2835989A1 (fr) 2003-08-15

Family

ID=27620067

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0201624A Withdrawn FR2835989A1 (fr) 2002-02-11 2002-02-11 Controle d'admission a un reseau de donnees pour l'assurance de la qualite de service

Country Status (1)

Country Link
FR (1) FR2835989A1 (fr)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999065194A1 (fr) * 1998-06-05 1999-12-16 Nokia Networks Oy Methode et dispositif permettant de proceder a un controle d'admission des connexions
WO2000033606A1 (fr) * 1998-12-01 2000-06-08 Nortel Networks Limited Programme de commande d'admission de connexion adaptatif pour reseaux de transmission par paquets

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999065194A1 (fr) * 1998-06-05 1999-12-16 Nokia Networks Oy Methode et dispositif permettant de proceder a un controle d'admission des connexions
WO2000033606A1 (fr) * 1998-12-01 2000-06-08 Nortel Networks Limited Programme de commande d'admission de connexion adaptatif pour reseaux de transmission par paquets

Similar Documents

Publication Publication Date Title
Sisalem et al. The loss-delay based adjustment algorithm: A TCP-friendly adaptation scheme
EP1383285B1 (fr) Système et procédé pour contrôle d&#39;admission de la session
US20060268692A1 (en) Transmission of electronic packets of information of varying priorities over network transports while accounting for transmission delays
EP1616414A2 (fr) Procede et dispositif de controle d&#39;un trafic de paquets de donnees en entree d&#39;un reseau
EP2504950B1 (fr) Controle d&#39;admission pour abonnement de service
EP1479203B1 (fr) Correlation des requetes en qualite de service
EP0886455A1 (fr) Procédé de gestion de largeurs de bandes allouées dans les réseaux locaux à accès partagés, protocole et filtre de mise en oeuvre
EP1343283A2 (fr) Contrôle d&#39;admission à un réseau de données pour l&#39;assurance de la qualité de service
US20020003779A1 (en) Method and a system for settign up a call in an internet protocol network
WO2003047186A1 (fr) Controle d&#39;admission a un reseau de donnees pour l&#39;assurance de la qualite de service
Lu Issues and technologies for supporting multimedia communications over the Internet
Cisco Quality of Service for Voice over IP
FR2835989A1 (fr) Controle d&#39;admission a un reseau de donnees pour l&#39;assurance de la qualite de service
EP3989494A1 (fr) Procede d&#39;agregation et de regulation de messages via un canal de communication bidirectionnel contraint
WO2008074817A1 (fr) Procédé d&#39;optimisation du partage d&#39;une pluralité de ressources réseau entre une pluralité de flux applicatifs
Rakocevic Dynamic bandwidth allocation in multi-class IP networks using utility functions.
EP1451987B1 (fr) Controle multi-domaine d admission de flux de donnees associes a des criteres de qualite de service
Ghyar et al. Basics of Quality of Services (QoS)
Domingo et al. Analysis of VBR VoIP traffic for ad hoc connectivity with a fixed IP network
WO2005022844A1 (fr) Systeme et procede de gestion de ressources permettant d&#39;assurer une qualite de service qos dans des reseaux bases sur le protocole internet
Chan et al. Multimedia streaming gateway with jitter detection
EP2476225B1 (fr) Procede et systeme pour le controle de l&#39;acheminement d&#39;un flux de donnees d&#39;une classe de service a travers un reseau maille et chiffre
Eberspächer et al. QoS Architectures and Resource Management in the Intranet
Floyd et al. RFC3714: IAB Concerns Regarding Congestion Control for Voice Traffic in the Internet
Vivanco et al. New QoS approaches for delay-sensitive applications over DiffServ

Legal Events

Date Code Title Description
ST Notification of lapse