FR2832889A1

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

Info

Publication number: FR2832889A1
Application number: FR0115428A
Authority: FR
Inventors: Alban Couturier; Nathalie Charton
Original assignee: Alcatel CIT SA; Alcatel SA
Current assignee: Alcatel CIT SA; Alcatel Lucent SAS
Priority date: 2001-11-29
Filing date: 2001-11-29
Publication date: 2003-05-30
Anticipated expiration: 2021-11-29
Also published as: CN1611042A; WO2003047186A1; US20050041576A1; FR2832889B1; EP1451986A1; CN100367732C

Abstract

Contrôleur d'admission (AC) à un réseau de données (N) possédant un ensemble d'équipements frontières (R1), caractérisé en ce qu'il possède :. des moyens de réception pour recevoir des requêtes en qualité de service associées à des flux de poquets,. Des moyens de vérification pour vérifier que ces requêtes peuvent être satisfaites par les ressources internes du réseau, et. des moyens d'émission pour émettre à l'équipement frontière correspondant à la requête, un message d'autorisation ou d'interdiction de la transmission du flux de paquets associé.

Description

Contrôle d'admission à un réseau de données pour l'assurance de la qualité 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, 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 ContraI Protocol /Internet Protocol), 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 le taux de perte des paquets 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 du taux de perte de paquets et du délai se fait classiquement par la réservation de ressources au sein des noeuds de réseau (ou routeurs).

Classiquement, le terminal souhaitant une certaine qualité de service pour un certain flux transmet une requête en qualité de service, avant d'envoyer les paquets correspondants à ce flux.

Dans la suite, on entend par flux, un micro-flux, c'est-à-dire un ensemble de paquets caractérisé classiquement par un 5-tuple : le protocole utilisé, l'adresse et le port de l'émetteur et le port et l'adresse du destinataire.

Généralement, cette 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 ressource doit, dans un premier temps, vérifier qu'il dispose des ressources demandées et acheminer la requête selon les algorithmes de routage classique. La requête en réservation ressources parcourt ainsi le chemin qui sera normalement celui des paquets du flux, jusqu'au destinataire.

Celui-ci transmet alors une réponse à l'émetteur initial qui va remonter le chemin. Lors de ce second passage, chaque routeur doit réserver effectivement les ressources demandées.

Ce protocole présente un inconvénient majeur en ce qu'il nécessite pour chaque requête en qualité de service adressée à un réseau, la réservation de ressources sur un ensemble important de routeur, et, en pratique, la maintenance d'un contexte de traitement au sein de chaque routeur.

Cet inconvénient est résolu par l'architecture DiffServ (Differentiated Services model), telle que définie par le RFC 2475 de l'IETF (Internet Engineering Task Force).

Selon cette architecture, la gestion de la qualité de service est mise en oeuvre par l'affectation de priorités, appelées dans ce contexte, couleurs, à chaque paquet du flux. Les routeurs recevant des paquets ainsi colorés (c'est-à-dire auxquels une priorité a été affectée) doivent les traiter en priorité.

Toutefois, ces deux solutions se complètent, de sorte que les solutions de l'état de la technique mettent généralement en oeuvre les deux protocoles simultanément, afin de tirer profit de leurs avantages respectifs.

Un exemple de mise en oeuvre d'une telle solution de l'état de la technique est présenté par la figure 1. Un tel état de l'art est par exemple décrit dans le RFC 2998 intitulé A Framework for Integrated Services Operation over Diffserv Networks et adopté en novembre 2000 par l'IETF.

Le réseau de données N comporte des routeurs R,, R, Rg, R, Rg.

Certains de ces routeurs sont des routeurs frontières (ou Edge routers, en anglais) Rl, R, Rg, c'est-à-dire qu'ils disposent de moyens de communication avec des terminaux ou des routeurs extérieurs à ce réseau de données N.

Les autres routeurs sont des routeurs internes, R4, R5, R6 qui ne disposent de moyens de communication qu'avec d'autres routeurs 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 Protoco/).

Selon cet état de l'art, les équipements frontières (routeurs, passerelles etc. ) peuvent mettre en oeuvre le protocole RSVP, tandis que les routeurs internes mettent principalement en oeuvre le mécanisme DiffServ. Les équipements frontières ont pour charge supplémentaire d'effectuer les traductions, ou inter-fonctionnements, entre les deux protocoles. Il est toutefois à noter que certains routeurs internes peuvent mettre en oeuvre le protocole RSVP, seul un réseau noyau mettant en oeuvre le mécanisme DiffServ.

