WO2005071902A1 - Marquage d'un datagramme transmis dans un reseau ip et transmission d'un tel datagramme - Google Patents

Marquage d'un datagramme transmis dans un reseau ip et transmission d'un tel datagramme Download PDF

Info

Publication number
WO2005071902A1
WO2005071902A1 PCT/FR2004/003157 FR2004003157W WO2005071902A1 WO 2005071902 A1 WO2005071902 A1 WO 2005071902A1 FR 2004003157 W FR2004003157 W FR 2004003157W WO 2005071902 A1 WO2005071902 A1 WO 2005071902A1
Authority
WO
WIPO (PCT)
Prior art keywords
datagram
router
vector
terminal
read
Prior art date
Application number
PCT/FR2004/003157
Other languages
English (en)
Inventor
Christophe Proust
Noël CANTENOT
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Priority to EP04805663A priority Critical patent/EP1766889A1/fr
Priority to US10/584,236 priority patent/US20070140265A1/en
Publication of WO2005071902A1 publication Critical patent/WO2005071902A1/fr

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00Routing or path finding of packets in data switching networks

Landscapes

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

Abstract

Un procédé de marquage d'un datagramme (20-22) transmis dans un réseau de communication de type IP par des routeurs (4, 5) comprend l'inscription de références dans des champs du datagramme (FFIV). Lors de la réception d'un datagramme (20, 22) par un routeur (5), le routeur lit une référence inscrite dans le datagramme et recherche la référence lue dans une table de références enregistrée au sein du routeur. Si la table de références ne contient pas la référence lue, le routeur sélectionne une nouvelle référence dans la table. Les références peuvent correspondre à des routes entre ledit routeur et un terminal destinataire du datagramme. La sélection d'une référence de route peut prendre en compte une valeur de taux de charge affectée à ladite route.

Description

