FR2857539A1

FR2857539A1 - Description de contenu de paquets dans un reseau de communication par paquets

Info

Publication number: FR2857539A1
Application number: FR0308524A
Authority: FR
Inventors: Moigne Olivier Le; Olivier Marce
Original assignee: Alcatel CIT SA; Alcatel SA
Current assignee: Alcatel CIT SA; Alcatel Lucent SAS
Priority date: 2003-07-11
Filing date: 2003-07-11
Publication date: 2005-01-14
Anticipated expiration: 2023-07-11
Also published as: EP1647125A1; FR2857539B1; CN1836421A; WO2005008992A1; US20060221929A1

Abstract

Le procédé de fonctionnement d'un noeud d'un réseau de communication par paquets, en particulier d'un routeur IP, comprend les étapes suivantes :a) réception par le noeud d'un paquet (10) depuis le réseau ;b) réception par le noeud d'une information (13) indépendante des protocoles des couches OSI 5 à 7 - voire des couches OSI 4 à 7 - du paquet et concernant au moins l'une des caractéristiques suivantes :- le type de données transportées dans le paquet,- la source d'émission des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet, et- le destinataire des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet ;c) traitement du paquet (10) par le noeud en fonction de ladite description.Il est avantageux que ladite information soit contenue dans le paquet lui-même.

Description

DESCRIPTION DE CONTENU DE PAQUETS DANS UN RESEAU DE COMMUNICATION PAR

PAQUETS

L'invention a trait aux réseaux de communication par paquets mettant en oeuvre des protocoles organisés en couches tels que standardisées dans le modèle de référence OSI ( Open System Interconnection ) défini par l'Organisation internationale de normalisation, dit ISO ou pouvant s'y assimiler. Plus particulièrement, l'invention concerne un procédé de fonctionnement d'un noeud d'un réseau de communication par paquets, en particulier d'un routeur IP. Elle concerne aussi un paquet de données pour un réseau de communication par paquets et un générateur de paquets de données pour un réseau de communication par paquets.

L'optimisation de la transmission des paquets émis dans un réseau de communication par paquets tel qu'un réseau au protocole IP (de l'anglais Internet Protocol ) repose sur le traitement spécifique des paquets au niveau des noeuds du réseau en fonction de leur contenu. Dans le cas d'un réseau au protocole IP, les noeuds sont traditionnellement appelés routeurs.

En particulier, les mécanismes de qualité de service ou QoS dans les réseaux comprennent un traitement différencié de paquets émis sur le réseau, en fonction de paramètres tels que l'expéditeur, le destinataire ou le type de données contenu dans le paquet. Les noeuds du réseau traitent les paquets en fonction de ces paramètres, par exemple en leur attribuant un routage, une bande passante, une priorité, ou toute autre caractéristique adéquate. La qualité de service est en particulier primordiale pour garantir une transmission dans de bonnes conditions de paquets contenant de la voix ou de la vidéo, notamment dans le cas de voix sur IP ou de vidéo sur IP.

II est donc nécessaire de pouvoir déterminer ces paramètres pour gérer correctement et efficacement les flux de paquets.

Il existe des logiciels tels que PacketShaperTM de la société américaine Packeter, Inc. ou des processeurs tels que Content Processor 5000TM de la société américaine LeWiz Communications, Inc prévus pour être mis en oeuvre dans les routeurs et qui réalisent une estimation du type de données contenues dans un paquet. Le routeur réalise cette estimation du type de données contenues dans le paquet en examinant les paquets pour déterminer les protocoles utilisés dans la partie des paquets correspondant aux couches OSI 5 à 7 (c'est-à-dire les couches 5 à 7 du modèle de référence OSI). Le routeur peut notamment déterminer que le protocole utilisé est FTP (de l'anglais File Transfer Protocol ) ou HTTP (de l'anglais Hypertext Transfer Protocol ). Ensuite, le routeur examine éventuellement les autres parties du paquet pour déterminer le type de données contenues dans le paquet, par exemple par reconnaissance de la signature d'une application ou d'un type de données présente parmi les données dans le corps du paquet (appelé paylaod ). Le routeur suppose que le paquet appartient à une catégorie de traitement prédéfinie en fonction du protocole reconnu ainsi que de l'éventuelle signature reconnue. Le paquet est ensuite classé dans la catégorie prédéfinie, et le routeur lui applique les traitements correspondants à cette catégorie.

Ce procédé présente cependant des inconvénients. D'une part, lors de l'utilisation d'un nouveau protocole dans les couches OSI 5 à 7 d'un paquet, le protocole n'est pas reconnu par un routeur non mis à jour. Le routeur ne peut donc plus supposer le contenu d'un tel paquet de données. Le routeur ne peut alors plus réaliser une gestion de la qualité de service en fonction du contenu d'un paquet.

D'autre part, un même protocole peut être utilisé pour des types de données différentes. Par exemple, le protocole HTTP est utilisé à la fois pour le transport de contenus interactifs et pour le transfert de fichiers statiques, et ne permet de transporter des informations que sur les données qui sont transportées dans une séquence de paquets (typiquement un flux TCP) et pas par un paquet seul. Ainsi, le routeur ne peut pas déterminer précisément le type de données uniquement en fonction du protocole de transmission utilisé. Par ailleurs, il n'est pas possible de programmer le routeur pour reconnaître de façon exhaustive les signatures de toutes les applications ou de tout type de données qui peuvent être présentes dans le paquet. De plus, il se pose le problème de la mise à jour des routeurs avec les signatures de nouvelles applications ou de données à un nouveau format. Le routeur n'est donc pas toujours capable de reconnaître correctement le type de données contenues dans les paquets. La qualité de service n'est alors pas optimale car les différents types de données peuvent requérir des exigences techniques différentes.

Une autre possibilité pour fournir les paramètres utiles aux routeurs consisterait à utiliser un protocole de signalisation connu qui soit prévu pour fournir des informations de ce type. Ainsi, il est envisageable de recourir au protocole SIP (de l'anglais Session Initiation Protocol ) qui permet d'envoyer des messages contenant le type de données transporté dans un flux de paquets. Néanmoins, cette solution présente des inconvénients car les messages sont émis d'un élément réseau émetteur vers un élément réseau destinataire et ne sont pas conçu pour faciliter leur interprétation par les routeurs. En particulier, ils sont transportés dans une séquence de paquets qui doivent être le cas échéant ré-ordonnancés avant de pouvoir interpréter leur contenu. De plus, le protocole de signalisation étant différent du protocole de transmission des paquets de données décrits, la probabilité que le message et les paquets de données empruntent des trajets différents est extrêmement élevée. Ainsi, les routeurs empruntés par les paquets de données ne disposent pour la plupart pas de la description contenue dans le message. Ces routeurs ne peuvent donc pas gérer de façon optimale la transmission des paquets de données.

Il existe donc un besoin pour un procédé de transmission qui résolve un ou plusieurs des inconvénients cités auparavant.

L'invention a ainsi pour objet un procédé de fonctionnement d'un noeud d'un réseau de communication par paquets, en particulier d'un routeur IP, 20 comprenant les étapes de: a) réception par le noeud d'un paquet depuis le réseau; b) réception par le nceud d'une information indépendante des protocoles des couches OSI 5 à 7 du paquet et concernant au moins l'une des caractéristiques suivantes: - le type de données transportées dans le paquet, - la source d'émission des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet, et - le destinataire des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet; c) traitement du paquet par le noeud en fonction de ladite description.

Il est plus avantageux encore que l'information reçue dans l'étape b) soit indépendante des protocoles des couches OSI 4 à 7 du paquet.