Ainsi, si le terminal T, initie un flux nécessitant une certaine qualité de service, avec le terminal T3 (par exemple, une communication vocale qui nécessite, entre autres, un débit minimal), il émet une requête en réservation de ressource selon le protocole RSVP.

Cette requête en réservation de ressource est reçue puis traitée par l'équipement frontière R,. Il vérifie qu'il dispose effectivement des ressources internes suffisantes pour fournir la qualité de service attendue (c'est-à-dire que la valeur actuelle due à l'agrégation des flux en sortie du routeur R, permet d'accepter ce nouveau flux).

Le cas échéant, l'équipement frontière R, peut transmettre alors une réponse au terminal T, 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 T3'
A leur réception, le routeur R, leur affecte une priorité en fonction de la requête en réservation de ressources précédemment reçue.

Comme dit précédemment, cette affectation de priorité est classiquement conforme au mécanisme DiffServ.

Les paquets prioritaires sont alors acheminés au sein du réseau de données N, au travers des routeurs R, Rg et R3. Chacun de ces routeurs traite les paquets qu'il reçoit en fonction des priorités qui leur sont affectées.

Le routeur R3 transmet alors le flux de paquets au terminal T., et la requête en qualité de service selon le protocole RSVP est transmise à ce

terminal Tg.

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. Aussi, si deux requêtes en qualité de service sont initiées sur deux équipements frontières distincts, il peut en résulter qu'une impossibilité de satisfaire cette qualité de service par un routeur interne ne puisse pas être détectée. Les deux requêtes en qualité de service seront alors accordées alors qu'une des deux, ou même les deux, ne pourront être satisfaites.

Sur l'exemple de la figure 1, le terminal T2 initie une deuxième requête en qualité service, auprès de l'équipement frontière R2. Cette requête

en qualité de service fait l'objet du même traitement que la requête initiée par le terminal T, et est, de même, destinée au terminal Tg.

Le flux de paquets auxquels l'équipement frontière R2 a affecté une priorité, suit un chemin R2, Rg, R6, R3 jusqu'au terminal T3'
Une partie, Rg-Rg, de ce chemin est donc commune avec le chemin emprunté par le flux de paquets issu du terminal T,.

Dans le cas d'une configuration économe du réseau, les liens comme ici Rg-Rg peuvent être dimensionnés de façon à accepter un certain volume de communications simultanées qui peut être dépassé dans ces situations statistiquement rares.

Ainsi, si la somme des débits de ces deux flux de paquets est supérieure au débit maximum possible sur le chemin Rg-Rg, te routeur Rg ne sera pas en mesure de satisfaire la qualité de service demandée par au moins un des terminaux T, et T2. Si les deux requêtes en qualité de service se sont vues attribuées des priorités égales, les qualités de service de ces deux flux de paquets seront dégradées.

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 de données) et celle effectivement fournie.

Le but de la présente invention est de palier ce problème en proposant un mécanisme d'autorisation et d'interdiction des requêtes en qualité de service, basé sur les ressources effectivement disponibles dans le réseau de données.

Plus précisément, l'invention a pour objet un contrôleur d'admission à un réseau de données possédant un ensemble d'équipements frontières (R,), qui se caractérise en ce qu'il possède :

des moyens de réception pour recevoir des requêtes en qualité de service associées à des flux de paquets, 'Des moyens de vérification pour vérifier que les requêtes en qualité de service peuvent être satisfaites par les ressources internes du réseau de données, et . des moyens d'émission pour émettre à l'équipement frontière correspondant à la requête en qualité de service, un message d'autorisation ou d'interdiction de la transmission du flux de paquets associé.

Selon une mise en oeuvre de l'invention, les moyens d'émission et les moyens de réception peuvent être aptes à communiquer selon un même protocole tel que COPS.

Selon une autre mise en oeuvre, ces protocoles sont différents : les moyens d'émission sont aptes à émettre des messages conformes au protocole COPS, et les moyens de réception peuvent être aptes à recevoir des requêtes en qualité de service, par exemple conformes aux protocoles SIP, H. 323 etc.