MARQUAGE D'UN DATAGRAMME TRANSMIS DANS UN RESEAU IP ET TRANSMISSION D'UN TEL DATAGRAMME
La présente invention concerne un procédé de marquage d'un 5 datagramme transmis dans un réseau de communication de type IP («Internet Protocol»). Elle concerne aussi un procédé de transmission qui peut utiliser un marquage d'un datagramme ainsi effectué. L'identification du chemin suivi par un datagramme dans un réseau de communication revêt un enjeu important pour plusieurs aspects. Ceci0 concerne, en particulier, certains services destinés à assurer des garanties de qualité de transmission. A titre d'exemple, il est préférable que des datagrammes successifs d'un même flux suivent un même chemin dans le réseau, afin d'éviter que l'ordre d'arrivée des datagrammes au terminal destinataire soit différent de l'ordre d'envoi des mêmes datagrammes par le5 terminal émetteur. Un procédé de transmission existe, selon lequel le chemin suivi par un datagramme dans le réseau est inscrit dans le datagramme par le terminal émetteur du datagramme. Ce procédé est connu sous l'appellation de «source routing». Un inconvénient de ce procédé provient du fait que les terminaux0 n'ont pas connaissance de la topologie du réseau, c'est-à-dire qu'ils ne connaissent pas les liens disponibles ou indisponibles du réseau. Le chemin inscrit dans le datagramme est définitivement fixé au moment de l'émission du datagramme par le terminal émetteur, et aucune modification ultérieure du chemin n'est possible en fonction d'indisponibilités éventuelles de certains liens du réseau. Ce procédé de transmission ne permet donc pas d'activer des mécanismes adaptatifs de la fonction de routage dans les réseaux IP. En outre, l'utilisation du procédé «source routing» ne réduit pas le risque d'apparition de phénomènes de congestion dans le réseau, c'est-à-dire des situations selon lesquelles le nombre de datagrammes devant être acheminés par un lien déterminé du réseau atteint ou dépasse la capacité maximale de transmission de ce lien. Par ailleurs, dans un réseau de type IPv4, le chemin inscrit dans un datagramme ne peut contenir plus de neuf routeurs, à cause de la taille du champ du datagramme dans lequel ce chemin est inscrit. Enfin, le procédé «source routing» manque de sécurité, en ce sens que l'adresse IP source de premiers datagrammes peut être usurpée pour franchir un système de contrôle d'accès basé sur cette adresse. Des seconds datagrammes émis en réponse aux premiers datagrammes en utilisant aussi le procédé «source routing» peuvent alors être détournés. Selon un procédé connu d'identification du chemin suivi par un datagramme dans un réseau, appelé «record routing», chaque routeur par lequel transite un datagramme inscrit son adresse IP dans ce datagramme, à la suite de l'adresse inscrite par le routeur précédent sur le chemin suivi par le datagramme. Une traçabilité du chemin suivi est ainsi obtenue, en lisant la suite d'adresses inscrites dans le datagramme. Ce procédé d'identification du chemin suivi présente l'inconvénient de ne pas permettre d'orienter un datagramme au niveau d'un routeur en fonction d'une donnée externe à ce routeur au moment de la transmission du datagramme. En outre, de la même façon que pour le procédé «source routing», le nombre de routeurs du chemin suivi par un datagramme inscrit dans ce datagramme selon le procédé «record routing» est limité à neuf routeurs. Un but de la présente invention consiste à élaborer un marquage d'un datagramme transmis dans un réseau de communication, qui ne présente pas les inconvénients des procédés «source routing» et «record routing» indiqués ci-dessus. L'invention propose un procédé de marquage d'un datagramme transmis dans un réseau de communication comprenant des routeurs connectés entre eux par des liens de transmission. Le datagramme est transmis à partir d'un terminal émetteur du datagramme raccordé à un premier routeur du réseau jusqu'à un terminal récepteur du datagramme raccordé à un second routeur du réseau. Le datagramme comprend un vecteur formé de champs ordonnés contenant chacun une référence et un champ d'index de vecteur. Par ailleurs, chaque routeur du réseau dispose d'une table de références. Le procédé de marquage comprend les étapes suivantes, lorsqu'un routeur reçoit le datagramme : - lecture d'une valeur dans le champ d'index du datagramme, - lecture de la référence contenue dans le champ du vecteur du datagramme désigné par la valeur d'index lue ; - si la table du routeur ne contient pas la référence lue, inscription, dans le champ du vecteur du datagramme désigné par la valeur d'index lue, d'une référence sélectionnée dans la table du routeur ; - inscription, dans le champ d'index du datagramme, d'une valeur égale à la valeur lue incrémentée d'une unité ; et - transmission du datagramme à un routeur suivant du réseau. Selon le procédé de l'invention, l'inscription d'une nouvelle référence dans le datagramme par un routeur n'est pas systématique. La référence lue, qui constitue une donnée externe au routeur lors de la transmission du datagramme, est privilégiée pour rester inscrite dans le datagramme. L'inscription par le routeur d'une nouvelle référence intervient lorsque la référence lue n'est pas contenue dans la table de références du routeur. Le routeur est alors autonome pour sélectionner, dans sa table de références, la nouvelle référence à inscrire dans le datagramme. Lorsque le terminal récepteur reçoit le datagramme, les références inscrites dans les champs du vecteur du datagramme sont identiques chacune à une référence contenue dans la table de références d'un routeur ayant transmis ce datagramme. Plus précisément, la référence inscrite dans le nlème champ du vecteur est contenue dans la table du nleme routeur situé sur le chemin suivi par le datagramme dans le réseau, n étant une valeur prise par l'index de vecteur du datagramme lors de la transmission de celui-ci dans le réseau.
En fonction de la signification des références, diverses informations peuvent ainsi être recueillies lors de la réception du datagramme par le terminal récepteur. Lorsque chaque référence identifie une route le long de laquelle le datagramme a été transmis par un routeur, la connaissance de la signification des références de la table de chaque routeur permet de reconstituer le chemin suivi par le datagramme dans le réseau.
Le procédé de marquage selon l'invention est sécuritaire, parce que la seule lecture dans le datagramme des références inscrites dans les champs du vecteur ne suffit pas pour obtenir une information significative. Il est indispensable de connaître en outre la signification des références pour chaque routeur. L'interception d'un datagramme sans posséder cette connaissance ne permet pas une exploitation des références inscrites dans ce datagramme.
Suivant le mode de mise en œuvre préféré d'un procédé de marquage selon l'invention, lorsque le datagramme appartient à un flux de datagrammes successivement transmis par le terminal émetteur au terminal récepteur, la référence lue par le routeur est identique à une référence inscrite par ce routeur lors de la transmission d'un datagramme antérieur dudit flux. Si le réseau présente un fonctionnement stable, c'est-à-dire qu'aucune panne ni congestion de certains liens du réseau ne survient, qui affecte un routeur par lequel a transité ledit datagramme antérieur, une même référence contenue dans la table d'un routeur par lequel transitent plusieurs datagrammes successifs du flux est alors associée à tous ces datagrammes. On obtient ainsi un marquage identique le long du chemin suivi par les datagrammes successifs du flux, auquel peut être attaché un traitement spécifique associé à ce flux. L'invention concerne aussi un procédé de transmission d'un datagramme dans lequel sont inscrites des références de routes. Ces références peuvent avoir été inscrites préalablement dans le datagramme en utilisant un procédé de marquage tel que décrit ci-dessus, mais non nécessairement. Elles peuvent aussi avoir été inscrites dans le datagramme selon un autre procédé, tel que, par exemple, un procédé de type «source routing». Dans ce cas, une connaissance de la topologie du réseau par les terminaux est nécessaire, ainsi qu'une connaissance par les terminaux des tables de références des routeurs. Pour la mise en œuvre du procédé de transmission, un routeur du réseau dispose d'une table de références associées à des routes respectives entre ce routeur et un terminal destinataire du datagramme raccordé au réseau. De préférence, la table de références est associée à un préfixe de destination unique contenu dans une table de routage du routeur. Le procédé de transmission du datagramme comprend alors les étapes suivantes : - lors de la réception du datagramme par le routeur, lecture d'une référence dans le datagramme ; et - recherche de la référence lue dans la table de références du routeur, . si la table contient la référence lue, transmission du datagramme le long de la route à laquelle la référence lue est associée, . sinon, sélection d'une référence dans la table, et transmission du datagramme le long de la route à laquelle est associée la référence sélectionnée. Un procédé de transmission selon l'invention est mis en œuvre au niveau de la couche de protocole IP. Un premier avantage d'un tel procédé de transmission réside dans le fait qu'il ne requiert qu'une adaptation de la couche IP, sans modification des autres couches de protocoles mises en œuvre dans les routeurs. Un réseau de communication existant peut donc être facilement adapté pour la mise en œuvre d'un tel procédé de transmission. Un second avantage d'un procédé de transmission selon l'invention provient du fait qu'il permet une qualification initiale du chemin suivi par un datagramme dans le réseau. En effet, la transmission d'un datagramme par un routeur prend en compte prioritairement une référence de route lue dans ce datagramme. Ainsi, des datagrammes successifs d'un même flux, transmis par un terminal émetteur donné à destination d'un terminal récepteur donné, sont transmis dans le réseau le long de routes identiques, si ces datagrammes contiennent, lors de leur transmission par le terminal émetteur, des mêmes références, et si le réseau présente un fonctionnement stable. Cependant, lorsque la table de références d'un routeur ne contient pas la référence lue dans un datagramme, ce routeur sélectionne une route parmi des routes possibles pour transmettre le datagramme. Le procédé de transmission de l'invention est donc conforme au mode de fonctionnement principal d'un réseau IP, par transmissions élémentaires indépendantes, désigné par «hop by hop» en anglais. De façon préférée, la référence sélectionnée dans la table de références du routeur est en outre inscrite dans le datagramme en utilisant un procédé de marquage tel que décrit précédemment. Lorsque des procédés de marquage et de transmission selon l'invention sont simultanément mis en œuvre au sein d'un réseau IP, outre les fonctions de transmission des datagrammes et de connaissance de la topologie du réseau, les routeurs peuvent modifier les références de routes inscrites dans les datagrammes. Des références initiales peuvent être inscrites dans les datagrammes par les terminaux, sans connaissance de la topologie du réseau. A cette fin, les terminaux peuvent stocker des références lues dans un datagramme reçu, afin d'utiliser ces références lues comme références initiales pour un datagramme émis. Selon le mode de mise en œuvre préféré d'un procédé de transmission selon l'invention, la table de références du routeur comprend en outre, pour chaque référence de ladite table, une valeur de taux de charge affectée à la route à laquelle ladite référence est associée. Le taux de charge d'une route caractérise la quantité de trafic acheminée le long de cette route. Lors de la transmission d'un datagramme par un routeur, si la table de références du routeur ne contient pas la référence lue dans le datagramme, la référence sélectionnée peut correspondre à une valeur de taux de charge minimale parmi les routes auxquelles sont associées des références contenues dans ladite table de références. Un tel procédé de transmission prend donc en compte le taux de charge des différentes routes calculées. Ceci permet d'éviter que des congestions ne se produisent sur des liens de transmission particuliers du réseau, ou tout au moins réduit le risque de survenance de congestion. Il en résulte une plus grande stabilité du fonctionnement du réseau : aucune oscillation de charge n'est observée, entre des parties différentes du réseau. En effet, un tel procédé de transmission tend à répartir et à maintenir les flux de datagrammes d'une façon équilibrée dans le réseau selon la disponibilité des resources. L'invention concerne encore un terminal adapté pour mettre en œuvre un procédé de marquage tel que décrit en premier lieu. Un tel terminal comprend : - des moyens de production d'un datagramme destiné à être émis par le terminal, le datagramme comprenant un vecteur de champs ordonnés et un champ d'index de vecteur ; - des moyens d'inscription d'une référence initiale dans chaque champ du vecteur du datagramme destiné à être émis par le terminal ; et - des moyens d'inscription d'une valeur initiale dans le champ d'index du datagramme destiné à être émis par le terminal. De façon préférée, le terminal comprend en outre : - des moyens de lecture de secondes références dans des champs d'un vecteur supplémentaire contenus dans un datagramme reçu par le terminal ; et - des moyens de stockage, dans une table de contextes de sessions de communication dudit terminal, des secondes références avec des données de contexte de session de communication du datagramme reçu, de telle sorte que la référence initiale inscrite dans chaque champ du vecteur du datagramme destiné à être émis par le terminal est une dite seconde référence lue dans un champ du vecteur supplémentaire du datagramme reçu, lorsque le datagramme destiné à être émis appartient à la session de communication du datagramme reçu. Ainsi, des références de routes déterminées préalablement peuvent être reprises pour le datagramme destiné à être émis. Les moyens de production du datagramme destiné à être émis peuvent être adaptés de sorte que le datagramme destiné à être émis comprend en outre un vecteur supplémentaire de champs. Le terminal comprend alors en outre : - des moyens de lecture de premières références dans des champs d'un vecteur contenus dans le datagramme reçu ; - des moyens de stockage, dans la table de contextes de sessions de communication dudit terminal, desdites premières références avec les données de contexte de session de communication du datagramme reçu ; et - des moyens d'inscription desdites premières références dans les champs du vecteur supplémentaire du datagramme destiné à être émis par le terminal, lorsque le datagramme destiné à être émis appartient à la session de communication du datagramme reçu. Ainsi, lorsque deux tels terminaux émettent et reçoivent chacun des datagrammes d'un flux-aller ou d'un flux-retour relevant d'une même session de communication, des références initiales peuvent être inscrites dans un datagramme du flux-aller par le terminal émetteur de ce datagragramme, qui sont respectivement identiques à des références contenues dans des champs dudit vecteur supplémentaire d'un datagramme du flux-retour. En appliquant ce mécanisme aux deux terminaux émetteur et récepteur d'un datagramme, il résulte que la référence lue par un routeur dans ce datagramme est identique à une référence inscrite par ce routeur lors de la transmission d'un datagramme antérieur de ce flux. L'invention concerne en outre un routeur adapté pour mettre en œuvre un procédé de transmission tel que décrit en second lieu. Un tel routeur comprend : - des moyens de lecture d'une valeur dans un champ d'index de vecteur d'un datagramme reçu par le routeur ; - des moyens de lecture d'une référence contenue dans un champ de vecteur dudit datagramme désigné par la valeur d'index lue ; - des moyens de stockage d'une table de références ; - des moyens d'association des références contenues dans la table avec des routes respectives ; - des moyens de recherche d'une référence lue, dans la table de références dudit routeur, agencés pour commander une transmission dudit datagramme le long de la route à laquelle est associée la référence lue, si la table de références contient la référence lue ; - des moyens de sélection d'une référence dans la table de références, agencés pour être activés si la table de références ne contient pas la référence lue, et agencés pour commander une transmission dudit datagramme le long de la route à laquelle est associée la référence sélectionnée ; et - des moyens d'inscription, dans le champ d'index dudit datagramme, d'une valeur égale à la valeur lue incrémentée d'une unité. Selon un mode de réalisation avantageux d'un tel routeur, les moyens d'association sont compris dans des moyens de calcul d'une table de routage de ce routeur. En outre, les moyens de calcul appartiennent à une unité de contrôle du routeur. Le routeur peut être adapté pour mettre en œuvre simultanément un procédé de marquage d'un datagramme transitant par ce routeur, tel que décrit en premier lieu. Pour cela, il comprend en outre des moyens d'inscription de la référence sélectionnée dans le champ du vecteur du datagramme désigné par la valeur d'index lue. Même si la combinaison au sein d'un même routeur des mises en œuvre des procédés de marquage et de transmission objets de l'invention est particulièrement avantageuse pour obtenir un fonctionnement efficace du réseau, le routeur peut comporter des moyens de mise en œuvre du procédé de transmission indépendamment de la présence, dans ce même routeur, de moyens de marquage de datagrammes. Et vice-versa. Pour un routeur qui combine des mises en œuvre des deux procédés, certains des moyens cités ci-dessus pour chaque procédé peuvent être communs aux deux procédés. L'invention concerne enfin un réseau de communication qui comprend un routeur tel que décrit ci-dessus. D'autres particularités et avantages de la présente invention apparaîtront dans la description ci-après d'un d'exemple de mise en œuvre non limitatif, en référence aux dessins annexés, dans lesquels : - la figure 1 représente un réseau de communication dans lequel l'invention peut être mise en œuvre ; - la figure 2 illustre la structure d'un en-tête de datagramme IP telle qu'utilisée pour une mise en œuvre de l'invention ; - les figures 3a et 3b, destinées à être associées, illustrent différentes étapes d'une transmission selon l'invention de plusieurs datagrammes, au sein d'un réseau tel que représenté sur la figure 1 ; - la figure 4 est un organigramme d'un procédé de transmission d'un datagramme selon l'invention. Selon la figure 1, un réseau de communication par transmission de datagrammes 100, de type IP, comprend des routeurs 4-9 reliés entre eux par des liens de transmission. Ainsi une chaîne de routeurs forme une route dans le réseau 100, pour transmettre un datagramme. Chaque routeur peut comprendre une unité d'acheminement (ou
«forwarding unit», en anglais) qui transfère les datagrammes entre deux liens reliés à cette unité, et une unité de commande (ou «control unit») qui supervise l'activité de l'unité d'acheminement. Pour le routeur 5, l'unité d'acheminement et l'unité de commande sont respectivement référencées 5a et 5b. Des terminaux sont connectés à certains des routeurs du réseau 100.
Ces terminaux peuvent être de différents types, tels que, par exemple, des unités informatiques, des unités de communication mobiles, etc.. Sur la figure 1 , des unités informatiques 1 et 10 sont connectées aux routeurs 4 et 7, respectivement. Des données produites par le terminal 1 et destinées au terminal 10 sont réparties par le terminal 1 dans des datagrammes IP. Ces datagrammes sont transmis par certains des routeurs du réseau 100 jusqu'au terminal 10. 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 DP, suivi d'identifiants de chacun des routeurs ou terminaux connectés à ce lien. Chaque datagramme IP possède un en-tête tel que représenté sur la figure 2, pour la version 4 du protocole IP (IPv4). L'en-tête comprend une partie d'en-tête de base Bl présente dans tous les datagrammes, et une partie d'entêté optionnelle Bll. La partie d'en tête Bl possède une longueur fixe de 20 octets. La partie d'en-tête Bll peut avoir une longueur variable. Parmi les champs de la partie d'en-tête Bl 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», ou TOS, dans lequel est spécifiée la façon dont le datagramme doit être géré ; - le champ «TOTAL LENGTH», dans lequel est spécifiée la longueur totale du datagramme ; - le champ «ID» destiné à recevoir un numéro d'identification du datagramme, notamment en vue d'une éventuelle fragmentation du datagramme ; - le champ «TTL» ou «TIME TO LIVE», en anglais, dans lequel est indiquée une durée maximale d'existence du datagramme en cours d'acheminement dans le réseau ; et - le champ «PROTOCOL», dans lequel est indiqué le protocole de haut niveau auquel se réfèrent les données placées par le terminal émetteur dans le champ de données du datagramme (ou «payload», en anglais, et non représenté sur la figure 2). La partie d'en-tête Bll comprend un premier champ noté «OPT. 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 Bll. A titre d'exemple, pour le mode de mise en œuvre 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 Bll, exprimée en octets, est indiquée dans le champ «OPT. LENGTH» (de 1 octet). Pour la mise en œuvre de l'invention décrite ici, on utilise la longueur maximale possible pour la partie d'en-tête Bll, à savoir 40 octets. Les 38 octets restant disponibles dans la partie d'en-tête Bll sont répartis en quatre champs disposés de la façon suivante : - un premier champ noté FVI, pour «Forward Vector Index» en anglais, de 1 octet, destiné à recevoir une valeur numérique d'index ; - un second champ noté BVL, pour «Backward Vector Length», aussi de 1 octet, destiné à recevoir une valeur de longueur de vecteur ; - une première série ordonnée de 36 champs, notée FFIV, pour «Forward Flow Identifier 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 références numériques, codées sur 4 bits chacune. Par souci de clarté, l'index et le premier vecteur sont respectivement désignés dans la suite par index FVI et vecteur FFIV. L'index FVI sert à repérer un champ dans le vecteur FFIV, par le numéro d'ordre de la position de ce champ dans le vecteur FFIV, compté à partir du début du vecteur. Ainsi, la valeur de l'index FVI varie entre 1 et 36. - une seconde série ordonnée de champs, notée BFIV, pour «Backward Flow Identifier Vector», aussi de 18 octets au total. Cette seconde série de champs est organisée de la même façon que la première série de champs. Les champs BFIV forment un second vecteur et sont destinés à recevoir 36 secondes références numériques codées sur 4 bits chacune. Ce second vecteur, qui correspond au vecteur supplémentaire cité dans la description générale de l'invention, est désigné ci-après par vecteur BFIV. Il est entendu que les positions des champs FVI et BVL, ainsi que celles des champs des vecteurs FFIV et BFIV représentées sur la figure 2 sont données à titre d'exemple. D'autres positions peuvent être choisies, pour obtenir des modes de mise en œuvre alternatifs de l'invention. De tels modes de mise en œuvre alternatifs sont aussi compris dans l'invention. Néanmoins, il est particulièrement avantageux, dans le cadre de la version IPv4 du protocole IP, de concevoir les champs FVI et BVL, ainsi que les champs des vecteurs FFIV et BFIV, de façon à exploiter la longueur maximale de la partie d'en-tête Bll. Il est aussi entendu que l'invention peut être mise en œuvre de façon équivalente dans le cadre de la version 6 du protocole IP (IPv6), en adaptant les champs FVI et BVL, ainsi que les champs des vecteurs FFIV et BFIV définis ci-dessus 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 un en-tête d'option de taille supérieure à 40 octets. 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. Le tableau 1 ci-dessous représente une partie d'une telle table de routage, établie à titre d'exemple pour le routeur 5 de la figure 1 :
Figure imgf000015_0001
Tableau 1
La table FIB doit être lue par lignes, chaque ligne correspondant à une route. A titre d'exemple, la deuxième ligne caractérise la direction à prendre, c'est-à-dire l'adresse IP du routeur suivant, soit DP_5_6 : 6, pour atteindre le préfixe de destination DP_7_10. La première colonne de la table FIB, intitulée «Destination Prefix» en anglais, regroupe des préfixes de destination DP. A titre d'exemple, le préfixe de destination noté DP_7_10 correspond au sous-réseau d'interconnexions entre le routeur 7 et le terminal 10. La seconde colonne de la table FIB, intitulée «Next Hop», indique une adresse IP d'un routeur ou d'un terminal relié au routeur 5 par un lien de transmission unique, pour chaque préfixe de destination indiqué dans la première colonne. Les adresses IP sont construites de la façon connue, avec un préfixe DP suivi d'un identifiant du terminal ou du routeur. Les colonnes «Interface» et «Encapsulation L2» donnent des informations utiles pour la transmission du datagramme, sans relation avec l'invention. Lors de la réception d'un datagramme par un routeur, l'adresse IP du terminal destinataire de ce datagramme est lue dans le champ «DESTINATION ADDRESS» de la partie d'en-tête Bl du datagramme. D'une façon connue, le préfixe de destination de l'adresse lue 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 selon un principe de plus grande coïncidence, ou «longest match» en anglais. Selon l'invention, la table FIB de chaque routeur est complétée de la façon suivante, illustrée par le tableau 2 ci-dessous. Le tableau 2 représente encore une partie de table FIB, établie à titre d'exemple pour le routeur 5 (voir figure 1 ) :
Figure imgf000016_0001
Tableau 2
Par rapport à une table FIB conforme au tableau 1, une table FIB conforme au tableau 2 possède deux colonnes supplémentaires. La première colonne contient des références de routes, et est intitulée «Réf.». La seconde colonne, intitulée «Load», contient des valeurs de taux de charge. Une table FIB conforme au tableau 1 indique une unique possibilité de transmission d'un datagramme par le routeur, pour chaque préfixe de destination. A la différence, une table FIB conforme au tableau 2 indique une ou plusieurs possibilités de transmission d'un datagramme pour chaque préfixe de destination. Chaque possibilité correspond à une route différente entre le routeur concerné, c'est-à-dire le routeur 5 dans l'exemple considéré, et le terminal destinataire dont l'adresse IP est lue dans le datagramme. La colonne «Réf.» associe à chacune de ces routes une référence numérique. Ces références distinguent les différentes routes prises en compte dans la table FIB, qui correspondent à un même préfixe de destination. Une même référence peut éventuellement être utilisée plusieurs fois dans la table FIB, pour désigner des routes correspondant à des préfixes de destination différents. Pour un même préfixe de destination, les références associées aux routes prises en compte dans la table FIB n'ont qu'une fonction d'identification, et ne correspondent pas à un classement. Les références utilisées dépendent des modifications intervenues dans la table FIB lors de mises à jour successives de celle-ci, établies par l'unité de commande du routeur. La table de références évoquée dans la description générale de l'invention est formée par l'ensemble des lignes de la table FIB qui correspondent à un préfixe de destination déterminé unique. Ainsi, dans l'exemple correspondant à la figure 1 et au tableau 2, la table de références considérée pour un datagramme dont le préfixe de destination est DP_7_10 comprend les troisième à cinquième lignes de la table FIB, sans compter la ligne des noms des colonnes. Pour chaque ligne de la table FIB, c'est à dire pour chaque route prise en compte, la colonne «Load» indique une valeur de taux de charge. Cette valeur est déterminée par l'unité de commande en fonction de données d'état du réseau. De telles données sont, par exemple, des valeurs de taux de charge de certains au moins des liens du réseau 100. 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. 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. On décrit maintenant en détail des transmissions de plusieurs datagrammes au sein du réseau 100 représenté sur la figure 1, en référence aux figures 3a et 3b. Les lettres A à O indiquées sur les figures 3a et 3b repèrent différentes étapes de ces transmissions. Lorsque des données sont produites par le terminal 1 à destination du terminal 10, le terminal 1 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 1 crée un contexte de session de communication (étape A de la figure 3a). Ce contexte de session de communication regroupe notamment les données suivantes : les adresses IP respectives des terminaux 1 et 10, un numéro de protocole de transport (par exemple les protocoles TCP ou UDP) et des numéros de ports source et destination. Les données du contexte de session de communication sont stockées dans le terminal 1. Lors de la création d'un premier datagramme 20, le terminal 1 configure la partie d'en-tête Bl de ce datagramme. En particulier, il inscrit les adresses IP respectives des terminaux 1 et 10 dans les champs «SOURCE ADDRESS» et «DESTINATION ADDRESS». Il configure aussi la partie d'en- tête Bll, en inscrivant les valeurs initiales suivantes dans les différents champs : - champ OPT. TYPE : 10011001 - champ OPT. LENGTH : 40 - champ FVI : 1 - champ BVL : 0 - champs du vecteur FFIV : 0, 0 0 - champs du vecteur BFIV : 0, 0 0 Selon le procédé donné ici en exemple, 1 est la valeur initiale de l'index FVI, et 0 est la valeur initiale inscrite dans le champ BVL. 0 est aussi la référence initiale inscrite dans tous les champs des vecteurs FFIV et BFIV. La référence 0 est réservée à la fonction d'initialisation : elle n'est pas utilisée dans les tables de références des routeurs pour identifier une route. Ainsi qu'il apparaîtra dans la suite, l'initialisation à 0 des champs des vecteurs FFIV et BFIV d'un datagramme par un terminal signifie que ce datagramme est soit un datagramme isolé, soit un premier datagramme d'un flux, soit un datagramme ultérieur d'un flux pour lequel le terminal émetteur ne dispose pas de références initiales prédéterminées. Ces références inscrites dans les champs des vecteurs FFIV et BFIV du datagramme 20, ainsi que les valeurs inscrites dans les champs FVI et BVL du datagramme 20, sont stockées par le terminal 1 avec les données du contexte de session de communication. Le terminal 1 transmet alors le datagramme 20 au routeur 4 (étape B).
On suppose que le routeur 4 transmet à son tour le datagramme 20 au routeur 5 (étape C). Lors de cette transmission, le routeur 4 inscrit la valeur 2 dans le champ d'index FVI du datagramme 20, ainsi que la référence 3, donnée à titre d'exemple, dans le premier champ du vecteur FFIV du datagramme 20. Le procédé de transmission du datagramme 20, mis en œuvre au sein de chaque routeur, est maintenant décrit en détail pour le routeur 5. Au cours de ce procédé, le routeur 5 sélectionne une ligne dans sa table FIB (tableau 2). Cette sélection est effectuée en deux étapes successives. Lors d'une première étape de la sélection d'une ligne de la table FIB, le routeur 5 lit l'adresse IP du terminal destinataire du datagramme 20 dans le champ «DESTINATION ADDRESS» de la partie d'en-tête Bl. Il isole le préfixe de destination de cette adresse, et le compare aux préfixes de destination contenus dans la première colonne de la table FIB. Selon le procédé de plus grande coïncidence («longest match»), il sélectionne dans la table FIB le plus long préfixe de destination qui correspond à celui de l'adresse IP du terminal destinataire. Dans l'exemple décrit ici, le préfixe de destination sélectionné est noté DP_7_10 (tableau 2). Les références contenues dans la colonne «Réf.» de la table FIB aux lignes correspondant au préfixe de destination DP_7_10 forment la table de références prise en compte lors de la transmission du datagramme 20. Cette table de références est donc une partie de la table FIB qui correspond au préfixe de destination unique sélectionné DP_7_10. La seconde étape de la sélection d'une ligne de la table FIB est maintenant décrite en référence à la figure 4. Les différentes étapes mentionnées à la figure 4 sont exécutées dans l'unité d'acheminement 5a. Le routeur 5 lit d'abord la valeur inscrite dans le champ d'index FVI du datagramme 20 (étape 30). La valeur lue est 2. Il lit ensuite la référence contenue dans le champ du vecteur FFIV dont la position au sein de ce vecteur correspond à la valeur lue dans le champ FVI (étape 31). La référence 0 est ainsi lue dans le deuxième champ du vecteur FFIV. Etant donné que la référence lue est égale à la référence d'initialisation (étape 32a), le routeur 5 est alors autonome pour déterminer la route le long de laquelle il transmet le datagramme. Il sélectionne, dans la table de références correspondant au préfixe de destination DP_7_10, la référence qui correspond à une valeur de taux de charge minimale (étape 33). Dans le cas de la table FIB du tableau 2, la référence 4 correspond à la valeur de taux de charge minimale. Le routeur 5 inscrit alors la référence 4 dans le champ du vecteur FFIV désigné par l'index FVI (deuxième champ du vecteur FFIV - étape 34 de la figure 4). Il incrémente ensuite d'une unité la valeur de l'index FVI et inscrit la valeur obtenue dans le champ FVI du datagramme 20 (étape 35). Le datagramme 20 contient alors les valeurs et références indiquées sur la figure 3a, pour l'étape D. La ligne de la table FIB qui correspond au préfixe de destination sélectionné et à la référence 4 est la ligne sélectionnée. Le routeur 5 transmet le datagramme 20 conformément à l'indication de la colonne «Next Hop» pour la ligne sélectionnée. Dans l'exemple décrit, il transmet le datagramme 20 au routeur 6. Les routeurs 6 (étape E de la figure 3b) puis 7 (étape F) transmettent chacun le datagramme 20 en suivant un procédé identique à celui décrit pour le routeur 5. Le terminal 10 reçoit alors le datagramme 20 contenant la valeur d'index FVI et les références, inscrites dans les champs des vecteurs FFIV et BFIV, indiquées à l'étape G, à titre d'exemple. Le terminal 10 stocke les données du contexte de la session de communication du datagramme 20, lues dans la partie d'en-tête Bl du datagramme 20. Il stocke aussi, avec ces données, les contenus des champs FVI et BVL, ainsi que ceux des champs des vecteurs FFIV et BFIV. Le terminal 10 lit alors les données contenues dans le champ de données (ou «payload») du datagramme 20. On suppose maintenant que le terminal 10 produit à son tour des données à destination du terminal 1, en réponse aux données véhiculées par le datagramme 20. Les données produites par le terminal 10 sont transmises dans le cadre de la même session de communication que celle du datagramme 20. Le datagramme 20 appartient donc à un flux-aller relevant de cette session de communication, et de nouveaux datagrammes émis par le terminal 10 appartiennent à un flux-retour de cette session de communication. Le terminal 10 crée un nouveau datagramme 21 , en reprenant les données du contexte de session de communication du datagramme 20 (étape H de la figure 3b). Le datagramme 21 possède une structure identique à celle du datagramme 20. Le terminal 10 complète les champs de la partie d'en-tête Bl du datagramme 21 de la façon décrite plus haut pour le terminal 1 et le datagramme 20, en échangeant les données relatives aux terminaux émetteur et destinataire. En outre, le terminal 10 récupère, avec les données du contexte de session de communication stockées, les références et valeurs mémorisées lors de la réception du datagramme 20. Il les inscrit dans les champs de la partie d'en-tête Bll du datagramme 21 , de la façon suivante : - dans les champs successifs du vecteur FFIV du datagramme 21 : les références contenues dans les champs du vecteur BFIV du datagramme 20, selon le même ordre ; - dans les champs successifs du vecteur BFIV du datagramme 21 : les références contenues dans les champs du vecteur FFIV du datagramme 20, selon le même ordre ; et - dans le champ BVL du datagramme 21 : la valeur lue dans le champ FVI du datagramme 20. De même que le terminal 1 lors de l'émission du datagramme 20, le terminal 10 inscrit la valeur initiale 1 dans le champ d'index FVI du datagramme 21 (étape I). La transmission du datagramme 21 dans le réseau 100 jusqu'au terminal 1 est effectuée d'une façon analogue à la transmission du datagramme 20 décrite plus haut. Il faut préciser que le datagramme 21 ne transite pas, a priori, par les mêmes routeurs que le datagramme 20, et que les nombres de routeurs par lesquels transite respectivement chacun des datagrammes 20 et 21 sont a priori différents. Sur les figures 3a et 3b, y est le nombre de routeurs par lesquels transite le datagramme 21. Les contenus du champ BVL et des champs du vecteur BFIV du datagramme 21 sont transportés lors de la transmission du datagramme 21 dans le réseau 100, sans être utilisés. La réception du datagramme 21 par le terminal 1 (étape J de la figure 3a) est effectuée d'une façon identique à la réception du datagramme 20 par le terminal 10, décrite ci-dessus. En particulier, les contenus des champs FVI et BVL, ainsi que ceux des vecteurs FFIV et BFIV du datagramme 21 , sont stockés par le terminal 1 avec les données du contexte de la session de communication. Les références inscrites dans les champs du vecteur BFIV du datagramme 21 du flux-retour, et la valeur inscrite dans le champ BVL du datagramme 21, sont alors stockées dans chacun des deux terminaux 1 et 10. Ainsi, les références inscrites par les routeurs dans les champs du vecteur FFIV du datagramme 20, de même que la dernière valeur inscrite dans le champ d'index FVI du datagramme 20, i.e. la valeur inscrite par le routeur 7, sont stockées dans les deux terminaux 1 et 10 avec les données du contexte de la session de communication. Le procédé décrit maintenant s'applique à la situation selon laquelle le terminal 1 produit de nouvelles données à destination du terminal 10, en réponse aux données véhiculées par le datagramme 21. Le terminal 1 crée alors un datagramme 22, selon la procédure déjà décrite, en reprenant les données du contexte de session de communication stockées (étape K de la figure 3a). Le datagramme 22 appartient au même flux-aller relevant de cette session de communication que le datagramme 20. Le terminal 1 inscrit, dans le champ FVI du datagramme 22, la valeur initiale 1 , et, dans le champ BVL du datagramme 22, la valeur y d'index FVI lue dans le datagramme 21 lors de la réception de ce dernier par le terminal 1. Il inscrit aussi, dans les champs du vecteur FFIV du datagramme 22, les références lues dans les champs du vecteur BFIV du datagramme 21. De même, il inscrit dans les champs du vecteur BFIV du datagramme 22, les références lues dans les champs du vecteur FFIV du datagramme 21. Les valeurs et références ainsi obtenues pour les champs du datagramme 22 sont indiqués à l'étape L de la figure 3a. Autrement dit, lorsqu'un datagramme appartient à un flux-aller de datagrammes successivement transmis par un terminal émetteur à un terminal récepteur, ledit flux-aller relevant d'une session de communication, les champs du vecteur BFIV dudit datagramme sont destinés à recevoir des références inscrites dans les champs d'un vecteur FFIV d'un datagramme d'un flux-retour relevant de ladite session de communication, transmis par le terminal récepteur des datagrammes du flux-aller, et reçu par le terminal émetteur des datagrammes du flux-aller avant la transmission dudit datagramme du flux- aller. De même, le champ BVL dudit datagramme du flux-aller est destiné à recevoir la dernière valeur inscrite dans le champ FVI dudit datagramme du flux-retour. On suppose que le datagramme 22 est transmis au routeur 4 par le terminal 1 , puis au routeur 5 par le routeur 4 (étape M), de la même façon que le datagramme 20. Lorsque le datagramme 22 est transmis par le routeur 4, celui-ci incrémente à 2 la valeur de l'index FVI. Le routeur 4 laisse en outre la référence 3 inscrite dans le premier champ du vecteur FFIV du datagramme 22. La description du procédé de transmission d'un datagramme par un routeur du réseau 100 est complétée maintenant, dans le cas du datagramme 22 transmis par le routeur 5. La première étape de la sélection d'une ligne de la table FIB est identique à celle décrite pour la transmission du datagramme 20. Lors de la seconde étape de la sélection d'une ligne de la table FIB, le routeur 5 analyse le vecteur FFIV du datagramme 22 conformément au procédé de la figure 4. Il lit la référence indiquée par l'index FVI (étapes 30 et 31). La référence lue est 4, conformément à l'inscription qu'avait opérée le routeur 5 dans le datagramme 20, lors l'étape D de la transmission de ce dernier. Cette référence lue étant différente de la référence d'initialisation 0 des champs de vecteurs (étape 32a), le routeur 5 examine si la table de références déterminée lors de la première étape de sélection d'une ligne de la table FIB contient la référence 4 (étape 32b). Deux situations peuvent alors se présenter : selon une première situation, la table de références contient encore la référence 4, et selon une seconde situation, elle ne contient plus la référence 4. La première situation intervient, notamment, lorsque la table FIB du routeur 5 n'a pas été modifiée entre les transmissions respectives des datagrammes 20 et 22. Elle intervient aussi si la référence 4 a été maintenue dans la table FIB pour le préfixe de destination DP_7_10 lors des mises à jour de la table FIB survenues entre les transmissions des datagrammes 20 et 22. Dans ce cas, conformément au diagramme de la figure 4, le vecteur FFIV n'est pas modifié par le routeur 5, l'index FVI est incrémente (étape 35), et le routeur 5 transmet le datagramme 22 au routeur 6 (étape 36). Les transmissions des datagrammes 20 et 22 par le routeur 5 sont alors identiques. La seconde situation se produit lorsqu'une mise à jour de la table FIB du routeur 5 est survenue entre la transmission du datagramme 20 et celle du datagramme 22. On suppose, pour l'exemple, que la mise à jour n'a consisté, en ce qui concerne les routes reliant le routeur 5 au terminal 10, qu'à la suppression de la ligne du tableau 2 correspondant au préfixe de destination DP_7_10 et à la référence 4. A l'issue de la première étape de sélection d'une ligne de la table FIB, le routeur 5 a sélectionné dans sa table FIB les deux lignes correspondant au préfixe de destination DP_7_10. Ces deux lignes constituent la nouvelle table de références considérée. La première de ces deux lignes correspond à la référence de route 1 , et la valeur de taux de charge indiquée est 70%. La seconde de ces deux lignes correspond à la référence de route 6, et la valeur de taux de charge indiquée est 20%. Le routeur 5 sélectionne celle de ces deux références pour laquelle la route présente la valeur minimale de taux de charge (étapes 32b et 33) : la référence 6. Il inscrit alors cette référence dans le deuxième champ du vecteur FFIV du datagramme 22 (étape 34). De la même façon que précédemment, il incrémente l'index FVI du datagramme 22 (étape 35). Enfin, il transmet le datagramme 22 selon l'indication de la colonne «Next Hop» de la table FIB pour la ligne correspondant au préfixe de destination DP_7_10 et à la référence 6 (étape 36). Dans l'exemple présent, le routeur 5 transmet le datagramme 22 au routeur 9. Les étapes N et O des figures 3a et 3b illustrent la seconde situation qui vient d'être décrite, x est une référence inscrite par le routeur 9. A la réception du datagramme 22 par le terminal 10, le terminal 10 actualise les valeurs et références stockées avec les données du contexte de la session de communication. A l'issue de cette actualisation, les références inscrites dans les champs du vecteur FFIV du datagramme 21 , recopiées dans les champs du vecteur BFIV du datagramme 22 par le terminal 1 , sont stockées dans les deux terminaux 1 et 10. Il en est de même pour la dernière valeur inscrite dans le champ d'index FVI du datagramme 21. Il ressort de la description ci-dessus que l'association des procédés de marquage et de transmission d'un datagramme selon l'invention procure les avantages suivants : - 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 datagramme ; - lorsque la route utilisée pour le datagramme antérieur du flux n'est plus disponible, le nouveau datagramme est transmis selon une nouvelle route ; 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 selon leurs degrés de disponibilité. Cette association combine une transmission par sauts élémentaires indépendants («hop by hop») et une réduction du risque de congestion du réseau. Un fonctionnement stable du réseau en résulte. II est entendu que des variantes peuvent être introduites par rapport au mode de mise en œuvre de l'invention qui a été décrit ci-dessus. En particulier, dans la figure 4, les étapes 32a et 32b peuvent être regroupées en une étape unique, correspondant au même test que celui de l'étape 32b. Enfin, dans des modes de mise en œuvre particuliers de l'invention, des références inscrites dans un champ du vecteur FFIV ou du vecteur BFIV d'un datagramme, de même qu'une valeur inscrite dans le champ FVI ou BVL d'un datagramme, peuvent n'être stockées que dans l'un des deux terminaux émetteur ou destinataire de ce datagramme. Une telle mise en œuvre peut, notamment, concerner un datagramme appartenant à un flux-retour.

