FR2858735A1 - Equipement de reseau a filtrage adaptable de trafics en vue de mesures de parametres, et procede de mesure associe - Google Patents

Abstract

Un équipement de réseau (RPi), d'un réseau de communications, comprend des moyens de contrôle (MCT), chargés de filtrer des trafics reçus, par exemple de type « bout-en-bout », en fonction d'informations de filtrage, et des moyens d'analyse de trafic (MA) chargés de déterminer des valeurs représentatives de paramètres choisis des trafics filtrés par les moyens de contrôle (MCT).

Description

ÉQUIPEMENT DE RÉSEAU À FILTRAGE ADAPTABLE DE TRAFICS EN VUE DE MESURES DE

PARAMÈTRES, ET PROCÉDÉ DE MESURE

ASSOCIÉ L'invention concerne le domaine des réseaux de communications, et plus particulièrement les mesures de paramètres de trafic au sein de tels réseaux.

On entend ici par mesures aussi bien les mesures de type local 1.o, que les mesures de type bout-en-bout (ou end-to-end ), qu'elles soient liées à la gestion du réseau, ou à la gestion de service, et notamment à la qualité de service (ou QoS).

Par ailleurs, on entend ici par trafic aussi bien des flux de paquets de données que des paquets de données d'un flux. De plus, on entend ci15 après par trafic de type bout-en-bout un trafic traversant intégralement un ensemble de réseaux, un réseau particulier ou au moins un domaine ou sousdomaine d'un réseau à contexte multidomaines.

Il est courant que les opérateurs des réseaux dits gérés passent avec leurs clients des accords de niveau de service (ou SLAs pour Service 20 Level Agreements ) par lesquels ils s'engagent à leur garantir une qualité de service (ou QoS) définie par des valeurs de paramètres ou caractéristiques de trafic, tels que la gigue (ou jitter ), le taux de perte de paquets et le retard de transmission (ou delay ).

Lorsque l'accord porte, par exemple, sur la garantie de la qualité de 25 service associée à des trafics, l'opérateur doit effectuer des mesures de paramètres portant sur lesdits trafics afin de s'assurer du respect des engagements pris.

Trois techniques sont actuellement utilisées pour effectuer des mesures permettant de contrôler des paramètres de qualité de service dans les 30 réseaux gérés.

Une première technique consiste à effectuer des mesures locales en interrogeant régulièrement la base d'informations de gestion (ou MIB pour 2à . 2858735 Management Information Base ) des équipements de réseau concernés ou en leur adressant régulièrement des requêtes reposant sur des commandes dédiées de type CLI (pour Command Line Interface ).

Cette première technique, largement utilisée, permet de déterminer, à 5 partir d'un modèle de mesure reposant sur la modélisation du réseau et du comportement des différents types de trafic au sein dudit réseau, des paramètres locaux, comme par exemple la bande passante utilisée d'une interface de routeur ou la charge de temps de calcul CPU d'un routeur, mais elle ne permet pas de déterminer certaines caractéristiques de trafic de type 0 bout-en-bout, comme par exemple le retard de transmission bout-en-bout d'un flux.

Une deuxième technique, qui concerne plus particulièrement le trafic bouten bout, consiste à effectuer des mesures de bout-en-bout dites actives sur un trafic additionnel injecté dans le réseau et présentant des 15 similitudes avec le trafic devant faire l'objet d'un contrôle. On entend ici par mesures actives des mesures effectuées sur des paramètres du trafic additionnel, et dont les résultats partiels et/ou locaux peuvent être éventuellement intégrés dans le trafic additionnel.

Du fait que le trafic additionnel n'est que partiellement identique au 20 trafic à contrôler, cette deuxième technique ne permet de se faire qu'une idée globale des caractéristiques des trafics bout-en-bout réels, Ainsi, cette technique s'avère limitée quant à son utilisation dans le cadre de la validation des engagements faits aux clients en matière de qualité de service. Elle ne permet pas non plus une facturation des clients en fonction de la qualité de 25 service qui leur est offerte.

Une troisième technique consiste à effectuer des mesures dites passives sur le trafic réel à contrôler à partir de valeurs représentatives de paramètres effectuées au sein des équipements de réseau.

Cette troisième technique permet de déterminer les caractéristiques 30 effectives du trafic réel, mais elle induit une surcharge importante de traitement au niveau des équipements de réseau étant donné que les valeurs représentatives des paramètres sont obtenues à l'aide de dispositifs de mesures qui leurs sont généralement raccordés. La surcharge est d'autant plus importante que tous les paquets de données de tous les flux contrôlés font l'objet d'analyses. En outre, le transfert des valeurs représentatives des paramètres des équipements de réseau vers le système de gestion de réseau monopolise de nombreuses ressources du réseau (principalement la bande passante).

Aucune technique connue n'apportant une entière satisfaction, l'invention a donc pour but d'améliorer la situation.

Elle propose à cet effet un équipement de réseau (comme par exemple un routeur ou un commutateur), pour un réseau de communications 10 géré, comprenant des moyens d'analyse de trafic chargés de déterminer des valeurs représentatives de paramètres choisis de trafics reçus et de les transmettre à un système de gestion du réseau (de type NMS pour Network Management System ), afin qu'il détermine les paramètres choisis.

Cet équipement de réseau se caractérise par le fait qu'il comprend en 5s outre des moyens de contrôle chargés de filtrer (ou échantillonner) certains trafic qu'il reçoit, en fonction d'informations de filtrage, et de transmettre aux moyens d'analyse les trafics filtrés de sorte qu'ils procèdent à la détermination des valeurs représentatives des paramètres choisis de ces trafics filtrés.

