Brevet FR2814307A1 — publié le 20020322

La présente invention se rapporte à un procédé, un produit logiciel et une source de logiciel de gestion de routage de paquets de données, dans un réseau de communication tel qu'Internet. Elle concerne aussi un routeur d'un réseau de communication, un dispositif de codage de paquets de données et un paquet de données numérisées correspondants. Classiquement, sur le réseau Internet, un serveur communique avec un ou plusieurs clients par une communication d'informations unidirectionnelle (du serveur vers le client) ou bidirectionnelle (serveurclient). Ces informations ou données sont constituées en paquets, formés chacun d'un entête (ou header) et d'un contenu utile consécutif appelé payload. Les paquets sont transportés par la toile ou web, qui comprend une multitude de routeurs chargés de faire transiter les paquets vers leurs destinations en suivant un protocole indiqué dans les entêtes des paquets. Si le flux de données est trop important au regard d'une bande passante locale ou des capacités d'un des routeurs, une congestion risque d'apparaître. Celle-ci peut se manifester par des retards et des pertes de paquets. Ce phénomène de congestion est d'autant plus fréquent que la plupart des applications de première génération utilisent une stratégie d'effort optimisé (best-effort), c'est-à-dire qu'elles produisent des transmissions de paquets Indépendamment de la charge du réseau. Il en résulte une surcharge de routeurs et des congestions durables. Pour remédier à ces difficultés, il a été proposé des applications de deuxième génération (qualifiées de tcp-friendly ), capables d'adapter leurs débits de transmission à la bande passante courante du réseau, selon une loi dite AIMD (additive increase/multiplicative decrease). Dans ces applications, si une congestion est détectée, le flux d'émission est réduit exponentiellement (divisé par deux par exemple) jusqu'à amélioration. Si, au contraire, la bande passante est suffisante, le débit d'émission peut être augmenté, mais seulement par Incréments additifs avec pas réduits. Bien que cette technique permette de réduire sensiblement les problèmes de congestion, son efficacité est limitée car une grande partie des applications ne respecte pas une telle stratégie. De plus, toute adaptation de débit est faite par les serveurs concernés après un délai suivant la détection d'une congestion, alors que des paquets ont généralement déjà été perdus. Des applications évoluées rendent possible une adaptation de la qualité de service en fonction de fluidité de flux dans le réseau, cette adaptation étant gérée au niveau d'un serveur et/ou d'un client. Par exemple, un flux vidéo étant codé avec un pas de quantification dans un serveur puis transmis à un client, le serveur peut diminuer le débit vidéo (et réduire la qualité) en augmentant le pas de quantification. Le client peut pour sa part demander au serveur de diminuer le pas de quantification ou, dans le cas de flux vidéo multicouches ( scalable en anglais), il peut se désabonner des couches les plus hautes. Par ailleurs, il a été proposé un protocole, dit RSVP (pour ReSource reserVation Protocol), permettant un partage de ressources disponibles suivant des priorités et de réserver une bande passante pour des applications particulières disposant de privilèges. Ces solutions aux problèmes de congestion ont pour inconvénients d'intervenir également a posteriori, souvent après des pertes de paquets. De plus, le serveur ou le client concerné a des réactions généralement imprécises. En effet, ils n'adaptent pas leurs niveaux de réaction, tels qu'une diminution de débit pour un serveur ou un nombre de couches à abandonner pour un client, à la mesure des problèmes de congestion en cause. On connaît d'autre part des routeurs spécifiques de réseaux de communication, disposant de capacités résidentes de gestion de flux de paquets de données. De tels routeurs présentent l'avantage de pouvoir gérer localement les transferts de données, donc en particulier de réagir rapidement à tout problème de congestion en leur sein. De plus, leurs moyens de gestion sont parfaitement adaptés à leurs propres capacités, notamment en termes de bande passante ou de débit. En revanche, ces routeurs appliquent généralement des règles de base, fondées sur la reconnaissance d'ordres de priorité dans les entêtes des paquets. Ils ne sont donc capables de faire face à des situations d'engorgement que dans des situations particulières correspondant à certains flux de données. De plus, ils sont généralement dépourvus de moyens d'action lorsqu'ils sont confrontés à des paquets de priorité identique. Ainsi, les problèmes de congestion et leurs conséquences néfastes ne disparaissent pas mais sont seulement atténués. La présente invention a pour objet un procédé de gestion de routage de paquets de données dans un réseau de communication, permettant de remédier aux problèmes de congestion, en rendant possible des réactions rapides et appropriées à ces problèmes. Le domaine d'applications principal de l'invention est le réseau Internet. Cependant, elle peut également s'appliquer à d'autres réseaux, en particulier ceux comprenant un grand nombre de routeurs traversés et dont la topologie (nombre et type des routeurs, chemins empruntés...) est inconnue a priori. Elle est notamment appropriée à des transmissions sur un réseau du type UMTS (Universal Mobile Telephone Service). L'invention est également relative à un routeur spécifique d'un réseau de communication, approprié à une mise en oeuvre du procédé de l'invention. Elle concerne aussi une source de logiciels de gestion de routage convenant pour la mise en oeuvre de ce procédé. L'invention porte par ailleurs sur un dispositif de codage de paquets de données particuliers et sur un paquet de données numérisées correspondant, de tels paquets permettant de mettre en route le procédé de l'invention ou d'en modifier les modalités. De plus, l'invention a pour objet un produit logiciel de gestion de routage de paquets de données, ainsi qu'un logiciel correspondant, convenant pour la mise en oeuvre du procédé de l'invention. Par produit logiciel , on entend un support matériel dans lequel est mis en place un logiciel , considéré comme un ensemble immatériel d'instructions destiné à interagir avec un ordinateur. A cet effet, l'invention s'applique à un procédé de gestion de routage de paquets de données dans un réseau de communication comprenant des routeurs. Dans ce procédé, on gère au moins un flux de paquets de données au moyen d'au moins un de ces routeurs. Selon l'invention : - on télécharge dans au moins un de ces routeurs, dit routeur de gestion, un ou plusieurs logiciels de gestion de routage à partir d'au moins une source de logiciels téléchargeables, et on gère au moyen de ces logiciels de gestion le routage d'au moins un flux de paquets de données associé à ces logiciels de gestion, transitant par ce routeur de gestion. Ainsi, le procédé de l'invention repose sur une gestion de flux organisée au niveau de routeurs eux-mêmes, ce qui permet de réagir au plus proche de défauts de transmission quand une congestion se produit. Cependant, contrairement à des systèmes connus dans lesquels des routeurs disposent de capacités de gestion résidentes chargées localement et une fos pour toutes par un administrateur du routeur, on télécharge des logiciels de gestion de routage adaptés à des flux de paquets de données consécutifs à l'envoi de ces logiciels. Préférentiellement, un même serveur fournit un algorithme de réaction et de contrôle d'un flux de paquets, avec ce flux. Ce procédé permet ainsi d'adapter dynamiquement les règles de gestion appliquées par les routeurs de gestion aux différents types de flux concernés, par exemple vidéo ou texte, de manière souple. Contrairement à toute attente au regard des développements passés, on ne résout donc pas les problèmes de congestion en augmentant la complexité des capacités de gestion de certains routeurs. Cette dernière solution les rendrait capables de réagir de manière plus appropriée à des situations plus diverses que dans les techniques existantes, mais impliquerait des coûts de développement et d'implantation, nécessiterait d'accroître les capacités des routeurs et augmenterait les difficultés de gestion associées. La complexité se reporterait également sur le codage des paquets de données, qui devrait permettre une reconnaissance plus fine par les routeurs que les ordres de priorité utilisés dans des méthodes connues. Le procédé de l'invention permet au contraire d'adapter de manière très souple le comportement des routeurs de gestion aux flux de paquets transitant par ces routeurs, sans nécessiter de capacités de gestion résidentes importantes, ni d'implantations complexes. En fait, les seuls paramètres de gestion propres aux routeurs de gestion eux-mêmes ( à vide ) concernent leur capacité de traitement (CPU), leur taille mémoire disponible et leur prise en compte des priorités des différents flux. Qui plus est, le procédé de l'invention peut permettre à un serveur de choisir lul-même les stratégies de réaction en cas de congestion réseau ou de variation de bande passante dans un routeur. Des réponses pertinentes peuvent ainsi être très rapidement appliquées face à des problèmes complexes, car le serveur est le mieux placé pour connaître le type de données qu'il envoie et donc pour les adapter à un changement de condition de transport. On déporte ainsi l'intelligence du serveur au niveau du routeur. A titre d'illustration, dans une mise en oeuvre avantageuse, le logiciel de gestion téléchargé est approprié à des flux vidéo compressés. De tels flux, avec compression par des méthodes MPEG, comprennent classiquement des paquets relatifs à des images de type 1, P ou B. Le logiciel de gestion est alors prévu pour permettre aux routeurs de gestion dans lesquels il est téléchargé de distinguer les paquets relatifs aux différents types d'images. En cas de saturation d'un de ces routeurs, ce dernier conserve et transmet les images du type 1 et jette les images des types P et B. Dans une première variante, on jette d'abord les images de type B si on est proche de la saturation (par exemple si la mémoire est pleine à plus de 80 %), et éventuellement aussi les images de type P si ça ne suffit pas (par exemple S ! la mémoire reste remplie à plus de 60 %). Dans une deuxième variante, on procède en davantage d'étapes, en commençant par jeter lors d'une saturation une partie seulement des images de type B (par exemple une sur deux si la mémoire est pleine à plus de 80 %), puis au besoin toutes les autres images de type B (par exemple si la mémoire reste pleine à plus de 65 %), et enfin les images de type P (par exemple si le taux de remplissage dépasse 50 %). Toutes autres partitions des images des types P et/ou B pour des abandons successifs selon différents taux de remplissage sont également possibles. Dans une autre mise en oeuvre avantageuse, un serveur transmet aux routeurs de gestion des images haute et basse résolutions, en déchargeant à un logiciel de gestion téléchargé dans ces routeurs la fonction de faire parvenir au client les images de haute résolution si cela est possible. Dans encore une autre mise en oeuvre d'illustration, le réseau considéré comprend une première partie constituée par Internet et une seconde partie par un réseau UMTS. La gestion de flux porte en particulier sur le niveau de redondance dû à l'utilisation de codes de correction d'erreurs. Un logiciel téléchargé a pour fonction de reconnaître le changement de type de transport en interrogeant le routeur, et lors du passage de l'Internet à l'UMTS, de générer des mots de correction d'erreurs adaptés à l'UMTS, en jetant les mots de correction d'erreurs adaptés à l'Internet. Cette stratégie permet à la fois d'éviter le transport d'informations Inutiles sur les deux réseaux, d'assurer la redondance voulue sur l'un et l'autre, et de se prémunir d'une dégradation de correction d'erreur UMTS pendant le transport sur Internet Dans ce qui suit, le terme client est employé indifféremment pour désigner un client proprement dit ou une adresse multi-diffusion (multiast). Par session , on entend un canal de communication entre un serveur et un client et par connexion , on signifie une mise en communication entre le serveur et le client d'une session donnée. Chacun des flux considérés correspond à une connexion déterminée. Préférentiellement, les logiciels de gestion sont respectivement associés de manière univoque à des connexions. Par exemple, pour une transmission vidéo par une connexion, le logiciel de gestion est prévu pour permettre au routeur de garder en mémoire les derniers paquets vidéo d'images du type 1 et de les ré-envoyer immédiatement au client en cas de perte. Mais ce logiciel n'est pas utilisé pour une autre connexion, portant par exemple sur la transmission de pages codées sous la forme dite HTML (Hyper Text Markup Language) Dans une autre forme d'association, les logiciels de gestion sont respectivement associés de manière univoque à des sessions. Cette mise en oeuvre est avantageuse pour des logiciels de gestion plus génériques, par exemple portant sur des types de données bien connues (comme de la vidéo MPEG2). Enfin, dans encore une autre forme encore plus générale, chaque logiciel de gestion est associé à un ensemble de sessions. Cette mise en oeuvre est par exemple utilisée pour des configurations par défaut. Les différentes sortes d'association sont avantageusement employées à tour de rôle, selon les flux considérés. Il est avantageusement mis fin à une association entre des flux et un logiciel de gestion de flux par l'indication initiale d'une durée maximale, dans un paquet ou dans le logiciel. Dans une autre forme avantageuse de fin d'association, on envoie au routeur un paquet spécial contenant une indication de fin de gestion de flux par le logiciel. Les logiciels de gestion téléchargés sont préférentiellement fournis sous forme de codes exécutables sur les routeurs de gestion, sans compilation. Cette forme des logiciels permet d'assurer un portage maximal sur différents types de routeurs. A titre d'exemple, les codes sont programmés dans le langage appelé JAVA. Il n'est pas nécessaire que tous les routeurs disposent de capacités de gestion. Au contraire, avantageusement, seule une partie minoritaire des routeurs sont des routeurs de gestion du procédé selon l'invention. Les autres routeurs sont alors du type traditionnel, se contentant de faire transiter les paquets, ou éventuellement comprennent des capacités de gestion résidentes. Préférentiellement : - on détecte au moyen d'au moins un des routeurs de gestion, dit routeur de gestion courant, dans un paquet transitant par ce routeur, dit paquet d'activation, l'existence d'un logiciel téléchargeable destiné à gérer le routage d'au moins un flux de paquets de données, - on envoie en amont de ce routeur au moyen de ce routeur une requête de téléchargement de ce logiciel, - et on télécharge ce logiciel dans ce routeur. Cette mise en oeuvre permet de déclencher les opérations de téléchargement de manière simple et efficace, tout au long de la chaîne de routeurs de gestion impliqués dans la transmission d'un ou plusieurs flux de données. Plus précisément, le paquet d'activation a un en-tête contenant par exemple, outre des informations relatives au routage de ce paquet (adresses source et destination, numéro de port, priorité...), un indicateur ou flag indiquant que ce paquet et les suivants du même flux peuvent être contrôlés par un ou plusieurs logiciels téléchargés aux routeurs de gestion. Dans une première forme préférée de téléchargement du logiciel impliquant un paquet d'activation, ce paquet d'activation étant émis par un serveur, on envoie la requête de téléchargement à ce serveur. Les opérations successives d'envois du paquet d'activation, de la requête de transfert et du logiciel de gestion s'en trouvent ainsi simplifiées, car la communication est établie entre chacun des routeurs de gestion et un unique interlocuteur (le serveur). Préférentiellement, ce même serveur envoie ensuite au routeur concerné les paquets de données. Dans une deuxième forme préférée de téléchargement du logiciel impliquant un paquet d'activation, ce paquet d'activation provenant d'au moins un routeur de gestion amont, on envoie la requête de transfert au routeur de gestion immédiatement en amont du routeur de gestion courant. Cette technique est avantageuse par sa rapidité, car elle évite les temps de transfert entre le routeur de gestion courant et le serveur, ou un autre système de stockage du logiciel. Dans d'autres formes de téléchargement du logiciel impliquant un paquet d'activation, on envoie la requête à un système de stockage du logiciel qui diffère du serveur dont cette requête provient. Une telle mise en oeuvre peut s'avérer utile pour accéder à des bases de logiciels de gestion spécialisées. Dans ce cas, le paquet d'activation contient dans son entête l'adresse de ce système de stockage. Le paquet d'activation permet préférentiellement au routeur de gestion considéré de déterminer le ou les flux de paquets de données associés au logiciel téléchargé. Dans une première forme avantageuse d'identification de ces flux, le paquet d'activation ayant une couche dite IP (Internet Protocol) et des couches dites UDP (User Defined Protocol) ou TCP (Transmission Control Protocol), le routeur de gestion est capable d'accéder non seulement à la couche IP contenant des informations d'adresse serveur et d'adresse client, mais aussi à l'une des couches UDP ou TCP contenant des informations de port serveur et port client. Cette mise en oeuvre permet d'utiliser des paquets d'activation avec une couche IP traditionelle. Dans une seconde forme avantageuse d'identification des flux, le paquet d'activation a sa couche IP modifiée. Cette couche IP contient alors, préférentiellement dans un champ protocol ou option , une indication que ce paquet utilise un protocole particulier, permettant un téléchargement du logiciel de gestion. Cette indication est suivie de données spécifiques pour l'association. Cette mise en oeuvre évite de devoir adapter le routeur pour le rendre capable de lire la couche UDP ou TCP. Selon une mise en oeuvre avantageuse, les logiciels de gestion sont des processus ou threads, prévus pour être exécutés simultanément et indépendamment sur les routeurs de gestion. Par programme , on entend un ensemble d'instructions permettant d'assurer une fonction autonome, un programme pouvant être constitué de plusieurs logiciels . Dans la présente mise en oeuvre, chaque programme de gestion téléchargé dans un des routeurs de gestion est composé de plusieurs threads, ce qui permet d'accroître l'efficacité et les possibilités de la gestion de flux. Dans un premier mode d'utilisation des threads, ces derniers assurent la gestion en parallèle de différents flux, respectivement. Dans un second mode d'utilisation, ils assurent la gestion des mêmes flux, en remplissant des fonctions distinctes. Dans ce cas, le routeur de gestion est capable de permettre des communications entre les threads. Les deux modes d'utilisation sont avantageusement combinés dans un même routeur. Dans une autre mise en oeuvre, chaque programme de gestion téléchargé se compose d'un seul thread. Les logiciels de gestion ont pour fonction d'assurer la gestion du flux des paquets, préférentiellement à l'aide de mémoires tampon ou buffers de tailles plus ou moins grandes, de façon à pouvoir lisser les débits de transmission. Avantageusement, chacun des threads d'un programme se volt attribuer une mémoire tampon. Les logiciels de gestion sont avantageusement capables d'effectuer une ou plusieurs des opérations suivantes. - décider quets paquets sont mis en mémoire tampon ou même abandonnés, lorsque le routeur de gestion impose un débit de sortie réduit (congestion) ; - faire du transcodage (ré-encodage des données) ; - ajouter des protections (notamment des codes de correction d'erreur, appelés FEC pour Forward Error Correction) ; - renseigner sur l'état local du routage par des paquets envoyés vers le serveur d'origine et 1 ou le client de destination, rendant compte de la statistique locale du routage ; - identifier et interpréter des informations de fonctionnement contenues dans des paquets spéciaux en provenance du serveur, pouvant en particulier produire une modification dynamique du comportement des logiciels (changement de paramètres...) ou une interruption d'utilisation du programme en cours (fin de flux). Avantageusement, on détermine pour chacun des logiciels de gestion téléchargés dans chacun des routeurs de gestion, avant d'exécuter ce logiciel et au moyen de ce routeur : - une taille de mémoire tampon, - un débit maximal de sortie, - et/ou une priorité de ce logiciel dans ce routeur. Le routeur détermine avantageusement ces modalités de fonctionnement en fonction des propriétés de la connexion et de la bande passante disponible en sortie, mais indépendamment du logiciel téléchargé. Plus précisément, il tient avantageusement compte : - de la priorité négociée à la connexion par les couches dites QoS (Quality of Service) traditionnelles, telles que notamment celles connues sous les noms RSVP, IntServ, DiffServ et ToS (Type of Service), - et de l'état courant du routeur, pouvant inclure en particulier la bande passante et la capacité de traitement (CPU) disponibles. La taille de mémoire tampon peut aussi être contenue dans un descriptif du logiciel ; dans ce cas, cependant, elle peut être réajustée par le routeur lui-même. La taille de mémoire tampon peut être nulle, par exemple dans le cas où un programme est composé de plusieurs threads dans le routeur, pour un ou plusieurs de ces threads. Selon une forme avantageuse de mise en oeuvre, on modifie dynamiquement le comportement d'au moins un des logiciels de gestion téléchargés dans au moins un des routeurs de gestion. Pour ce faire : - on envoie à ce routeur au moins un paquet spécial contenant des informations de modification, dit paquet de modification, - on identifie ces informations dans ce paquet au moyen du logiciel téléchargé dans ce routeur, - et on effectue des modifications correspondant à ces informations au moyen de ce logiciel. Ces modifications sont préférentiellement choisies parmi : - un changement de paramètres de ce logiciel (par exemple la taille de la mémoire tampon), - et une commutation de ce logiciel d'un mode de fonctionnement courant à un autre mode de fonctionnement (par exemple d'un mode haute résolution à un mode basse résolution). Avantageusement, on emploie de façon similaire des paquets spéciaux contenant des informations de communication, dits paquets de communication, qui permettent de déclencher une négociation entre un serveur et le routeur pour changer les propriétés de ce dernier ou de transmettre au routeur des requêtes pour connaître son état (niveau de charge CPU, mémoire...). L'invention a aussi pour objet un routeur d'un réseau de communication. Selon l'invention, celui-ci comprend un système d'installation et d'exécution d'au moins un logiciel téléchargeable capable de gérer le routage d'au moins un flux d'un ensemble de paquets de données. Un tel routeur, qui permet de mettre en oeuvre) le procédé de gestion de l'invention, connaît un protocole de téléchargement de logiciel, par exemple de manière similaire à un navigateur de la toile équipé pour des programmes du type JAVA. Par rapport aux routeurs avec capacités de gestion résidentes, il nécessite des développements simples, tout en pouvant offrir des possibilités et une efficacité bien supérieures. Ce routeur est alors préférentiellement apte à constituer un des routeurs de gestion permettant de mettre en oeuvre un procédé de gestion de routage conforme à l'un des procédés avantageux définis plus haut. Dans tout ce qui suit, on distingue différents modules et 1 ou unités dans les routeurs ou les logiciels de gestion, qui ont une signification essentiellement fonctionnelle. Ainsi, ils ne doivent pas être interprétés dans un sens restrictif comme étant constitués d'entités matérielles physiquement disjointes, mais peuvent au contraire être intégrés dans des mêmes composants ou logiciels, leur dissociation physique étant seulement un cas particulier. De préférence, le routeur comprend des moyens de déclenchement du système d'installation et d'exécution, incluant : - un module de détection, apte à identifier dans au moins un en- tête de respectivement au moins un paquet de données reçu par le routeur, dit paquet d'activation, un indicateur d'exploitation d'un ou plusieurs des logiciels téléchargeables, capables de gérer le routage d'au moins un flux de paquets de données consécutif à la réception de ce paquet d'activation, - un module d'envoi de requête, apte à envoyer en amont de ce routeur une requête en transmission de ces logiciels de gestion téléchargeables, - et une unité de commande, destinée à déclencher le module d'envoi de requête pour une transmission d'un des logiciels de gestion de routage lorsque le module de détection détecte dans un des paquets d'activation que ce logiciel est destiné à être exploité et que ce logiciel est absent du routeur. Par ailleurs, le routeur est avantageusement capable de gérer un nombre important de threads ayant des propriétés différentes (priorité, mémoire allouée, bande passante permise..). L'invention a aussi pour objet une source d'au moins un logiciel de gestion de routage d'un ensemble de paquets de données dans un réseau de communications. Cette source comprend : - des moyens de stockage incluant le logiciel de gestion, - et des moyens de téléchargement de ce logiciel dans un routeur disposant d'un système d'installation et d'exécution de ce logiciel. La source est préférentiellement apte à une mise en oeuvre d'un procédé de gestion conforme à l'une quelconque des mises en oeuvre de l'invention. L'invention s'applique également à un dispositif de codage de paquets de données comprenant respectivement des en-têtes, prévus pour circuler dans un réseau de communications. Selon l'invention, ce dispositif comprend des moyens d'introduction dans les en-têtes des paquets, dits paquets d'activation, d'indicateurs d'exploitation d'au moins un logiciel téléchargeable de gestion de routage de flux de paquets, ces indicateurs étant destinés à être identifiés par un routeur comprenant un système d'installation et d'exécution de ce logiciel. Avantageusement, ce dispositif comprend des moyens d'introduction dans les en-têtes des paquets, dits paquets de modification, d'informations de modification du comportement du logiciel téléchargé. Avantageusement, il comprend aussi des moyens d'introduction dans les en-têtes des paquets, d'informations de communication entre un serveur et un routeur de gestion, et/ou de fin de gestion de flux avec un programme de gestion. L'invention concerne aussi un paquet de données numérisées comprenant un en-tête, obtenu au moyen du dispositif de codage de l'un des modes de réalisation de l'invention, en mettant en oeuvre les moyens d'introduction d'indicateurs d'exploitation, d'informations de modification, d'informations de communication et 1 ou d'informations de fin de gestion. L'invention est de plus relative à un produit logiciel et à un logiciel de gestion de routage de paquets de données. Ce logiciel est destiné à être utilisé dans un routeur d'un réseau de communications. Selon l'invention, il comprend des paramètres d'identification d'au moins une session et avantageusement d'au moins une connexion de cette session. Au contraire, les logiciels de gestion de flux résidents dans des routeurs connus ne sont pas associés à des sessions ou des connexions particulières. Ce logiciel est préférentiellement apte à une mise en oeuvre d'un procédé conforme à l'une quelconque des variantes de l'invention. L'invention sera mieux comprise et illustrée au moyen des exemples suivants de réalisation et de mise en oeuvre, nullement limitatifs, en référence aux figures annexées sur lesquelles : - la Figure 1 est une illustration schématique de la toile (réseau Internet), montrant des serveurs, des routeurs et des clients, dans laquelle est mise en oeuvre une forme préférée du procédé selon l'invention ; - la Figure 2 représente un mode de réalisation particulier d'un routeur de gestion selon l'invention dans la toile de la figure 1, ainsi que des opérations effectuées par ce routeur ; - la Figure 3 détaille des parties de l'unité centrale du routeur de la Figure 2 et leurs fonctions ; - la Figure 4 détaille des fonctionnalités d'un programme de gestion téléchargé dans le routeur de la Figure 2, permettant de modifier son comportement ; - la Figure 5A schématise une première étape (envoi d'un paquet d'activation) de mise en oeuvre d'une forme avantageuse du procédé de gestion conforme à l'invention, pour le téléchargement d'un logiciel de gestion d'un serveur vers un routeur de gestion ; - la Figure 5B schématise une deuxième étape (envoi d'une requête) de mise en oeuvre de la forme du procédé de gestion de la Figure 5A ; - la Figure 5C schématise une troisième étape (téléchargement d'un logiciel de gestion) de mise en oeuvre de la forme du procédé de gestion des Figures 5A et 5B ; - la Figure 5D schématise une quatrième étape (envoi de paquets de données) de mise en oeuvre de la forme du procédé de gestion des Figures 5A à 5C ; - la Figure 6A schématise une première étape (envoi du paquet d'activation de la figure 5A) de la forme du procédé de gestion des Figures 5A à 5d, pour le téléchargement d'un logiciel de gestion d'un premier routeur de gestion vers un second routeur de gestion ; - la Figure 6B schématise une deuxième étape (envoi d'une requête) de la forme du procédé de gestion de la Figure 6A ; - la Figure 6C schématise une troisième étape (envoi du logiciel de la Figure 5C) de la forme du procédé de gestion des Figures 6A et 6B. Dans les figures, on a représenté par convention et pour clarifier la présentation : - les paquets de données (y compris paquets d'activation et de modification) par des parallélogrammes ; - les requêtes par des losanges ; - et les logiciels par des rectangles aux coins arrondis. Le réseau Internet 1 (Figure 1) comprend un ensemble de routeurs R1-R12, qui permettent à des serveurs S143 de communiquer avec des clients C1-C3 en leur envoyant des informations (communication unidirectionnelle), et éventuellement en en recevant également (communication bi-directionnelle). Certains des routeurs de ce réseau 1, dits routeurs de gestion, sont munis d'un système d'installation et d'exécution de logiciels téléchargeables. Un tel routeur 2 (Figure 2) comprend une unité centrale 3 et des emplacements 11-15 prévus pour recevoir des threads téléchargés, en provenance de l'un des serveurs Si. Par emplacements , on entend non seulement des espaces mémoire disponibles dans le routeur 2, mais aussi la capacité du routeur 2 de faire tourner en parallèle des threads installés dans ces espaces mémoire et d'en gérer l'ensemble (en particulier par le contrôle des priorités et l'allocation de CPU et de mémoire dynamique). L'unité centrale 3 dispose en particulier d'une unité de gestion d'installation 10 des threads, chargée de la mise en place des processus au sein du routeur 2. Cette unité de gestion d'installation 10 est pourvue de trois modules 5, 6 et 7, respectivement d'affectation de priorité, de taille de mémoire tampon et de débit maximal de sortie, pour chacun des threads téléchargés dans le routeur 2. Dans l'exemple représenté sur la Figure 2, des threads 17,18 et 19 ont ainsi été installés respectivement dans les emplacements 11,12 et 13, et se sont vus affecter respectivement des priorités 25, 35 et 45 par le module 5, des mémoires tampons 26, 36 et 46 de tailles fixées par le module 6 et des débits maximaux de sortie 17,27 et 37 par le module 7. Ces threads 17,18 et 19 reçoivent respectivement en fonctionnement des paquets de données d'entrée 21,31 et 41 et transmettent des paquets de données de sortie 22,32 et 42, multiplexés pour former un flux 20. L'unité centrale 3 est équipée d'un module de détection 8, destiné à Identifier un indicateur d'exploitation d'un ou plusieurs threads dans un paquet de données 50 muni d'un tel indicateur dans son en-tête, dit paquet d'activation. Il comprend aussi un module d'envoi de requête 9, destiné à envoyer au serveur dont l'adresse est identifiée dans le paquet d'activation 50, ou au routeur de gestion immédiatement amont, une requête 51 en transmission de ce thread ou de ces threads. Une unité de commande 4 a un rôle central de commande et de contrôle vis-à-vis des modules 8 et 9 et de l'unité de gestion d'installation 10. En fonctionnement, un serveur Si envoie ainsi le paquet d'activation 50 dans le réseau 1 (Figure 5A) jusqu'à ce qu'il parvienne à un des routeurs de gestion 2, référencé RG1. Le module de détection 8 du routeur RG1 détecte alors l'information d'exploitation d'un ou plusieurs threads, ainsi que l'adresse du serveur Si et la spécification du flux ou des flux visés, par exemple par des renseignements portant sur la connexion ou la session visée. Il envoie ensuite par son module d'envoi 9 (Figure 5B) la requête 51 en transmission de ces threads, au serveur Si et le serveur Si transmet en retour (Figure 5C) le thread 52, qui peut être suivi ou accompagné d'autres processus complémentaires. Le thread 52 est reçu par l'unité de gestion d'installation 10 (Figure 3), qui lui affecte un des emplacements 14-15 disponibles. Si tous les emplacements sont pleins, c'est-à-dire si le routeur 2 n'est pas capable d'installer d'autres processus, le thread 52 est par exemple transmis directement aux routeurs Ri suivants, le routeur de gestion RG1 agissant alors comme un routeur ordinaire. Dans un autre exemple de mise en oeuvre, le routeur RG1 sélectionne les processus à conserver en fonction des priorités qui leur sont affectées. Le serveur Si envoie ensuite (Figure 5D) un flux 60 de paquets 53-56, qui transite par le routeur RG1. Celui-ci gère son routage vers un client Ck de destination, au moyen du thread 52. Dans un premier exemple de mise en oeuvre, tous les routeurs de gestion 2 sur le trajet vers le client Ck envoient leurs requêtes directement au serveur Si. Ainsi, les étapes décrites précédemment s'effectuent de manière similaire pour tous les routeurs de gestion 2. Dans un second exemple de mise en oeuvre, le routeur de gestion courant envoie sa requête au routeur de gestion immédiatement en amont, s'il existe, et sinon au serveur. Ainsi, les étapes décrites ci-dessus en référence aux Figures 5A à 5D ne valent que pour le premier routeur de gestion RG1 suivant le serveur Si. Un deuxième routeur de gestion RG2 immédiatement en aval du routeur RG1 reçoit le paquet d'activation 50 en provenance du routeur RG1 (Figure 6A), par le biais de routeurs Rj ayant une fonction de pure transmission. Le routeur RG2 émet alors une requête 62 en transmission de threads (Figure 6B), non adressée au serveur Si mais au routeur RG1. C'est ensuite le routeur RG1 qui transmet le logiciel 52 à télécharger (Figure 6C). Les logiciels de gestion 50 sont avantageusement pourvus de moyens de modification de leur comportement. Ainsi (Figure 4) le thread 17, par exemple, comprend-il un module de lecture 23, prévu pour identifier des renseignements dans l'en-tête d'un paquet spécial 58, dit paquet de modification. Ces renseignements incluent l'identification d'un indicateur de changement pour ce thread 17, c'est-à-dire en fait pour la connexion ou la session concernée, et des informations relatives à la nature des modifications (changement de paramètre, commutation d'un mode de fonctionnement à un autre...). Le contenu d'un thread (qui correspond par exemple à l'un des threads 17 à 19) est donné ci-dessous à titre d'illustration, dans une syntaxe similaire à celle employée pour le langage JAVA. t est adapté à la gestion de routage de flux vidéo compressés, en particulier par une méthode MPEG. Une procédure Receive est automatiquement Invoquée quand un paquet concerné par ce thread, nommé ThreadRouter est reçu ; elle est appelée Juste après le téléchargement du thread au routeur de gestion 2. Le thread dispose d'arguments spécifiques qui lui permettent d'identifier la signature des paquets qu'il doit router. Ces arguments comprennent une adresse source arc , une adresse destination test et un champ de couche IP ipflag . La procédure consiste à ne garder que les paquets de type 1 dans le cas où un état de congestion est proche, et à abandonner alors les paquets des types P et B. En pratique, tous les paquets mis dans une mémoire tampon de sortie appelée OuputBuffer sont routés vers un routeur en aval. Le thread est exprimé ainsi (les commentaires sont précédés du signe // et les termes Class , Abstract , Int , Public , Private et Void désignent des types de données connus dans le langage JAVA ; Packet et Address sont des classes définies dans des librairies additionnelles connues dans le langage JAVA ou définies par ailleurs ; et lpflag est un objet défini dans une librairie additionnelle) : Class ThreadGeneric { // Classes virtuelles qui doivent être définies par toute classe héritant de "ThreadGeneric". Abstract Receive (Packet) ; Il Appelé à chaque réception de paquet. } Class ThreadRouter extends ThreadGeneric { &num;define SIZEJMAX 500 Packet OutputBuffertStZEMAX] ; Int nbOutputBuffer ; II Constructeur, c'est-à-dire la méthode de ThreadRouter Public ThreadRouter (Address src, Address dest, Ipflag ipflag) { Il Définit la signature des paquets concernés par ce thread. src =123. 198. 21. 128 ; dest= 123.198. 25.108 ; Ipflag = 2 ; nbOutputBuffer = 0 ; } Public Void Receive (Packet packet) { // SI saturation proche, ne garder que les paquets de type "1". If (nbOutputBuffer > 0.8* SIZE~MAX){// saturation proche If (Type (packet) ! = TYPE~I) Delete (packet) ; } else OutputBuffer [nbOutputBuffer++] = packet ; } Private Int Type (Packet packet) { &num;define itype 23 // cas où le type du vidéo packet se trouve être le 23ième byte. return (packet. data [itype]) ; } } REVENDICATIONS 1. Procédé de gestion de routage de paquets de données (21-22, 31-32, 41-42, 53-56) dans un réseau de communication (1) comprenant des routeurs (Rj), selon lequel on gère au moins un flux (60) de paquets (53-56) de données au moyen d'au moins un desdits routeurs (Rj), caractérisé en ce qu'on télécharge dans au moins un desdits routeurs (2, RG1-RG2), dit routeur de gestion, au moins un logiciel de gestion de routage (17-19,52) à partir d'au moins une source (Si, RG1) de logiciels téléchargeables et en ce qu'on gère au moyen dudit logiciel de gestion (17-19, 52) le routage d'au moins un flux (60) de paquets (53-56) de données associé audit logiciel de gestion (17-19,52), transitant par ledit routeur de gestion (2, RG1-RG2). 2. Procédé de gestion de routage selon la revendication 1, caractérisé en ce que : - on détecte au moyen d'au moins un desdits routeurs de gestion (2, RG1-RG2), dit routeur de gestion courant, dans un paquet (50) transitant par ledit routeur (2, RG1-RG2), dit paquet d'activation, l'existence d'un logiciel téléchargeable (52) destiné à gérer le routage d'au moins un flux (60) de paquets (53-56) de données, - on envoie en amont dudit routeur (2, RG1-RG2) au moyen dudit routeur (2, RG1-RG2) une requête de téléchargement (51, 61) dudit logiciel (52), - et on télécharge ledit logiciel (52) dans ledit routeur (2, RG1-RG2). 3. Procédé de gestion de routage selon la revendication 2, caractérisé en ce que ledit paquet d'activation (50) étant émis par un serveur (Si), on envoie ladite requête (51) audit serveur (Si). 4. Procédé de gestion de routage selon la revendication 2, caractérisé en ce que ledit paquet d'activation (50) provenant d'au moins un routeur de gestion (2) amont, on envoie ladite requête (61) audit routeur de gestion (RG1) immédiatement en amont dudit routeur de gestion courant (RG2). 5. Procédé de gestion de routage selon l'une quelconque des revendications précédentes, caractérisé en ce que lesdits logiciels de gestion (17-19) sont des processus ou threads, prévus pour être exécutés simultanément et indépendamment sur lesdits routeurs de gestion (2). 6. Procédé de gestion de routage selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on détermine pour chacun desdits logiciels de gestion (17-19) téléchargés dans chacun desdits routeurs de gestion (2), avant d'exécuter ledit logiciel et au moyen dudit routeur : - une taille de mémoire tampon (26, 36, 46), - un débit maximal de sortie (27,37, 47), - et/ou une priorité (25, 35,45) dudit logiciel (17-19) dans ledit routeur (2). 7. Procédé de gestion de routage selon l'une quelconque des revendications précédentes, caractérisé en ce qu'on modifie dynamiquement le comportement d'au moins un des logiciels de gestion téléchargés (17) dans au moins un des routeurs de gestion (2), en envoyant audit routeur (2) au moins un paquet spécial (58) contenant des informations de modification, dit paquet de modification, en identifiant lesdites informations dans ledit paquet au moyen dudit logiciel téléchargé dans ledit routeur (2) et en effectuant des modifications correspondant aux dites informations au moyen dudit logiciel (17). 8. Procédé de gestion de routage selon la revendication 7, caractérisé en ce que lesdites modifications sont choisies parmi : - un changement de paramètres dudit logiciel (17), - et une commutation dudit logiciel (17) d'un mode de fonctionnement courant à un autre mode de fonctionnement. 9. Routeur (2, RG1-RG2) d'un réseau de communication (1), caractérisé en ce qu'il comprend un système d'installation et d'exécution (3) d'au moins un logiciel téléchargeable (17-19,52) capable de gérer le routage d'au moins un flux (60) d'un ensemble de paquets (53-56) de données, ledit routeur (2, RG1-RG2) étant préférentiellement apte à constituer un des routeurs de gestion permettant de mettre en oeuvre un procédé de gestion de routage conforme à l'une quelconque des revendications 1 à 8. 10. Routeur (2, RG1-RG2) selon la revendication 9, caractérisé en ce qu'il comprend des moyens de déclenchement du système d'installation et d'exécution (3), incluant : - un module de détection (8), apte à identifier dans au moins un en- tête de respectivement au moins un paquet de données (50) reçu par ledit routeur (2, RG1-RG2), dit paquet d'activation, un indicateur d'exploitation d'au moins un desdits logiciels téléchargeables (17-19,52) capable de gérer le routage d'au moins un flux (60) de paquets (53-56) de données consécutif à la réception dudit paquet d'activation (50), - un module d'envoi de requête (9), apte à envoyer en amont dudit routeur (2, RG1-RG2) une requête (51, 61) en transmission dudit logiciel de gestion (17-19,52) téléchargeable, - et une unité de commande (4), destinée à déclencher le module d'envoi de requête (9) pour une transmission d'un desdits logiciels de gestion de routage (17-19, 52) lorsque le module de détection (8) détecte dans un desdits paquets d'activation (50) que ledit logiciel est destiné à être exploité et que ledit logiciel est absent du routeur (2, RG1-RG2) 11. Source (Si) d'au moins un logiciel de gestion de routage (17- 19,52) d'un ensemble de paquets de données (21-22,31-32, 41-42, 53-56) dans un réseau de communications (1), comprenant : - des moyens de stockage incluant ledit logiciel de gestion (17-19, 52), - et des moyens de téléchargement dudit logiciel (17-19, 52) dans un routeur (2, RG1-RG2) disposant d'un système d'installation et d'exécution dudit logiciel (17-19,52), ladite source étant préférentiellement apte à une mise en oeuvre d'un procédé de gestion conforme à l'une quelconque des revendications 1 à 8. 12. Dispositif de codage (Si) de paquets de données (50,58) comprenant respectivement des en-têtes, prévus pour circuler dans un réseau de communications (1), caractérisé en ce que ledit dispositif (Si) comprend des moyens d'introduction dans les en-têtes desdits paquets (50), dits paquets d'activation, d'indicateurs d'exploitation d'au moins un logiciel téléchargeable (17-19,52) de gestion de routage de flux (60) de paquets (53-56), lesdits indicateurs étant destinés à être identifiés par un routeur (2, RG1-RG2) comprenant un système d'installation et d'exécution (3) dudit logiciel (17-19, 52). 13. Dispositif de codage (Si) selon la revendication 12, caractérisé en ce que qu'il comprend des moyens d'introduction dans les en-têtes desdits paquets (58), dits paquets de modification, d'informations de modification du comportement dudit logiciel (17-19,52) téléchargé. 14. Paquet de données numérisées (50, 58) comprenant un entête, obtenu au moyen du dispositif de codage (Si) de l'une des revendications 12 ou 13 en mettant en oeuvre lesdits moyens d'introduction d'indicateurs d'exploitation et/ou lesdits moyens d'introduction d'informations de modification. 15. Produit logiciel de gestion de routage (17-19,52) de paquets de données (21-22, 31-32, 41-42, 53-56), destiné à être utilisé dans un routeur (2, RG1-RG2) d'un réseau de communications (1), caractérisé en ce qu'il comprend des paramètres d'identification d'au moins une session et avantageusement d'au moins une connexion de ladite session, ledit logiciel (17-19,52) étant préférentiellement apte à une mise en oeuvre d'un procédé conforme à l'une quelconque des revendications 1 à 8.