Claims

R E V E N D I C A T I O N S
1. Procédé de marquage d'un datagramme (20, 22) transmis dans un réseau de communication (100) comprenant des routeurs (4-9) connectés entre eux par des liens de transmission, à partir d'un terminal émetteur du datagramme (1) raccordé à un premier routeur du réseau (4) jusqu'à un terminal récepteur du datagramme (10) raccordé à un second routeur du réseau (7), le datagramme comprenant un vecteur (FFIV) formé de champs ordonnés contenant chacun une référence, le datagramme comprenant en outre un champ d'index de vecteur (FVI), chaque routeur disposant d'une table de références, le procédé comprenant les étapes suivantes, lorsqu'un routeur (5) reçoit le datagramme : - lecture d'une valeur dans le champ d'index (FVI) du datagramme, - lecture de la référence contenue dans le champ du vecteur du datagramme (FFIV) désigné par la valeur d'index lue ; - si la table du routeur ne contient pas la référence lue, inscription, dans le champ du vecteur du datagramme désigné par la valeur d'index lue, d'une référence sélectionnée dans la table du routeur ; - inscription, dans le champ d'index du datagramme, d'une valeur égale à la valeur lue incrémentée d'une unité ; et - transmission du datagramme à un routeur suivant du réseau.
2. Procédé de marquage selon la revendication 1, suivant lequel les champs du vecteur (FFIV) et le champ d'index (FVI) sont disposés dans l'entête du datagramme.
3. Procédé de marquage selon la revendication 1 ou 2, suivant lequel les références contenues dans la table du routeur (5) sont associées à des routes respectives dans le réseau (100).
4. Procédé de marquage selon la revendication 3, suivant lequel la table de références du routeur (5) est une partie d'une table de routage dudit routeur, ladite partie correspondant à un préfixe de destination unique contenu dans la table de routage.
5. Procédé de marquage selon l'une quelconque des revendications 1 à 4, suivant lequel le datagramme (22) appartient à un flux de datagrammes successivement transmis par le terminal émetteur (1) au terminal récepteur (10), et suivant lequel la référence lue est identique à une référence inscrite par ledit routeur (5) lors de la transmission d'un datagramme antérieur dudit flux (20).
6. Procédé de marquage selon la revendication 5, suivant lequel une référence initiale est inscrite dans chaque champ du vecteur (FFIV) d'un premier datagramme du flux (20) par le terminal émetteur (1), la référence initiale ne correspondant à aucune référence contenue dans les tables de références des routeurs.
7. Procédé de marquage selon l'une quelconque des revendications précédentes, suivant lequel le datagramme (22) appartient à un flux-aller de datagrammes successivement transmis par le terminal émetteur (1) au terminal récepteur (10), ledit flux-aller relevant d'une session de communication, et suivant lequel ledit datagramme (22) comprend en outre un vecteur supplémentaire (BFIV) formés de champs destinés à recevoir des références inscrites dans les champs d'un vecteur (FFIV) d'un datagramme d'un flux- retour (21) relevant de ladite session de communication, transmis par le terminal récepteur des datagrammes du flux-aller (10), et reçu par le terminal émetteur des datagrammes du flux-aller (1) avant la transmission dudit datagramme du flux-aller (22).
8. Procédé de marquage selon la revendication 7, suivant lequel les références inscrites dans les champs du vecteur (FFIV) du datagramme du flux-retour (21) sont stockées avec des données de contexte de la session de communication dans l'un au moins des deux terminaux (1, 10).
9. Procédé de marquage selon la revendication 7 ou 8, suivant lequel les champs du vecteur supplémentaire (BFIV) sont disposés dans l'en-tête dudit datagramme du flux-aller (22).
10. Procédé de marquage selon l'une quelconque des revendications 7 à 9, suivant lequel des références initiales sont inscrites par le terminal émetteur (1) dans les champs du vecteur (FFIV) dudit datagramme du flux-aller (22), lesdites références initiales étant respectivement identiques à des références contenues dans des champs d'un vecteur supplémentaire (BFIV) du datagramme du flux-retour (21).
11. Procédé de marquage selon la revendication 10, suivant lequel les références inscrites dans les champs du vecteur supplémentaire (BFIV) du datagramme du flux-retour (21) sont stockées avec des données de contexte de la session de communication dans l'un au moins des deux terminaux (1, 10).
12. Procédé de marquage selon l'une quelconque des revendications 7 à 11, suivant lequel ledit datagramme du flux-aller (22) comprend en outre un champ de longueur de vecteur (BVL) destiné à recevoir la dernière valeur inscrite dans le champ d'index (FVI) du datagramme du flux-retour (21).
13. Procédé de marquage selon la revendication 12, suivant lequel la dernière valeur inscrite dans le champ d'index (FVI) du datagramme du flux- retour (21) est stockée avec des données de contexte de la session de communication dans l'un au moins des deux terminaux (1, 10).
14. Procédé de marquage selon la revendication 12 ou 13, suivant lequel le champ de longueur de vecteur (BVL) est disposé dans l'en-tête dudit datagramme du flux-aller (22).
15. Procédé de marquage selon l'une quelconque des revendication 12 à 14, suivant lequel une valeur inscrite dans un champ de longueur de vecteur (BVL) du datagramme du flux-retour (21) est stockée avec des données de contexte de la session de communication dans l'un au moins des deux terminaux (1, 10).
16. Procédé de transmission d'un datagramme (20, 22) par un routeur (5) d'un réseau de communication (100), le routeur disposant d'une table de références associées à des routes respectives entre ledit routeur et un terminal, destinataire du datagramme (10) raccordé au réseau, le procédé de transmission comprenant les étapes suivantes : - lors de la réception du datagramme par le routeur, lecture d'une référence dans le datagramme ; et - recherche de la référence lue dans la table de références du routeur, . si la table contient la référence lue, transmission du datagramme le long de la route à laquelle la référence lue est associée, . sinon, sélection d'une référence dans la table, et transmission du datagramme le long de la route à laquelle est associée la référence sélectionnée ; procédé selon lequel la référence lue a été inscrite préalablement dans le datagramme en utilisant un procédé de marquage selon l'une quelconque des revendications 1 à 15.
17. Procédé de transmission selon la revendication 16, suivant lequel la référence sélectionnée dans la table de références du routeur est en outre inscrite dans ledit datagramme (20, 22) en utilisant un procédé de marquage selon l'une quelconque des revendications 1 à 15.
18. Procédé de transmission selon la revendication 16 ou 17, suivant lequel la table de références est associée à un préfixe de destination unique contenu dans une table de routage dudit routeur (5).
19. Procédé de transmission selon la revendication 18, comprenant les étapes suivantes effectuées lors de la réception du datagramme par le routeur
(5) avant la recherche de la référence lue dans la table de références dudit routeur : - lecture d'une adresse de destination dans le datagramme ; et - sélection dans la table de routage dudit routeur du plus long préfixe de destination correspondant à l'adresse de destination lue, la table de références dudit routeur dans laquelle la référence lue dans le datagramme est ensuite recherchée étant associée au préfixe de destination sélectionné.
20. Procédé de transmission selon l'une quelconque des revendications 16 à 19, suivant lequel la table de références comprend en outre, pour chaque référence de ladite table, une valeur de taux de charge affectée à la route à laquelle est associée ladite référence, et suivant lequel la référence sélectionnée correspond à une valeur de taux de charge minimale parmi les routes auxquelles sont associées des références contenues dans ladite table de références.
21. Terminal (1 , 10) comprenant : - des moyens de production d'un datagramme destiné à être émis par le terminal (20-22), le datagramme comprenant un vecteur de champs ordonnés (FFIV) et un champ d'index de vecteur (FVI) ; - des moyens d'inscription d'une référence initiale dans chaque champ du vecteur (FFIV) du datagramme destiné à être émis par le terminal ; et - des moyens d'inscription d'une valeur initiale dans le champ d'index (FVI) du datagramme destiné à être émis par le terminal.
22. Terminal selon la revendication 21 , comprenant en outre : - des moyens de lecture de secondes références dans des champs d'un vecteur supplémentaire (BFIV) contenus dans un datagramme reçu (21) par le terminal ; et - des moyens de stockage, dans une table de contextes de sessions de communication dudit terminal, des secondes références avec des données de contexte de session de communication du datagramme reçu, dans lequel la référence initiale inscrite dans chaque champ du vecteur (FFIV) du datagramme destiné à être émis par le terminal (21 , 22) est une dite seconde référence lue dans un champ du vecteur supplémentaire (BFIV) du datagramme reçu (20, 21), lorsque le datagramme destiné à être émis appartient à la session de communication du datagramme reçu.
23. Terminal selon la revendication 22, dans lequel les moyens de production du datagramme destiné à être émis (21 , 22) sont adaptés de sorte que le datagramme destiné à être émis comprend en outre un vecteur supplémentaire (BFIV) de champs, le terminal comprenant en outre : - des moyens de lecture de premières références dans des champs d'un vecteur (FFIV) contenus dans le datagramme reçu (20, 21) ; - des moyens de stockage, dans la table de contextes de sessions de communication dudit terminal, desdites premières références avec les données de contexte de session de communication du datagramme reçu ; et - des moyens d'inscription desdites premières références dans les champs du vecteur supplémentaire (BFIV) du datagramme destiné à être émis par le terminal (21 , 22), lorsque le datagramme destiné à être émis appartient à la session de communication du datagramme reçu.
24. Terminal selon la revendication 23, dans lequel les moyens de production du datagramme destiné à être émis (21 , 22) sont aussi adaptés de sorte que le datagramme destiné à être émis comprend en outre un champ de longueur de vecteur (BVL), le terminal comprenant en outre : - des moyens de lecture d'une valeur dans un champ d'index de vecteur (FVI) contenu dans le datagramme reçu (20, 21 ) ; - des moyens de stockage, dans la table de contextes de sessions de communication dudit terminal, de la valeur d'index lue avec les données de contexte de session de communication du datagramme reçu ; et - des moyens d'inscription de la valeur d'index lue dans le champ de longueur de vecteur (BVL) du datagramme destiné à être émis par le terminal (21 , 22), lorsque le datagramme destiné à être émis appartient à la session de communication du datagramme reçu.
25. Routeur (5) comprenant : - des moyens de lecture d'une valeur dans un champ d'index de vecteur (FVI) d'un datagramme reçu (20, 22) par le routeur ; - des moyens de lecture d'une référence contenue dans un champ de vecteur (FFIV) dudit datagramme désigné par la valeur d'index lue ; - des moyens de stockage d'une table de références ; - des moyens d'association des références contenues dans la table avec des routes respectives ; - des moyens de recherche d'une référence lue, dans la table de références dudit routeur, agencés pour commander une transmission dudit datagramme le long de la route à laquelle est associée la référence lue, si la tablé de références contient la référence lue ; - des moyens de sélection d'une référence dans la table de références, agencés pour être activés si la table de références ne contient pas la référence lue, et agencés pour commander une transmission dudit datagramme le long de la route à laquelle est associée la référence sélectionnée ; et - des moyens d'inscription, dans le champ d'index dudit datagramme (FVI), d'une valeur égale à la valeur lue incrémentée d'une unité.
26. Routeur selon la revendication 25, comprenant en outre des moyens d'inscription de la référence sélectionnée dans le champ de vecteur (FFIV) dudit datagramme désigné par la valeur d'index lue.
27. Routeur selon la revendication 25 ou 26, dans lequel les moyens d'association sont compris dans des moyens de calcul d'une table de routage dudit routeur, lesdits moyens de calcul appartenant à une unité de contrôle dudit routeur (5b).
28. Routeur selon la revendication 27, dans lequel les moyens d'association sont agencés en outre pour associer une table de références à un préfixe de destination unique contenu dans la table de routage dudit routeur (5).
29. Routeur selon la revendication 28, dans lequel la table de références dudit routeur comprend, pour chaque référence de ladite table, une valeur de taux de charge affectée à la route à laquelle est associée ladite référence, et dans lequel les moyens de sélection d'une référence sont agencés pour sélectionner la référence pour laquelle la route correspond à une valeur de taux de charge minimale.
30. Réseau de communication comprenant un routeur (5) selon l'une quelconque des revendications 25 à 29.
PCT/FR2004/003157 2003-12-26 2004-12-08 Marquage d'un datagramme transmis dans un reseau ip et transmission d'un tel datagramme WO2005071902A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP04805663A EP1766889A1 (fr) 2003-12-26 2004-12-08 Marquage d'un datagramme transmis dans un reseau ip et transmission d'un tel datagramme
US10/584,236 US20070140265A1 (en) 2003-12-26 2004-12-08 Marking of a datagram transmitted over an ip network and transmission of one such datagram

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0315470 2003-12-26
FR0315470 2003-12-26