Ces moyens de contrôle peuvent être agencés soit pour effectuer un 20 (premier) filtrage (ou échantillonnage) des trafics constitués de flux de paquets de données, soit pour effectuer un (second) filtrage (ou échantillonnage) des trafics constitués de paquets de données, soit encore pour effectuer un premier filtrage portant sur les flux, puis un second filtrage portant sur des paquets choisis des flux filtrés de sorte que les moyens d'analyse déterminent les 25 valeurs représentatives des caractéristiques choisies des paquets filtrés.

Le premier filtrage correspond préférentiellement à l'échantillonnage de flux en fonction de la classe à laquelle ils appartiennent. On entend ici par classe de flux des flux comportant par exemple, dans le cas du protocole IP, un même DSCP, ou les mêmes SRC/DST, ou encore les mêmes 30 DSCP/SRC/DST, mais également des flux concernant des appels VolP (pour Voice over IP ) entre deux réseaux (ou sous-réseaux, ou encore terminaux), ou des flux appartenant tous à une certaine application (par exemple des flux SAP) et/ou échangés entre deux sites. D'une manière générale, le premier é 4 filtrage consiste en une analyse d'au moins une classe choisie de flux à un ou plusieurs niveaux de protocole (IP, UDP/TCP, http, ...) choisis.

Par exemple, le premier filtrage consiste à effectuer une première analyse des flux pour tester leur appartenance à un domaine ou à des sous5 domaines du réseau, puis une seconde analyse d'un ou plusieurs identifiants de flux contenus dans l'entête de chaque paquet appartenant à un flux testé.

Par ailleurs, le second filtrage correspond préférentiellement à l'échantillonnage de flots de paquets en fonction de la classe à laquelle leur flux appartient. Cela peut se faire par exemple par l'utilisation d'une fonction 10 modulo n afin de ne retenir qu'un paquet sur n paquets ou bien à l'aide de

tables statistiques.

Par exemple, le second filtrage peut consister à effectuer une première analyse d'une partie invariante de l'entête des paquets reçus, puis une seconde analyse portant sur un mode choisi de filtrage (ou échantillonnage) 15 des paquets objets de la première analyse.

En outre, les moyens de contrôle de chaque équipement de réseau sont préférentiellement agencés de manière à recevoir les informations de filtrage du système de gestion de réseau (NMS).

L'invention propose également un serveur de gestion pour un système 20 de gestion (NMS) d'un réseau de communications comprenant une multiplicité d'équipements de réseau du type de celui présenté ci-avant.

Ce serveur se caractérise par le fait qu'il comprend, d'une part, des moyens de calcul chargés, lorsqu'ils reçoivent des équipements de réseau des valeurs représentatives de paramètres choisis de trafic, de mesurer les 25 paramètres choisis, et d'autre part, des moyens de gestion chargés de déterminer des informations de filtrage, représentatives de trafics à filtrer, ainsi que les équipements de réseau correspondants, à partir des mesures de paramètre délivrées par les moyens de calcul et d'informations de gestion provenant du système de gestion NMS.

Préférentiellement, les moyens de gestion sont agencés de manière à ordonner la transmission aux équipements de réseau des informations de filtrage correspondantes qu'ils ont déterminées.

Egalement de préférence, les informations de gestion sont choisies parmi la classe du flux, un ou plusieurs identifiants de flux, la précision de mesure d'un paramètre de trafic, la valeur seuil d'un paramètre de trafic et le mode de filtrage (ou d'échantillonnage) des flux ou des paquets.

Par ailleurs, les moyens de gestion peuvent comprendre des moyens 5 d'évaluation chargés de déterminer, à partir de la valeur seuil d'un paramètre et d'une ou plusieurs mesures précédentes de ce paramètre (dont au moins la dernière), une précision minimale de mesure du paramètre de nature à interdire qu'une future mesure de ce paramètre dépasse la valeur seuil compte tenu d'une précision fixée. Dans ce cas, les moyens de gestion peuvent 10 comprendre des premiers moyens de configuration, chargés de définir les informations de filtrage de flux à partir des informations de gestion et/ou de la précision minimale délivrée par les moyens d'évaluation, et/ou des seconds moyens de configuration chargés de définir les informations de filtrage de paquets à partir des informations de gestion et/ou de la précision minimale 15 délivrée par les moyens d'évaluation. Ces seconds moyens de configuration sont préférentiellement agencés de manière à déterminer des caractéristiques de filtrage (définissant un mode d'échantillonnage) à appliquer pour la mesure associée à un paramètre choisi de flots de paquet ou de flux, en fonction de tables statistiques, de la précision fixée et/ou de la précision minimale 20 déterminée par les moyens d'évaluation, et d'informations statistiques sur le paramètre choisi.

En outre, les paramètres sont par exemple des caractéristiques de qualité de service choisies parmi la gigue, le taux de perte de paquets et le retard de transmission. Mais, il pourrait s'agir d'autres paramètres comme par 2 5 exemple des paramètres de gestion de réseau.

L'invention propose en outre un procédé dédié à la mesure de paramètres de trafics entre des équipements de réseau d'un réseau de communications.

Ce procédé se caractérise par le fait qu'il consiste, d'une première part, 30 à transmettre à des équipements de réseau choisis des informations de filtrage de trafics choisis, d'une deuxième part, à filtrer au niveau de ces équipements de réseau choisis les trafics choisis parmi tous ceux qu'ils reçoivent, en fonction des informations de filtrage reçues, afin de déterminer des valeurs représentatives de paramètres choisis de ces trafics filtrés, et d'une troisième part, à déterminer des mesures des paramètres choisis à partir des valeurs déterminées.

