FR2879869A1 - Procede de transmission d'un datagramme, routeur et terminal adaptes pour mettre en oeuvre un tel procede - Google Patents

Abstract

Un procédé de transmission d'un datagramme par un routeur d'un réseau de communication prend en compte une classe de service (DSCP) codée dans le datagramme. La table de routage contient une ou plusieurs lignes associées à des routes respectives, pour au moins une classe de service par préfixe de destination. Lors de la transmission du datagramme, une première partie de la table de routage (P1) est d'abord sélectionnée en fonction du préfixe de destination. Une seconde partie de la table de routage (P2), associée à la classe de service du datagramme (DSCP), est ensuite sélectionnée à l'intérieur la première partie (P1). La route selon laquelle le datagramme est transmis par le routeur correspond à une ligne de la table de routage sélectionnée dans la seconde partie (P2). Un tel procédé de transmission est de type « hop by hop » avec contrainte d'équilibrage de charge par classe de service.

Description

PROCEDE DE TRANSMISSION D'UN DATAGRAMME, ROUTEUR ET TERMINAL ADAPTES POUR

METTRE EN OEUVRE UN TEL PROCEDE

La présente invention concerne un procédé de transmission d'un datagramme dans un réseau de communication de type IP ( Internet Protocol ). Elle concerne aussi un routeur et un terminal adaptés pour mettre en oeuvre un tel procédé.

Un réseau de communication par transmission de datagrammes comprend des routeurs reliés entre eux par des liens de transmission. Chaque routeur transmet un datagramme reçu en fonction d'une adresse de terminal destinataire lue dans ce datagramme. La transmission du datagramme dans le réseau, entre un terminal émetteur du datagramme et le terminal destinataire, résulte d'une suite de transmissions élémentaires du datagramme, effectuées par une chaîne de routeurs du réseau. Un tel procédé de transmission est désigné par "hop by hop" en anglais.