Publications (1)

Publication Number Publication Date
WO2005071902A1 true WO2005071902A1 (fr) 2005-08-04

Family

ID=34803300

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2004/003157 WO2005071902A1 (fr) 2003-12-26 2004-12-08 Marquage d'un datagramme transmis dans un reseau ip et transmission d'un tel datagramme

Country Status (3)

Country Link
US (1) US20070140265A1 (fr)
EP (1) EP1766889A1 (fr)
WO (1) WO2005071902A1 (fr)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10609156B2 (en) * 2017-04-03 2020-03-31 Bank Of America Corporation Data transfer, over session or connection, and between computing device and server associated with one or more routing networks in response to detecting activity
US10601718B2 (en) 2017-04-03 2020-03-24 Bank Of America Corporation Data transfer, over session or connection, and between computing device and server associated with a routing network for modifying one or more parameters of the routing network
US10716060B2 (en) 2017-04-03 2020-07-14 Bank Of America Corporation Data transfer between computing device and user device at different locations and over session or connection to display one or more routing networks to use
US10601934B2 (en) 2017-04-03 2020-03-24 Bank Of America Corporation Data transfer, over session or connection, and between computing device and one or more servers for transmitting data to a third party computing device
US10608918B2 (en) 2017-04-03 2020-03-31 Bank Of America Corporation Data transfer, over session or connection, and between computing device and one or more servers to determine likelihood of user device using a routing network

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6130889A (en) * 1996-10-02 2000-10-10 International Business Machines Corporation Determining and maintaining hop-count for switched networks
US6512766B2 (en) * 1997-08-22 2003-01-28 Cisco Systems, Inc. Enhanced internet packet routing lookup
US6763007B1 (en) * 1998-12-11 2004-07-13 Lucent Technologies Inc. Two phase local mobility scheme for wireless access to packet based networks
CN1242632C (zh) * 1999-02-16 2006-02-15 Ntt移动通信网株式会社 在移动通信系统中无线电信道分配判断方法和无线电信道控制装置
US20050259682A1 (en) * 2000-02-03 2005-11-24 Yuval Yosef Broadcast system
US7496096B1 (en) * 2002-01-31 2009-02-24 Cisco Technology, Inc. Method and system for defining hardware routing paths for networks having IP and MPLS paths
US8392952B2 (en) * 2002-05-03 2013-03-05 Time Warner Cable Enterprises Llc Programming content processing and management system and method
US7660255B2 (en) * 2002-11-13 2010-02-09 International Business Machines Corporation System and method for routing IP datagrams
US7872991B2 (en) * 2003-02-04 2011-01-18 Alcatel-Lucent Usa Inc. Methods and systems for providing MPLS-based layer-2 virtual private network services
US6970464B2 (en) * 2003-04-01 2005-11-29 Cisco Technology, Inc. Method for recursive BGP route updates in MPLS networks
US7715380B2 (en) * 2003-06-19 2010-05-11 Cisco Technology, Inc. Apparatus and methods for handling shared services through virtual route forwarding (VRF)-aware-NAT
US7698455B2 (en) * 2003-08-01 2010-04-13 Foundry Networks, Inc. Method for providing scalable multicast service in a virtual private LAN service
US7903565B2 (en) * 2005-08-12 2011-03-08 Alcatel Method of monitoring a tandem connection in a MPLS telecommunication network
US7609620B2 (en) * 2005-08-15 2009-10-27 Cisco Technology, Inc. Method and apparatus using multiprotocol label switching (MPLS) label distribution protocol (LDP) to establish label switching paths (LSPS) for directed forwarding
KR100735276B1 (ko) * 2005-08-18 2007-07-03 삼성전자주식회사 디지털 비디오 방송 시스템에서 다중 프로토콜 캡슐화순방향 오류 정정 프레임의 복호 방법 및 장치
US7644343B2 (en) * 2006-01-17 2010-01-05 Rajugopal Gubbi Error resilience methods for multi-protocol encapsulation forward error correction implementations
US7684350B2 (en) * 2006-03-16 2010-03-23 Cisco Technology, Inc. Method and apparatus for distributing labels in a label distribution protocol multicast network
EP2074842B1 (fr) * 2006-10-12 2018-10-03 Telefonaktiebolaget LM Ericsson (publ) Distribution efficace de services mbms sur une épine dorsale en utilisant une approche sur un seul tunnel
KR101405970B1 (ko) * 2007-06-28 2014-06-12 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법
KR101486372B1 (ko) * 2007-07-25 2015-01-26 엘지전자 주식회사 디지털 방송 시스템 및 데이터 처리 방법