Le procédé selon l'invention peut comporter des caractéristiques 5 complémentaires qui pourront être prises séparément ou en combinaison, et notamment: - on peut effectuer au niveau des équipements de réseau choisis soit seulement un (premier) filtrage des trafics constitués de flux de paquets de données, soit seulement un (second) filtrage des trafics constitués de 10 paquets de données, soit encore un premier filtrage portant sur des flux, puis un second filtrage portant sur des paquets choisis des flux filtrés afin de déterminer les valeurs représentatives des paramètres choisis de ces paquets filtrés, - un premier filtrage consistant par exemple en une analyse d'au moins une 1:5 classe choisie de flux à un ou plusieurs niveaux de protocole choisis, - un second filtrage consistant par exemple en un échantillonnage de flots de paquets appartenant à au moins un flux d'une classe choisie, - des informations de filtrage provenant de préférence du système de gestion du réseau (NMS), des informations de filtrage, représentatives des trafics à filtrer, et les équipements de réseau correspondants, déterminés à partir des mesures de paramètre et d'informations de gestion, - on peut déterminer, à partir de la valeur seuil d'un paramètre (information de gestion) et d'une ou plusieurs mesures précédentes de ce paramètre (dont 25 la dernière), une précision minimale de mesure du paramètre qui interdit à une future mesure de ce paramètre de dépasser la valeur seuil compte tenu d'une précision fixée, - on peut définir les informations de filtrage de flux et/ou les informations de filtrage de paquets à partir des informations de gestion et/ou de la précision 30 minimale déterminée, - on peut déterminer des informations de filtrage, représentatives d'un mode (ou type) de filtrage (ou échantillonnage) de flots de paquets ou de flux associés à un paramètre choisi, en fonction de tables statistiques, d'une précision fixée et/ou de la précision minimale déterminée, et d'informations statistiques sur ce paramètre.

L'invention est particulièrement bien adaptée, bien que de façon non exclusive aux réseaux de communications à protocole internet, aux réseaux 5 IP/MPLS, aux réseaux ATM, aux réseaux Ethernet, et aux réseaux mobiles (GPRS/UMTS/EDGE).

D'autres caractéristiques et avantages de l'invention apparaîtront à l'examen de la description détaillée ci-après, et des dessins annexés, sur lesquels: - la figure 1 illustre de façon très schématique un exemple de réseau géré, - la figure 2 illustre de façon schématique, sous la forme de diagrammes bloc, un exemple de réalisation d'un système de gestion de réseau comprenant un serveur de gestion selon l'invention couplé à deux équipements de réseau selon l'invention, 15s - la figure 3 est un diagramme illustrant l'intensité de mesure d'une caractéristique en fonction du temps, pour un seuil donné et une précision donnée, et - la figure 4 est un diagramme illustrant le taux d'échantillonnage de paquets en fonction de la mesure d'un paramètre.

Les dessins annexés pourront non seulement servir à compléter l'invention, mais aussi contribuer à sa définition, le cas échéant.

L'invention a pour objet de permettre la mesure de trafics au sein d'un réseau de communications géré.

Dans ce qui suit, on considèrera que le réseau de communications est 25 un réseau à protocole internet (ou réseau IP). On entend ici par réseau IP un contexte multidomaines constitué d'une somme de domaines et/ou de sousdomaines IP raccordés les uns aux autres.

Mais, I'invention n'est pas limitée à ce seul type de réseau. Elle concerne également, notamment, les réseaux de type IP/MPLS, les réseaux 30 ATM, les réseaux Ethernet, et les réseaux mobiles (GPRS/UMTS/EDGE).

Comme cela est illustré sur la figure 1, un réseau internet N peut être, d'une façon très schématique, assimilé à un ensemble d'équipements de -.4 réseau (ou noeuds) RPi et RC, raccordés entre eux de manière à assurer le routage de paquets de données qu'ils reçoivent, et à un ensemble de terminaux de communication (non représentés), raccordés à certains équipements de réseau (ou noeuds) RPi, éventuellement via un ou plusieurs 5 autres terminaux de type serveur d'accès, de manière à échanger entre eux des paquets de données.

On entend ici par terminal de communication tout équipement de réseau capable d'échanger des paquets de données, comme par exemple un ordinateur portable ou fixe, un téléphone fixe ou mobile, un assistant personnel:_ numérique (ou PDA pour Personal Digital Assistant ), ou un serveur.