Selon un mode de réalisation préféré, ladite information est contenue dans le paquet, l'étape b) comprenant la lecture de ladite information dans le paquet par le noeud. Ladite information peut notamment être contenue dans l'en-tête au protocole de la couche OSI 3 du paquet, l'étape b) comprenant alors la lecture par le noeud de ladite information dans l'en-tête au protocole de la couche OSI 3 du paquet.

Selon un autre mode de réalisation préféré, le paquet contient un identifiant de ladite information, l'étape a) comprenant la lecture de l'identifiant par le noeud. L'identifiant peut notamment être contenu dans l'en-tête au protocole de la couche OSI 3 du paquet, l'étape a) comprenant la lecture par le noeud de l'identifiant dans l'en-tête au protocole de la couche OSI 3 du paquet. Par ailleurs, il est avantageux que l'étape b) comprenne la réception par le noeud d'un autre paquet depuis le réseau, ledit autre paquet contenant ladite information. Ladite information peut notamment être contenue dans l'en-tête au protocole de la couche OSI 3 dudit autre paquet, l'étape b) comprenant alors la lecture par le noeud de ladite information dans l'en-tête au protocole de la couche OSI 3 dudit autre paquet. En variante, Procédé selon ladite information peut être contenue dans le corps selon le protocole de la couche OSI 3 dudit autre paquet, l'étape b) comprenant alors la lecture par le noeud de ladite information dans le corps selon le protocole de la couche OSI 3 dudit autre paquet. II est avantageux que ledit autre paquet contienne en outre l'identifiant, l'étape b) comprenant également la lecture par le noeud de l'identifiant dans ledit autre paquet. L'identifiant peut notamment être contenu dans l'en-tête au protocole de la couche OSI 3 dudit autre paquet auquel cas l'étape b) comprend la lecture par le noeud de l'identifiant dans l'en-tête au protocole de la couche OSI 3 dudit autre paquet. Le procédé peut encore avantageusement comprendre après l'étape b), une étape d'envoi par le noeud vers une base de données, de l'identifiant et de ladite information.

Selon un autre mode de réalisation préféré, le procédé comprend après l'étape a) et avant l'étape b), une étape d'interrogation par le noeud d'une base de 30 données avec l'identifiant.

Selon un autre aspect, l'invention propose aussi un paquet de données pour un réseau de communication par paquets, comprenant une information indépendante des protocoles des couches OSI 5 à 7 du paquet et concernant au moins l'une des caractéristiques suivantes: - le type de données transportées dans le paquet, - la source d'émission des données transportées dans le paquet autre que 5 l'adresse réseau de la source d'émission du paquet, et - le destinataire des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet.

II est plus avantageux encore que ladite information soit indépendante des protocoles des couches OSI 4 à 7 du paquet.

Selon un mode de réalisation préféré, ladite information est contenue dans l'en-tête au protocole de la couche OSI 3 du paquet. De façon préférentielle, le paquet est au protocole IP, ladite information étant contenue dans l'en-tête IP.

Selon un autre aspect encore, l'invention propose un générateur de paquets selon l'invention tels que définis précédemment.

D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description qui suit de modes de réalisation de l'invention, donnée à titre d'exemple et en référence aux dessins annexés qui montrent: -figure 1, une représentation schématique d'un exemple de réseau de transmission dans lequel l'invention est mise en oeuvre; -figure 2, une structure d'un paquet de données contenant une description de données; -figure 3, une structure d'un paquet de données contenant un identifiant de description de données; -figure 4a, une structure d'un paquet de données contenant à la fois un 25 identifiant de données et une description de données dans l'entête du paquet; -figure 4b, une structure d'un paquet de données contenant un identifiant de description de données placée dans l'en-tête du paquet et une description de données placée dans le corps du paquet; -figure 5, une structure d'un paquet de données contenant une description de données dans le corps du paquet.

Selon l'invention, le procédé de fonctionnement d'un noeud d'un réseau de communication par paquets, comprend les étapes de a) réception par le noeud d'un paquet depuis le réseau; b) réception par le noeud d'une information indépendante des protocoles des couches OSI 5 à 7 du paquet et concernant au moins l'une des caractéristiques suivantes: le type de données transportées dans le paquet, la source d'émission des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet, et le destinataire des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet; c) traitement du paquet par le noeud en fonction de ladite description.