Non-Patent Citations (5)

* Cited by examiner, † Cited by third party
Title
ACHARYA, GRIFFOUL, ANSARI: "IP multicast Support in MLPS networks", IETF NETWORK WORKING GROUP DRAFT, 23 February 1999 (1999-02-23), XP002289485 *
AWDUCHE ET AL: "RSVP-TE: Extensions to RSVP for LSP Tunnels", IETF NETWORK WORKING GROUP RFC 3209, December 2001 (2001-12-01), XP015008988 *
CLERGET A ET AL: "TUF : tag-based unified fairness", PROCEEDINGS IEEE INFOCOM 2001. THE CONFERENCE ON COMPUTER COMMUNICATIONS. 20TH. ANNUAL JOINT CONFERENCE OF THE IEEE COMPUTER ANDCOMMUNICATIONS SOCIETIES. ANCHORAGE, AK, APRIL 22 - 26, 2001, PROCEEDINGS IEEE INFOCOM. THE CONFERENCE ON COMPUTER COMMUNI, vol. VOL. 1 OF 3. CONF. 20, 22 April 2001 (2001-04-22), pages 498 - 507, XP010538731, ISBN: 0-7803-7016-3 *
ROSEN ET AL.: "Multiprotocol Label switching Architecture RFC3031", IETF NETWORK WORKING GROUP RFC3031, January 2001 (2001-01-01), XP015008814 *
STOICA, ZHANG, VENKITARAMAN, MYSORE: "Per Hop Behaviors Based on Dynamic Packet State", IETF DRAFT, October 2002 (2002-10-01), XP002289486 *