Le mode de transmission à coût minimal, dit best effort en anglais, constitue le principal procédé de transmission de type "hop by hop". Selon ce mode de transmission, un datagramme reçu par un routeur du réseau est toujours accepté en vue d'être transmis, mais sans garantir le succès de la transmission ni assurer que celle-ci sera exécutée dans un délai déterminé. Des datagrammes appartenant à un même flux de communication peuvent alors parvenir de façon irrégulière au terminal destinataire de ceux-ci, notamment avec des retards variables. En outre, l'ordre des datagrammes n'est pas garanti. Certains datagrammes peuvent aussi être l'objet d'un échec de transmission. L'information véhiculée par ceux-ci est alors perdue. De tels défauts de transmission sont plus particulièrement gênants pour certaines applications, telles que la transmission de communications vocales par un réseau IP (VOIP de l'anglais Voice Over IP ), notamment.

De nombreuses améliorations du mode de transmission à coût minimal ont été proposées, en introduisant des techniques de routage qui prennent en considération une qualité de service. De telles techniques de routage sont couramment désignées par QOS routing (QOS pour Quality Of Service ).

-2-Parmi celles-ci, on peut citer les suivantes.

La technique de routage QOSPF ( Qos routing mechanisms and OSPF extensions ) combine le protocole OSPF ( Open Shortest Path First ) et une méthode de calcul de routes qui tient compte du niveau de bande passante disponible de celles-ci, tout en minimisant la longueur des chemins suivis par les datagrammes dans le réseau de communication. Elle présente l'inconvénient de se fonder sur l'utilisation du protocole de réservation de ressources RSVP ( Resource reSerVation Protocol ), dont le champ d'application est limité. En outre, elle n'est pas applicable à des réseaux de grandes dimensions.

La technique de routage OMP ( Optimized Multi-Path ) met en oeuvre, dans les protocoles de transmission IGP ( Interior Gateway Protocol ) standards de l'Internet, une répartition du trafic le long de routes multiples qui est ajustée en fonction de l'état de charge du réseau. Mais, lorsque survient une variation brutale de la charge du réseau le long de routes multiples associées à un même préfixe de destination, la répartition du trafic entre les routes est susceptible de subir des oscillations. Cette technique de routage manque donc de stabilité.

Enfin, dans les techniques de routage à qualités de service différenciées (désignées par diffserv pour differentiated services ), les flux de datagrammes sont regroupés en catégories distinguées par exemple au moyen d'un numéro de port de protocole de transport. Chaque catégorie de flux correspond à une classe de service distincte. Celle-ci indique les réservations de ressources statistiques qui sont effectuées pour la transmission des datagrammes. Mais le fonctionnement d'un réseau dans lequel des mécanismes de gestion des paramètres de qualité de services de type diffserv sont utilisés manque de prédictibilité et peut faire l'objet d'instabilités. En outre, les procédés de gestion des paramètres de qualité de services de type diffserv conçus jusqu'à présent ne garantissent qu'un traitement local de chaque datagramme, c'est-à-dire au sein de chaque routeur, conformément à une marque inscrite dans le datagramme. Ils ne permettent pas d'assurer une qualité de service homogène sur tout le chemin de transmission suivi par un -3-datagramme dans le réseau de communication.

Un but de la présente invention consiste donc à proposer un mécanisme de routage qui ne présente pas les inconvénients cités ci- dessus.

Pour cela, l'invention propose un procédé de transmission d'un datagramme par un routeur d'un réseau de communication, suivant lequel une table de routage du routeur contient, pour certains au moins des préfixes de destination et pour au moins une valeur d'un code de classe de service répertoriés dans ladite table, une ou plusieurs lignes associées à des routes respectives et identifiées chacune par une valeur d'un index de route. Le procédé de transmission comprend les étapes suivantes: asélection d'une première partie de la table de routage associée à un préfixe de destination correspondant à une adresse de destination lue dans le datagramme; b- sélection, dans ladite première partie de la table de routage, d'une 15 seconde partie de la table de routage, associée à une valeur du code de classe de service lue dans le datagramme; c- sélection, dans ladite seconde partie de la table de routage, d'une ligne associée à une valeur d'index de route lue dans le datagramme; et d- transmission du datagramme selon la route qui correspond à la ligne 20 sélectionnée de la table de routage.

Un procédé de transmission selon l'invention met donc en oeuvre plusieurs classes de services. En outre, un datagramme est transmis par tous les routeurs situés sur le chemin suivi par celui-ci dans le réseau en respectant la classe de service indiquée dans le datagramme par la valeur du code qui y est inscrite. De cette façon, la qualité de service correspondante est garantie de bout-en-bout, c'est-à-dire sur tout le chemin du datagramme. L'invention constitue donc une amélioration du modèle diffserv, obtenue en utilisant un procédé de transmission hop by hop contraint, c'est-à-dire qui est combiné avec un critère de sélection de la route selon laquelle chaque routeur transmet un datagramme.

Un premier avantage d'un procédé de transmission selon l'invention réside dans la stabilité du fonctionnement du réseau de communication qui en résulte. En effet, chaque routeur transmet prioritairement un datagramme conformément aux indications de classe de service et d'index de route qui sont inscrites dans celui-ci. Le traitement du datagramme par le routeur est donc en partie déterminé initialement, de sorte que l'autonomie du routeur est réduite.

Des datagrammes successifs d'un même flux qui comportent des valeurs de code de classe de service et d'index de route identiques, sont donc préférentiellement transmis de la même façon. Cette caractéristique procure un fonctionnement stable du réseau.

L'inscription des valeurs de code de classe de service et d'index de o route dans le datagramme permet de prévoir, dans la plupart des cas, la façon dont ce datagramme est transmis par un routeur. Cette prédictibilité constitue un second avantage d'un procédé de transmission selon l'invention. En particulier, elle permet de tester des changements de configuration du réseau par simulation numérique, avant que ces changements soient mis en oeuvre réellement.

En outre, un procédé de transmission selon l'invention peut facilement être mis en oeuvre dans un réseau de communication de grandes dimensions. De même, un réseau dans lequel un tel procédé est utilisé peut être élargi sans difficulté, notamment par ajout de routeurs supplémentaires.

Si la seconde partie de la table de routage qui est sélectionnée ne contient pas la valeur d'index de route lue dans le datagramme, le procédé comprend avantageusement les étapes suivantes: - sélection, dans la seconde partie de la table de routage, d'une ligne associée à une route correspondant à un coût minimal parmi les routes des lignes de ladite seconde partie de la table de routage ayant une bande passante disponible suffisante; - inscription par le routeur dans le datagramme, de la valeur d'index de route correspondant à la ligne sélectionnée; et - reprise du procédé à l'étape d.

Ainsi, lorsque la table de routage d'un routeur qui reçoit un datagramme ne comporte pas de ligne contenant le préfixe de destination, la valeur du code de classe de service et la valeur d'index de route qui sont lus dans le datagramme, le datagramme est transmis avec un coût minimal tout en respectant la classe de service dont il relève. En outre, une disponibilité suffisante de la route selon laquelle il est transmis est garantie.

Selon un mode de mise en oeuvre préféré de l'invention, la valeur d'index de route qui est lue dans le datagramme appartient à un vecteur d'index de routes prévu dans celui-ci. Elle est inscrite à une position dans ce vecteur qui est indiquée par une valeur d'un pointeur incrémentée lors de chaque transmission du datagramme par un routeur du réseau de communication. Un tel mode d'inscription et de lecture des valeurs d'index de o routes, de type FIFO, est facile à mettre en oeuvre et ne ralentit pas sensiblement le traitement des datagrammes par chaque routeur.

L'invention propose aussi un routeur destiné à être connecté à un réseau de communication, qui est adapté pour mettre en oeuvre un procédé de transmission tel que décrit précédemment.

Un tel routeur comprend des moyens de mémorisation d'une table d'informations de routage constituée de lignes respectivement associées à des routes entre ce routeur et un sous-réseau compris dans le réseau de communication. Il comprend en outre des moyens de mise à jour de la table de routage d'après la table d'informations de routage. De façon avantageuse, le routeur est adapté de sorte que certaines au moins des lignes de la table d'informations de routage contiennent les données suivantes: un préfixe de destination, une valeur du code de classe de service, et une valeur de l'index de route attribuée pour identifier de façon univoque chacune des lignes correspondant à un même préfixe de destination et à une même valeur du code de classe de service.

L'invention concerne enfin un terminal destiné à être relié à un réseau de communication, qui comprend des moyens de mémorisation d'un contexte de session de communication. Le contexte de session de communication regroupe usuellement une adresse de source de datagrammes transmis dans ladite session, une adresse de destination desdits datagrammes, un numéro de port de source, un numéro de port de destination et un numéro de protocole de transport. Pour la mise en oeuvre de l'invention, le contexte de session de communication comprend aussi une valeur du code de classe de service. Le terminal comprend en outre des moyens d'inscription, dans un datagramme destiné à être transmis, de la valeur du code de classe de service qui est mémorisée dans le contexte de session de communication dont dépend ce datagramme.

D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'un exemple de mise en oeuvre non limitatif, en référence aux dessins annexés, dans lesquels: - la figure 1 illustre une partie d'un réseau de communication dans laquelle 10 le procédé de transmission selon l'invention peut être mis en oeuvre; - la figure 2 est un exemple de partie de table de routage mémorisée au sein d'un des routeurs représentés sur la figure 1; et - les figures 3a et 3b, destinées à être associées, sont un diagramme synoptique des étapes d'un procédé de transmission selon l'invention.

Selon la figure 1, un réseau de communication par transmission de datagrammes 100, de type IP, comprend des routeurs 1-4 reliés entre eux par des liens de transmission. Un terminal 10 est relié au routeur 1 par le sous-réseau A, et un terminal 20 est relié au routeur 3 par le sousréseau B. Les chaînes de routeurs 1-2-3 et 1-4-3 appartiennent à deux chemins possibles dans le réseau 100, pour transmettre des datagrammes entre les terminaux 10 et 20.

Chaque routeur comprend, de façon connue, une unité d'acheminement (ou forwarding unit en anglais) qui transfère les datagrammes entre deux liens de transmission reliés à cette unité, et une unité de commande (ou control unit ) qui supervise l'activité de l'unité d'acheminement.

Les terminaux 10 et 20 peuvent être de différents types, tels que, par exemple, des unités informatiques ou des unités de communication mobiles. Des données produites par le terminal 10 à destination du terminal 20 sont réparties par le terminal 10 dans des datagrammes successifs d'un même flux.

On considère dans la suite que le fonctionnement d'un réseau de type IP est connu. Dans ce cadre, sur la figure 1, chaque lien de transmission du réseau 100 est repéré par un préfixe PD suivi d'identifiants de chacun des routeurs connectés à ce lien.

Chaque datagramme IP possède un en-tête, tel que défini par la version 4 du protocole IP (IPv4) par exemple. Un tel en-tête comprend une partie d'en-tête de base présente dans tous les datagrammes, et une partie d'en-tête optionnelle. Parmi les champs de la partie d'en-tête de base figurent le champ SOURCE ADDRESS , dans lequel est indiquée l'adresse IP du terminal émetteur du datagramme, et le champ DESTINATION ADDRESS , dans lequel est indiquée l'adresse IP du terminal destinataire du datagramme. Parmi les autres champs figurent notamment le champ Type Of Service (de 8 bits), ou TOS, dans lequel est spécifiée la façon dont le datagramme doit être géré.

Dans la mise en oeuvre de l'invention qui est décrite ici, les six bits de poids les plus forts du champ TOS sont utilisés pour inscrire une valeur de code de classe de service, appelée valeur DSCP (pour Differentiated Services Code Point en anglais). Les codes BE (pour Best Effort ), AF (pour Assured Forwarding ) et EF (pour Expressed Forwarding ) issus de la terminologie diffserv peuvent être repris, à titre d'exemples de classes de services, pour désigner des modes de transmission à coût minimal, avec garantie d'un débit minimal de transmission au terminal destinataire et avec garanties de débit minimal de transmission et de délai maximum de transmission. 63 classes de services différentes peuvent ainsi être inscrites dans les datagrammes, en plus de la classe correspondant à une transmission à coût minimal ( best effort ). Cette dernière est préférentiellement identifiée par une valeur DSCP nulle.

La partie d'en-tête optionnelle d'un datagramme comprend un premier champ, appelé OPTION TYPE , de 1 octet. Ce champ est destiné à recevoir une référence construite selon une nomenclature connue de l'Homme du métier. Cette référence spécifie la présence, la classe et un numéro dédié d'option, qui permettent d'identifier la nature du contenu de la partie d'en-tête optionnelle. A titre d'exemple, pour le mode de mise en oeuvre de l'invention décrit ci-après, cette référence peut être 10011001 en représentation binaire de l'octet. La longueur de la partie d'en-tête optionnelle, exprimée en octets, est indiquée dans le champ OPTION LENGTH (de 1 octet). Pour la mise en oeuvre de l'invention qui est décrite ici, on utilise la longueur maximale possible pour la partie d'en-tête optionnelle, à savoir 40 octets. Les 38 octets restant disponibles dans la partie d'en-tête optionnelle sont répartis en quatre champs disposés de la façon suivante: - un premier champ, noté CVI pour Current Vector Index en anglais, de 1 octet, destiné à recevoir une valeur numérique d'un pointeur; un second champ, noté FF pour Flow Flag , aussi de 1 octet, destiné à recevoir une valeur de champ de bits de contrôle; une première série ordonnée de 36 champs, notée FRIV pour Forward Route Index Vector , de 18 octets au total. Les champs de cette première série, disposés les uns à la suite des autres, forment un premier vecteur et sont destinés à recevoir 36 premières valeurs numériques, codées sur 4 bits chacune. Pour raison de clarté, le pointeur et le premier vecteur sont respectivement désignés dans la suite par pointeur CVI et vecteur FRIV. Le pointeur CVI sert à repérer un champ dans le vecteur FRIV, par le numéro d'ordre de la position de ce champ dans le vecteur FRIV, compté à partir du début du vecteur. Ainsi, la valeur du pointeur CVI varie entre 1 et 36; - une seconde série ordonnée de champs, notée BRIV pour Backward Route Index Vector , aussi de 18 octets au total. Cette seconde série de champs forme un second vecteur et est destinée à recevoir 36 secondes valeurs numériques codées sur 4 bits chacune. Ce second vecteur est désigné ci-après par vecteur BRIV.

Ces positions et tailles des champs CVI et FF dans le datagramme, ainsi que celles des champs des vecteurs FRIV et BRIV, sont données à titre d'exemple. D'autres positions peuvent être choisies, pour obtenir des modes de mise en oeuvre alternatifs de l'invention. Néanmoins, il est particulièrement avantageux, dans le cadre de la version IPv4 du protocole IP, de concevoir les champs CVI et FF, ainsi que les vecteurs FRIV et BRIV, de façon à exploiter la longueur maximale de la partie d'en- tête optionnelle.

L'invention peut être mise en oeuvre de façon équivalente dans le cadre de la version 6 du protocole IP (IPv6), en adaptant les champs CVI et FF, ainsi que les vecteurs FRIV et BRIV, aux particularités de cette dernière version du protocole IP. Notamment, la version IPv6 permet d'adopter des longueurs de champs et de vecteurs supérieures, grâce à la possibilité de définir une partie d'en-tête optionnelle de taille supérieure à 40 octets, sans limite de taille.

Chaque routeur du réseau 100 dispose d'une table de routage utilisée par l'unité d'acheminement de ce routeur pour transmettre les datagrammes reçus. Cette table de routage est désignée par table FIB, pour Forwarding Information dataBase en anglais. La figure 2 reproduit une partie de la table FIB du routeur 1 de la figure 1.

La table FIB doit être lue par lignes, chaque ligne correspondant à une route. Sa structure, adaptée pour mettre en oeuvre l'invention, est décrite maintenant.

La première colonne de la table FIB, intitulée Destination Prefix en anglais, regroupe des préfixes de destination.

La deuxième colonne de la table FIB, intitulée Code DSCP , regroupe des valeurs DSCP.

La troisième colonne de la table FIB, intitulée Index , regroupe des valeurs d'index de routes. Ces valeurs sont attribuées par chaque routeur d'une façon qui sera décrite plus loin.

La quatrième colonne de la table FIB, intitulée Next Hop , indique une adresse IP d'un routeur ou d'un terminal qui est relié au routeur 1 par un lien de transmission unique, pour chaque préfixe de destination, pour chaque valeur DSCP et pour chaque valeur d'index de route indiqués dans les trois premières colonnes. Ces adresses IP sont construites de la façon connue, avec un préfixe suivi d'un identifiant du terminal ou du routeur.

La cinquième colonne de la table FIB, intitulée Cost , indique pour chaque ligne une mesure du coût de transmission par la route correspondante. D'une façon connue, le coût d'une transmission selon une route est mesuré par rapport à une métrique, telle que, par exemple, la somme des coûts statiques d'utilisation des liens d'interconnexion des routeurs situés le long de cette route.

Enfin, la sixième colonne de la table FIB, intitulée Load , indique une valeur qui caractérise la charge et/ou la disponibilité des ressources de la route correspondant à chaque ligne. Ce peut être une valeur de taux de charge, par exemple.

La table FIB peut encore comporter d'autres colonnes, qui ne sont pas reprises ici parce qu'elles n'ont pas de relation directe avec l'invention. Ces autres colonnes peuvent indiquer des informations complémentaires qui sont utiles pour la transmission des datagrammes.

Une table FIB telle que couramment utilisée pour transmettre un datagramme à coût minimal ( best effort ) indique une unique route pour chaque préfixe de destination. En outre, le calcul de telles routes s'appuie sur un algorithme de Dijkstra, noté SPF pour "Shortest Path First", de calcul des plus courts chemins qui ne considère qu'une seule métrique de nature statique: le coût d'utilisation des liens d'interconnexion. A la différence, une table FIB adaptée pour mettre en oeuvre un procédé de transmission selon l'invention peut indiquer plusieurs routes pour chaque préfixe de destination, ainsi que pour plusieurs valeurs du code de classe de service. Chacune de ces routes correspond à une ligne différente de la table FIB. En outre, ces routes sont calculées au moyen d'un algorithme de Dijkstra modifié, noté CSPF pour Constraint Shortest Path First , qui tient compte à la fois de la métrique statique lié au coût d'utilisation des liens d'interconnexion et de la métrique dynamique caractéristique de l'état de disponibilité des ressources situées le long de la route considérée. La colonne Index indique une valeur numérique distincte pour chacune de ces lignes. Ces valeurs d'index distinguent les différentes routes prises en compte dans la table FIB, qui correspondent à un même préfixe de destination et à une même valeur DSCP. Une même valeur d'index peut éventuellement être utilisée plusieurs fois dans la table FIB, pour des lignes correspondant à des préfixes de destination différents et/ou des valeurs DSCP différentes. Les valeurs d'index associées aux lignes de la table FIB n'ont qu'une fonction d'identification des routes, et ne correspondent pas à un classement. Leur attribution dépend notamment des modifications intervenues dans la table FIB lors de mises à jour successives de celle- ci.

De façon connue, la table FIB d'un routeur est mise à jour par l'unité de commande de ce routeur d'après une ou plusieurs tables d'informations de routage, ou tables RIB (pour Routing Information dataBase en anglais). Chaque table RIB est enregistrée au sein de l'unité de commande du routeur. Elle contient des indications de routes qui relient le routeur à différents sous-réseaux d'interconnexion, routeurs connectés au réseau de communication.

Chaque table RIB est elle-même mise à jour pour prendre en compte des modifications intervenues dans le réseau, telles que, par exemple, la suppression d'un routeur particulier par l'exploitant du réseau ou la coupure d'un lien de transmission du réseau, ou encore une variation du trafic ayant un impact sur la politique de routage.

Une table RIB contient les mêmes colonnes que la table FIB, ainsi que des colonnes supplémentaires. Pour la mise en oeuvre de l'invention qui est décrite ici, chaque table RIB comprend les colonnes Destination Prefix , Code DSCP , Index , Next Hop , Cost et Load présentées plus haut. L'une des colonnes supplémentaires indique, pour chaque ligne de la table RIB, la suite ordonnée des routeurs situés sur la route correspondant à cette ligne, entre le routeur au sein duquel la table RIB est mémorisée et le sous-réseau qui correspond au préfixe de destination. Une telle colonne est couramment désignée par Path .

De même que la table FIB, une table RIB peut aussi contenir plusieurs lignes associées à un même couple constitué par un préfixe de destination et une valeur DSCP. Dans ce cas, les routes de la table RIB correspondantes indiquées dans la colonne Path diffèrent les unes des autres. Lors de l'élaboration de la table RIB, une valeur d'index de route est affectée à chaque nouvelle ligne ajoutée. Si une ou plusieurs lignes existent déjà pour un couple donné de préfixe de destination et de valeur DSCP, la valeur d'index de route affectée à une nouvelle ligne pour ce couple est distincte de celles des lignes existantes. Elle peut être, par exemple, le plus petit nombre entier distinct des - 12 -valeurs d'index de routes déjà affectées à ces lignes existantes. La valeur 1 d'index de route peut être attribuée prioritairement à la route la plus courte répertoriée dans la table RIB, pour un préfixe de destination donné et pour une valeur DSCP donnée. En outre, à condition que les changements de topologie n'impactent pas l'intégrité d'une route de plus court chemin repérée par une valeur d'index égale à 1, il peut être également avantageux de ne jamais supprimer ces routes des tables de routage, même lorsqu'elles présentent des taux d'activité nuls ou de charge quasi-nuls.

La colonne Load indique, pour chaque ligne de la table RIB, la valeur de taux de charge de la route correspondante pour la classe de service indiquée dans la colonne Code DSCP . Cette valeur peut être déterminée par l'unité de commande du routeur en fonction de données d'état du réseau de communication. De telles données sont, par exemple, des valeurs de taux de charge de certains au moins des liens du réseau 100, qui se rapportent à une classe de service donnée. La valeur indiquée dans la colonne Load pour chaque ligne de la table FIB peut être égale, par exemple, à la plus grande des valeurs de taux de charge de tous les liens le long de la route correspondant à cette ligne, pour la classe de service indiquée. Elle peut être exprimée de diverses façons, telles que, notamment, sous forme d'un pourcentage d'une capacité maximale de transmission par cette route, ou bande passante, et pour la classe de service concernée.

Le routeur peut être conçu de sorte que l'unité de commande élabore elle-même la table RIB. Pour cela, le routeur comprend en outre des moyens d'élaboration de la table RIB à partir d'éléments d'information reçus caractérisant un état de fonctionnement du réseau 100. Chaque élément d'information se rapporte à une classe de service identifiée par la valeur DSCP correspondante. Il peut alors être utilisé pour ajouter, modifier ou supprimer des lignes associées à cette classe de service, c'est-à-dire qui contiennent la valeur DSCP correspondante.

Eventuellement, le routeur comprend aussi des moyens pour produire des éléments d'information caractérisant un état de fonctionnement du réseau 100 et se rapportant chacun à une classe de service identifiée par la valeur DSCP correspondante. La table RIB d'un routeur donné est alors construite à partir des éléments d'information collectés et/ou transmis par d'autres routeurs du réseau 100. Chaque routeur possède donc une double fonction: production d'informations de fonctionnement du réseau d'une part, et transmission de datagrammes d'autre part.

On décrit maintenant en détail la transmission de datagrammes entre les terminaux 10 et 20.

Lorsque des données sont produites par le terminal 10 à destination du terminal 20, le terminal 10 répartit ces données dans des datagrammes successifs. Le procédé de création des datagrammes est considéré connu. En particulier, le terminal 10 mémorise un contexte de session de communication qui regroupe les données suivantes: les adresses IP respectives des terminaux 10 et 20, dites adresses de source et de destination, des numéros de ports de source et de destination, et un numéro de protocole de transport (par exemple les protocoles TCP ou UDP). Ces données sont notées respectivement Ad(10), Ad(20), p, p' et protocol sur la figure 1, pour un flux-aller F. Elles sont enregistrées peu avant l'instant t1 d'émission d'un premier datagramme de ce flux. Pour la mise en oeuvre de l'invention, le contexte de session de communication mémorisécomprend en outre une valeur du code DSCP. Cette valeur peut correspondre au code EF, par exemple. Le contexte de session de communication mémorisé peut comprendre encore, de façon avantageuse, les valeurs des champs des vecteurs FRIV et BRIV et éventuellement celle du champ FF.

Lors de la création du premier datagramme du flux F, le terminal 10 configure la partie d'en-tête de base de celui-ci. En particulier, il inscrit les adresses Ad(10) et Ad(20) respectivement dans les champs SOURCE ADDRESS et DESTINATION ADDRESS , ainsi que la valeur DSCP dans le champ TOS .

Le terminal 10 configure aussi la partie d'en-tête optionnelle du premier datagramme en inscrivant les valeurs initiales suivantes dans les différents champs: - champ OPTION TYPE: 10011001 - 14 - - champ OPTION LENGTH: 40 - champ CVI: 1 - champ FF: 0 - champs du vecteur FRIV: 0, 0,... , 0 - champs du vecteur BRIV: 0, 0,..., 0 Ainsi, 1 est la valeur initiale de l'index CVI, et 0 est la valeur initiale inscrite dans le champ FF. 0 est aussi la valeur d'index de route qui est inscrite initialement dans tous les champs des vecteurs FRIV et BRIV. La valeur 0 est réservée à la fonction d'initialisation des champs FRIV et BRIV: elle n'est pas utilisée dans les tables RIB et FIB des routeurs en tant que valeur d'index de route. Ainsi qu'il apparaîtra dans la suite, la valeur à 0 lue dans des champs du vecteur FRIV d'un datagramme signifie que ce datagramme est soit un premier datagramme d'un flux, soit un datagramme ultérieur d'un flux pour lequel le terminal émetteur ne dispose pas de valeurs d'index de routes prédéterminées, soit un datagramme ultérieur d'un flux pour lequel l'une des routes correspondant aux valeurs d'index de routes initialement inscrites dans ce datagramme n'existe plus.

Les valeurs d'initialisation qui sont inscrites dans les champs FRIV et CVI du datagramme sont mémorisées par le terminal 10 avec les données du contexte de session de communication relatives au flux-aller F. Celles qui sont inscrites dans les champs BRIV et FF sont mémorisées avec les données du contexte de session de communication relatives à un flux retour F'.

On suppose que le premier datagramme du flux F est transmis par le terminal 10 au routeur 1, via le sous-réseau A. Le procédé de transmission mis en oeuvre au sein du routeur 1 est maintenant décrit.

Lors de la réception du datagramme par le routeur 1 (étape 100 de la figure 3a), l'adresse IP du terminal destinataire de ce datagramme, c'est-à-dire Ad(20), est lue dans le champ DESTINATION ADDRESS de la partie d'en-tête de base du datagramme. Le préfixe de destination de cette adresse est isolé en utilisant un masque de réseau, et est identifié à l'un des préfixes de destination contenus dans la première colonne de la table FIB du routeur 1. Cette identification est effectuée selon un principe de plus grande coïncidence, ou longest match en anglais. Cette étape est notée L_PREFIX_MS sur la figure 3a, pour Longest Prefix Matching Search , et référencée 101. Si la table FIB ne contient pas de préfixe correspondant à l'adresse Ad(20), le datagramme n'est pas transmis par le routeur 1 et est détruit (étapes 102 et 103).

Si la table FIB du routeur 1 contient le préfixe correspondant à l'adresse Ad(20) lue dans le datagramme, une première partie de la table FIB est sélectionnée par l'unité d'acheminement du routeur 2, qui regroupe les lignes contenant ce préfixe dans la première colonne (étape 104). Sur la figure 2, une telle première partie de la table FIB est indiquée par P1. Par simplicité, le préfixe de l'adresse IP du terminal 20 est noté B, en correspondance avec le sous-réseau d'interconnexions auquel est relié le terminal 20.

Les deux étapes suivantes du procédé de transmission (étapes 105 et 106 de la figure 3a) permettent de sélectionner les datagrammes qui sont transmis selon l'invention. Les autres datagrammes peuvent être transmis de façon usuelle, par exemple selon une route correspondant à un coût minimal ( best effort , étape 107).

L'étape 105 consiste à vérifier la présence d'une partie d'en-tête optionnelle dans le datagramme. En effet, le vecteur FRIV et le pointeur CVI qui sont utilisés dans la suite du procédé sont inscrits dans la partie d'en-tête optionnelle.

L'étape 106 consiste à vérifier la présence d'un en-tête de protocole de transport TCP ou UDP dans le datagramme. La présence d'en- têtes de l'un au moins de ces protocoles de transport indique que le datagramme transporte probablement des données d'application destinées à un utilisateur du réseau 100, par opposition à des datagrammes transportant de la signalisation. Ainsi, le procédé de transmission selon l'invention est principalement utilisé pour des datagrammes de données.

Le routeur 1 lit alors la valeur DSCP inscrite dans le champ TOS du datagramme. La valeur lue est recherchée dans la colonne Code DSCP pour les lignes de la partie P1 de la table FIB qui a été sélectionnée précédemment. Cette recherche est indiquée par E_DSCP_MS, pour Exact DSCP value Matching Search (étapes 108 et 109).

Si la partie P1 de la table FIB ne contient pas la valeur DSCP lue dans le datagramme, le routeur 1 inscrit dans le champ TOS du datagramme la valeur DSCP qui correspond à une transmission selon une route de coût minimal (étape 110). Des étapes 120 et 121 respectivement analogues aux étapes 108 et 109 sont exécutées. Si la partie P1 de la table FIB ne contient pas la valeur BE du champ DSCP, alors le datagramme est détruit (étape 122).

Si la partie P1 de la table FIB contient la valeur DSCP lue dans le datagramme, l'unité d'acheminement du routeur 1 sélectionne une seconde partie de la table FIB, formée par les lignes qui contiennent, dans les première et deuxième colonnes de la table FIB, le préfixe de destination et la valeur DSCP lus dans le datagramme. Les lignes de cette seconde partie de la table FIB, qui est indiquée par P2 sur la figure 2, sont sélectionnées dans la partie P1 (étape 111 de la figure 3b).

L'étape 112 consiste à déterminer si le datagramme est le premier d'un flux destiné à être transmis le long d'une route optimisée selon les critères de coût et de disponibilité. La valeur d'index de route qui est contenue dans le vecteur FRIV du datagramme à la position indiquée par la valeur du curseur CVI est lue. Elle est nulle pour le premier datagramme du flux F transmis par le terminal 10.

Le routeur 1 sélectionne alors une ligne dans la partie P2 de la table FIB (étape 116). La méthode de sélection désignée par WES, pour Wide Enough bandwidth Shortest path est préférentiellement utilisée. Selon cette méthode, une ou plusieurs lignes sont d'abord sélectionnées, à l'intérieur de la partie P2 de la table FIB, pour chacune desquelles la route correspondante présente une bande passante disponible suffisante. Cette disponibilité est déduite du contenu de la colonnne Load pour chaque ligne de la partie P2 de la table FIB. Différents critères de disponibilité ou seuils de bande passante peuvent être adoptés pour cette sélection. Ces critères ou seuils peuvent dépendre, notamment, de la classe de service indiquée par la valeur DSCP lue dans le datagramme. Si plusieurs lignes ont ainsi été sélectionnées dans la partie P2, une seule parmi celles-ci est finalement retenue. Elle correspond à la route de coût minimal parmi toutes les routes des lignes sélectionnées qui présentent une bande passante disponible suffisante. Dans le cas de la table FIB du routeur 1 reproduite à la figure 2, un critère de disponibilité spécifiant que le taux de charge est inférieur à 90% exclut la ligne de la partie P2 qui possède la valeur d'index de route 1. Les lignes de la partie P2 qui possèdent les valeurs d'index de routes 2 et 3 sont ainsi sélectionnées. La ligne de valeur d'index 3 est finalement retenue, car la valeur de coût correspondante est inférieure à celle de la ligne de valeur d'index 2.

La valeur d'index de route 3 est inscrite dans le champ du vecteur FRIV du datagramme qui correspond à la valeur du pointeur CVI (étape 117). Le datagramme est transmis par le routeur 1 au routeur 4, conformément à l'indication contenue dans la colonne Next Hop pour la ligne sélectionnée (étape 119). Avant la transmission du datagramme par le routeur 1, la valeur du pointeur CVI est incrémentée d'une unité et la nouvelle valeur est inscrite dans le champ CVI du datagramme (étape 118).

Le datagramme est ainsi transmis de proche en proche par des routeurs du réseau 100, jusqu'à parvenir au terminal 20. Chaque routeur applique un procédé de transmission analogue à celui qui a été décrit pour le routeur 1. En particulier, un champ supplémentaire du vecteur FRIV du datagramme est rempli par chaque routeur situé sur le chemin suivi par le datagramme. Ce champ est désigné par la valeur du pointeur CVI qui est lue dans le datagramme.

A la réception du datagramme (instant noté t2 sur la figure 1), le terminal 20 mémorise les données du contexte de la session de communication du datagramme, lues dans les parties d'en-tête de celui-ci. Il mémorise notamment les contenus des champs du vecteur FRIV du datagramme reçu, respectivement en tant que valeurs des champs du vecteur BRIV associé au flux-retour noté G' du contexte de session de communication du terminal 20. X1, X2, X3, ... désignent les valeurs d'index de routes inscrites par les routeurs lors de chacune de ces transmissions élémentaires. Le terminal 20 lit alors les données contenues dans le champ de données (ou payload ) du datagramme.

On suppose maintenant que le terminal 20 produit à son tour des données à destination du terminal 10, en réponse aux données reçues. Les données produites par le terminal 20 sont transmises dans le cadre de la même session de communication que celle du premier datagramme.

Le terminal 20 crée un deuxième datagramme. Ce datagramme appartient au flux-aller G. Il reprend les données de contexte de session de communication qui ont été mémorisées à l'instant t2. Ce deuxième datagramme possède une structure identique à celle du premier datagramme transmis par le terminal 10. Le terminal 20 complète les champs de la partie d'en-tête de base du deuxième datagramme de la façon décrite plus haut pour le terminal 10. En particulier, il inscrit la valeur DSCP dans le champ TOS . En outre, le terminal 20 inscrit les valeurs de champs du vecteur BRIV mémorisées dans les champs correspondants de la partie d'entête optionnelle du deuxième datagramme.

Enfin, il initialise les champs CVI et FRIV du deuxième datagramme, de la même façon que celle décrite pour le terminal 10 et le premier datagramme.

Le deuxième datagramme est alors transmis dans le réseau 100 jusqu'au terminal 10. Il faut préciser que ce deuxième datagramme ne transite pas, a priori, par les mêmes routeurs que le premier datagramme, et que les nombres de routeurs par lesquels transite respectivement chacun des deux datagrammes sont a priori différents. Les contenus des champs du vecteur BRIV du deuxième datagramme, inscrits par le terminal 20, sont transportés lors de la transmission de ce datagramme dans le réseau 100, sans être utilisés.

La réception du deuxième datagramme par le terminal 10 est effectuée d'une façon identique à la réception du premier datagramme par le terminal 20. Le deuxième datagramme appartient au flux-retour F' de la session de communication dont le contexte est mémorisé dans le terminal 10. Les valeurs contenues dans les champs FRIV (notées X1', X2', X3', ...) et BRIV (X1, X2, X3, ....) du deuxième datagramme sont mémorisées par le terminal 10 parmi les données du contexte de la session de communication, respectivement en tant que valeurs de champs du vecteur BRIV d'un datagramme du flux-retour F', et valeurs de champs du vecteur FRIV d'un datagramme du flux-aller F. Les valeurs sont indiquées sur la figure 1 pour l'instant t3 de réception du deuxième datagramme. Elles remplacent les valeurs correspondantes mémorisées à l'instant t1. Les valeurs d'index de routes inscrites dans les champs du vecteur FRIV du premier datagramme sont alors mémorisées dans chacun des deux terminaux 10 et 20. Les valeurs d'index de routes inscrites par les routeurs dans les champs du vecteur FRIV du deuxième datagramme, de même que la dernière valeur inscrite dans le champ d'index CVI de celui-ci, sont mémorisées dans le terminal 10.

Le procédé de transmission décrit est maintenant complété en considérant que le terminal 10 produit de nouvelles données à destination du terminal 20, en réponse aux données véhiculées par le deuxième datagramme. Le terminal 10 crée alors un troisième datagramme, selon la procédure déjà décrite, en reprenant les données du contexte de session de communication actualisées lors de la réception du deuxième datagramme. Ce troisième datagramme appartient au même flux-aller F que le premier datagramme.

On suppose que le troisième datagramme est aussi transmis au routeur 1. Les étapes 100 à 111 des figures 3a et 3b sont alors exécutées de la même façon que pour le premier datagramme.

La valeur d'index de route qui est lue à l'étape 112 (figure 3b) dans le vecteur FRIV du troisième datagramme, à la position indiquée par la valeur du pointeur CVI, est 3. Cette valeur d'index de route est alors recherchée dans la table FIB, parmi les lignes de la partie P2 de celle- ci (étapes 113 et 114, E_INDEX_MS indiquant que la recherche est de type Exact INDEX value Matching Search ).

Si la valeur d'index de route lue dans le troisième datagramme, à la position indiquée par la valeur du curseur CVI, figure à l'une des lignes de la partie P2 de la table FIB, cette ligne est sélectionnée et le troisième datagramme est transmis selon la route associée à celle-ci (étape 119).

Préalablement, la valeur du pointeur CVI est incrémentée (étape 118).

Il est possible que la valeur d'index de route non nulle qui est lue dans le troisième datagramme à l'étape 112 ne figure plus dans aucune des lignes de la partie P2 de la table FIB. Cela peut se produire, notamment, lorsque la ligne de la partie P2 qui contenait cette valeur d'index de route a été supprimée lors d'une mise à jour de la table FIB intervenue entre les transmissions des premier et troisième datagrammes. Cela peut aussi indiquer que le troisième datagramme n'a pas été transmis conformément aux index de routes contenues dans son vecteur FRIV, pour l'un au moins des routeurs figurant sur la portion du chemin suivi entre le terminal 10 et le routeur 1. La valeur d'index de route lue par le routeur 1 dans le datagramme n'est alors pas significative. Dans un tel cas, pour indiquer sans ambiguïté que le troisième datagramme 7o suit un nouveau chemin de transmission dans le réseau 100, différent de celui suivi par les datagrammes antérieurs du même flux, le procédé peut comprendre une étape supplémentaire de réinitialisation de certains des index de routes du vecteur FRIV. Une valeur nulle est alors inscrite dans les champs du vecteur FRIV du troisième datagramme, qui sont associés à des valeurs du pointeur CVI supérieures à la valeur actuelle de celui-ci (étape 115). La suite du procédé de transmission du troisième datagramme par le routeur 1 est alors identique à celle du premier datagramme du flux-aller F (étapes 116-119).

A la réception du troisième datagramme, le terminal 20 actualise les valeurs mémorisées du contexte de la session de communication. A l'issue de cette actualisation, les valeurs d'index de routes inscrites dans les champs du vecteur FRIV du deuxième datagramme, recopiées dans les champs du vecteur BRIV du troisième datagramme par le terminal 10, sont mémorisées dans les deux terminaux 10 et 20.

Il ressort de la description ci-dessus qu'un tel procédé de transmission 25 d'un datagramme procure les avantages suivants: - chaque datagramme est transmis dans le réseau de communication, tout le long du chemin suivi, conformément à la classe de service inscrite dans celui-ci par le terminal émetteur ou un routeur d'accès; - une même classe de service est commune à tous les datagrammes d'un même flux; - lorsqu'un nouveau datagramme appartient à un flux pour lequel des datagrammes ont déjà été transmis, l'utilisation d'une route suivie par un datagramme antérieur du même flux est privilégiée pour le nouveau -21 - datagramme; - lorsque la route utilisée pour les datagrammes antérieurs du flux n'est plus disponible, ou lorsque le datagramme est un premier datagramme d'un flux, le datagramme est transmis selon une nouvelle route déterminée par les routeurs en respectant la classe de service indiquée pour ce flux; et - la nouvelle route est déterminée de façon à répartir les flux de datagrammes entre différents liens de transmission du réseau en fonction de leurs disponibilités respectives et, si plusieurs routes sont disponibles, selon celle qui correspond au coût minimal.

Une qualité de service fixée à l'émission d'un datagramme peut donc être garantie de façon globale sur tout le chemin de transmission de celui-ci. En outre, le procédé assure une réduction du risque de congestion du réseau et un fonctionnement stable de celui-ci.

II est entendu que de nombreuses adaptations peuvent être introduites dans le procédé de transmission qui a été décrit en détail ci- dessus. En particulier, la mémorisation du contexte de session de communication au sein de chaque terminal, ainsi que la façon d'inscrire la valeur DCSP dans les datagrammes, peuvent être modifiées pour prendre en compte une classe de service affectée au flux-retour d'une session de communication qui est différente de la classe de service affectée au flux- aller de la même session.

De même, la colonne Load des tables de routage (FIB) et d'informations de routage (RIB) peut être remplacée par une ou plusieurs colonnes contenant des informations de disponibilité des routes autres qu'un taux de charge.

Enfin, le champ FF des datagrammes qui a été introduit n'est pas indispensable à la mise en oeuvre de l'invention.

- 22 -

Claims (12)

REVENDICATIONS

1. Procédé de transmission d'un datagramme par un routeur (1-4) d'un réseau de communication (100), suivant lequel une table de routage du routeur contient, pour certains au moins des préfixes de destination et pour au moins une valeur d'un code de classe de service (DSCP) répertoriés dans ladite table, une ou plusieurs lignes associées à des routes respectives et identifiées chacune par une valeur d'un index de route, le procédé de transmission comprenant les étapes suivantes: a- sélection d'une première partie de la table de routage (P1) associée à un préfixe de destination correspondant à une adresse de destination lue dans le datagramme; b- sélection, dans ladite première partie de la table de routage (P1), d'une seconde partie de la table de routage (P2), associée à une valeur du code de classe de service (DSCP) lue dans le datagramme; csélection, dans ladite seconde partie de la table de routage (P2), d'une ligne associée à une valeur d'index de route lue dans le datagramme; et dtransmission du datagramme selon la route correspondant à la ligne sélectionnée.

2. Procédé selon la revendication 1, comprenant les étapes suivantes, exécutées si la première partie de la table de routage (P1) ne contient pas la valeur du code de classe de service (DSCP) lue dans le datagramme: - inscription par le routeur dans le datagramme, d'une valeur du code de classe de service correspondant à une transmission selon une route de coût minimal; et - reprise du procédé à l'étape b.

3. Procédé selon la revendication 1 ou 2, comprenant les étapes suivantes: - avant l'étape c, vérification de la présence d'un en-tête de protocole de transport TCP ou UDP dans le datagramme; et - si le datagramme comprend un en-tête de l'un desdits protocoles, exécution des étapes c et d du procédé, sinon transmission du datagramme selon une route de coût minimal.

4. Procédé selon l'une quelconque des revendications 1 à 3, suivant lequel la valeur d'index de route lue dans le datagramme appartient à un vecteur d'index de routes (FRIV) prévu dans ledit datagramme, et est inscrite à une position dans ledit vecteur indiquée par une valeur d'un pointeur (CVI) incrémentée lors de chaque transmission du datagramme par un routeur du réseau de communication (1-4) .

5. Procédé selon la revendication 4, suivant lequel le vecteur d'index de route (FRIV) et le pointeur (CVI) sont prévus dans une partie d'en-tête optionnelle du datagramme, et suivant lequel le procédé comprend les étapes suivantes: - avant l'étape c, vérification de la présence d'une partie d'en-tête optionnelle dans le datagramme; et - si le datagramme comprend une partie d'en-tête optionnelle, exécution des étapes c et d du procédé, sinon transmission du datagramme selon une route de coût minimal.

6. Procédé selon l'une quelconque des revendications 1 à 5, comprenant les étapes suivantes, exécutées si la seconde partie de la table de routage (P2) ne contient pas la valeur d'index de route lue dans le datagramme: sélection, dans la seconde partie de la table de routage (P2), d'une ligne associée à une route correspondant à un coût minimal parmi les routes des lignes de ladite seconde partie de la table de routage ayant une bande passante disponible suffisante; - inscription par le routeur dans le datagramme, de la valeur d'index de route correspondant à la ligne sélectionnée; et - 24 - - reprise du procédé à l'étape d.

7. Procédé selon la revendication 4 ou 5 ensemble la revendication 6, suivant lequel, si la seconde partie de la table de routage (P2) ne contient pas la valeur d'index de route lue dans le datagramme, le routeur réinitialise toutes les valeurs d'index de routes inscrites dans le datagramme (FRIV) à des positions indiquées par des valeurs du pointeur (CVI) supérieures à la valeur actuelle dudit pointeur.

8. Routeur (1-4) destiné à être connecté à un réseau de communication (100), adapté pour mettre en oeuvre un procédé de transmission selon l'une quelconque des revendications 1 à 7.

9. Routeur selon la revendication 8, comprenant des moyens de mémorisation d'une table d'informations de routage constituée de lignes respectivement associées à des routes entre ledit routeur et un sous- réseau (A, B) compris dans ledit réseau de communication (100), et contenant les données suivantes, pour certaines au moins des lignes de ladite table d'informations de routage: un préfixe de destination, une valeur du code de classe de service (DSCP), et une valeur de l'index de route attribuée pour identifier de façon univoque chacune des lignes correspondant à un même préfixe de destination et à une même valeur du code de classe de service, le routeur comprenant en outre des moyens de mise à jour de la table de routage d'après la table d'informations de routage.

10. Routeur selon la revendication 9, comprenant en outre des moyens d'élaboration de la table d'informations de routage à partir d'éléments d'information reçus caractérisant un état de fonctionnement du réseau (100), chaque élément d'information se rapportant à une classe de service identifiée par la valeur correspondante du code (DSCP).

11. Routeur selon la revendication 10, comprenant en outre des moyens pour produire des éléments d'information caractérisant un état de fonctionnement du réseau (100) et se rapportant chacun à une classe de service identifiée par la valeur correspondante du code (DSCP).

- 25 -

12. Terminal (10, 20) destiné à être relié à un réseau de communication (100), comprenant des moyens de mémorisation d'un contexte de session de communication, ledit contexte regroupant une adresse de source de datagrammes transmis dans ladite session, une adresse de destination desdits datagrammes, un numéro de port de source, un numéro de port de destination, un numéro de protocole de transport et une valeur d'un code de classe de service (DSCP), le terminal comprenant en outre des moyens d'inscription, dans un datagramme destiné à être transmis, de la valeur du code de classe de service (DSCP) mémorisée dans le contexte de session de communication o dont dépend ledit datagramme.