Ainsi, par l'utilisation d'un contrôleur d'admission, les équipements frontières admettent les flux de paquets uniquement si la qualité de service demandée peut être effectivement satisfaite par le réseau.

Le contrôleur d'admission centralisant l'ensemble des requêtes en qualité de service adressées au réseau de données, cette vérification peut être effectuée de façon globale.

On peut ainsi éviter tout sur-approvisionnement des ressources du réseau de données.

L'invention et ses avantages vont être décrits de façon plus claire dans la description de mises en oeuvre, qui va suivre en liaison avec les figures annexées.

La figure 1, déjà commentée, représente une solution de l'état de la technique.

La figure 2 illustre une première mise en oeuvre de l'invention.

La figure 3 illustre une deuxième mise en oeuvre de l'invention.

La figure 4 illustre une troisième mise en oeuvre de l'invention.

La figure 2 représente un réseau de données N comportant un ensemble de routeurs R, R.-. Rn. Un terminal T, initie un flux de paquets à destination du terminal T2.

Ce flux de paquets nécessite une certaine qualité de service. Il peut par exemple s'agir d'une session multimédia nécessitant un débit minimum.

Aussi, le terminal Tl émet une requête en qualité de service, QoS,, à destination d'un routeur frontière Rl (dans l'exemple décrit par cette figure 2, l'équipement frontière est un routeur frontière, mais le principe de l'invention peut naturellement s'appliquer à d'autres types d'équipements de réseau).

Cette requête en qualité de service peut être une requête en réservation de ressources conforme au protocole RSVP ainsi que décrit précédemment.

Cette requête en réservation de ressources comprend des paramètres caractéristiques de la qualité de service demandé pour ce flux. Notamment, elle peut comprendre le débit minimal souhaité pour les paquets du flux associé à cette requête en réservation de ressources.

Le routeur frontière R, possède des moyens pour transmettre cette requête en qualité de service à un contrôleur d'admission AC, sous la forme d'une requête en qualité de service QoS.

Cette transmission peut par exemple être effectuée en utilisant le protocole COPS, défini par le RFC 2748 intitulé The COPS (Common Open Policy Service) Protocol , adopté en janvier 2000.

Le contrôleur d'admission dispose de moyens pour recevoir cette requête en qualité de service et de moyens pour vérifier qu'elle peut être satisfaite par les ressources internes du réseau de données.

Pour ce faire, le contrôleur d'admission peut disposer de la connaissance de ces ressources internes, fournie par un système de gestion de réseau NMS.

Ces ressources internes peuvent concerner l'intégralité du réseau de données N ou bien une partie de celui-ci.

Ces ressources internes peuvent être les bandes passantes des connexions (ou de certaines connexions) entre les routeurs composants ce réseau de données.

Connaissant la topologie du réseau de données, les informations de routage telles que des tables de routage et les bandes passantes possibles sur les connexions de ce réseau, le contrôleur d'admission est à même d'avoir une vue globale. En ayant la connaissance de l'ensemble des requêtes en qualité de service transitant par le réseau de données, il peut alors savoir si une requête en qualité de service peut être effectivement satisfaite ou non.

Le contrôleur d'admission possède en outre un moyen pour émettre au routeur frontière R correspondant à la requête en qualité de service, un message d'autorisation ou d'interdiction, Ok.

Ce routeur frontière R ne permet la transmission des paquets ultérieurs du flux de paquets que si un message d'autorisation est reçu du contrôleur d'admission AC.

Le cas échéant, ce message d'autorisation peut contenir des paramètres de dégradation de la qualité de service.

En effet, selon une mise en oeuvre de l'invention, si la qualité de service demandé ne peut pas être satisfaite compte tenu des ressources internes du réseau de données N et des requêtes en qualité de service précédemment autorisées, il peut être possible d'autoriser la transmission du flux de paquets mais en ne lui accordant qu'une qualité de service moindre que celle demandée, c'est-à-dire, par exemple, en lui accordant une priorité moindre. Cette priorité peut notamment être une couleur dans le cas d'une mise en oeuvre utilisant le protocole DiffServ.

Selon un mode de réalisation de l'invention, ce message d'autorisation peut contenir des paramètres de reroutage, permettant de changer le chemin du flux de paquets vers un nouveau chemin plus à même de fournir la qualité de service demandée.