Also Published As

Publication number Publication date
US20070140265A1 (en) 2007-06-21
EP1766889A1 (fr) 2007-03-28

Similar Documents

Publication Publication Date Title
US6567408B1 (en) Methods and apparatus for packet classification with multi-level data structure
FR2835135A1 (fr) Appareil et procede pour reclasser des modeles de flux de trafic dans un systeme de communication mobile
FR2789778A1 (fr) Procede pour associer des references d'acheminement a des paquets de donnees au moyen d'une memoire trie, et routeur de paquets appliquant ce procede
EP2436155B1 (fr) Procédé de gestion de chemins entre un noeud source et un noeud destinataire au niveau de la couche de liaison, noeud source et table correspondants
EP1486047B1 (fr) Procede de selection et de tri de paquets de donnees
FR2811180A1 (fr) Reseau de transmission de donnees ip utilisant un syteme de selection de route base sur des informations de niveau 4/5
WO2005071902A1 (fr) Marquage d'un datagramme transmis dans un reseau ip et transmission d'un tel datagramme
WO2002015488A1 (fr) Procedes et systeme de classement par paquets comportant de multiples ensembles de reponses
EP3503499A1 (fr) Procédé d'optimisation de l'efficacité spectrale dans un contexte d'interconnexion mpls
FR2838898A1 (fr) Dispositif d'aiguillage a commutation et routage centralises
EP3949287A1 (fr) Passerelle et procédé de différentiation de trafic émis par la passerelle, dispositif et procédé gestion du trafic
EP2031809B1 (fr) Procédé de traitement de flots dans un réseau de communication
FR2919139A1 (fr) Mecanisme de mise a jour des parametres d'un pseudo-lien
EP1595362A1 (fr) Procede pour l'interconnexion de reseaux prives virtuels en mode non connecte
EP1355454B1 (fr) Dispositif de routage à traitement parallèle
FR2857539A1 (fr) Description de contenu de paquets dans un reseau de communication par paquets
WO2006067288A1 (fr) Procede de transmission d'un datagramme, routeur et terminal adaptes pour mettre en œuvre un tel procede
EP1762051A1 (fr) Procede de gestion d'une interconnexion entre reseaux de telecommunication et dispositif mettant en oeuvre ce procede
WO2005025146A1 (fr) Transmission de trafic multipoint au sein d’un reseau de communication
EP1714467A1 (fr) ATTRIBUTION AUTOMATIQUE DE NUMERO DE RESEAU POUR UN EQUIPEMENT DE COMMUNICATION AU SEIN D'UN RESEAU IPv6
EP2476225B1 (fr) Procede et systeme pour le controle de l'acheminement d'un flux de donnees d'une classe de service a travers un reseau maille et chiffre
WO2005052812A1 (fr) Dispositif de memoire de type trie avec mecanisme de compression
EP4024820A1 (fr) Procédé de configuration d'une interface sécurisée entre un réseau de transport et un réseau élémentaire d'une pluralité de réseaux élémentaires fédérés à travers le réseau de transport; interface associée
WO2005071901A1 (fr) Procede de mise a jour d'une table d'informations de routage et routeur correspondant
FR3087610A1 (fr) Echange de donnees dans une infrastructure des objets connectes

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BW BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE EG ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NA NI NO NZ OM PG PH PL PT RO RU SC SD SE SG SK SL SY TJ TM TN TR TT TZ UA UG US UZ VC VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): BW GH GM KE LS MW MZ NA SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LT LU MC NL PL PT RO SE SI SK TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2004805663

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2007140265

Country of ref document: US

Ref document number: 10584236

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2004805663

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 10584236

Country of ref document: US