Les équipements de réseau (ou noeuds) sont généralement des routeurs périphériques (ou edge routers ) RPi (ici i = 1 à 3, mais il peut prendre n'importe quelle valeur supérieure ou égale à deux), et des routeurs de coeur (ou core routers ). Ici, un seul routeur de coeur RC a été représenté, 1s mais il peut y en avoir plusieurs.

Les terminaux de communication sont habituellement raccordés chacun à l'un des routeurs périphériques RPi, qui leurs servent de noeud d'accès au réseau internet N, et les réseaux périphériques RPi sont généralement reliés entre eux par l'intermédiaire d'un ou plusieurs routeurs de 20 coeur RC.

Dans un réseau IP, chaque domaine ou sous-domaine possède ses propres routeurs périphériques RPi et ses propres routeurs de coeur RC. Dans un réseau IP/MPLS, les équipements de réseau sont appelés Label Switch Routers . Ils se présentent alors soit sous la forme de routeurs, soit sous la 25 forme de commutateurs ATM contrôlés par une fonction de routage.

Le réseau N comporte également un système de gestion de réseau ou NMS (pour Network Management System ) couplé, notamment, à ses équipements de réseau RPi et RC. Ce système de gestion de réseau NMS, également appelé système d'exploitation du réseau, permet notamment au 30 gestionnaire (ou superviseur) du réseau de gérer les équipements de réseau RPi et RC qui le constituent. A cet effet, les équipements de réseau RPi et RC sont agencés de manière à pouvoir échanger des données selon un protocole de gestion de réseau avec le système de gestion NMS, comme par exemple le protocole SNMP (pour Simple Network Management Protocol RFC 25712580).

Comme indiqué ci-avant, I'invention a pour but de permettre la mesure de paramètres choisis de trafics, qu'elle soit de type bout-en-bout ou local.

Dans ce qui suit, on considère à titre d'exemple illustratif que les mesures portent sur des paramètres de trafics de type bout-en-bout. Par ailleurs, on considère dans ce qui suit, à titre d'exemple illustratif, que les paramètres de trafic concernent la gestion de service, et plus particulièrement la gestion de la qualité de service (QoS). Mais, I'invention concerne également _0 la gestion d'autres types de service (niveau OSS), comme par exemple la voix sous IP (VolP), et la gestion de niveau réseau, pour lesquelles les paramètres sont formés par agrégaion de paramètres de niveau inférieur. L'invention concerne également les mesures locales de performance, comme par exemple la charge d'une interface ou d'un tunnel MPLS, ou la charge de calcul CPU ou 15 de la mémoire d'un routeur.

Un trafic de type bout-en-bout est un flux de paquets de données ou un paquet de données d'un flux qui traverse intégralement plusieurs réseaux ou un réseau ou au moins un domaine ou sous-domaine d'un réseau à contexte multidomaines, tel qu'un réseau IP. On entend ici par traverser 20 intégralement le fait de pénétrer dans un réseau ou un domaine par l'un de ses routeurs périphériques RPi, dit routeur d'entrée (ou ingress router ) et de ressortir de celui-ci par un autre de ses routeurs périphériques RPi', dit routeur de sortie (ou egress router ).

Il est important de noter que dans le cas de trafics de type bout-en25 bout les mesures bout-en-bout sont effectuées en deux points d'extrémité du réseau, indépendamment de ce qui se trouve intercalé entre ces deux points de mesure. Ces deux points de mesure peuvent donc être placés à deux extrémités d'un réseau, ou d'une fédération de réseau, ou encore d'un ou plusieurs domaines d'un réseau multidomaines.

Par conséquent, pour déterminer les valeurs représentatives des paramètres de trafics de type bout-en-bout on observe les flux de paquets de données ou simplement les (flots de) paquets de données des flux au niveau des routeurs périphériques RPi du réseau N. Comme illustré sur la figure 2, chaque routeur périphérique RPi, concerné par des mesures bout- en-bout, comporte, tout d'abord, un module d'analyse de trafic MA (également appelé agent d'observation) chargé de déterminer des valeurs représentatives de paramètres choisis de trafic de 5 type bout-en-bout qui lui sont transmis. Ces analyses sont préférentiellement de type passif puisqu'elles portent sur des trafics réels. Elles portent par exemple sur la gigue (ou jitter ) du réseau N, le taux de perte de paquets ou le retard ou délai (< delay ) de transmission.

Le module d'analyse MA est préférentiellement implanté à l'intérieur du o routeur périphérique RPi, mais il peut également être raccordé à celui-ci.

Par ailleurs, le module d'analyse MA du routeur périphérique RPi est agencé pour transmettre les valeurs qu'il détermine à un module de calcul MCM du système de gestion de réseau NMS. Ce module de calcul MCM est préférentiellement implanté dans un serveur de gestion SG du système de 15 gestion de réseau NMS. Il est chargé de mesurer, à l'aide de modèles mathématiques bien connus de l'homme de l'art et appelés métriques MET, les paramètres des trafics de type bout-en-bout qui sont représentés par les valeurs reçues des routeurs périphériques RPi concernés par ces trafics.

Le module de calcul MCM ne faisant pas l'objet de l'invention, il ne 20 sera pas décrit en détail. Il est simplement rappelé qu'il est capable de mesurer des paramètres, mais également de déterminer des statistiques associées (maximum, minimum, valeur moyenne, variation moyenne, écart-type, ...).

Les mesures de paramètres et leurs statistiques associées sont préférentiellement stockées dans une mémoire M, ici du serveur de gestion 25 SG.

Le module de calcul MCM est généralement raccordé à une interface graphique, de type GUI (pour Graphical User Interface ), du système de gestion de réseau NMS (pouvant être implantée dans le serveur de gestion SG). Cela permet au système de gestion NMS de lui transmettre les métriques, 30 mais cela permet également d'afficher sur un écran les résultats des mesures soit en temps réel, soit en différé.

L'interface graphique GUI est habituellement raccordée à un module de commande MCO du système de gestion de réseau NMS, sur lequel on reviendra plus loin.

Selon l'invention, chaque routeur périphérique RPi, concerné par des mesures bout-en-bout, comporte un module de contrôle MCT chargé de filtrer (ou échantillonner) les trafics de type bout-en-bout reçus par les interfaces s d'entrée IE, en fonction d'informations de filtrage, afin de transmettre les trafics filtrés au module d'analyse (les autres trafics poursuivant leur trajet et quittant le routeur par ses interfaces de sortie IS).

En d'autres termes, le module d'analyse MA analyse exclusivement les trafics (flux et/ou paquets) filtrés qui lui sont transmis par le module de contrôle 1o MCT.

On entend ici par filtrer le fait de sélectionner certains flux de paquets de données et/ou certains paquets de données en fonction d'informations de filtrage.

Le filtrage de flux de paquets consiste à sélectionner certains flux 15 parmi tous ceux reçus sur les interfaces d'entrée IE. Bien entendu, les deux routeurs périphériques d'entrée, ici RP1, et de sortie, ici RP2, concernés par un trafic de type bout-en-bout, objet de mesure(s), doivent filtrer (ou sélectionner) le ou les mêmes flux.

D'une manière générale, le filtrage de flux consiste à échantillonner 20 des flux en fonction de la classe à laquelle ils appartiennent.

On entend ici par classe de flux des flux comportant par exemple, pour le protocole IP, un même champ DSCP, ou les mêmes champs SRC/DST, ou encore les mêmes champs DSCP/SRC/DST.

Le module de contrôle MCT peut effectuer cet échantillonnage de flux 25 en analysant la classe d'appartenance des flux à un ou plusieurs niveaux de protocole (IP, UDP/TCP, http, ...) choisis.

Cette analyse peut donc par exemple porter sur les contenus de champs placés dans l'entête des paquets appartenant aux flux reçus, comme par exemple les champs dédiés à la classe du flux (utilisée pour différencier 30 entre eux des flux appartenant à des sous-domaines ou domaines différents du réseau N). Ces champs de classe comportent généralement un identifiant de domaine source, un identifiant de domaine destinataire, un identifiant DSCP et un identifiant de protocole de transmission.

Les contenus de ces champs sont comparés aux contenus des champs de classe définis par les informations de filtrage.

Puis, le module de contrôle MCT compare les contenus des champs d'identification de flux d'une classe donnée (utilisés pour différencier entre eux 5 des flux d'un même type) aux contenus des champs d'identification de flux définis par les informations de filtrage. Ces champs d'identification de flux comportent généralement un identifiant de source, un identifiant de destinataire, un identifiant DSCP et un identifiant de protocole de transmission.

Il ne s'agit là que d'un exemple d'analyse. On peut en effet analyser 10 d'autres champs des protocoles des niveaux supérieurs, comme par exemple les niveaux TOP et http.

Dans l'exemple présenté ci-avant, chaque flux comprenant des paquets dont les entêtes comportent des identifiants de classe et d'identification de flux identiques à ceux définis par les informations de filtrage is est donc sélectionné, puis transmis, en vue d'analyse(s), au module d'analyse MA.

Dans une première variante, le filtrage peut porter sur les paquets d'un ou plusieurs flux. Il s'agit alors non pas de sélectionner un ou plusieurs flux, mais un ou plusieurs paquets d'un ou plusieurs flux parmi tous ceux reçus sur 20 les interfaces d'entrée IE. Bien entendu, les deux routeurs périphériques d'entrée, ici RP1, et de sortie, ici RP2, concernés par un trafic de type bout-enbout, objet de mesure(s), doivent filtrer (ou sélectionner) le ou les mêmes paquets.

D'une manière générale, le filtrage de paquets consiste à 25 échantillonner des flots de paquets appartenant à au moins un flux d'une classe choisie.

Cette analyse peut par exemple porter sur les champs placés dans l'entête des paquets appartenant aux flux reçus. Ces champs à analysés sont spécifiés par les informations de filtrage.

3 0 On peut également utiliser la partie de données utiles (ou data ) des paquets pour effectuer le filtrage de paquets.

Par exemple, le module de contrôle MCT compare une partie invariante de l'entête (et éventuellement de la partie data) des paquets reçus à la partie invariante définie par les informations de filtrage. Cette partie invariante est par exemple le champ d'identification IP.

Puis, le module de contrôle MCT applique aux paquets présélectionnés un mode de filtrage (ou d'échantillonnage) défini par les 5 informations de filtrage. Ce mode de filtrage (ou mode d'échantillonnage) permet de sélectionner définitivement un ou plusieurs paquets pré-sélectionnés afin qu'il(s) soi(en)t analysé(s) par le module d'analyse MA.

Le mode de filtrage définit par exemple une fonction modulo d'échantillonnage, de type modulo deux, consistant à prendre un paquet sur 10 deux (seulement les pairs ou seulement les impairs), ou de type modulo trois, consistant à prendre un paquet sur trois, ou plus généralement modulo n, consistant à prendre un paquet sur n.

Dans une seconde variante, illustrée sur la figure 2, le filtrage peut porter tout d'abord sur les flux, puis sur les paquets d'un ou plusieurs flux. Cela is revient à enchaîner successivement le filtrage de flux puis le filtrage de paquets décrits ci-avant. Bien entendu, dans ce cas ce sont les paquets filtrés qui sont transmis au module d'analyse MA en vue deleur analyse.

Le module de contrôle MCT comprend alors préférentiellement un sousmodule de contrôle de flux M1, couplé aux interfaces d'entrée IE et 20 chargé de filtrer les flux, et un sous-module de contrôle de paquets M2, couplé au sous-module de contrôle de flux M1 et au module d'analyse MA et chargé de filtrer les paquets des flux sélectionnés par M1. Dans le cas d'un simple traitement de flux le module de contrôle MCT ne comprend qu'un sous-module de contrôle de flux M1, tandis que dans le cas d'un simple traitement de 25 paquets le module de contrôle MCT ne comprend qu'un sous-module de contrôle de paquets M2.

Les informations de filtrage peuvent être implantées statiquement dans les routeurs périphériques concernés. Mais, il est préférable qu'elles leurs soient transmises de façon dynamique par le système de gestion de réseau 30 NMS, via le réseau N. Plus préférentiellement encore, ces informations de filtrage sont définies (ou déterminées) en fonction d'informations de gestion, par un module de gestion MG, qui est par exemple implanté dans le serveur de gestion SG.

Une fois qu'il les a définies, le module de gestion MG peut ainsi ordonner au serveur de gestion SG de les transmettre aux routeurs périphériques RPi correspondants.

Les informations de gestion, également appelées politique de filtrage, 5 proviennent du système de gestion de réseau NMS, et plus précisément de son module de commande MCO. Elles indiquent au module de gestion MG les flux et/ou les paquets qui doivent faire l'objet de mesures et les paramètres des flux et/ou paquets qui doivent être mesurés, ainsi que préférentiellement le niveau de précision des mesures et/ou une valeur seuil (ou seuil), associée à 10 un paramètre, à ne pas dépasser. En d'autres termes, les informations de gestion indiquent au module de gestion MG les trafics à contrôler et les paramètres permettant de contrôler la qualité de service associée à ces trafics.

Le module de gestion MG est alors chargé de déterminer les informations de filtrage qui correspondent aux informations de gestion reçues, puis de les 15 transformer en commandes, par exemple de type CLI, compréhensibles par les routeurs périphériques RPi, et plus précisément par leur module de contrôle MCT.

Pour ce faire, le module de gestion MG comporte un module de configuration de mesures de flux MCF et/ou un module de configuration de 20 mesures de paquets MCP, selon la variante envisagée.

Dans une variante particulièrement avantageuse, le module de gestion MG peut comporter un module d'évaluation ME couplé au module de calcul MCM et chargé de déterminer la précision minimale qui doit être mise en ceuvre pour que la future mesure d'un paramètre donné ne dépasse pas la 25 valeur seuil (ou seuil) qui lui correspond (reçue sous forme d'information de gestion), compte tenu de la dernière mesure de ce paramètre et d'éventuelles mesures antérieures et/ou de statistiques de mesures, stockées dans la mémoire M. En effet, si le paramètre à mesurer est par exemple un délai et que, 30 d'une part, la dernière mesure de ce délai est égale à 10 ms et, d'autre part, la valeur seuil est égale à 45 ms, alors la précision minimale de la mesure suivante du délai doit être inférieure à 35 ms.

Cette précision minimale est une information de gestion complémentaire qui influence le choix du mode de filtrage. Par conséquent, dans cette variante de réalisation, le module d'évaluation ME est couplé à chaque sous-module de configuration M1 et/ou M2, de manière à les alimenter en informations de gestion complémentaires, comme par exemple la précision minimale d'un paramètre, ou la dynamicité d'évolution de ce paramètre.

Le sous-module de configuration Ml peut alors définir les informations de filtrage de flux à partir des informations de gestion reçues du NMS et/ou de la précision minimale délivrée par le module d'évaluation ME. De même, le sous-module de configuration M2 peut définir les informations de filtrage de 10 paquets à partir des informations de gestion reçues du NMS eVt/ou de la précision minimale délivrée par le module d'évaluation ME. Le sous-module de configuration M2 peut ainsi déterminer des informations de filtrage représentatives du mode d'échantillonnage (ou de filtrage) des paquets associés à un paramètre choisi, en fonction de tables statistiques, de la 15 précision fixée et/ou de la précision minimale, et d'informations statistiques sur le paramètre choisi, extraites de la mémoire M. L'utilisation de tables statistiques suppose que la mesure du paramètre correspondant soit régie par une loi statistique, comme par exemple la théorie de limite centrale, et que l'on connaisse l'écart type de la mesure du paramètre 2 0 concerné. Cette théorie définit le nombre d'échantillons nécessaires à l'obtention d'une précision 6 donnée pour une mesure de paramètre compte tenu de la valeur moyenne I de la mesure du paramètre et de sa variation moyenne a.

Un exemple de détermination du mode de filtrage (ou 25 d'échantillonnage) va maintenant être décrit en référence aux figures 3 et 4.

L'objectif de cette détermination est de garantir, avec une probabilité fixée, qu'un paramètre ne va pas dépasser un seuil. A cet effet, on calcule tout d'abord à l'intérieur d'une fenêtre de dimension choisie la valeur moyenne de ce paramètre et sa variation moyenne. Puis, on calcule la distance entre la 30 valeur moyenne du paramètre et le seuil. Cette distance, la valeur moyenne et la variation moyenne sont alors utilisées pour déterminer le taux d'échantillonnage (ou mode de filtrage) à l'aide d'une loi dite Normale ou tout autre type de loi appropriée. Un exemple d'application d'une loi Normale est donné sur la figure 4.

Les modules de contrôle MCT des équipements de réseau RPi selon l'invention, et les module de calcul MCM et module de gestion MG du serveur de gestion SG selon l'invention, peuvent être réalisés sous la forme de circuits 5 électroniques, de modules logiciels (ou informatiques) , ou d'une combinaison de circuits et de logiciels.

Il est important de noter que le module de commande MCO et/ou l'interface graphique GUI peuvent être implantés dans le serveur de gestion du système de gestion de réseau NMS.

L'invention offre également un procédé dédié à la mesure de paramètres de trafics entre des équipements de réseau RPi d'un réseau de communications N. Celui-ci peut être notamment mis en ceuvre à l'aide des équipements de réseau RPi et du serveur de gestion SG présentés ci-avant. Les fonctions et 15 sous-fonctions principales et optionnelles assurées par les étapes de ce procédé étant sensiblement identiques à celles assurées par les différents moyens constituant lesdits équipements de réseau RPi et ledit serveur de gestion SG, seules seront résumées ci-après les étapes mettant en ceuvre les fonctions principales du procédé selon l'invention.

Ce procédé consiste, d'une première part, à transmettre à des équipements de réseau RPi choisis des informations de filtrage de trafics choisis, d'une deuxième part, à filtrer au niveau de ces équipements de réseau RPi choisis les trafics choisis parmi tous ceux qu'ils reçoivent, en fonction des informations de filtrage reçues, afin de déterminer des valeurs représentatives 25 de paramètres choisis de ces trafics filtrés, et d'une troisième part, à déterminer des mesures des paramètres choisis à partir des valeurs déterminées.

Grâce à l'invention, il est désormais possible de limiter le volume de données que les équipements de réseau (ou noeuds) et le système de gestion de réseau doivent respectivement traiter lors des mesures de trafic destinées, 30 par exemple, à contrôler la qualité de service, notamment de type bout-enbout. En outre, I'invention permet de réduire notablement le nombre de valeurs qui doivent être transférées des équipements de réseau vers le système de gestion, ce qui permet de limiter les ressources allouées à ce transfert. De plus, 17- 2858735 17 l'invention permet d'adapter le taux d'échantillonnage des trafics en fonction de la précision des mesures requise, ainsi qu'éventuellement de la distance à un seuil de mesure. Enfin, I'invention permet de contrôler avec une plus grande précision les paramètres de trafic qui sont proches de leurs seuils de mesure respectifs.

Tous ces avantages favorisent la montée en charge des réseaux et permettent l'implantation de technologies de contrôle, notamment de type bouten-bout, dans les réseaux opérationnels.

L'invention ne se limite pas aux modes de réalisation d'équipements de 10 réseau, de serveur de gestion et de procédé de mesure décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art dans le cadre des revendications ciaprès.

Ainsi, dans ce qui précède il a été décrit un exemple d'application de l'invention aux mesures de paramètres de trafics de type bout-en-bout, liés à la qualité de service. Mais, I'invention concerne également la gestion d'autres types de service (niveau OSS), comme par exemple la voix sous IP, et la gestion de niveau réseau, ainsi que les mesures locales de performance.

Par ailleurs, dans ce qui précède il a été décrit un exemple d'application de l'invention à un équipement de réseau de type routeur. Mais, l'invention concerne également les boîtiers de mesure externes qui sont raccordés à de tels équipements de réseau afin de déterminer des valeurs représentatives de paramètres choisis des trafics qu'ils reçoivent.

Claims (34)

REVENDICATIONS

1. Equipement de réseau (RPi) pour un réseau de communications (N), 5 comprenant des moyens d'analyse de trafic (MA) propres à déterminer des valeurs représentatives de paramètres choisis de trafics reçus et à les transmettre à un système de gestion (NMS) dudit réseau (N) afin qu'il détermine lesdits paramètres choisis, caractérisé en ce qu'il comprend des moyens de contrôle (MCT) agencés pour filtrer certains trafics reçus, en.o fonction d'informations de filtrage, et pour transmettre auxdits moyens d'analyse (MA) lesdits trafics filtrés de sorte qu'ils procèdent à la détermination des valeurs représentatives des paramètres choisis desdits trafics filtrés.

2. Equipement selon la revendication 1, caractérisé en ce que lesdits moyens de contrôle (MCT) sont agencés pour effectuer un premier filtrage des 15 trafics constitués de flux de paquets de données de sorte que lesdits moyens d'analyse (MA) déterminent des valeurs représentatives des paramètres choisis des flux filtrés.

3. Equipement selon la revendication 1, caractérisé en ce que lesdits moyens de contrôle (MCT) sont agencés pour effectuer un premier filtrage 20 portant sur des trafics constitués de flux de paquets de données de manière à filtrer des flux choisis, puis pour effectuer un second filtrage portant sur des paquets choisis desdits flux filtrés de manière à transmettre auxdits moyens d'analyse (MA) lesdits paquets filtrés de sorte qu'ils procèdent à la détermination des valeurs représentatives des paramètres choisis desdits 25 paquets filtrés.

4. Equipement selon l'une des revendications 2 et 3, caractérisé en ce que ledit premier filtrage consiste en une analyse d'au moins une classe choisie de flux à au moins un niveau de protocole choisi.

5. Equipement selon la revendication 1, caractérisé en ce que lesdits 30 moyens de contrôle (MCT) sont agencés pour effectuer un second filtrage des trafics constitués de paquets de données de sorte que lesdits moyens d'analyse (MA) déterminent des valeurs représentatives des paramètres choisis des paquets filtrés.

6. Equipement selon l'une des revendications 3 et 5, caractérisé en ce que ledit second filtrage consiste en un échantillonnage de flots de paquets appartenant à au moins un flux d'une classe choisie.

7. Equipement selon l'une des revendications 1 à 6, caractérisé en ce 5 que lesdits moyens de contrôle (MCT) sont agencés pour recevoir lesdites informations de filtrage dudit système de gestion de réseau (NMS).

8. Serveur de gestion (SG) pour un système de gestion (NMS) d'un réseau de communications (N) comprenant une multiplicité d'équipements de réseau (RPi) selon l'une des revendications précédentes, caractérisé en ce 10 qu'il comprend i) des moyens de calcul (MCM) agencés, à réception de valeurs représentatives de paramètres choisis de trafic reçu desdits équipements de réseau (RPi), pour mesurer lesdits paramètres choisis, et ii) des moyens de gestion (MG) agencés pour déterminer des informations de filtrage, représentatives de trafics à filtrer, et les équipements de réseau (RPi) 15 correspondants, à partir desdites mesures de paramètres délivrées par lesdits moyens de calcul (MCM) et en fonction d'informations de gestion.

9. Serveur selon la revendication 8, caractérisé en ce que lesdits moyens de gestion (MG) sont agencés pour ordonner la transmission auxdits équipements de réseau (RPi) des informations de filtrage correspondantes.

10. Serveur selon l'une des revendications 8 et 9, caractérisé en ce que lesdites informations de gestion sont choisies dans un groupe comprenant au moins une classe de flux, au moins un identifiant de flux, une précision de paramètre de trafic, une valeur seuil de caractéristique de trafic et un mode de filtrage de trafic.

11. Serveur selon la revendication 10, caractérisé en ce que lesdits moyens de gestion (MG) comprennent des moyens d'évaluation (ME) agencés pour déterminer, à partir d'une valeur seuil de paramètre et d'au moins la dernière mesure dudit paramètre, une précision minimale de mesure dudit paramètre interdisant à une future mesure de ce paramètre de dépasser la 30 valeur seuil compte tenu d'une précision fixée.

12. Serveur selon la revendication 11, caractérisé en ce que lesdits moyens d'évaluation (ME) sont agencés pour déterminer ladite précision minimale de mesure d'un paramètre à partir d'une valeur seuil de paramètre et fi* 2858735 ' s 20 d'un nombre choisi d'anciennes mesures dudit paramètre.

13. Serveur selon l'une des revendications 11 et 12, caractérisé en ce que lesdits moyens de gestion (MG) comprennent des premiers moyens de configuration (MCF) agencés pour définir lesdites informations de filtrage de 5 flux à partir desdites informations de gestion et/ou de ladite précision minimale délivrée par lesdits moyens d'évaluation (ME).

14. Serveur selon l'une des revendications 11 à 13, caractérisé en ce que lesdits moyens de gestion (MG) comprennent des seconds moyens de configuration (MCP) agencés pour définir lesdites informations de filtrage de 1o paquets à partir desdites informations de gestion et/ou de ladite précision minimale délivrée par lesdits moyens d'évaluation (ME).

15. Serveur selon l'une des revendications 13 et 14, caractérisé en ce que lesdits seconds moyens de configuration (MCP) sont agencés pour déterminer des informations de filtrage représentatives d'un mode de filtrage de 15 trafics associés à un paramètre choisi, en fonction de tables statistiques, d'une précision fixée et/ou de ladite précision minimale déterminée, et d'informations statistiques sur ledit paramètre.

16. Serveur selon l'une des revendications 8 à 15, caractérisé en ce que lesdits paramètres sont des caractéristiques de qualité de service choisies 20 dans un groupe comprenant au moins une gigue, un taux de perte de paquets et un retard de transmission.

17. Procédé de mesure de caractéristiques de trafics entre des équipements de réseau (RPi) d'un réseau de communications (N), caractérisé en ce qu'il consiste i) à transmettre à des équipements de réseau (RPi) choisis 25 des informations de filtrage de trafics choisis, puis ii) à filtrer au niveau desdits équipements de réseau (RPi) choisis lesdits trafics choisis parmi les trafics qu'ils reçoivent, en fonction desdites informations de filtrage, de manière à déterminer des valeurs représentatives de paramètres choisis desdits trafics filtrés, et iii) à déterminer des mesures desdits paramètres choisis à partir 30 desdites valeurs déterminées.

18. Procédé selon la revendication 17, caractérisé en ce que l'on effectue au niveau desdits équipements de réseau (RPi) choisis un premier filtrage des trafics constitués de flux de paquets de données de manière à déterminer des valeurs représentatives des paramètres choisis des flux filtrés.

19. Procédé selon la revendication 17, caractérisé en ce que l'on effectue au niveau desdits équipements de réseau (RPi) choisis un premier filtrage portant sur des trafics constitués de flux de paquets de données de manière à 5 filtrer des flux choisis, puis un second filtrage portant sur des paquets choisis desdits flux filtrés de manière à déterminer des valeurs représentatives des paramètres choisis desdits paquets filtrés.

20. Procédé selon l'une des revendications 18 et 19, caractérisé en ce que ledit premier filtrage consiste en une analyse d'au moins une classe 10 choisie de flux à au moins un niveau de protocole choisi.

21. Procédé selon la revendication 17, caractérisé en ce que l'on effectue au niveau desdits équipements de réseau (RPi) choisis un second filtrage des trafics constitués de paquets de données de manière à déterminer des valeurs représentatives des paramètres choisis des paquets filtrés.

15s

22. Procédé selon l'une des revendications 18 et 20, caractérisé en ce que ledit second filtrage consiste en un échantillonnage de flots de paquets appartenant à au moins un flux d'une classe choisie.

23. Procédé selon l'une des revendications 17 à 22, caractérisé en ce que lesdites informations de filtrage proviennent d'un système de gestion 20 (NMS) dudit réseau (N).

24. Procédé selon l'une des revendications 17 à 23, caractérisé en ce que lesdites informations de filtrage, représentatives de trafics à filtrer, et les équipements de réseau (RPi) correspondants, sont déterminés à partir desdites mesures de paramètre et d'informations de gestion.

25. Procédé selon la revendication 24, caractérisé en ce que lesdites informations de gestion sont choisies dans un groupe comprenant au moins une classe de flux, au moins un identifiant de flux, une précision de paramètre de trafic, une valeur seuil de paramètre de trafic et un mode de filtrage de trafic.

26. Procédé selon la revendication 25, caractérisé en ce que l'on 30 détermine, à partir d'une valeur seuil de paramètre et d'au moins la dernière mesure dudit paramètre, une précision minimale de mesure dudit paramètre interdisant à une future mesure de ce paramètre de dépasser la valeur seuil compte tenu d'une précision fixée.

2;2 2858735 " ' 22

27. Procédé selon la revendication 26, caractérisé en ce que l'on détermine ladite précision minimale de mesure d'un paramètre à partir d'une valeur seuil de paramètre et d'un nombre choisi d'anciennes mesures dudit paramètre.

28. Procédé selon l'une des revendications 26 et 27, caractérisé en ce que l'on définit lesdites informations de filtrage de flux à partir desdites informations de gestion et/ou de ladite précision minimale déterminée.

29. Procédé selon l'une des revendications 26 à 28, caractérisé en ce que l'on définit lesdites informations de filtrage de paquets à partir desdites 10 informations de gestion et/ou de ladite précision minimale déterminée.

30. Procédé selon l'une des revendications 28 et 29, caractérisé en ce que l'on détermine des informations de filtrage représentatives d'un mode de filtrage de trafics associés à un paramètre choisi en fonction de tables statistiques, d'une précision fixée et/ou de ladite précision minimale 15 déterminée, et d'informations statistiques sur ledit paramètre.

31. Procédé selon l'une des revendications 17 à 30, caractérisé en ce que lesdits paramètres sont des caractéristiques de qualité de service choisies dans un groupe comprenant au moins une gigue, un taux de perte de paquets et un retard de transmission.

32. Utilisation de l'équipement de réseau (RPi) et du procédé de mesure selon l'une des revendications précédentes dans les réseaux de communications choisis parmi les réseaux à protocole internet, les réseaux IP/MPLS, les réseaux ATM, les réseaux Ethernet et les réseaux mobiles, en particulier de type GPRS, UMTS et EDGE. 25

33. Utilisation selon la revendication 32, caractérisée en ce que les mesures sont choisies dans un groupe comprenant les mesures de gestion de réseau et les mesures de gestion de service.

34. Utilisation selon la revendication 33, caractérisée en ce que lesdites mesures sont de type bout-en-bout ou de type local,