L'on comprendra que l'ordre dans le temps des étapes a) et b) est indifférent. Autrement dit, l'étape a) peut être postérieure ou antérieure à l'étape b). Les étapes a) et b) peuvent également être concomitante notamment dans le cas où ladite information est contenue dans le paquet lui-même.

L'on comprendra que ladite information peut concerner uniquement l'une quelconque des caractéristiques indiquées dans l'étape b), ou deux quelconques d'entre elles ou encore les trois. Elles peut encore comporter d'autres informations concernant par exemple le traitement à effectuer par le noeud sur les paquets.

Le fait que ladite information est fournie au noeud permet donc à ce dernier de traiter le paquet par exemple de choisir un chemin dans le réseau - en fonction de ladite information. Autrement dit, le traitement du paquet ne dépend plus seulement des informations contenues conventionnellement dans le paquet à cette fin telles que l'adresse réseau de la source du paquet et l'adresse réseau du destinataire final du paquet.

Du fait que ladite information est indépendante des protocoles des couches OSI 5 à 7 utilisés dans le paquet, le noeud peut lire et comprendre ladite information sans connaître ces protocoles. Autrement dit, le noeud est capable de traiter le paquet en fonction de ladite information sans connaître les protocoles des couches 5 à 7. Il est encore plus avantageux que ladite information soit indépendante du protocole de la couche OSI 4 utilisé dans le paquet, ce qui permet au noeud de traiter le paquet en fonction de ces informations indépendamment de ce protocole. En effet, un noeud de réseau peut ne pas être capable d'analyser la couche correspondante des paquets qu'il reçoit ou encore il n'est pas souhaitable qu'il doive pouvoir le faire pour des raisons de vitesse de traitement.

Ladite information est avantageusement écrite selon un code ou langage que le noeud est capable de comprendre. Ce code ou langage peut toujours être le 5 même quel que soit le paquet concerné.

De façon préférée, ladite information peut être incluse dans la paquet lui-même. Ceci permet de faire parvenir de façon simple et fiable ladite information au noeud du réseau pour traiter le paquet de données correspondant. II est avantageux que ladite information soit complètement contenue dans le paquet concerné par l'information car il 'agit d'une manière simple d'assurer que le noeud reçoive toujours ladite information pour chacun des paquets. Si, au contraire, ladite information était répartie dans plusieurs paquets, le noeud doit la reconstituer à partir de la pluralité de paquets en les ordonnançant de façon adéquate, ce qui rend l'opération plus complexe. De plus, le noeud peut être dans l'impossibilité de reconstituer l'information s'il ne reçoit pas l'un d'entre eux par exemple en cas de changement de chemin de routage dans le réseau.

Etant donnée que les données envoyées d'un terminal émetteur vers un terminal destinataire dans un réseau sont généralement transportées dans un flux constitués de nombreux paquets contenant chacun le même type de données par exemple audio, chaque paquet peut simplement contenir - au lieu de ladite information - un identifiant de ladite information, l'identifiant étant indépendant des protocoles des couches OSI 5 à 7, voire des couches OSI 4 à 7, utilisés dans le paquet. Le noeud détermine alors ladite information qui correspond à l'identifiant pour traiter chaque paquet en fonction de ladite information. Ladite information peut être fourni au noeud par différents moyens telles que par un paquet qui la contient ou par une base de donnée qu'il interroge.

L'invention est particulièrement adaptée à être mise en oeuvre dans un réseau au protocole IP (qui correspond à la couche OSI 3). On rappelle qu'un réseau IP est organisé typiquement en quatre couches: la couche Internet au protocole IP correspondant à la couche OSI 3, la couche transport (typiquement au protocole TCP ou UDP) correspondant à la couche OSl 4, et la couche application correspondant aux couches OSI 5 à 7.

La figure 1 représente schématiquement un exemple de réseau de communication par paquets 1, en l'occurrence un réseau au protocole IP. Le réseau 1 comprend un terminal 2 envoyant des paquets de données par l'intermédiaire d'un sous-réseau 3 vers un destinataire final non représenté. On désignera dans la suite par données utiles d'un paquet les données transportées dans ce paquet qui sont à transmettre au destinataire final du paquet soit en l'état, soit éventuellement sous forme modifiée (dans le cas de traitement effectué par le réseau sur les données transportées).

Le sous-réseau 3 est muni de routeurs 4 à 7 fournissant plusieurs trajets de 10 routage aux paquets de données à travers le sous-réseau 3.

Le terminal 2 comprend un générateur 8 de paquets de données pouvant être d'un type quelconque connu, par exemple une application logicielle de transmission de voix ou de vidéo sur IP. Le générateur 8 génère des paquets de données au protocole IP qui sont envoyés vers le destinataire final à travers le sous- 1 5 réseau 3 grâce à une interface 9 adéquate du terminal 2.

Pour assurer un traitement correct d'un paquet émis par le générateur 8, il est souhaitable que le routeur qui reçoit ce paquet puisse connaître des informations concernant les données utiles transportées, leur source ou leur destinataire. Dans ce but, l'on fait parvenir au routeur des informations à ce sujet pour lui permettre de traiter le paquet de façon adéquate. Pour la suite, nous prendrons en exemple la fourniture au routeur d'informations concernant les données transportées que l'on désignera par commodité de description de données.

Selon un premier mode de réalisation, cette description de données est placée dans le paquet transportant ces données. Plus particulièrement, il est avantageux que la description de données soit placée dans l'en-tête IP de ce paquet comme illustré par la figure 2.