La figure 3 illustre une seconde mise en oeuvre de l'invention.

Selon cette mise en oeuvre, la requête en qualité de service QoS est transmise par l'émetteur du flux de données, qui peut par exemple être un terminal, une application de bureautique, etc. Elle peut provenir directement de cet émetteur ou bien être transmise via une application intermédiaire comme par exemple un softswitch .

Dans ce dernier cas, l'application intermédiaire peut effectuer de la mise en forme, des hypothèses, de la corrélation entre plusieurs requêtes en qualité de services etc. préalablement à la transmission d'une requête en qualité de service vers le contrôleur d'admission AC.

Le protocole mis en oeuvre pour la transmission de cette requête en qualité de service par l'émetteur du flux de données peut typiquement être SIP (Session Initiation Protocol) ou H. 323 de l'ITU-T (International Telecommunication Union).

Dans le cas particulier illustré par la figure 3, le termina ! T, transmet une requête en qualité de service QoS directement au contrôleur d'admission AC.

Comme dans la mise en oeuvre précédente, le contrôleur d'admission dispose de moyens de vérification afin de vérifier que la requête en qualité de service peut être satisfaite par les ressources internes du réseau de données N. La connaissance de ces ressources internes peut par exemple être fournie par un système de gestion de réseau NMS.

Selon cette mise en oeuvre, il peut revenir au contrôleur d'admission AC d'effectuer l'affectation de priorité aux paquets du flux de paquets, à partir de cette requête en qualité de service.

Pour cela, le contrôleur d'admission AC peut disposer de moyens pour déterminer des priorités à partir de paramètres contenus dans les requêtes en qualité de service. Ces moyens permettent de faire correspondre une priorité à un profil donné de requête en qualité de service déterminé par ses paramètres. Par exemple, une requête en qualité de service émanant d'un client important ou d'une personnalité VIP (Very Important Person) a une priorité plus élevée qu'une requête en qualité de service provenant d'un tiers, tous les autres paramètres étant égaux par ailleurs (taux de perte de paquets...).

Le contrôleur d'admission AC dispose, de surcroît, de moyens pour transmettre au routeur frontière R, une requête en affectation de priorité, Aff.

Cette requête en affectation de priorité peut être conforme au protocole COPS.

Une telle requête pourrait, par exemple, prendre la forme suivante :
DEC : = < Handle B >
Context : in, Resv > < Decision : command, Install >

Context : allocation, Resv > < Decision : command, Install > < Decision : Stateless, Priority=7 > < Context : out, Resv > < Decision : command, Install > < Decision replacement, POLICY-DATAI >
Ce protocole permet en effet à une entité distante, tel le contrôleur d'admission AC, de contrôler le comportement d'un routeur.

Le routeur frontière R possède alors des moyens pour recevoir ces requêtes en affectation de priorité et pour affecter la priorité demandée aux paquets du flux de paquets.

Ces priorités et la façon dont elles sont affectées aux paquets du flux de paquets peuvent être conformes au mécanisme DiffServ.

Selon une autre mise en oeuvre, la détermination des priorités peut être effectuée en collaboration avec l'application intermédiaire de type Softswitch d'où la requête en qualité de service est arrivée. Le contrôleur d'admission dispose alors de moyens de communication avec cette autre application intermédiaire, qui peut être sous la forme d'une interface protocolaire ou d'une interface de programmation ou API (pour Application

Programming interface})).

La figure 4 illustre un cas particulier où un même flux de données est associé à deux requêtes en qualité de service : . La première est une requête en réservation de ressource, QoS1, comme décrit dans la mise en oeuvre de la figure 2. Ce peut par exemple être une requête RSVP.

La seconde est une requête en qualité de service QOS3, de type SIP ou H. 323 tel que décrit pour la mise en oeuvre de la figure 3.

Comme décrit précédemment, la première requête donne lieu à une requête en qualité de service QOS2 transmis par le routeur frontière R au contrôleur d'admission AC.

La seconde requête QOS3 aboutit à une application intermédiaire SS, de type Softswitch . Elle donne lieu à une requête en qualité de service QOS4 transmise au contrôleur d'admission AC.

Les deux transmissions sont effectuées de façon asynchrone ; ce qui signifie que l'ordre dans lequel elles peuvent arriver au contrôleur d'admission AC n'est pas fixe.