La figure 2 représente la structure d'un paquet 10 comprenant un en-tête IP 1 1 et un corps 1 2 (aussi communément appelé payload en anglais). L'en-tête 1 1 comprend une description 13 des données utiles contenues dans le corps 12 du paquet. Le corps 12 contient les données utiles à transmettre au destinataire final du paquet et qui peuvent être au format d'un protocole d'une couche OSI supérieure à la couche IP, ce dernier étant un protocole correspondant à la couche OSI 3. En particulier, le corps 12 peut classiquement contenir un en-tête à un protocole correspondant à la couche OSI 4 (dite couche transport) tel que TCP (de l'anglais Transmission Control Protocol ) ou UDP (de l'anglais User Datagram Protocol ) encapsulant les données utiles à transmettre au destinataire du paquet. Les données sont au format d'un protocole de la couche application du modèle IP qui correspond aux couches OSI 5 à 7 comme mentionné plus haut. Ces données peuvent par exemple être de la voix sur IP ou de la vidéo sur IP.

Les routeurs 4 à 7 sont prévus pour lire la description de données 13 placée dans l'en-tête IP 11 des paquets qu'ils reçoivent et traiter chaque paquet en fonction de la description 13 contenue dans son en-tête IP.

Le fait que la description de données 13 soit placée dans l'en-tête IP du paquet 10 est avantageuse puisque le routeur peut la lire en analysant uniquement l'en-tête I P 1 1 du paquet. Or, un routeur est classiquement capable d'analyser les en-têtes IP. Au contraire, il n'a pas besoin de traiter le corps 12 du paquet. Ainsi, le routeur n'a pas besoin de connaître le ou les protocoles des couches OSI 4 à 7 qui sont éventuellement utilisées dans le corps 12 du paquet. Par conséquent, l'on évite que le routeur ait à faire des traitements sur les données dans le corps 12 du paquet et en particulier sur les données utiles transportées, le routeur n'étant pas destiné à effectuer ce type de traitement. D'autre part, le routeur est en mesure de traiter la description de données 13 quel que soient le ou les protocoles des couches OSI 4 à 7 utilisés dans le corps 12 du paquet. Enfin, la description 13 complète étant contenue dans le paquet à traiter, le routeur n'a pas besoin de reconstituer préalablement la description en lisant plusieurs paquets différents qu'il réordonnance avant de pouvoir traiter un paquet en fonction de la description de données.

Ce mode de réalisation est particulièrement adapté à être mis en oeuvre avec les paquets au protocole IPv6 car un tel paquet présente une en-tête 1 1 de taille suffisante pour inclure une description de donnée. Dans ce cas, la description de données 13 peut notamment être placée dans une extension d'en-tête (appelée extension header en anglais) de l'entête IPv6, par exemple une extension d'en-tête du type dit Hop-by-Hop Options .

Mais ce mode de réalisation peut également être mis en oeuvre avec les paquets au protocole IPv4 par exemple en inscrivant la description de données 13 dans une option de l'en-tête 11.

Par ailleurs, il est avantageux d'avoir une information dans l'en-tête 1 1 du paquet indiquant au routeur le fait qu'il contient une description de données. Il peut notamment s'agir d'un marqueur prédéterminé dans l'entête IP. Sous IPv6, dans le cas cité où la description de données 13 est placée dans une extension d'en-tête, il peut par exemple s'agir d'un code prédéterminé placé dans l'extension d'en-tête immédiatement à la suite de son propre en-tête. Sous IPv4, dans le cas cité où la description de données 13 est placée dans une option d'en-tête, il peut notamment s'agir de l'octet codant le type d'option.

Concernant les traitements à effectuer par un routeur donné en fonction de la description de données 13, le routeur peut être configuré par un gestionnaire de routage 20 (appelé en anglais Policy Decision Point ou PDP) par exemple via le réseau IP lui-même.

Bien entendu, dans le cas d'un routeur non prévu pour interpréter la description de données 13, il peut se borner à traiter - en particulier router - le paquet 10 de façon conventionnelle sans tenir compte de la description 13.

Dans ce premier mode de réalisation, chaque paquet 10 est traité par les routeurs en fonction de la description de données 13 qui est placée dans ce paquet. Selon un deuxième mode de réalisation, un identifiant de la description de données est placée dans le paquet IP envoyé par le terminal 2. Plus précisément, à un identifiant placé dans un paquet de données correspond une description des données utiles transportées dans le paquet contenant cet identifiant. Là-encore, l'identifiant peut avantageusement être inclus dans l'en-tête IP du paquet. La figure 3 illustre la structure d'un tel paquet l0a avec un identifiant 14 de la description de données qui est placée dans l'en-tête IP 11, le corps (ou payload ) du paquet étant référencé 12.

Sous IPv6 ou IPv4, l'identifiant peut par exemple être placée dans une extension d'en-tête ou une option respectivement de façon similaire à celle décrite pour la description de données 13 dans le premier mode de réalisation.

Par ailleurs, i l est avantageux d'avoir une information dans l'en-tête 1 1 du paquet indiquant au routeur le fait qu'il contient un identifiant 14. Sous IPv4 ou IPv6, cela peut être mis en oeuvre de façon similaire aux exemples données pour l'indication de la présence de la description de données 13 dans le premier mode de réalisation.

Les routeurs 4 à 7 peuvent être prévus pour lire l'identifiant 14 dans l'en-têtes IP 11 des paquets qu'ils reçoivent et déterminer la description de données qui correspond à l'identifiant 14. Ensuite, le routeur traite le paquet en fonction de la description de données correspondante à l'identifiant 14 contenu dans son en-tête IP 11.

Ce mode de réalisation est avantageux par rapport au précédent dans la mesure où la taille de l'identifiant 14 peut être moindre en comparaison de la description de données, ce qui laisse donc plus de place disponibles dans les paquets pour les données utiles à transporter.

Il existe différente manière de mettre à disposition d'un routeur la description de données correspondant à un identifiant 14.

Une manière avantageuse consiste à envoyer sur le réseau un paquet IP contenant à la fois l'identifiant 14 et la description de données correspondant à l'identifiant 14. Ce paquet est préférentiellement envoyé le long du chemin à travers le réseau qui sera emprunté subséquemment par les paquets l0a contenant l'identifiant 14 sans la description de données. Ainsi, la description de données est mise à la disposition des routeurs concernés par ce flux de paquets. Il peut par exemple s'agir d'un paquet envoyé par le terminal 2 vers le destinataire final qui contient donc à la fois l'identifiant 14 et la description de données.

La figure 4a illustre un exemple de structure d'un tel paquet, référencé 15a, dans lequel l'identifiant 14 et la description de données 13 correspondant à l'identifiant 14 sont tous les deux placés dans l'en-tête IP du paquet 15a. Le corps 12 du paquet peut contenir des données utiles. Sous IPv6, l'identifiant 14 peut par exemple être placée dans une extension d'en-tête et la description 13 dans une autre extension d'entête. En variante, l'identifiant 14 et la description 13 peuvent être placée dans une même extension d'entête. Sous IPv4, l'identifiant 14 peut par exemple être placée dans une option d'en-tête et la description 13 dans une autre option d'en-tête. En variante, l'identifiant 14 et la description 13 peuvent être placée dans une même option d'entête.

La figure 4b illustre un autre exemple de structure d'un tel paquet, référencé 15b, dans lequel l'identifiant 14 est placé dans l'en-tête IP 11 et la description de données 13 correspondant à l'identifiant 14 est placée dans le corps 12 du paquet. Le reste de place disponible dans le corps 12 du paquet peut contenir des données utiles. Sous IPv6, l'identifiant 14 peut par exemple être placé dans une extension d'en-tête. La description 13 peut être placée à un endroit prédéterminé dans le corps 12 du paquet. Sous IPv4, l'identifiant 14 peut par exemple être placée dans une option d'en-tête. La description 13 peut aussi être placée à un endroit prédéterminé dans le corps 12 du paquet. La structure de paquet de la figure 4b est particulièrement adaptée au cas où la taille de la description 13 est trop importante pour être contenue dans l'en-tête IP 11.

Par ailleurs, i l est avantageux d'avoir une information dans l'en-tête 1 1 du paquet indiquant au routeur le fait qu'il contient à la fois un identifiant 14 et une description 13. Sous IPv4 ou IPv6, cela peut être mis en oeuvre de façon similaire aux exemples données pour l'indication de la présence de la description de données 13 dans le premier mode de réalisation.

Lorsque le routeur reçoit un tel paquet contenant à la fois l'identifiant 14 et la description 15, il lit ces derniers. Le routeur peut alors traiter ce paquet 15 en fonction de la description 13. Par ailleurs, le routeur garde en mémoire l'identifiant 14 et la description 13 correspondante. Ainsi, lorsque le routeur reçoit subséquemment des paquets de type l0a contenant l'identifiant 14, il traite ces paquets en fonction de la description 13 correspondant à l'identifiant 14 précédemment mémorisés.

Dans le cas où la mise à disposition des routeurs la description de données correspondant à un identifiant se fait par l'envoi d'un paquet IP contenant à la fois l'identifiant 14 et la description de données 13correspondante, il est préférable d'assurer que ce paquet emprunte le même chemin à travers le réseau que les paquets subséquents incluant l'identifiant 14. Ainsi, tous les routeurs sur le chemin des paquets subséquents auront eu la possibilité de mémoriser au préalable la description 13. En particulier, les routeurs peuvent être prévus pour appliquer le même routage à tous les paquets comportant un même identifiant 14, qu'il comprenne en outre la description 13 ou non. En variante, sous IPv6, tous les paquets de ce flux de paquets sont affectés d'un même Flow Label et les routeurs sont prévus pour appliquer toujours le même routage à tout paquet présentant un même Flow Label .

Un paquet contenant à la fois l'identifiant 14 et la description 13 peut être envoyé une seule fois préalablement aux autres paquets du flux du type l0a incluant l'identifiant 14 sans la description 13. Mais il est plus avantageux d'envoyer un paquet contenant à la fois l'identifiant 14 et la description 13 régulièrement, par exemple à chaque fois après qu'un certain nombre de paquets du type 10a ont été envoyés. Ainsi, un routeur qui a accidentellement perdu de sa mémoire le descriptif de données 13 correspondant à l'identifiant 14 peut le remettre en mémoire. De préférence, le routeur met à jour sa mémoire avec la description de donnée 13 pour l'identifiant 14 concerné à chaque fois qu'il reçoit un tel paquet.

Il peut en outre être prévu que le routeur n'utilise la description 13 qu'il a en mémoire pour un identifiant 14 donné que pendant une durée prédéterminée depuis la réception du dernier paquet contenant à la fois cet identifiant 14 et celte description 13. Cette durée d'expiration est préférentiellement définie pour être supérieure au temps séparant un paquet contenant à la fois l'identifiant 14 et la description 13 du prochain paquet contenant également à la fois l'identifiant 14 et la description 13 pour un même flux de paquets. De la sorte, il est inutile de gérer la fin du flux de paquets présentant tous l'identifiant 14 envoyés par le terminal 2 pour pouvoir éventuellement réaffecter ultérieurement l'identifiant à une autre description de données 13.

Concernant le deuxième mode de réalisation, une autre possibilité de mettre à la disposition d'un routeur la description de données 13 correspondant à un identifiant 14 consiste à donner accès au routeur à une base de données 21 qui stocke les identifiants 14 et les descriptions de données 13 correspondantes. La communication entre le routeur et la base de données 21 peut être assurée via le réseau IP lui-même comme illustré sur la figure 1. Bien entendu, la même base de données 21 peut être avantageusement accessible à une pluralité de routeurs, voire à l'ensemble des routeurs du sous-réseau 3.