Si le contrôleur d'admission reçoit la requête en qualité de service QOS4 avant de recevoir la requête en qualité de service QOS2, alors il peut juste mettre en oeuvre une vérification en comparant les paramètres contenus dans chacune des requêtes.

Si le contrôleur d'admission AC reçoit la requête en qualité de service QOS2 en premier, il peut mettre en oeuvre une collaboration C avec l'application intermédiaire SS, notamment pour obtenir des informations supplémentaires sur le flux de paquets associé.

En fonction de ces informations supplémentaires, il peut alors déterminer des paramètres de mise en forme du trafic et/ou de dégradation de la qualité de service, et les transmettre au routeur frontière R.

Selon un mode de réalisation de l'invention, si le contrôleur d'admission AC détecte qu'une ressource est fréquemment utilisée, voire saturée, de telle façon qu'il refuse des requêtes en qualité de service ou les reachemine, alors il peut notifier cette configuration trop faible au système de gestion de réseau NMS.

Il peut en être de même pour une ressource trop peu utilisée.

Parallèlement à cette boucle de réaction basée sur une détection de dépassement de seuils, le contrôleur d'admission peut aussi envoyer, par exemple périodiquement, des statistiques de l'utilisation du réseau à ce système de gestion de réseau NMS. Celui peut alors reconfigurer au mieux le réseau.

Ces informations peuvent comprendre :
Des descriptions des liens (débit, taux d'erreur, délai...)
Des descriptions des routeurs,
Des descriptions des tables de routage, etc.

Le contrôleur d'admission AC peut aussi proposer au système de gestion de réseau NMS, une configuration du réseau. La responsabilité d'entériner cette proposition de configuration peut rester au système de gestion de réseau.

Claims

REVENDICATIONS

1) Contrôleur d'admission (AC) à un réseau de données (N), ledit réseau de données possédant un ensemble d'équipements frontières (R1L caractérisé en ce qu'il possède : 'des moyens de réception pour recevoir des requêtes en qualité de service associées à des flux de paquets,

Des moyens de vérification pour vérifier que lesdites requêtes en qualité de service peuvent être satisfaites par les ressources internes dudit réseau de données, et * des moyens d'émission pour émettre à l'équipement frontière correspondant à ladite requête en qualité de service, un message d'autorisation ou d'interdiction de la transmission du flux de paquets associé.

2) Contrôleur d'admission selon la revendication 1, dans lequel lesdits moyens d'émission sont aptes à émettre des messages d'autorisation ou d'interdiction conformément au protocole COPS.

3) Contrôleur d'admission selon l'une des revendications 1 et 2, dans lequel lesdits moyens de réception sont aptes à recevoir des requêtes en qualité de service, par exemple conformes au protocole COPS, provenant dudit équipement frontière.

4) Contrôleur d'admission selon l'une des revendications 1 et 2, dans lequel lesdits moyens de réception sont aptes à recevoir des requêtes en qualité de service provenant de l'émetteur (T,) dudit flux de données, éventuellement par l'intermédiaire d'une application intermédiaire.

5) Contrôleur d'admission selon la revendication précédente, possédant de surcroît des moyens pour déterminer des priorités à partir de paramètres contenus dans lesdites requêtes en qualité de service, et dans le quel lesdits moyens d'émission sont aptes à transmettre des requêtes en affectation de priorité basées sur lesdites priorités.

6) Contrôleur d'admission selon la revendication précédente, dans lequel ladite détermination est effectuée en collaboration avec ladite application intermédiaire.

7) Contrôleur d'admission selon l'une des revendications 1 à 7, dans lequel lesdits moyens d'émission sont aptes à transmettre des paramètres de mise en forme du trafic et/ou de dégradation de la qualité de service audit routeur frontière.

8) Contrôleur d'admission selon l'une des revendications précédentes, dans lequel lesdits moyens d'émission sont aptes à transmettre des paramètres de reroutage audit routeur frontière.

9) Contrôleur d'admission selon l'une des revendications précédentes, possédant en outre des moyens d'acquisition de connaissances sur lesdites ressources internes, auprès d'un système de gestion de réseau (NMS).

10) Contrôleur d'admission selon la revendication précédente, possédant des moyens de transmission d'information sur l'utilisation desdites ressources internes, audit système de gestion de réseau.