Ainsi, lorsqu'il reçoit un paquet 10a, le routeur lit l'identifiant 14 contenu dans le paquet. II interroge alors la base de données 21 avec cet identifiant 14 et la base de données 21 lui retourne la description de données 13 correspondante. Le routeur traite ensuite le paquet en fonction de la description de données 13 fournie par la base de données 21. En outre, le routeur peut stocker en mémoire l'identifiant 14 et la description 13 correspondante. Dans ce cas, lorsque le routeur reçoit subséquemment des paquets de type l0a contenant le même identifiant 14, il traite ces paquets en fonction de la description 13 correspondante précédemment mémorisés. Autrement dit, le routeur vérifie s'il n'a pas déjà en mémoire une description 13 associée à l'identifiant 14 lu dans le paquet et interroge la base de données 21 uniquement si la vérification est négative. Par conséquent, le traitement des paquets subséquents est plus rapide puisqu'il ne perd pas le temps lié à l'interrogation de la base de données 21.

Le recours à la base de données 21 est avantageuse car un routeur a toujours la possibilité de connaître la description 13 pour un identifiant quelconque même si le chemin emprunté par les différents paquets varient ou encore si la description 13 correspondant à un identifiant 14 est accidentellement effacée dans la mémoire du routeur.

II existe différentes manières de mettre à jour la base de données 21. Par exemple, le terminal 2 peut envoyer un paquet IP contenant à la fois l'identifiant 14 et la description 13 correspondante vers la base de données 21. La base de données 21 en accuse réception au terminal 2 par un message en retour. Après réception de l'accusé de réception, le terminal 2 envoie les paquets IP avec les données utiles et comportant l'identifiant 14 vers le destinataire final.

Suivant une mise en oeuvre particulièrement avantageuse, on combine l'utilisation de la base de données 21 et le procédé décrit précédemment pour mettre à la disposition des routeurs la description de données correspondant à un identifiant 14 qui comprend l'envoi sur le réseau d'un paquet IP contenant à la fois l'identifiant 14 et la description de données correspondante. Toute la description faite concernant l'envoi d'un paquet contenant à la fois un identifiant 14 et la description de données 13 correspondante pour mettre à disposition des routeurs ladite description 13 est applicable ici avec les explications complémentaires suivantes.

Lorsqu'un routeur reçoit un tel paquet contenant à la fois l'identifiant 14 et la description 13 correspondante, il lit ces derniers. Le routeur envoie à la base de données 21 l'identifiant 14 et la description 13, ce qui assure la mise à jour de la base de données 21. Par ailleurs, le routeur traite ce paquet en fonction de la description 13. Enfin, le routeur peut avantageusement garder en mémoire l'identifiant 14 et la description 13 correspondante. Ainsi, lorsque le routeur reçoit subséquemment des paquets de type 10a contenant l'identifiant 14, il traite ces paquets en fonction de la description 13 correspondant à l'identifiant 14 précédemment mémorisés.

Mais il peut arriver qu'un routeur n'ait pas en mémoire la description 13 correspondant à un identifiant 14 contenu dans un paquet de type 10a. Ce peut être le cas du fait que le routeur l'a perdu accidentellement de sa mémoire ou encore parce qu'il n'a pas reçu le paquet contenant à la fois l'identifiant 14 et la description 13 correspondante. Cette dernière situation peut notamment survenir lorsque les routeurs ont changé le chemin de routage postérieurement à l'envoi du paquet contenant à la fois l'identifiant 14 et la description 13 correspondante. Dans ce cas, le routeur interroge la base de données 21 avec l'identifiant 14. La base de données 21 lui fournit en réponse la description 13 correspondante. Le routeur traite alors le paquet en fonction de la description 13 fournie et la mémorise pour le traitement des paquets reçus subséquemment et présentant le même identifiant 14.

Bien entendu, similairement au premier mode de réalisation, un routeur peut être configuré par un gestionnaire de routage 20 (appelé en anglais Policy Decision Point ou PDP), par exemple via le réseau IP lui-même, pour définir les traitements à effectuer sur un paquet 10a par le routeur en fonction de la description de données 13 qui y correspond. La base de données 21 peut éventuellement faire partie du gestionnaire de routage 20.

Par ailleurs, dans le cas d'un routeur non prévu pour lire les identifiants 14, il peut se borner à traiter - en particulier router - le paquet l0a de façon conventionnelle sans tenir compte de l'identifiant 14 et de la description 13 correspondante.

Dans le cas où il n'est pas prévu un contrôle centralisé de la définition des identifiants 14 dans le réseau, il est possible qu'un même identifiant 14 soit utilisé simultanément dans le réseau mais pour des descriptions 13 différentes. Pour éviter la confusion, les routeurs peuvent prendre en compte des paramètres supplémentaires pour distinguer les flux de paquets, par exemple, l'adresse 1P de la source des paquets.

Quel que soit le mode de réalisation considéré, les descriptions de données 13 et/ou les identifiants 14 peuvent être placés dans les paquets IP envoyés par le terminal 2 par le terminal 2 lui-même. Dans ce but, le terminal 2 peut comprendre une application logicielle coopérant avec le générateur de paquets 8 pour y placer la description 13 et/ou l'identifiant 14 en fonction du type de paquet à générer. Ce peut aussi être est le générateur de paquets 8 qui place la description 13 et/ou l'identifiant 14 dans les paquets IP.

En variante, c'est le premier routeur auquel est connecté le terminal 2 en l'occurrence le routeur 4 qui ajoute dans les paquets IP provenant du terminal 2 la description 13 et/ou l'identifiant 14 en fonction du type de paquet à générer. Dans ce cas, la description 13 peut être fournie au premier routeur par le terminal 2 et le routeur défini un identifiant 14 qu'il fait correspondre à la description.

Quel que soit le mode de réalisation considéré, la description de données 13 peut avantageusement définir le type des données utiles transportées dans le paquet ou les paquets IP concernés, tel que le fait qu'il s'agisse de données audio ou vidéo, ou plus généralement qu'il s'agit de données faisant partie d'un flux de données temps réel ou d'un flux de données de très grande taille ou encore que ces données ont un caractère d'envoi cyclique. La description de données peut également comprendre des caractéristiques techniques concernant les données telles que par exemple la fréquence d'échantillonnage pour des données audio.

Les routeurs pourront alors traiter en particulier router les paquets IP non seulement en fonction de la seule adresse IP de destination placée dans leur en-tête, mais aussi en fonction de la nature des données utiles transportées et de ces autres caractéristiques techniques. Le routeur peut notamment utiliser l'équipement le plus adapté pour traiter le type de données concerné. Par exemple, le routeur ou les équipements connectés à lui peuvent utiliser l'algorithme le plus adéquat pour évaluer la qualité de service fournie à l'utilisateur finale pour le flux audio concerné. Par exemple, le routeur peut sélectionner une carte spécifique de gestion de flux audio pour réaliser de la compression à la volée et à la demande dans le cas de données audio, ou encore pour fusionner plusieurs flux audio et vidéo lors d'une conférence sur IP.

Par ailleurs, la description de données 13 peut être complétée ou remplacer - avec des informations concernant la source des données ou le destinataire des données autres que leur adresse IP dans le réseau. A titre d'exemple, il peut s'agir du nom patronymique ou de la dénomination sociale de la source et/ou du destinataire. Par conséquent, le routeur peut traiter les paquets en tenant compte de cette information. En particulier, le routeur peut router les paquets en fonction de règles de routage définies pour le destinataire ainsi définie avec la description de données 13. Par exemple, il peut préférentiellement envoyer des paquets transportant une image vers une des machines du destinataire qui présente un afficheur adapté pour l'afficher, indépendamment de l'adresse IP de destination spécifiée dans l'en-tête IP du ou des paquets concernés.

Enfin, la description de données 13 peut encore inclure des informations concernant le traitement à effectuer par les routeurs traversés, notamment des informations relatives à la qualité de service QoS (de l'anglais Quality of Service ) à fournir. Par exemple, une telle information peut être la bande passante à réserver à ces paquets de données. Il peut encore s'agir de paramètres de routage, par exemple, un chemin de routage préférentiel défini par l'émetteur des données, en l'occurrence, le terminal 2.

II est avantageux que les descriptions de données 13 placés dans les paquets 1P soient écrits en XML. En effet, une description 13 en XML peut être interprétée par la plupart des routeurs, le schéma XML utilisé pour la description pouvant être recherché sur le réseau par exemple à une adresse prédéterminée de celui-ci. Ce schéma peut être ensuite interprété par le routeur pour construire une représentation interne des informations contenues dans le document XML.

A titre d'exemple, un descriptif associé à des données du type voix, peut être rédigé en XML de la façon suivants: <flow xmins= http://www.alcatel.com/Routing/Flow/Voice > <source> <user> Durand </user> </source> <destination> <user> Dupond </user> </destination> <sampling> 8kbits </sampling> <direction> full-duplex </direction> Cette description spécifie le contenu de type voix ( Voice ), le nom patronymique de l'émetteur ( Durand ) et du destinataire ( Dupond ), l'échantillonnage ( 8kbits ) et la direction de l'échange ( full-duplex ). En fonction de ces informations, les routeurs sont à même de réaliser un routage adapté, en associant aux paquets une taille de mémoire tampon suffisante pour absorber les effets de gigues qu'on peut rencontrer dans le réseau, ou bien en choisissant une route ou une priorité des paquets en fonction de l'identité des destinataires et émetteurs. Les différents champs d'une telle descriptif sont de préférence normalisés.

Un identifiant 14 associé à ce descriptif peut par exemple prendre la forme d'un code alphanumérique tel que voice .

L'on comprendra que les descriptions de données peuvent aussi être écrites sous une forme codée au lieu d'être proche d'un langage naturel plus directement compréhensible par l'homme comme le permet XML.

Bien entendu, la présente invention n'est pas limitée aux exemples et modes de réalisation décrits et représentés, mais elle est susceptible de nombreuses variantes accessibles à l'homme de l'art. Bien qu'on ait décrit auparavant des paquets contenant une description 13 et/ou un identifiant 14, il est bien clair que l'invention s'applique également à des paquets munis de plusieurs descriptions 13 et/ou identifiants 14.

Par ailleurs, les premier et deuxième modes de réalisation de l'invention décrits plus haut peuvent être mis en oeuvre sans que la description de données 13 ni l'identifiant de description 14 ne soient inscrits dans l'en-tête IP du paquet, ni même que l'en-tête IP contienne une quelconque information indiquant que le paquet contienne une description 13 et/ou un identifiant 14. A titre d'exemple, la figure 5 illustre un exemple de mise en oeuvre du premier mode de réalisation dans lequel un la description 13 est placée dans le corps 12 d'un paquet IP 16 alors que son en-tête IP 11 est du type conventionnel. En l'occurrence, le corps 12 contient à la fin de celui-ci un code d'identification prédéterminé 16 servant à indiquer à un routeur recevant le paquet le fait qu'il contient une description 13. Le corps 12 contient immédiatement avant le code d'identification 16 une valeur 17 indicative de la longueur de la description 13 dans le paquet 16. La description 13 est placée dans le corps immédiatement avant la valeur 17. Le reste du corps 12 contient les données utiles à transporter. Lorsqu'un routeur reçoit un paquet IP, il lui suffit de lire la fin du paquet pour vérifier la présence du code 12. Dans l'affirmative, il lit ensuite la valeur 17. Ensuite, le routeur lit la description 13 contiguë à la valeur 17 dans le paquet 16 et délimitée par la longueur définie par la valeur 17. Ensuite, le routeur traite le paquet comme décrit précédemment. Bien évidemment, le deuxième mode de réalisation peut être mis en oeuvre de façon similaire, avec l'identifiant 14 qui vient en remplacement de la description 13 dans le corps 12. Un code 17 spécifique prédéterminé peut être définie au cas où le corps 12 contient à la fois la description 13 et l'identifiant 14. Dans ce cas, le code 17 peut être précédé par une valeur 17 indicative de la longueur de la description 13 dans le paquet 16, puis une autre valeur 17a indicative de la longueur de l'identifiant 14 dans le paquet 16, puis de la description 13 et enfin de l'identifiant 14. Dans une telle mise en oeuvre du premier et du deuxième mode de réalisation, la description 13 et/ou l'identifiant 14 sont écrits dans un langage indépendant des protocoles des couches OSI 5 à 7. Ainsi, les rouleurs sont capables de lire la description et l'identifiant 14 quel que soit les protocoles des couches OSI 5 à 7.

Bien que les différents modes de réalisations aient été décrit pour des paquets au protocole 1P, l'on comprendra que l'invention peut être mise en oeuvre similairement avec d'autres protocoles de la couche OSI 3 (dite couche réseau).

La mise en oeuvre de l'invention à l'aide des en-têtes au niveau de la couche OSI 3 est préférée car les noeuds sont classiquement prévus pour router les paquets grâce à ce protocole. Mais l'invention peut aussi être mise en oeuvre au niveau des en-têtes des protocoles de la couche OSI 4 (dite couche transport) dans le cas où il est possible d'y inscrire la description de données 13 et/ou l'identifiant 14 et que les noeuds ont la capacité de traiter ce protocole ou ces protocoles s'il y en a plusieurs utilisées au sein du même réseau.

Concernant la mise en oeuvre du protocole IPv4, l'on peut se reporter notamment au document RFC 791.

Concernant la mise en oeuvre du protocole IPv6, l'on peut se reporter notamment au document RFC 2460.

Concernant le modèle de référence OSI, l'on peut se reporter notamment à la norme ISO 7498.

Claims

REVENDICATIONS

1. Procédé de fonctionnement d'un noeud d'un réseau de communication par paquets, en particulier d'un routeur IP, comprenant les étapes de: a) réception par le noeud d'un paquet (10; 10a) depuis le réseau; b) réception par le noeud d'une information (13) indépendante des protocoles des couches OSI 5 à 7 du paquet et concernant au moins l'une des caractéristiques suivantes: - le type de données transportées dans le paquet, - la source d'émission des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet, et - le destinataire des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet; c) traitement du paquet (10; 10a) par le noeud en fonction de ladite 15 description.

2. Procédé selon la revendication 1, caractérisé en ce que l'information reçue dans l'étape b) est indépendante des protocoles des couches OSI 4 à 7 du paquet.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce que ladite information (13) est contenue dans le paquet (10), l'étape b) comprenant la lecture de ladite information dans le paquet par le noeud.

4. Procédé selon la revendication 3, caractérisé en ce que ladite information (13) est contenue dans l'en-tête (11) au protocole de la couche OSI 3 du paquet (10), l'étape b) comprenant la lecture par le noeud de ladite 25 information dans l'en-tête au protocole de la couche OSI 3 du paquet.

5. Procédé selon la revendication 1 ou 2, caractérisé en ce que le paquet (10a) contient un identifiant (14) de ladite information, l'étape a) comprenant la lecture de l'identifiant par le noeud.

6. Procédé selon la revendication 5, caractérisé en ce que l'identifiant (14) est contenu dans l'en-tête (11) au protocole de la couche OSI 3 du paquet (10a), l'étape a) comprenant la lecture par le noeud de l'identifiant dans l'en-tête au protocole de la couche OSI 3 du paquet.

7. Procédé selon la revendication 5 ou 6, caractérisé en ce que l'étape b) comprend la réception par le noeud d'un autre paquet (15a; 15b) depuis le réseau, ledit autre paquet contenant ladite information (13).

8. Procédé selon la revendication 7, caractérisé en ce que ladite information (13) est contenue dans l'en-tête (11) au protocole de la couche OSI 3 dudit autre paquet (15a), l'étape b) comprenant la lecture par le noeud de ladite information dans l'en-tête au protocole de la couche OSI 3 dudit autre paquet.

9. Procédé selon la revendication 7, caractérisé en ce que ladite information (13) est contenue dans le corps (12) selon le protocole de la couche OSI 3 dudit autre paquet (15b), l'étape b) comprenant la lecture par le noeud de ladite information dans le corps selon le protocole de la couche OSI 3 dudit autre paquet.

10. Procédé selon la revendication 7, 8 ou 9, caractérisé en ce que ledit autre paquet (15a;15b) contient en outre l'identifiant (14), l'étape b) comprenant la lecture par le noeud de l'identifiant dans ledit autre paquet.

11. Procédé selon la revendication 10, caractérisé en ce que l'identifiant (14) est contenu dans l'en-tête (11) au protocole de la couche OSI.3 dudit autre paquet (15a; 15b), l'étape b) comprenant la lecture par le noeud de l'identifiant dans l'en-tête au protocole de la couche OSI 3 dudit autre paquet.

12. Procédé selon la revendication 10 ou 11, caractérisé en ce qu'il comprend après l'étape b), une étape de: - envoi par le noeud vers une base de données (21) de l'identifiant (14) et de ladite information.

13. Procédé selon la revendication 5 ou 6, caractérisé en ce qu'il comprend après l'étape a) et avant l'étape b), une étape de: interrogation par le noeud d'une base de données (21) avec l'identifiant (14).

14. Paquet de données (10) pour un réseau de communication par paquets, comprenant une information indépendante des protocoles des couches OSI 5 à 7 du paquet et concernant au moins l'une des caractéristiques suivantes: le type de données transportées dans le paquet, - la source d'émission des données transportées dans le paquet autre que l'adresse réseau de la source d'émission du paquet, et - le destinataire des données transportées dans le paquet autre que 15 l'adresse réseau de la source d'émission du paquet.

15. Paquet de données selon la revendication 14, caractérisé en ce que ladite information est indépendante des protocoles des couches OSI 4 à 7 du paquet.

16. Paquet de données selon la revendication 14 ou 15, caractérisé en ce que ladite information est contenue dans l'en-tête (Il) au protocole de la couche OS1 3 du paquet.

17. Paquet de données selon la revendication 16, caractérisé en ce que le paquet est au protocole IP, ladite information étant contenue dans l'entête IP.

18. Générateur de paquets tels que définis par l'une quelconque des revendications 14 à 17.