FR 2780839 A1 20000107 FR 9808629 A 19980706 10.La présente invention concerne un procédé et un dispositif de communication d'information. Elle s'applique, en particulier, à un réseau à commutation asynchrone de paquets, permettant notamment d'interconnecter un petit nombre d'équipements multimédia, tout en leur fournissant différentes qualités de service pour échanger des données. Le comportement d'un trafic de données généré par un équipement multimédia (ou application) peut s'inscrire dans deux classes de service principales, elles mêmes divisées, chacune, en deux sous-classes. Ainsi le trafic peut être soit élastique (il s'adapte facilement aux changements de conditions de transmission), soit temps réel. S'il est élastique, il peut soit être de nature interactive, et donc sensible au délai de transfert, soit correspondre à un transfert massif d'un gros volume de données et donc sensible à la bande passante. S'il s'agit d'un trafic temps réel, soit il est acceptable de perdre certains paquets d'information pour privilégier le délai de transmission, le trafic est alors appelé "déterministe", soit il est préférable de disposer d'un débit moyen mais sans perte de données, le trafic est alors appelé "garanti". Le trafic élastique correspond au trafic de type datagramme. Ce trafic est dit élastique car il est capable de s'adapter aux conditions de transmission sans pour autant perdre de son utilité. Un transfert de fichier pourra aussi bien s'exécuter via un chemin supportant un débit de 64 kilobit par seconde que via un chemin supportant un débit de 2 Mégabit par seconde. Pour le trafic élastique, une première classe de base concerne le trafic généré par les applications interactives ou transactionnelles (comme une application de type client-serveur), et une seconde classe identifie les données véhiculées par bloc (comme le transfert de fichiers). Les équipements générateurs d'un trafic temps réel requierent un service déterministe ou garanti. Pour le trafic déterministe, qui privilégie le respect d'une contrainte élevée en ce qui concerne le délai de transmission, I'application qualifie la bande passante dont elle suppose avoir besoin, ainsi que le délai maximal de transmission qu'elle peut accepter. Le réseau privilégie ce type de trafic mais se débarrasse des données pour lesquelles le délai ne peut être respecté. Il s'agit par exemple de transmission vidéo (en cas de problèmes de transmission, une image statique apparaît), ou de systèmes audio de qualité moyenne. Le service dit garanti se différencie du service déterministe par le fait que le réseau ne se débarrasse pas volontairement des données issues d'un trafic garanti mais que celui ci peut être affecté d'un délai de transmission variable en fonction du trafic déterministe plus prioritaire ou au trafic garanti concurrent. Il s'agit, par exemple, du trafic vidéo haute définition (utilisant des techniques de compression). Dans ce cas, le réseau réserve la bande passante à l'application qui requiert un service garanti, mais pour gérer les problèmes de gigue (en anglais "jitter") sur les données à la réception, I'application doit posséder des capacités de stockage temporaires des données (de l'ordre de la seconde de trafic), afin de rétablir le comportement original du trafic. La garantie de la qualité de service exigée par des applications concurrentes et de natures différentes passe par la résolution de problèmes tels que la gestion des ressources et le contrôle de trafic. Les procédés à mettre en oeuvre doivent permettre au réseau de fonctionner de façon optimale tout en fournissant une qualité de service acceptable aux différentes applications. Ce problème a fait l'objet de nombreuses études pour les réseaux à commutation de circuits et pour les réseaux à commutation de paquets. Dans les réseaux à commutations de circuits, la solution connue consiste à allouer à chaque connexion une bande passante constante (canal) pendant toute sa durée. Au préalable, une procédure d'acceptation d'appel permet au réseau de savoir s'il peut supporter l'appel. Dans le cas o aucun canal n'est disponible, I'appel est rejeté. Dans les réseaux à commutation de paquets o le trafic est, par définition, imprévisible, la nature variable des débits offre l'opportunité d'un partage statistique des ressources du réseau. Cette optimisation des ressources augmente, malheureusement, les risques de congestion. Ces réseaux peuvent être vus comme une succession de files d'attente à capacité limitée dont il convient de contrôler le remplissage afin d'éviter leur saturation, synonyme de perte de paquets. Il est connu de contrôler le trafic par un mécanisme dit "de fenêtrage": lorsqu'un état de saturation est détecté, le récepteur demande explicitement à la source de réduire son flux. On parle alors de régulation et de contrôle de flux. Aucune de ces approches n'est suffisante, la première parce qu'elle conduit à un gaspillage inévitable des ressources du réseau en allouant à la source une bande passante correspondant à son débit maximal et la seconde parce que le rapport du temps de propagation sur le temps de transmission augmente de manière considérable lorsque les liaisons sont à très haut débit. Dans les systèmes de contrôle de flux par rétroaction, entre l'instant d'émission de la notification de congestion et l'instant de sa réception par le noeud source, le trafic déjà en transit dans le réseau peut être considéré comme définitivement perdu en raison de la congestion, à moins de disposer de mémoires de grande capacité pour conserver tous les paquets en transit pendant l'état de congestion. Par conséquent, pour la commutation rapide de paquets, les méthodes de contrôle purement réactives sont insuffisantes dans un environnement haut débit. La commutation nécessite des mécanismes élaborés dans les équipements de commutation (noeuds intermédiaires du réseau) incluant des méthodes préventives et des méthodes réactives. La technologie ATM ("Asynchronous Transfert Mode" ou mode de transfert asynchrone), propose des techniques de gestion de la qualité de service, et de contrôle de congestion basées sur des mécanismes élaborés implémentés au sein des équipements de commutation. Des exemples de tels mécanismes sont décrits dans les brevets US ,291,481 et US 5,313,454 qui illustrent aussi la complexité et le coût potentiel d'implémentation de telles méthodes. Ces méthodes ne sont donc pas adaptées à des réseaux comprenant un nombre plus restreint d'équipements à interconnecter o le coût des moyens de communication ne doit pas être trop élevé par rapport au coût des équipements à interconnecter. Des tentatives d'utilisation de commutateurs ATM embarqués ont été faites, telles que celle décrite dans la thèse "Architecture distribuée temps réel fondée sur ATM" de Jean-François Guilaud (INPG). Cette thèse mentionne l'utilisation de la signalisation ATM classique afin de permettre la gestion des connexions, ce qui représente une implémentation complexe. Cependant, la mise en oeuvre complète des mécanismes de gestion des connexions doit prévoir d'éviter la congestion, qui, afin de simplifier l'utilisation du commutateur, reposent sur une gestion locale des informations de charge et sur l'utilisation des files d'attente en sortie pour chaque commutateur. Le contrôle de flux strict, à la source, tel qu'il est décrit dans la thèse, prévoit l'utilisation d'un mode connecté uniquement, et vérifie le non dépassement du transfert de données par rapport à ce qui a été prévu lors de l'établissement de la connexion correspondante. Cela peut donc engendrer une mauvaise utilisation des ressources réseau ainsi qu'un manque de flexibilité du système. Par ailleurs, il n'est envisagé aucun moyen simple pour réagir au problème de congestion si ce n'est en se reposant sur les solutions décrites précédemment, propre a l'utilisation de l'ATM, mais qui demeurent des solutions complexes. De plus, I'utilisation d'une dimension de paquet fixe, conformément à l'ATM, engendre une perte fixe du débit utile par lien du réseau disponible. En revanche, une taille de paquet variable en fonction de la charge du réseau permet d'optimiser le débit utile. Les techniques de contrôle de la taille des paquets ont déjà été testées sur des architectures réseau de type bus ou anneau. La commutation asynchrone de paquets, telle que décrite dans la norme IEEE-P1355, est basée sur une technologie de commutation (matrice de commutation non bloquante permettant plusieurs chemins simultanés) à faible coût de réalisation en ce qui concerne le commutateur. En effet, le commutateur en question n'utilise qu'un minimum de ressources pour effectuer la commutation d'un paquet à partir d'un port d'entrée vers un port de sortie. Le transfert d'un paquet au travers du commutateur a lieu dès que le commutateur a connaissance des informations de commutation du dit paquet (en-tête de paquet) sans attendre la complète réception de toutes les données du paquet. Il n'y a donc aucune gestion de file d'attente ou de priorité dans les noeuds intermédiaires du chemin. Par ailleurs, afin de régler les problèmes de contention d'accès à un port d'entrée (respectivement vers un port de sortie) du commutateur, lorsque plusieurs paquets sont à priori destinés à transiter via ce port d'entrée (respectivement de sortie), un mécanisme de contrôle de flux au niveau du lien est implémenté, n'autorisant une source à transmettre des données sur la ligne de transmission que lorsqu'elle a obtenu l'autorisation de la part de la destination, c'est-à-dire lorsqu'un groupe de données précédemment émises par la source ont été acquittées par la destination. Cependant, la commutation asynchrone de paquets, telle que connue dans l'état de la technique, si elle laisse envisager des coûts d'implémentation attractifs, ne prévoit pas de garantir différentes qualités de service pour les trafics concurrents au sein d'un même réseau. Les technologies de type bus série proposent une alternative à l'utilisation de la commutation de paquets pour interconnecter des périphériques à moindre coût. En effet, les mécanismes mis en oeuvre pour partager les ressources se trouvent simplifiés du fait de l'unicité de la ressources principales, en l'occurrence le médium de communication. Cette simplicité implique aussi I'inconvénient d'une bande passante limitée: la bande passante moyenne disponible par terminal diminue en fonction du nombre de terminaux connectés. Certaines technologie bus série, telles que celle normalisée par l'IEEE, référence P1394, définie pour l'interconnexion d'équipements multimédia, supportent le transfert des données selon principalement deux classes de service en mettant en oeuvre une architecture logique de type bus. Des mécanismes sont donc nécessaires pour arbitrer l'accès au bus et organiser le transfert des données. Cette technologie de bus série prévoit un mécanisme de réservation de ressources. Il permet, d'une part, la transmission de données dite isochrone, comprenant une phase de réservation, et, d'autre part, la transmission de données dite asynchrone, sans phase de réservation. Le document US-A-5,615,254 décrit une méthode pour construire des tables de routage comprenant, pour chaque paire de noeuds, un chemin direct et plusieurs chemins de secours, ainsi que pour mettre à jour périodiquement ces tables en fonction d'information de charges. Il n'effectue cependant pas de choix à priori d'un chemin sur la base d'information effective sur la charge, ce qui permet d'améliorer le rendement du processus de contrôle d'admission des connexions. Le document US-A-5,649,108 décrit l'inconvénient d'utiliser un routage à la source sans connaissance à priori sur la charge du réseau et propose donc le re-routage par certains noeuds qui, eux, ont une connaissance de cette charge. Cependant le routage à la source reste plus efficace lorsque la source elle-même a une connaissance sur la charge effective. L'invention vise à permettre, sur un réseau à commutation de paquets, d'une part, d'effectuer un contrôle d'admission des connexions, selon un chemin défini à la source, sur la base d'information représentatives de la charge du réseau associée à toutes les connexions actives, et d'autre part, de mettre à jour les tables de charges indépendamment de la connaissance de chaque noeud (calcul de paramètres de transmission en fonction du service requis, effectué par chaque noeud). L'invention propose d'améliorer cet art antérieur pour un réseau à gestion de chemin à la source. A cet effet, la présente invention propose, en particulier, de mettre en oeuvre: - des moyens de signalisation qui permettent des échanges pendant la phase d'établissement (par des messages de format spécifique qui permettent, d'une part, à chaque noeud d'indiquer les besoins de ses applications, besoins qui forment des paramètres fixes, et, d'autre part, à chaque noeud voisin d'être informé des besoins des applications, par des messages de format spécifiques), - des moyens de sélection de chemin (constitués d'une table de charge), dans chaque noeud source, qui lui permettent de déterminer le chemin à faire suivre à chaque message qu'il a à transmettre, et - les moyens de surveillance de charge (chaque noeud étant capable de conserver l'information de charge globale sur le réseau, en fonction des paramètres de trafic, grâce à la structure de la table de charge). Ainsi, lorsqu'un chemin est disponible, il est alloué à la connexion et les conflits sont évités, même si les tables de charge ne sont pas cohérentes, grâce aux noeuds intermédiaires. Ainsi, la présente invention vise, selon un premier aspect, un procédé de communication sur un réseau, caractérisé en ce qu'il comporte, pour l'établissement d'une connexion: A/ effectuées par un dispositif de communication source d'information à transmettre en mode connecté: - une opération de détermination de besoin de bande passante pour la transmission de ladite information en mode connecté, - une opération de détermination d'un éventuel chemin disponible pour ladite transmission, en fonction d'informations conservées dans une table de charge de chaque lien du réseau, et - lorsqu'un chemin disponible est déterminé: À une opération de transmission d'une information représentative dudit besoin de bande passante à destination du dispositif de communication suivant sur ledit chemin, et une opération de mise à jour de ladite table de charge des liens du réseau, - une opération de diffusion à destination d'au moins tous les dispositifs de communication en dehors du chemin, d'une information représentative dudit besoin de bande passante, B/ effectuées par chaque dispositif de communication intermédiaire sur ledit chemin: une opération de détermination de disponibilité dudit chemin, pour ladite communication, en fonction d'informations conservées dans une table de charge de chaque lien du réseau, et - lorsque le chemin est disponible: a une opération de transmission d'une information représentative dudit besoin de bande passante, au dispositif de communication suivant sur le chemin, et À une opération de mise à jour de la table de charge des liens du réseau, C/ effectuée par chaque dispositif de communication en dehors dudit chemin: - une opération de mise à jour d'une table de charge des liens du réseau. Grâce à ces dispositions, chaque dispositif de communication du réseau conserve une table de charge contenant des informations représentatives de toutes les connexions déjà établies. Il peut donc gérer les transmissions qu'il a à effectuer, que ce soit, en mode connecté ou en mode non connecté. Ainsi, la mise à jour des tables de charge des dispositifs de communications est simultanée à l'établissement de la connexion. Ceci entraîne un meilleur contrôle de l'admission des connexions. Le choix d'un chemin a donc moins de chance d'être erroné. Selon des caractéristiques particulières, au cours de l'opération de transmission dudit besoin de bande passante à destination du dispositif de communication suivant sur ledit chemin, le dispositif de communication source transmet une information représentative d'un service requis pour ladite transmission en mode connecté. Selon d'autres caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, effectuée par chaque dispositif de communication du réseau, une opération de détermination de paramètres de communication dépendant du service requis, et l'opération de mise à jour des tables est effectuée en prenant en compte lesdits paramètres. Grâce à chacune de ces dispositions, chaque connexion est caractérisée de la même façon, par le service requis, pour tous les dispositifs de communication du réseau, quelles que soient les contraintes propres à chacun de ces dispositifs de communication. En revanche les paramètres pourront varier, dispositif de communication par dispositif de communication, en fonction de ces contraintes propres et des informations à transmettre. Selon d'autres caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, à la fin de la transmission en mode connecté: - effectuée par un dispositif de communication source d'information transmise en mode connecté, une opération de diffusion d'une information représentative du relâchement de la connexion, à destination de tous les dispositifs de communication du réseau, et - effectuée par chaque dispositif de communication dudit réseau, une opération de mise à jour d'une table de charge des liens du réseau. Grâce à ces dispositions, chaque dispositif de communication du réseau conserve une table de charge contenant des informations représentant uniquement les connexions valides, et non les connexions qui ont été relâchées, afin d'améliorer le temps de traitement des mises à jour des tables de charge. Selon d'autres caractéristiques particulières, au cours de l'établissement d'une connexion, I'opération de diffusion à destination d'au moins tous les dispositifs de communication en dehors du chemin, d'une information représentative dudit besoin de bande passante, est effectuée après que chaque dispositif de communication dudit chemin ait effectué: - une opération de détermination de disponibilité dudit chemin, pour ladite communication, en fonction d'informations conservées dans une table de charge de chaque lien du réseau, et - lorsque le chemin est disponible: * une opération de transmission dudit besoin de bande passante, au dispositif de communication suivant sur le chemin, et * une opération de mise à jour d'une table de charge des liens du réseau. Grâce à ces dispositions, les dispositifs de communication du réseau qui ne se trouvent pas sur ledit chemin n'ont à effectuer de mise à jour de leur table de charge que si chaque dispositif de communication du chemin a déterminé que ce chemin est disponible pour la transmission envisagée. En outre, pour tous les dispositifs de communication du réseau, les tables de charges permettent d'éviter les conflits d'établissement de connexion. Selon d'autres caractéristiques particulières, le procédé tel que succinctement exposé ci-dessus comporte, au cours de l'établissement d'une connexion, effectuée par le dispositif de communication source, une opération de détermination de l'intégralité du chemin destiné à être suivi par l'information à transmettre en mode connecté. Selon ces dispositions, le choix du chemin par le dispositif de communication source de l'information à transmettre permet d'améliorer le temps d'établissement d'une connexion. Selon un deuxième aspect, la présente invention vise un dispositif de communication sur un réseau, caractérisé en ce que: - il comporte une mémoire adaptée à conserver une table de charge contenant des informations relatives à la charge de chaque lien du réseau, et - il est adapté, pour l'établissement d'une connexion destinée à la transmission d'information en mode connecté: à déterminer un besoin de bande passante pour la transmission de ladite information en mode connecté, 5. à déterminer un éventuel chemin disponible pour ladite transmission, en fonction d'informations conservées dans ladite table de charge, et lorsqu'un chemin disponible est déterminé, * à transmettre une information représentative dudit besoin de bande passante, à destination du dispositif de communication suivant sur ledit chemin, ò à mettre à jour ladite table de charge, à diffuser, à destination d'au moins tous les dispositifs de communication en dehors du chemin, une information représentative dudit besoin de bande passante. L'invention vise aussi un ordinateur, une caméra, un télécopieur, un appareil photographique, un téléviseur, une imprimante, un scanner et un lecteur audio/vidéo, caractérisés en ce qu'ils comportent un dispositif tel que succinctement exposé ci-dessus. L'invention vise aussi: - un moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique caractérisé en ce qu'il permet la mise en oeuvre du procédé de l'invention telle que succinctement exposée ci-dessus, et - un moyen de stockage d'informations amovible, partiellement ou totalement, et lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique caractérisé en ce qu'il permet la mise en oeuvre du procédé de l'invention telle que succinctement exposée cidessus. Les caractéristiques préférentielles ou particulières, et les avantages de ce dispositif, de cet ordinateur, de cette caméra, de ce télécopieur, de cet appareil photographique, de ce téléviseur, de cette imprimante, de ce scanner, de ce lecteur audio/vidéo et de ces moyens de stockage d'information étant identiques à ceux du procédé tel que succinctement exposé ci-dessus, ces avantages ne sont pas rappelés ici. D'autres avantages et caractéristiques de l'invention ressortiront de la description qui va suivre, faite en regard des dessins annexés dans lesquels: - la figure 1 représente un réseau de noeuds interconnectés, la figure 2 représente un dispositif (ou "moyen") de communication selon la présente invention, - la figure 3 représente des échanges de messages intervenant entre un noeud source et un noeud destinataire pour véhiculer d'une part un trafic connecté et, d'autre part, un trafic non connecté, la figure 4 représente un organigramme mis en oeuvre par le moyen de communication du noeud dit "source" pour une transmission en mode connecté, - la figure 5 représente un organigramme mis en oeuvre par un moyen de communication d'un noeud dit "intermédiaire" pour une transmission en mode connecté, - la figure 6 représente un organigramme mis en oeuvre par un moyen de communication d'un noeud dit "destinataire" pour une transmission en mode connecté, - la figure 7 représente un organigramme mis en oeuvre par un moyen de communication d'un noeud dit "voisin" pour une transmission en mode connecté, - la figure 8 représente un réseau sur lequel circulent des messages de contrôle destinés à la gestion du mode connecté, - la figure 9 représente la structure de messages de contrôle destinés à la gestion du mode connecté, - la figure 10 représente la structure de données d'une table de charge en mémoire d'un moyen de communication, - la figure 11 représente la structure de données d'une table de spécifications et de priorités contenant des canaux virtuels réservés à la transmission en mode connecté, en mémoire d'un moyen de communication, - la figure 12 représente un organigramme d'émission en modes connecté et non connecté d'un moyen de communication tel qu'illustré en figure 2, - la figure 13 représente un organigramme de détermination, par le noeud source, de disponibilité de chemin pour l'établissement d'une connexion, incorporé dans l'organigramme de la figure 4, - la figure 14 représente un organigramme de détermination, par un noeud intermédiaire ou le noeud destinataire, de disponibilité de chemin pour l'établissement d'une connexion, incorporé dans l'organigramme de la figure 5 ou 6, et - la figure 15 représente un organigramme de détermination, par un noeud voisin, de disponibilité de chemin pour l'établissement d'une connexion, incorporé dans l'organigramme de la figure 7. Dans toute la présente demande les termes "dispositifs de communication " et "moyen de communication" ont la même signification et désignent les mêmes combinaisons de moyens objets de la présente invention. Le mode préféré de réalisation gère trois classes de service spécifiques, déterministe (en mode connecté), garantie (en mode connecté) et élastique (en mode non connecté), sur un réseau à commutation de paquet. En figure 1, on observe cinq équipements multimédias 101 à 105 d'un réseau à commutation de paquet 100, reliés entre eux par six liens 106 à 111. Chaque équipement multimédia comporte un moyen de communication 112 et un moyen de traitement de données 113. Le moyen de communication 112 permet au moyen de traitement 113 d'ouvrir une connexion dédiée à un trafic connecté (trafic temps réel déterministe ou garanti) puis de générer ce trafic, ou bien de générer directement un trafic non connecté (trafic élastique). Lorsque l'équipement multimédia 101 envoie un paquet de données à l'équipement multimédia 105, par l'intermédiaire des liens 108 et , l'équipement 101 est un noeud "source", l'équipement 105 est un noeud "destinataire", l'équipement 102, par lequel transitent les données, est un noeud "intermédiaire", tandis que les noeuds 103 et 104 sont des noeuds "voisins", aucune des données transmises ne transitant par l'un d'entre eux. Le mode de réalisation décrit et représenté concerne un réseau local composé de plusieurs noeuds interconnectés par des liens bidirectionnels rapides. Chaque noeud incorpore un commutateur non bloquant possédant une matrice de commutation à réception et émission simultanées (en anglais "cut- through crossbar") et possède un certain nombre de ports externes auxquels peuvent être raccordés des liens. Dans un tel réseau, la route ou le chemin suivi par un paquet est une succession de liens, chacun des liens étant défini par les deux noeuds qu'il rejoint. La communication sur un tel réseau est dite "commutée". Un exemple d'un tel réseau est donné par un système utilisant des composants selon la norme IEEE 1355. En figure 2, on observe un schéma bloc d'un moyen de communication 112 du réseau, comportant un composant commutateur/routeur 209 couplé à une unité centrale 206 (décomposée en deux entités 206A et 206 B). Le composant commutateur/routeur 209, constitué d'un composant de la marque SGS-THOMSON (marque déposée), référencé ST C104, comporte des ports physiques reliés à un connecteur 230, et deux ports internes dont l'un est dédié au contrôle, reliés à l'unité centrale 206 par l'intermédiaire de différents composants décrits ci-dessous. On observe ici que le composant commutateur/routeur susmentionné 209 ST C104 possède, en fait, trente-deux ports physiques en plus de deux ports de contrôle, seulement un port de contrôle et quelques ports physiques étant représentés en figure 2. Des composants d'interface 213 et 216 sontreliés aux deux ports internes du composant commutateur/routeur 209 et sont, chacun, basés sur un composant référencé ST C1 01 et fabriqué sous la marque SGS-THOMSON. Le composant commutateur/routeur 209 et les composants d'interface 213 et 216 effectuent un codage conforme à la norme IEEE 1355. Le composant commutateur/routeur 209 est à architecture de type non bloquante. Des émetteur/récepteurs, non représentés, plus connus sous leur dénomination technique de langue anglaise "transceiver", convertissent des signaux TTL, sur les ports physiques du composant commutateur/routeur 209 en signaux différentiels sur le connecteur 230. Les émetteurs/récepteurs sont, par exemple, des composants de la marque AT&T (marque déposée) référencés 1141 MK. Le connecteur 230 est destiné à être relié à plusieurs connecteurs identiques incorporés à d'autres moyens de communication du réseau. Ils sont de la marque déposée HARTING et de référence 2721-121-8000. Les composants d'interface 213 et 216 sont reliés, par une liaison parallèle, à une interface PCI 208, elle-même reliée à un bus PCI 231. L'interface 208 est, par exemple, composée d'un circuit AMCC (marque déposée) S5933. Le bus PCI 231 est, en outre, relié: - à un composant d'interface 232, identique au composant 208, lui- même relié au moyen de traitement 113 (figure 1); - à une interface de contrôle 203, par exemple constituée d'un composant 82439 HX de marque INTEL , lui même relié à un bus local d'unité centrale 206, comportant un microprocesseur 206A et une mémoire cache statique 206B, et à une mémoire dynamique 204 (constituée des deux entités 204A et 204 B); et - à un composant d'interface 205, par exemple de référence 823715B de marque INTEL , ce composant étant relié à un bus ISA qui relie un contrôleur ISA de périphériques 233, à une mémoire flash de système d'exploitation BIOS 234, à une horloge temps-réel 235 et à une extension de mémoire flash 236. L'architecture et les composants du moyen de communication 112 sont bien connus de l'homme du métier des systèmes informatiques et ils ne sont pas plus détaillés ici. Pour une meilleure compréhension de la constitution du mode de réalisation décrit et représenté, le lecteur est invité à consulter les notes d'utilisation des composants, notes fournies par leurs constructeurs respectifs. L'unité centrale de traitement CPU 206 est composée d'un microcontrôleur 206A de la marque déposée INTEL et de référence PENTIUM (marque déposée) avec 32 Mo de mémoire vive dynamique DRAM 204 à titre de mémoire de travail, 256 Ko de mémoire statique cache 206B. On observe ici que l'expression "segment de mémoire" utilisée ci- dessous désigne, dans chacune des mémoires, aussi bien une zone mémoire de faible capacité (ne conservant que quelques données binaires), qu'une zone mémoire de grande capacité (permettant de stocker un programme entier). La mémoire vive 204A conserve des données, des variables et des résultats intermédiaires de traitement utilisés par les programmes stockés en mémoire 204B, dans des segments de mémoire portant, dans la suite de la description, les mêmes noms que les données dont ils conservent les valeurs. En cours de fonctionnement, la mémoire flash 204B contient le BIOS et les logiciels de contrôle (qui opèrent avec le système d'exploitation temps-réel CHORUS (marque déposée)) qui sont décrits en figure 3 à 7. La mémoire vive 204 comporte notamment: - un segment de mémoire "user data" dans lequel sont conservées les informations utilisateur à transmettre, dont, en particulier, le service requis (comportant la bande passante nécessaire), - un segment de mémoire "adddata "dans lequel sont conservées des informations additionnelles à transmettre, informations qui définissent, notamment, dans son intégralité, le chemin à suivre par les données utilisateur sur le réseau de communication (figure 9), et - un segment de mémoire "Tables" dans lequel sont conservées une table de charge de chemins et une table de charge de liens comportant des informations décrivant tous les chemins dont le noeud considéré est la source et tous les liens faisant partie de ces chemins (figures 10 et 11). La zone d'extension de mémoire 236 est adaptée à conserver: - le programme de fonctionnement de l'unité centrale de traitement 206, dans un segment de mémoire "program1 ", et - un identificateur représentatif du moyen de communication 112, identificateur qui est unique sur le réseau de communication. A l'initialisation du moyen de communication, le programme stocké dans la mémoire d'extension 236 est au moins partiellement copié et organisé dans la zone mémoire d'exécution 204B. La zone d'extension de mémoire 236 constitue un moyen de stockage d'informations lisibles par un ordinateur ou un microprocesseur, conservant des instructions d'un programme informatique caractérisé en ce qu'il permet la mise en oeuvre du procédé de l'invention. Selon une variante, la zone d'extension de mémoire 236 est amovible, partiellement ou totalement, et comporte, par exemple, une bande magnétique, une mémoire flash, une disquette ou un compact disque à mémoire figée ("CD-ROM" en anglais). Dans le mode de réalisation décrit et représenté, le moyen de traitement utilise le moyen de communication conforme à l'invention. Le moyen de traitement demande l'établissement d'une connexion au moyen de communication en lui faisant part du service requis ("application requirement" en anglais). Ces paramètres dits de "service requis" sont, d'une part, transmis dans certains messages de signalisation et, d'autre part, utilisés pour calculer les paramètres de transmission ("trafic parameters" en anglais). Le service requis est l'étalon utilisé pour la mise à jour des tables de charges dans les différents noeuds du réseau car il ne dépend pas de l'état respectif des tables de charges. Les organigrammes objets des figures 4 à 7 n'illustrent que partiellement le fonctionnement des dispositifs de communication. L'unité centrale de traitement 206 est adaptée à mettre en oeuvre les organigrammes décrits en figures 4 à 7. En figure 3, on observe, symbolisés par des flèches descendantes placées dans une colonne centrale, des messages transmis sur le réseau, entre un noeud source, à gauche, et un noeud destinataire, à droite. Les flèches orientées de la gauche vers la droite correspondent à des messages transmis depuis le noeud source des données utilisateur à destination du noeud destinataire de ces données et les flèches orientées de la droite vers la gauche correspondent à des messages transmis depuis le noeud destinataire des données utilisateur vers le noeud source de ces données. Dans la colonne de gauche, sont représentés les messages échangés entre le moyen de traitement du noeud source (à gauche) et le moyen de communication du noeud source (à droite de la colonne de gauche). Dans la colonne de droite, sont représentés les messages échangés entre le moyen de traitement du noeud destinataire (à droite) et le moyen de communication du noeud destinataire (à gauche de la colonne de droite). Les six flèches 251 à 256 de la colonne centrale correspondent à un mode de communication connecté conforme à la présente invention, les flèches 257 et 258 correspondent à une transmission en mode non connecté avec synchronisation des deux moyens de traitement et la flèche 259 correspond à une communication en mode non connecté sans synchronisation des deux moyens de traitement. Dans la colonne centrale, les flèches 254, 257, 258 et 259 correspondent à des transferts de données sur le réseau, les autres flèches correspondant à des messages organisant ces transferts. En mode connecté, c'est-à-dire dans le cas du trafic connecté, le moyen de traitement du noeud source informe le moyen de communication du noeud source de l'ouverture d'une connexion en lui envoyant un message de requête de connexion ("connect_req") En conséquence, le moyen de communication du noeud source lance la phase d'initialisation ("set-up" en anglais). Cette phase comporte notamment l'émission d'un message d'initialisation 251 (message "set-up") par le moyen de communication du noeud source et à destination du moyen de communication du noeud destinataire (par l'intermédiaire, le cas échéant, du moyen de communication de chaque noeud intermédiaire). A réception du message de "set-up", le moyen de communication du noeud destinataire informe le moyen de traitement du noeud destinataire qu'il a reçu une demande d'ouverture de connexion, par l'intermédiaire d'un message de demande d'ouverture de connexion "connect_ind'. Si la demande est acceptée, le moyen de communication du noeud destinataire est informé par le moyen de traitement du noeud destinataire, par l'intermédiaire d'un message "connect_ans" (identifié en figure 6 par le nom "callRequest ack' pour acceptation de requête d'appel ou de "callRequestnack", pour rejet de requête d'appel, selon le résultat de la demande d'ouverture de connexion, opérations 377 et 378 respectivement. Dans le premier cas, un message de connexion 252 ("connect") est émis par le moyen de communication du noeud destinataire vers le moyen de communication du noeud source. Le moyen de traitement du noeud source est alors informé du bon déroulement de l'ouverture de la connexion par un message de confirmation de connexion "connectcfr", de la part du moyen de communication du noeud source. Le moyen de communication de chaque noeud du réseau est alors informé de l'établissement d'une nouvelle connexion par l'intermédiaire d'un message 253 de mise à jour de table de charge "LinkTabLoad" diffusé par le moyen de communication du noeud source. Ce message est aussi utilisé pour confirmer auprès des noeuds intermédiaires et du noeud destinataire le bon déroulement de la phase d'établissement de la connexion. Le transfert de données composant le trafic connecté associé à la connexion, du noeud source vers le noeud destinataire, peut alors avoir lieu. A cet effet, le moyen de traitement du noeud source et le moyen de communication du noeud source échangent des messages de demande d'émission d'un message de données "sendlsoDatareq" et de confirmation d'émission du message de données "sendlsoData_cft"'. Le transfert des messages de données 254 est alors effectué après segmentation du flot de données en paquets de taille prédéfinie. Le moyen de communication du noeud destinataire reçoit les paquets de données qu'il confie au moyen de traitement du noeud destinataire, par l'intermédiaire du message de réception d'un message de données "sendisoData_ind"), après avoir restructuré le flot de données. Lorsque les données à transmettre ont été transmises, le moyen de traitement du noeud source peut décider de la fermeture d'une connexion en transmettant un message de demande de fermeture de connexion "releasereq" au moyen de communication du noeud source. Le moyen de communication du noeud source émet alors: - un message de confirmation de relâchement "release_cfr' à destination du moyen de traitement du noeud source, - un message de relâchement "release" 255 à destination des éventuels noeuds intermédiaires et du noeud destinataire, et - un message 256 de mise à jour de table de charge "LinkTabFree" à tous les noeuds du réseau. Le message 256 est utilisé pour confirmer auprès des noeuds intermédiaires, des noeuds voisins et du noeud destinataire le bon déroulement de la phase de libération de la connexion. Au niveau du noeud destinataire, le moyen de communication informe le moyen de traitement de la fermeture de la connexion par l'intermédiaire d'un message de notification de fermeture de connexion "releaseind"'. Le transfert de données pour le trafic élastique, en mode non connecté avec synchronisation des moyens de traitement, se fait sans ouverture préalable d'un connexion, par la transmission du message d'émission de message "sendSyncData_req" par le moyen de traitement du noeud source vers le moyen de communication du noeud source. Ce moyen de communication effectue le transfert 257 des données après segmentation du flot de données en paquets de taille prédéfinie. Au niveau du noeud destinataire, la réception des données est effectuée par le moyen de communication, qui informe le moyen de traitement, et transmet le flot de données restructuré, par l'usage du message de réception de message "sendSyncDataind". En réponse, le moyen de traitement du noeud destinataire émet, à destination du moyen de communication du noeud destinataire, un message de bonne réception "sendSyncData_ans", qui contient la réponse du moyen de traitement du noeud destinataire et provoque le transfert d'un message 258 entre le moyen de communication du noeud destinataire et le moyen de communication du noeud source. A réception de ce message 258, le moyen de communication du noeud source émet à destination du moyen de traitement du noeud source un message de confirmation de transmission "sendSyncData_cfr". Le transfert de données pour le trafic élastique, en mode non connecté sans synchronisation des moyens de traitement, se fait sans ouverture préalable d'un connexion, par la transmission du message d'émission de message "sendAsyncData_req" par le moyen de traitement du noeud source vers le moyen de communication du noeud source. Ce moyen de communication effectue le transfert 259 des données après segmentation du flot de données en paquets de taille prédéfinie et émet à destination du moyen de traitement du noeud source un message de confirmation de transmission "sendAsyncDatacfr?'. Au niveau du noeud destinataire, la réception des données est effectuée par le moyen de communication, qui informe le moyen de traitement et transmet le flot de données restructuré, par l'usage du message de réception de message "sendAsyncData_ind'. Les figures 4 à 7 illustrent les procédures de gestion des connexions selon l'invention. En ce qui concerne le moyen de communication du noeud source, après avoir été dans un état d'initialisation 300 (figure 4), un message entrant "connect req" est reçu au cours d'une opération 301, de la part du moyen de traitement du noeud source. Ce message comporte le service requis, dont la bande passante, et le mode de transmission. Le moyen de communication du noeud source effectue alors la sélection d'un chemin alloué à la connexion, le calcul des paramètres de transmission en fonction du service requis puis la mise à jour de la table de charge si un chemin est disponible (figure 13), au cours d'une opération 302. Ensuite, au cours d'un test 304, le moyen de communication du noeud source détermine si la bande passante nécessaire à la connexion envisagée est disponible sur le chemin sélectionné, ou non. Cette procédure de test 304 est connue sous le nom de " Contrôle d'Admission de Connexion "ou encore "CAC". Lorsque le résultat du test 304 est négatif, au cours d'une opération 303, le moyen de communication émet un message de refus d'ouverture (message "connectcfr' négatif) de communication à destination du moyen de traitement du noeud source. Ce message de refus "connect_cf'r" négatif a pour effet d'avertir l'application logicielle qui avait requis la transmission de l'impossibilité d'effectuer cette transmission en mode connecté. Ensuite, les ressources associées à la gestion de la connexion sont libérées. Lorsque le résultat du test 304 est positif, au cours d'une opération 305, le moyen de communication émet le message 251 "set-up" (figure 3) à destination du moyen de communication du noeud destinataire, par l'intermédiaire de chacun des dispositifs de communication des éventuels noeuds intermédiaires. Ce message 251 décrit la connexion à établir (voir figure 9). Ensuite, au cours d'une opération 306, un compteur d'horloge (en anglais "timer") "cncAckWait" est initialisé à une valeur qui correspond à un délai maximum accordé à l'établissement de la connexion demandée. Le moyen de communication se met alors dans un état d'attente de la réponse du réseau quant à l'établissement de la connexion, état 307. Dans cet état 307, trois événements différents peuvent se produire, au cours d'opérations 308, 310 ou 311. Lorsque, dans l'état 307, le message entrant est un message "cncAckWait', provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait" initialisé au cours de l'opération 306, opération 308, ou lorsque le message entrant est un message "release_back", provenant du noeud destinataire ou de l'un des éventuels noeuds intermédiaires, opération 310, l'opération 323 est effectuée, au cours de laquelle le moyen de traitement du noeud source est informé du rejet de la demande de connexion. A cet effet, le moyen de communication du noeud source émet un message "openCalinack", correspondant à un message "connect_cfr' négatif, notifiant le rejet de la connexion, à destination du moyen de traitement du noeud source. A la suite de l'opération 323, au cours d'une opération 324, le moyen de communication du noeud source procède à la mise à jour des tables de charge associées à la connexion qui a été rejetée. Puis, au cours d'une opération 325, les ressources associées à la gestion de la connexion sont libérées. Enfin, lorsque, dans l'état 307, le message entrant est un message de connexion 252 "connect", provenant du noeud destinataire, opération 311, le moyen de communication du noeud source effectue l'émission d'un message d'acquittement d'ouverture de connexion "openCallack", correspondant à un message "connect_cfr' positif, à destination du moyen de traitement du noeud source, opération 312, puis, au cours d'une opération 313, diffuse un message 253 "LinkTabLoad"' comportant notamment la description du service requis, la bande passante utilisée ainsi que la description du chemin correspondant à la connexion, en termes de liens. Ce message est diffusé à destination de tous les noeuds du réseau, ce qui a pour effet que chaque noeud du réseau met à jour ses tables de charge. La diffusion de ce message est effectuée en suivant un arbre de recouvrement du réseau, déterminé selon des techniques connues (voir figure 8). Le moyen de communication du noeud source se met alors dans l'état 314 au cours duquel il attend une évolution de la connexion et transmet toutes les données destinées à être transmises en mode connecté, sur la connexion mise en place. Deux messages peuvent alors entrer dans le moyen de communication, au cours d'opérations 315 et 318. Lorsque, dans l'état 314, le message entrant est un message de relâchement provenant d'un autre noeud du réseau "release_back", opération 315, le moyen de communication du noeud source émet un message de terminaison de communication "callTerminate", "release ind' figure 3, à destination du moyen de traitement du noeud source, opération 316, ce qui a pour effet d'informer le moyen de traitement de la fermeture de la connexion. Puis, le moyen de communication émet un message d'alarme "alarrn_dcnBack", opération 317, à destination du moyen de traitement du noeud source, ce qui a pour effet de déclencher le traitement d'une alarme par ce moyen de traitement puisque la connexion a été interrompue de manière anormale. Puis, le moyen de communication diffuse à destination de tous les autres noeuds du réseau, un message de mise à jour de tables de charges "LinkTabFree", comportant notamment une description du service requis et du chemin correspondant à la connexion, en termes de liens, opération 320. Le moyen de communication effectue alors une opération 321, identique à l'opération 324, puis une opération 322 au cours de laquelle les ressources associées à la gestion de la connexion sont détruites. Lorsque le message reçu, dans l'état 314, est un message de demande de fin de connexion (message "releasereq" provenant du moyen de traitement du noeud source et message "release_cf?', en réponse), opération 318, le moyen de communication émet un message de relâchement 255 "release", opération 319, puis effectue les opérations 320, 321 et 322. En ce qui concerne chaque noeud intermédiaire (figure 5), après avoir été dans un état d'initialisation 300, un message entrant 251 "set-up" est reçu au cours d'une opération 331, de la part du noeud source (voir opération 305). Le service requis pour la connexion considérée est alors extrait de ce message 251 "set-up". Le moyen de communication du noeud intermédiaire effectue alors un calcul des paramètres de transmission, à partir du service requis, puis, si la charge est acceptable, une mise à jour de ses tables de charge, au cours d'une opération 332, détaillée figure 14. Ensuite, au cours d'un test 335, le moyen de communication du noeud intermédiaire détermine si la bande passante nécessaire à la connexion envisagée est disponible sur le chemin sélectionné, ou non (voir test 304). Lorsque le résultat du test 335 est négatif, au cours d'une opération 333, le moyen de communication du noeud intermédiaire émet un message de relâchement de connexion "release_bacK' à destination du noeud source (voir opération 310). Puis le moyen de communication du noeud intermédiaire libère les ressources associées à la gestion de la connexion considérée, opération 334. Lorsque le résultat du test 335 est positif, au cours d'une opération 336, le moyen de communication émet un message d'initialisation "set-up" 251 à destination du moyen de communication du noeud destinataire et de chacun des moyens de communication des éventuels noeuds intermédiaires. Ce message est émis après mise à jour du champ identifiant la position du noeud dans le chemin, à partir de la description du chemin en termes de liens (voir figure 9). Ensuite, au cours d'une opération 337, le compteur d'horloge "cncAckWaif' est initialisé à une valeur qui correspond à la durée maximale accordée à l'établissement de la connexion. Le moyen de communication se met alors dans l'état 338 d'attente de la réponse du réseau quant à l'établissement de la connexion. Dans cet état 338, cinq événements différents peuvent se produire, au cours d'opérations 339, 341, 345, 346 et 347. Lorsque le message entrant est un message "cncAckWait', provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait' initialisé au cours de l'opération 337, opération 339, le moyen de communication émet un message de relâchement "release", opération 340, à destination du noeud destinataire et des éventuels noeuds intermédiaires qui le séparent du noeud destinataire, et émet un message de relâchement "release_back", à destination du noeud source et des éventuels noeuds intermédiaires qui le séparent du noeud source, opération 342. Ensuite, au cours d'une opération 343, le moyen de communication du noeud intermédiaire considéré procède à la mise à jour des tables de charge associées à la connexion qui a été rejetée. Puis, au cours d'une opération 344, les ressources associées à la gestion de la connexion sont libérées. Lorsque le message entrant est un message "release" 255, provenant du noeud source ou d'un noeud intermédiaire entre le noeud source et le noeud intermédiaire considéré, opération 341, le moyen de communication effectue les opérations 342 à 344. Lorsque, dans l'état 338, le message entrant est un message 256 "LinkTabFree", opération 347, ce message est mémorisé et le moyen de communication reste dans l'état 338. Lorsque, dans l'état 338, le message entrant est un message de demande de fin de connexion émis par un moyen de contrôle de noeud, dont la fonction est de prendre en compte les différents problèmes du réseau, opération 346, ce message est mémorisé et le moyen de communication reste dans l'état 338. Enfin, lorsque le message entrant est un message 253 "LinkTabLoac', comportant notamment la description du service requis, ainsi que la description du chemin en termes de liens, en provenance du noeud source (voir opération 313), opération 345, le moyen de communication se met dans un état 348 au cours duquel il attend une évolution de la connexion et transmet toutes les données destinées à être transmises en mode connecté, sur la connexion mise en place. On observe ici que le message 253 "LinkTabLoacd' a, vis à vis d'un noeud intermédiaire (et du noeud destinataire), pour fonction de confirmer l'établissement de la connexion, au cours de l'opération 345. Dans l'état 348, trois événements peuvent se produire, au cours d'opérations 349, 350 et 351. Lorsque, dans l'état 348, le message entrant est un message 256 "LinkTabFree", opération 351, ce message est mémorisé et le moyen de * communication reste dans l'état 348. Lorsque, dans l'état 348, le message entrant est un message 255 "release", I'opération 353 décrite plus loin est effectuée. Enfin, lorsque, dans l'état 348, le message entrant est un message de demande de fin de connexion, émis par un moyen de contrôle de noeud, opération 350, le moyen de communication émet un message de relâchement "release_back" à destination du noeud source, opération 352. A la suite de l'une des opérations 349 ou 352, le moyen de communication effectue, au cours d'une opération 353, l'émission d'un message de relâchement "release" à destination du noeud destinataire et de chaque éventuel noeud intermédiaire qui sépare le noeud intermédiaire considéré et le noeud destinataire. Le moyen de communication effectue alors une opération 354 identique à l'opération 324, puis une opération 355 au cours de laquelle le compteur d'horloge "cncAckWait' est initialisé à une valeur qui correspond à la durée maximale accordée à la libération de la connexion. Le moyen de communication se met alors dans l'état 356 d'attente de la réponse du réseau quant au relâchement de la connexion. Dans l'état 356, deux messages peuvent survenir, au cours d'opérations 357 et 358. Lorsque le message entrant est un message 256 "LinkTabFree", opération 357, les ressources associées à la gestion de la connexion sont libérées, opération 360. Lorsque, dans l'état 356, le message entrant est un message "cncAckWait', provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait' initialisé au cours de l'opération 355, opération 358, le moyen de communication émet un message d'alarme "alarm_dcnTO", opération 359, à destination d'un moyen de contrôle de noeud, ce qui a pour effet de déclencher le traitement d'une alarme par ce moyen de traitement puisque la connexion n'a pas été relâchée de manière normale. A la suite de l'une des opérations 357 ou 359, les ressources associées à la gestion de la connexion sont libérées, opération 360. En ce qui concerne le noeud destinataire, (figure 6), après avoir été dans un état d'initialisation 370, un message entrant "setUpend" est reçu au cours d'une opération 371, de la part du noeud source ou d'un noeud intermédiaire. Le moyen de communication du noeud destinataire effectue alors l'extraction du service requis, opération 371, puis le calcul desparamètres de transmission à partir du service requis, et, si la charge est acceptable, la mise à jour de la table de charge, au cours d'une opération 372 similaire à l'opération 332, décrite figure 14. Ensuite, au cours d'un test 373, le moyen de communication du noeud destinataire détermine si la bande passante nécessaire à la connexion envisagée est disponible sur le chemin sélectionné, ou non (voir tests 304 et 335). Lorsque le résultat du test 373 est négatif, au cours d'une opération 333, le moyen de communication du noeud destinataire émet, à destination du noeud source et de tous les éventuels noeuds intermédiaires, un message de relâchement "release_back", au cours d'une opération 380. Ensuite, les ressources associées à la gestion de la connexion sont libérées, opération 382. Lorsque le résultat du test 373 est positif, le moyen de communication du noeud destinataire émet, à destination du moyen de traitement du noeud destinataire un message de demande de connexion "connect_ind', au cours d'une opération 374. Puis, le moyen de communication se met dans un état 375 d'attente de la réponse du moyen de traitement du noeud destinataire. Dans l'état 375, trois événements peuvent survenir, au cours d'opérations 376, 377 et 378. Lorsque le message entrant est un message de relâchement "release", provenant du noeud source ou de l'un des noeuds intermédiaires, il est mémorisé au cours de l'opération 376. Lorsque, dans l'état 375, le message entrant est une réponse défavorable "callReq_nack", correspondant à un message "connect_ans" négatif (figure 3), provenant du moyen de traitement du noeud destinataire, opération 378, au cours d'une opération 379, le moyen de communication du noeud destinataire procède à la mise à jour des tables de charge associées à la connexion qui a été rejetée. Puis les opérations 380 et 382 sont effectuées. Enfin, lorsque, dans l'état 375, le message entrant est un message favorable "callReq_acK', correspondant à un message "connect_ans" positif (figure 3), en provenance du moyen de traitement du noeud destinataire, opération 377, le moyen de communication émet un message 252 "connect', directement vers le noeud source, par mise en oeuvre du moyen de routage, au cours d'une opération 381. Ensuite, au cours d'une opération 383, le compteur d'horloge "cncAckWait' est initialisé à une valeur qui correspond à un délai maximum accordé à l'établissement de la connexion demandée. Le moyen de communication se met alors dans l'état d'attente de la réponse du réseau quant à l'établissement de la connexion, état 384. Dans cet état 384, cinq événements peuvent survenir au cours d'opérations 385, 386, 387, 389 et 390. Lorsque le message entrant est un message de relâchement "release", provenant du noeud source ou de l'un des noeuds intermédiaires, il est mémorisé au cours de l'opération 385. Lorsque, dans l'état 384, le message entrant est un message de mise à jour de table de charge 256 "LinkTabFree", provenant du noeud source, il est mémorisé au cours de l'opération 389. Lorsque, dans l'état 384, le message entrant est un message de demande de fin de connexion provenant du moyen de traitement ou d'un moyen de contrôle de noeud, il est mémorisé au cours de l'opération 386. Lorsque, dans l'état 384, le message entrant est un message "cncAckWait', provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait' initialisé au cours de l'opération 383, opération 390, le moyen de communication émet un message de relâchement de connexion "release_back", opération 391, à destination des noeuds intermédiaires et du noeud source. Ensuite, au cours d'une opération 392, le moyen de communication du noeud destinataire procède à la mise à jour des tables de charge associées a la connexion qui a été rejetée. Puis, au cours d'une opération 393, les ressources associées à la gestion de la connexion sont libérées. Enfin, lorsque, dans l'état 384, le message entrant est un message 253 "LinkTabLoad", message comportant notamment la description du service requis ainsi que la description du chemin en terme de liens (message ayant pour fonction de confirmer l'établissement de la connexion), opération 387, le moyen de communication du noeud destinataire se met dans un état 388 d'attente d'évolution de la connexion. On observe ici que le message 253 "LinkTabLoac' a, vis à vis d'un noeud intermédiaire, pour fonction de confirmer l'établissement de la connexion. Dans l'état 388, trois événements peuvent survenir, au cours d'opérations 394, 396 et 397. Lorsque, dans l'état 388, le message entrant est un message de mise à jour de table de charge 256 "LinkTabFree", provenant du noeud source, il est mémorisé au cours de l'opération 396. Lorsque, dans l'état 388, le message entrant est un message de relâchement 255 "release", opération 397, le moyen de communication effectue la notification "caliTerminate", correspondant à un message "release_ind" (figure 3), de la rupture de la connexion au moyen de traitement du noeud destinataire, opération 398. Ensuite, I'opération 399 décrite plus loin est effectuée. Enfin, lorsque, dans l'état 388, le message entrant est un message de demande de fin de connexion émis par un moyen de contrôle de noeud, opération 394, le moyen de communication émet un message de relâchement "releaseback" à destination du noeud source et des noeuds intermédiaires, opération 395. A la suite de l'une des opérations 395 ou 398, le moyen de communication effectue une opération 399 identique à l'opération 324, puis une opération 400 au cours de laquelle le compteur d'horloge "cncAckWaitr' est initialisé à une valeur qui correspond à la durée maximale accordée à la libération de la connexion. Le moyen de communication se met alors dans l'état 401 d'attente de la réponse du réseau quant au relâchement de la connexion de la même façon que pour les noeuds intermédiaires. Dans l'état 401, deux messages peuvent survenir, au cours d'opérations 402 et 403. Lorsque le message entrant est un message 256 "LinkTabFree", opération 402, les ressources associées à la gestion de la connexion sont libérées, opération 405. Lorsque, dans l'état 401, le message entrant est un message "cncAckWait', provenant du passage à zéro de la valeur du compteur de signaux d'horloge "cncAckWait' initialisé au cours de l'opération 400, opération 403, le moyen de communication émet un message d'alarme "alarm_dcnTO", opération 404, à destination du moyen de contrôle de noeud, ce qui a pour effet de déclencher le traitement d'une alarme par ce moyen de traitement puisque la connexion n'a pas été relâchée de manière normale. A la suite de l'une des opérations 402 ou 404, les ressources associées à la gestion de la connexion sont libérées, opération 405. En ce qui concerne chaque noeud voisin (figure 7), après avoir été dans un état d'initialisation 411, le moyen de communication du noeud voisin reçoit un message 253 "LinkTabLoacd"', comprenant notamment la description du service requis ainsi que la description du chemin en termes de liens, opération 412. Ensuite, au cours d'une opération 413, le moyen de communication du noeud voisin effectue le calcul des paramètres de transmission à partir du service requis, puis, indépendamment de la charge, la mise à jour de la table de charge. Ensuite, dans l'état 414, le moyen de communication du noeud voisin attend l'évolution de la connexion. Ensuite, au cours d'une opération 415, il reçoit un message 256 "LinkTabFree" concernant la connexion, message comprenant notamment la description du service requis ainsi que la description du chemin en termes de liens. Ensuite, au cours d'une opération 416, le moyen de communication du noeud voisin procède à la mise à jour des tables de charge associées à la connexion qui a été libérée. Puis, au cours d'une opération 417, les ressources associées à la gestion de la connexion sont libérées. On observe ici que le message 253 "LinkTabLoad" a, vis à vis d'un noeud voisin, pour fonction d'informer sur l'établissement de la connexion. Ainsi la procédure (figure 7) correspond plutôt à une notification qu'à un contrôle d'admission. En figure 8 sont représentés, dans un réseau à commutation de paquets 800: - un noeud source 801, - un noeud destinataire 802, - deux noeuds intermédiaires 803 et 804, - cinq noeuds voisins 805 à 809, et - les liens entre ces noeuds. Le long de ces liens sont représentés des messages transitant successivement sur le réseau ainsi constitué, sous forme de flèches. On observe que le message 251 "set-up" circule: - du noeud source 801 au noeud intermédiaire 803, puis - du noeud intermédiaire 803 au noeud intermédiaire 804, puis - du noeud intermédiaire 804 au noeud destinataire 802. En revanche, le message 252 "connect" retourne directement du noeud destinataire 802 au noeud source 801, sans intervention des noeuds intermédiaires 803 ou 804. Ce message 252 peut, en fait, passer par n'importe quel chemin entre le noeud destinataire et le noeud source, par exemple par un chemin passant par le noeud voisin 808. Enfin, les messages de mise à jour de table de charge 253 "LinkTabLoacd' et 256 "LinkTabFree" sont diffusés à tous les noeuds du réseau, en suivant un arbre de recouvrement. Préférentiellement, toutes les extrémités, ou "feuilles" de l'arbre de recouvrement se trouvent sur le chemin de la connexion. Ainsi, lorsqu'il y a une panne dans le réseau, les noeuds du chemin, noeuds intermédiaires ou noeud destinataire, qui, comme on l'a vu dans les organigrammes des figures 5 et 6, attendent le message "LinkTabLoad' 253, respectivement dans les états 345 et 387, peuvent détecter la panne lorsque l'un des noeuds voisins ne transmet pas ce message. En figure 9, on observe, sur quatre lignes successives, les structures des messages 251 "set-up", 255 "release", de mise à jour de table de charge, 253 "LinkTabLoad' ou 256 "LinkTabFree" et 252 "connect'. Le message 251 "set-up" comporte successivement les champs: - 901, d'identification du type de message ("set-up", "LinkTabLoad', "LinkTabFree", "Connect' ou "Release", voir figure 3), - 902, d'identification de connexion, - 903, de description de trafic, représentatif du service requis, - 904, de données propres au moyen de communication permettant notamment d'identifier les moyens de traitement des noeuds source et destinataire, 905, de nombre de liens qui utilisent le chemin associé à la connexion, 906, de rang du lien sur lequel transite le message, sur le chemin associé à la connexion, - 907, des descripteurs de liens successifs du chemin correspondant à la connexion souhaitée, et - 908, de données de protocole. Le message 255 "release" comporte successivement les champs: - 901, d'identification du type de message ("set-up", "LinkTabLoad", "LinkTabFree", "Connect" ou "Release", voir figure 3), - 902, d'identification de connexion, - 909, de cause de la demande de relâchement, - 905, de nombre de liens qui utilisent le chemin associé à la connexion, - 906, de rang du lien sur lequel transite le message, sur le chemin associé à la connexion, - 907, des descripteurs de liens successifs du chemin correspondant à la connexion souhaitée, et - 908, de données de protocole. Un message de mise à jour de table de charge 253 ou 256 comporte successivement les champs: - 901, d'identification du type de message ("set-up", "LinkTabLoad", "LinkTabFree", "Connect" ou "Release", voir figure 3), - 902, d'identification de connexion, - 903, de description de trafic, représentatif du service requis, - 910, d'information relative à l'arbre de recouvrement mis en oeuvre, 905, de nombre de liens qui utilisent le chemin associé à la connexion, 906, de rang du lien sur lequel transite le message, sur le chemin associé à la connexion, - 907, des descripteurs de liens successifs du chemin correspondant à la connexion souhaitée, et - 908, de données de protocole. Le message 252 "connect' comporte successivement les champs: - 901, d'identification du type de message ("set-up", "LinkTabLoad", "LinkTabFree", "Connect" ou "Release", voir figure 3), - 902, d'identification de connexion, - 911, de données de protocole, pouvant être utilisées par le moyen de traitement du noeud source. - 908, de données de protocole. En figure 10, on observe des descripteurs de liens 1001 à 1007 disposés côte à côte et des descripteurs de chemins 1011 à 1015 disposés sur des lignes successives. Chaque descripteur de chemin est une structure de données pour la description d'un chemin qui comporte, en particulier la référence des liens impliqués dans la description de ce chemin et la référence de chaque connexion associée à ce chemin. Chaque descripteur de chemin sortant (1 011, 1012 ou 1013) concerne un chemin créé par le moyen de routage du moyen de communication. Les chemins qui ne partent pas du noeud considéré sont dits "temporaires" et permettent de connaître les charges des liens des chemins sortants. Les chemins temporaires sont créés par le moyen de contrôle de charge qui gère tous les chemins (opérations 1307, 1407 et 1504, figures 13 à ). Dans le mode de réalisation décrit et représenté, les chemins 1011, 1012 et 1013 sont des chemins sortants (en traits gras) et les chemins 1014 et 1015 sont des chemins temporaires (en traits fins). Les chemins 1011, 1012 et 1013 décrivent la table de routage et sont utilisés par le noeud considéré pour établir des chemins vers n'importe quel noeud destinataire. Chaque descripteur de lien 1001 à 1007 comporte, en particulier, la référence de chaque chemin qui traverse le lien considéré, identifié par un rectangle, à l'intersection d'une ligne verticale partant du descripteur de lien considéré et d'une ligne horizontale partant du descripteur de chemin considéré. Les liens 1001 à 1004 font partie d'au moins l'un des chemins sortants, et sont représentés en traits gras. Chaque intersection de deux lignes marquée par un point représente une référence en mémoire: - les lignes externes (en haut et/ou à gauche des rectangles) repèrent les références conservées avec chaque lien: ces références concernent chaque chemin qui traverse ledit lien, et - les lignes internes (en bas et/ou à droite des rectangles) repèrent les références conservées avec chaque chemin: ces références concernent chaque lien traversé par ledit chemin. La mise à jour de la table de charge effectuée par le moyen de contrôle de charge, comporte les étapes suivantes: - pour l'établissement d'une connexion: * mise à jour de la charge de tous les liens référencés par le chemin (ajout de charge), et * pour chaque lien, mise à jour de la charge de chaque chemin référencé pour ce lien; - pour le retrait d'une connexion: * mise à jour de la charge de tous les liens référencés par le chemin (déduction de charge), et * pour chaque lien, mise à jour de la charge de chaque chemin référencé pour ce lien - pour l'ajout d'un chemin: À soit par le moyen de routage, lors de l'établissement de la table de routage du noeud considéré (il s'agit alors d'un chemin sortant), ou lors de la mise à jour de la table de routage, * soit par le moyen de contrôle de charge, lorsque le chemin associé à une nouvelle connexion lors de l'ajout de charge n'est pas déjà spécifié (il s'agit alors de chemin temporaire); - pour la suppression d'un chemin: * par retrait d'un chemin temporaire lorsqu'il n'est plus traversé par aucune connexion, après retrait d'une connexion, soit lorsque la liste de connexions référencée par ce chemin est vide, - pour la transformation d'un chemin sortant en chemin temporaire lorsqu'il ne fait plus partie de la table de routage (à la suite d'une opération de mise à jour de la table de routage); et - pour la suppression d'un lien * par retrait d'un lien lorsqu'il n'est plus traversé par aucun chemin, ou lorsque la liste des chemins référencés par ledit lien est vide. Dans la table de charge, à chaque lien est associée une information de charge et à chaque chemin est associée une information représentative du lien le moins disponible. Ainsi, la bande passante disponible du lien le moins disponible est aussi la bande passante disponible du chemin. On observe que c'est en utilisant cette information de disponibilité de bande passante de chemin, que le moyen de communication effectue le choix du chemin en choisissant le chemin le plus disponible. Pour chaque information à transmettre en mode non connecté, la disponibilité de chaque chemin du réseau est ainsi estimée, en fonction du trafic en mode connecté. La charge d'un chemin est définie à partir de son lien le moins disponible. Il est caractérisé par la bande passante totale qu'il autorise et la part maximale de la bande passante associée au trafic en mode connecté. Etant donnée la charge effective du trafic en mode connecté, chaque moyen de communication définit la part associée au trafic en mode non connecté, comme égale à la bande passante totale à laquelle on a soustrait la part associée au mode connecté. Le moyen de communication alloue à l'ensemble des transmissions en mode non connecté qu'il a à effectuer, tout ou partie de la bande passante (préférentiellement une partie, pour éviter des problèmes de congestion du réseau). Cette part est équitablement répartie entre toutes les transmissions en mode non connecté et se trouve donc dynamiquement mise à jour au début et à la fin de chaque transmission en mode connecté (lorsque la charge du trafic en mode connecté varie). L'attribution d'une part est effectuée en définissant un plage de valeurs du nombre de paquets à émettre entre deux valeurs extrêmes (spec_CPmin 1114 et specCPmax 1115 (figure 11). Cette opération d'attribution de bande passante est effectuée avant l'émission de l'information 257 ou 259 (figure 3). En outre, on considère qu'un chemin qui supporte plus d'un nombre prédéterminé de transmission sortante en mode non connecté n'est pas disponible pour une transmission en mode non connecté supplémentaire. Les événements qui peuvent influencer l'attribution de bande passante à une transmission en mode connecté sont de deux types: - ceux qui concernent le mode connecté, l'établissement ou la fermeture d'une connexion, et qui influent sur la bande passante qui lui est réservée, et, par conséquent, sur le nombre de paquets à émettre en mode non connecté mais aussi sur la taille de ces paquets, et - ceux qui concernent le mode non connecté, le début ou la fin d'une transmission, et qui influent sur le nombre de paquets à émettre en mode non connecté. Pour la gestion de la table de charge illustrée en figure 10, la charge d'un chemin est déterminée par la charge du lien le moins disponible, en prenant en compte, pour la charge d'un lien, la somme des charges des chemins qui le traversent. Les chemins sortants utilisés sont établis par un moyen de routage de type connu. On observe ici que chaque noeud du réseau contrôle le flux qu'il génère et que l'information permettant de contrôler ces flux est établie à partir de la table de charge qui est partagée entre les différents noeuds, chaque noeud conservant cette information sous forme d'un tableau tel que celui illustré en figure 11. Les niveaux de priorité des messages sont établis par le moyen de traitement à partir du service requis. En figure 11, on observe un tableau 1100, comportant trois lignes 1101, 1102 et 1103, chacune des lignes comportant des spécifications de canaux virtuels 1105 à 1110. On rappelle ici que chaque canal virtuel est une entité logique associée à une communication entre deux applications mises en oeuvre par deux moyens de traitements associés à deux moyens de communication. Dans le tableau de la figure 11, on a choisi de représenter deux canaux virtuels pour chaque niveau de priorité, pour des raisons de clarté. Cependant, pour chaque niveau de priorité, le nombre de canaux virtuels peut varier entre zéro à un nombre prédéterminé. Chacune de ces spécifications comporte: - une information représentative de la taille "specL" 1111 des paquets associés au canal; - une information représentative du nombre de paquets à émettre "spec_CP' 1112 durant l'intervalle de temps primaire considéré; - une information représentative de la durée "spec CT' 1113 de l'intervalle de temps primaire considéré; une information représentative du niveau de priorité (haut, moyen ou bas) "specprio" 1114 associé au canal; - une information "dynrCP' 1117 représentative du nombre de paquets réellement émis sur le canal virtuel, pendant l'intervalle de temps primaire considéré; - une information "dyn_CT' 1118 représentative du nombre d'intervalles de temps secondaires écoulés pendant l'intervalle de temps primaire considéré; et - une information "VC_state" 1119 représentative de l'état dans lequel se trouve le canal virtuel, "libre", "actif' ou "endorme' (voir figure 12); et - une information "références" 1120 représentative des positions (ou références), en mémoire, des données utilisateur à transmettre. En outre, les spécifications du niveau de priorité basse comportent: - une information "specCPmin" 1115 représentative de la valeur minimale du nombre de paquets à émettre "spec_CPF' 1112 - une information "spec_CPmax" 1116 représentative de la valeur maximale du nombre de paquets à émettre "specCP' 1112, ceci afin de permettre de diminuer la valeur de "specCP' 1112 au cours de l'opération 1221 ou de l'augmenter au cours de l'opération 1215, dans la limite de ces bornes specCPmin 1115 et specCPmax 1116. Enfin, chaque ligne, ou niveau de priorité, est affectée d'une information "prio_state" 1120 représentative de l'état dans lequel se trouve I'ensemble des canaux virtuels du niveau de priorité considéré: lorsqu'au niveau de priorité considéré ne se trouve aucun canal, le niveau de priorité est "libre", lorsque tous les canaux du niveau de priorité sont dans un état "endormi', le niveau de priorité est lui-même dans un état "endormi', et dans les autres cas, le niveau de priorité est "actif'. La table de spécifications et de priorités 1100 est constituée en plaçant: - en première ligne 1101 (niveau de priorité "haut") tous les canaux virtuels affectés à des transmissions en mode connecté, ou "temps réel déterministe" (en anglais "predictive real time"); - en deuxième ligne 1102 (niveau de priorité "moyen") tous les canaux virtuels affectés à des transmissions en mode connecté temps réel garanti (connu sous le nom de temps réel garanti, ou, en anglais, "guaranted real time"); - en troisième ligne 1103 (niveau de priorité "haut") tous les canaux virtuels affectés à des transmissions en mode non connecté (connu sous les noms de "asynchrone" et "élastique", ou, en anglais "elastic"). Ainsi, tous les noeuds disposent d'une table de priorité concernant le trafic qu'il peut générer, et chacun s'occupe des messages dont il est la source (principe connu sous le nom de "outgoing trafic" en anglais, qui signifie "trafic sortant"). On observe ici que les paramètres de transmission sont déterminés par le moyen de contrôle de charge à partir du contenu de la table de charge. Par conséquent, les paramètres de transmission associés aux canaux virtuels de haute et moyenne priorité 1101 et 1102 sont calculés à partir d'une connaissance, a priori, sur tout le trafic connecté alors que les paramètres de transmission associés aux canaux virtuels de faible priorité 1103 sont estimés à partir d'une connaissance limitée au trafic non-connecté sortant du noeud considéré. La figure 12 représente un organigramme de fonctionnement d'émission en modes connecté et non connecté d'un moyen de communication tel qu'illustré en figure 2. Cet organigramme est mis en oeuvre par l'unité centrale 206 (figure 2). Le principe du fonctionnement utilisé est que l'ordre d'émission des paquets est basé sur le remplissage d'un intervalle de temps primaire ITP, comprenant des intervalles de temps secondaires IT-S. A la suite de l'opération d'initialisation 1201 par remise à zéro de toutes les variables, un test 1202 détermine si un intervalle de temps secondaire s'est écoulé, le début d'un intervalle de temps secondaire étant déterminé à partir de l'horloge temps réel 235. Lorsque le résultat du test 1202 est positif, au cours d'une opération 1203, l'unité centrale 206 se place en début de la table de spécifications et de priorités (figure 11). Ensuite, au cours d'une opération 1204, I'information "dynCT" 1118 du canal virtuel considéré est décrémentée. Puis, au cours d'un test 1205, l'unité centrale 206 détermine si la valeur de l'information "dynCT" 1118 du canal virtuel considéré est égale à zéro, ou non. Lorsque le résultat du test 1205 est positif, c'est-à-dire à la fin d'un intervalle de temps primaire, au cours d'un test 1220, I'unité centrale 206 détermine si la valeur de l'information "dynCP' 1117 est égale à zéro, ou non. Le test 1220 correspond donc à chaque début d'un nouvel intervalle de temps primaire. Lorsque le résultat du test 1220 est négatif, au cours d'une opération 1221, I'unité centrale 206 gère les priorités de la manière suivante: pour le trafic déterministe, priorité haute, les paquets non transmis durant l'intervalle de temps requis, dont le nombre est égale à la valeur de valeur "dynCP" 1117, sont supprimés (perte de paquets) puis, la valeur "dynCP" 1117 est mise à zéro, et - pour le trafic garanti, priorité moyenne, les paquets non transmis durant l'intervalle de temps sont conservés et "dynCPF" 1117 conserve sa valeur, et - pour le trafic élastique, priorité basse, la bande passante est réduite, par décrémentation de la valeur "spec _CPF" 1112 dans la limite des bornes autorisées. A la suite de l'opération 1221 ou lorsque le résultat du test 1220 est positif, une opération 1206 est effectuée. Au cours de l'opération 1206, les spécifications et paramètres de transmission sont mis à jour (voir figure 11): - les informations 1111 à 1113 et 1115 à 1116 sont mises à jourà la fin de chaque intervalle de temps primaire, en fonction des changements d'état de la table de charge déterminé par le moyen de contrôle de charge, - la valeur de l'information "dynCPF" 1117 est incrémentée de la valeur de l'information "specCP' 1112, - la valeur de l'information "dyn_CT' 1118 est incrémentée de la valeur de l'information "specCT"' 1113, - la valeur de l'information "VC_state" 1119 passe de l'état "endormi' à l'état "actif'. A la suite de l'opération 1206 ou lorsque le résultat du test 1205 est négatif, une opération 1207 consiste, pour l'unité centrale 206, à considérer le canal virtuel suivant dans la table de spécifications et de priorités. Ensuite, le test 1208 détermine si la fin de la table de spécifications et de priorités a été dépassée, ou non. Lorsque le résultat du test 1208 est négatif, les opérations 1204 à 1207 sont réitérées. Lorsque le résultat du test 1208 est positif, c'est-à-dire lorsqu'un intervalle de tempssecondaire est achevé, un test 1209 détermine si la liste des canaux virtuels de niveau de priorité "haut" possède une information d'état "priostate" 1120 à la valeur "actif' ou non. Lorsque le résultat du test 1209 est positif, au cours d'une opération 1210, I'unité centrale 206 procède a l'émission du paquet dont le remplissage est effectué à partir du champ référence 1120, qui indique la position mémoire des prochaines données à émettre, en mode connecté temps réel déterministe et procède à la mise à jour des spécifications du canal virtuel permettant l'émission du paquet considéré: - l'information "dyn_CP' 1117 est décrémentée, - si l'information "dynCP" 1117 est égale à zéro, la valeur de I'information "VC_state" 1119 prend la valeur "endormi' et le prochain canal virtuel du même niveau de priorité est considéré et, s'il n'y a aucun autre canal virtuel de même niveau de priorité, le niveau de priorité voit son information "priostate" 1120 prendre la valeur "endormi'. L'émission du paquet ne se termine que lorsque le prochain noeud intermédiaire a acquitté le contrôle de flux qu'il a opéré sur les données dudit paquet, tel que cela est décrit dans la norme IEEE-1355 et implémenté par les composants ST-C101 213 ou 216 et ST-C104 209. On remarque ainsi que les conflits d'accès aux ressources de transmission (les liens de communications) sont détectés par le protocole de transmission de paquets, par exemple conforme à la norme IEEE-1355. L'invention permet donc de limiter les effets de ces conflits d'accès pour équitablement répartir l'accès aux ressources entre les différents noeuds du réseau, tout en garantissant une qualité de service spécifiée par le service requis. Lorsque le résultat du test 1209 est négatif, un test 1211 détermine si la liste des canaux virtuels de niveau de priorité "moyen" possède une information d'état "priostate" 1120 à la valeur "actif' ou non. Lorsque le résultat du test 1211 est positif, au cours d'une opération 1212, l'unité centrale 206 procède à l'émission d'un paquet en mode connecté temps réel garanti et procède à la mise à jour des spécifications du canal virtuel permettant l'émission du paquet considéré: - I'information "dyn_CP' 1117 est décrémentée, - si l'information "dyn_CP' 1117 est égale à zéro, la valeur de l'information "VCstate" 1119 prend la valeur "endormi' et le prochain canal virtuel du même niveau de priorité est considéré et, s'il n'y a aucun autre canal virtuel de même niveau de priorité, le niveau de priorité voit son information "prio_state" 1120 prendre la valeur "endormi'. Lorsque le résultat du test 1211 est négatif, un test 1213 détermine si la liste des canaux virtuels de niveau de priorité "bas" possède une information d'état "priostate" 1120 à la valeur "actif' ou non. Lorsque le résultat du test 1213 est positif, au cours d'une opération 1214, I'unité centrale 206 procède à l'émission d'un paquet en mode non connecté et procède à la mise à jour des spécifications du canal virtuel permettant l'émission du paquet considéré: - I'information "dyn_CP" 1117 est décrémentée, - si l'information "dynCP"' 1117 est égale à zéro, la valeur de l'information "VCstate" 1119 prend la valeur "endormi' et le prochain canal virtuel du même niveau de priorité est considéré et, s'il n'y a aucun autre canal virtuel de même niveau de priorité, le niveau de priorité voit son information "prio_state" 1120 prendre la valeur "endormi'. Lorsque le résultat du test 1213 est négatif, au cours d'une opération 1215, l'unité centrale procède à l'analyse de la charge effective du réseau. A cet effet, l'unité centrale 206 comptabilise les périodes d'inactivité du moyen de communication, pour ajuster le nombre de paquets à émettre par canal virtuel, pour le trafic de priorité basse (c'est-à-dire en mode non connecté). En fonction du nombre d'intervalles de temps secondaires non utilisés pour la transmission effective de paquets, la bande passante est accrue, par incrémentation de la valeur "specCP' 1112 dans la limite des bornes autorisées. Puis, le moyen de communication cesse ses émissions jusqu'à ce que le résultat du test 1202 devienne positif. L'allocation ou la libération d'un canal virtuel est effectuée par manipulation: - des listes 1101 et 1102, lors de l'exécution des différentes étapes de gestion d'une connexion illustrée en figure 4. - de la liste 1103, lors de la réception d'un message "SendSyncDatareq" ou "SendAsyncData_cfr', par le moyen de communication, émis par le moyen de traitement, jusqu'à transmission complète du message. Ainsi, le moyen de contrôle de charge tient compte de la charge effective sur le réseau pour répartir les droits d'accès entre les différents niveaux de priorité. La figure 13 représente un organigramme de détermination, par le noeud source, de disponibilité de chemin pour l'établissement d'une connexion, ce qui correspond, en figure 4, à l'opération 302. Le moyen de communication prend en compte la description du service requis établi par l'application ou le périphérique qui émet le message, au cours d'une opération 1302. Puis, le moyen de communication effectue le choix du canal virtuel et du chemin le plus disponible, au cours de l'opération 1304, en faisant usage de la table de routage. Au cours d'un test 1305, le moyen de communication du noeud source détermine si un chemin a été choisi au cours de l'opération 1304 ou non. Lorsque le résultat du test 1305 est négatif, le moyen de communication revendique l'arrêt de la procédure de mise en place de la connexion, au cours d'une opération 1306. Lorsque le résultat du test 1305 est positif, le moyen de communication effectue le calcul des paramètres de transmission, en particulier de la bande passante, de la taille des paquets transmis, des taux (fréquences d'émission) de paquets et de priorité de la communication correspondant au champ 1111 à 1113 illustrés en figure 11, en faisant usage de la table de charge, au cours d'une opération 1303. Puis, au cours d'une opération 1307, le moyen de communication: - alloue un canal virtuel en spécifiant les paramètres de transmission précédemment calculés, et - fait varier la taille des paquets avec la charge du chemin ainsi que le taux de paquets sur ledit chemin, et - met à jour sa table de charge par l'intermédiaire du moyen de contrôle de charge. Ensuite, au cours d'une opération 1308, il revendique la poursuite de la mise en place de la connexion L'opération 302 est alors terminée. La figure 14 représente un organigramme de détermination, par un noeud intermédiaire ou le noeud destinataire, de disponibilité de chemin pour l'établissement d'une connexion, ce qui correspond, en figures 5 et 6, aux opérations 332 et 372. Le moyen de communication obtient, d'abord, la description du chemin et du service requis associés à la nouvelle connexion, en lisant le message 251 "set-up" provenant du noeud source (opération 305), au cours d'une opération 1402. Puis, le moyen de communication vérifie la disponibilité du chemin en fonction du service requis, au cours de l'opération 1404, en faisant usage de la table de routage. Au cours d'un test 1405, le moyen de communication du noeud considéré détermine si le chemin est disponible au cours de l'opération 1404 ou non. Lorsque le résultat du test 1405 est négatif, le moyen de communication revendique la procédure de mise en place de la connexion, au cours d'une opération 1406. Lorsque le résultat du test 1405 est positif, le moyen de communication effectue le calcul des paramètres de transmission, en particulier de la bande passante, de la taille des paquets transmis, des taux (fréquence d'émission) de paquet et de priorité de la communication, en faisant usage de la table de charge, au cours d'une opération 1403. Puis, au cours d'une opération 1407, le moyen de communication met à jour sa table de charge par l'intermédiaire du moyen de contrôle de charge, ce qui revient à réserver les ressources nécessaires à la connexion envisagée, puis, au cours d'une opération 1408, il poursuit la mise en place de la connexion. A la fin de l'une des opérations 1406 ou 1408, l'opération 334 est terminée. La mise à jour de la table de charge s'accompagne d'une mise à jour des paramètres de transmissions associés aux canaux virtuels existants représentatifs du trafic sortant pour le noeud considéré, à travers la valeur des champs 1111 à 1113 pour le trafic connecté et l11, 1113, 1115, 1116 pour le trafic non connecté. La figure 15 représente un organigramme de détermination, par un noeud voisin, de disponibilité de chemin pour l'établissement d'une connexion, ce qui correspond, en figure 7, aux opérations 413. Le moyen de communication obtient, d'abord, la description du chemin et du service requis associés à la nouvelle connexion, en lisant le message 253 "LinkTabLoad" provenant du noeud source (opération 313), au cours d'une opération 1502. Ensuite, le moyen de communication effectue le choix des paramètres de transmission, en particulier de la bande passante, de la taille des paquets transmis, des taux de paquet et de priorité de la communication, en faisant usage de la table de charge, au cours d'une opération 1503. Puis, au cours d'une opération 1504, le moyen de communication met à jour sa table de charge. A la fin de l'opération 1504, le fonctionnement de mise en place de la connexion, par le noeud voisin, est terminé. REVENDICATIONS 1. Procédé de communication sur un réseau, caractérisé en ce qu'il comporte, pour l'établissement d'une connexion: A/ effectuées par un dispositif de communication source d'information à transmettre en mode connecté (801): - une opération de détermination (1302) de besoin de bande passante pour la transmission de ladite information en mode connecté, une opération de détermination d'un éventuel chemin disponible pour ladite transmission (1304), en fonction d'informations conservées dans une table de charge de chaque lien du réseau, et - lorsqu'un chemin disponible est déterminé: une opération de transmission (305) d'une information représentative dudit besoin de bande passante (251) à destination du dispositif de communication suivant sur ledit chemin (803), et une opération de mise à jour (1307) de ladite table de charge des liens du réseau, - une opération de diffusion à destination d'au moins tous les dispositifs de communication en dehors du chemin (805 à 809), d'une information représentative dudit besoin de bande passante (253), B/ effectuées par chaque dispositif de communication intermédiaire (803, 804) sur ledit chemin: - une opération de détermination de disponibilité dudit chemin (1404), pour ladite communication, en fonction d'informations conservées dans une table de charge de chaque lien du réseau, et - lorsque le chemin est disponible: une opération de transmission (336) d'une information représentative dudit besoin de bande passante, au dispositif de communication suivant sur le chemin (804, 802), et une opération de mise à jour de la table de charge (1407) des liens du réseau, C/ effectuée par chaque dispositif de communication en dehors dudit chemin (805 à 809): - une opération de mise à jour d'une table de charge des liens du réseau (1504). 2. Procédé de communication selon la revendication 1, caractérisé en ce que, au cours de l'opération de transmission (305) dudit besoin de bande passante (251) à destination du dispositif de communication suivant sur ledit chemin, le dispositif de communication source (801) transmet une information représentative d'un service requis pour ladite transmission en mode connecté. 3. Procédé de communication selon la revendication 2, caractérisé en ce qu'il comporte, effectuée par chaque dispositif de communication du réseau (801 à 809), une opération de détermination de paramètres de communication (1303, 1403, 1503) dépendant du service requis, et en ce que l'opération de mise à jour des tables (1307, 1407, 1504) est effectuée en prenant en compte lesdits paramètres. 4. Procédé de communication selon l'une quelconque des revendications 1 à 3, caractérisé en ce qu'il comporte, à la fin de la transmission en mode connecté: - effectuée par un dispositif de communication source d'information transmise en mode connecté, une opération de diffusion (320) d'une information représentative du relâchement de la connexion (256), à destination de tous les autres dispositifs de communication du réseau (802 à 809), et - effectuée par chaque dispositif de communication dudit réseau, une opération de mise à jour d'une table de charge des liens du réseau. 5. Procédé de communication selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, au cours de l'établissement d'une connexion, I'opération de diffusion (313) à destination d'au moins tous les dispositifs de communication en dehors du chemin, d'une information représentative dudit besoin de bande passante, est effectuée après que chaque dispositif de communication dudit chemin ait effectué: - une opération de détermination de disponibilité dudit chemin, pour ladite communication, en fonction d'informations conservées dans une table de charge de chaque lien du réseau, et - lorsque le chemin est disponible: une opération de transmission dudit besoin de bande passante, au dispositif de communication suivant sur le chemin, et = une opération de mise à jour d'une table de charge des liens du réseau. 6. Procédé de communication selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comporte, au cours de l'établissement d'une connexion, effectuée par le dispositif de communication source, une opération de détermination de l'intégralité du chemin (1304) destiné à être suivi par l'information à transmettre en mode connecté. 7. Procédé de communication selon l'une quelconque des revendications 1 à 6, caractérisé en ce que, au cours de l'opération de transmission (305) d'une information représentative dudit besoin de bande passante à destination du dispositif de communication suivant sur ledit chemin (251), le dispositif de communication source transmet une information représentative dudit chemin. 8. Procédé de communication selon l'une quelconque des revendications 1 à 7, caractérisé en ce que, au cours de l'opération de diffusion (313), l'information représentative dudit besoin de bande passante suit un arbre de recouvrement du réseau dont au moins la moitié des feuilles sont des dispositifs de communication intermédiaires ou le dispositif de communication destinataire, sur le chemin associé à la connexion. 9. Procédé de communication selon l'une quelconque des revendications 1 à 8, caractérisé en ce que, au cours de l'opération de diffusion (313), l'information représentative dudit besoin de bande passante est diffusée avec une information représentative de l'intégralité du chemin associé à ladite connexion. 10. Procédé de communication selon l'une quelconque des revendications 1 à 9, caractérisé en ce que chaque table de charge comporte, pour chaque lien du réseau, une référence (1120) concernant chaque chemin qui comporte ledit lien et qui est associé à une connexion. 11. Procédé de communication selon la revendication 10, caractérisé en ce qu'à chaque lien du réseau est associée une information représentative de la bande passante disponible sur ledit lien. 12. Procédé de communication selon l'une quelconque des revendications 1 à 11, caractérisé en ce que chaque table de charge comporte, pour chaque chemin, une référence concemrnant chaque lien qu'il comporte. 13. Procédé de communication selon la revendication 12, caractérisé en ce qu'à chaque chemin est associée une information représentative de la bande passante disponible sur ledit chemin. 14. Procédé de communication selon les revendications 11 et 13, caractérisé en ce que l'information représentative de bande passante disponible sur ledit chemin est égale à l'information de bande passante disponible sur le lien le moins disponible dudit chemin. 15. Procédé de communication selon l'une quelconque des revendications 11 à 14, caractérisé en ce que, au cours de l'opération de détermination de chemin (1304), le chemin choisi est le chemin dont la disponibilité est la plus élevée. 16. Procédé de communication selon l'une quelconque des revendications 1 à 15, caractérisé en ce qu'il comporte, effectuée par le dispositif de communication source, une opération de détermination de taille du paquet à transmettre sur le réseau (1221), prenant en compte la charge sur ledit réseau. 17. Procédé de communication selon l'une quelconque des revendications 1 à 16, caractérisé en ce qu'il comporte, effectuée par le dispositif de communication source, une opération de détermination de fréquence d'émission de paquets à transmettre sur le réseau (1221), prenant en compte la charge sur ledit réseau. 18. Procédé selon l'une quelconque des revendications 1 à 17, caractérisé en ce que chaque dispositif de communication effectue chaque transmission d'information par commutation de paquet. 19. Procédé de communication selon l'une quelconque des revendications 1 à 18, entre des dispositifs de communication susceptibles, de déterminer, chacun, pour chaque information qu'il a à transmettre, un chemin à lui faire suivre, caractérisé en ce qu'il comporte: - effectuée par chaque dispositif de communication dit "source", qui a besoin d'une connexion associée à un chemin, pour effectuer une transmission d'information à destination d'un dispositif de communication destinataire, une opération de demande de connexion, au cours de laquelle, le dispositif de communication source transmet, à destination de chaque dispositif de communication dudit chemin, une demande d'établissement de connexion, lorsque l'établissement de ladite connexion est possible, effectuée par au moins le dispositif de communication destinataire, une opération d'émission à destination du dispositif de communication source d'une acceptation de connexion, - effectuée par le dispositif de communication source, une opération de diffusion, à tous les dispositifs de communication du réseau, d'une information représentative de l'établissement de la connexion, - effectuée par chaque dispositif de communication dudit chemin, à réception de ladite information représentative d'établissement de connexion, une opération de confirmation d'établissement de ladite connexion, et - effectuée par chaque dispositif de communication en dehors dudit chemin, à réception de ladite information représentative d'établissement de connexion, une opération de mise en mémoire d'une information représentative de ladite connexion. 20. Dispositif de communication sur un réseau, caractérisé en ce que: - il comporte une mémoire (204A) adaptée à conserver une table de charge contenant des informations relatives à la charge de chaque lien du réseau, et - il est adapté, pour l'établissement d'une connexion destinée à la transmission d'information en mode connecté: à déterminer un besoin de bande passante pour la transmission de ladite information en mode connecté, ò à déterminer un éventuel chemin disponible pour ladite transmission, en fonction d'informations conservées dans ladite table de charge, et lorsqu'un chemin disponible est déterminé, ò à transmettre une information représentative dudit besoin de bande passante, à destination du dispositif de communication suivant sur ledit chemin, 10. à mettre à jour ladite table de charge, à diffuser, à destination d'au moins tous les dispositifs de communication en dehors du chemin, une information représentative dudit besoin de bande passante. 21. Dispositif de communication selon la revendication 20, caractérisé en ce qu'il est adapté, lorsqu'il reçoit, de la part d'un dispositif de communication source, une information représentative d'un besoin de bande passante, associée à une information représentative d'un chemin sur lequel il se trouve: - à déterminer la disponibilité dudit chemin, pour ladite communication, en fonction d'informations conservées dans ladite table de charge de chaque lien du réseau, et lorsque le chemin est disponible - à transmettre une information représentative dudit besoin de bande passante, à destination du dispositif de communication suivant sur ledit chemin, - à mettre à jour ladite table de charge. 22. Dispositif de communication selon l'une quelconque des revendications 20 ou 21, caractérisé en ce qu'il est adapté, lorsqu'il reçoit une information représentative d'un besoin de bande passante, associée à une information représentative d'un chemin sur lequel il ne se trouve pas, à mettre à jour ladite table de charge. 23. Dispositif de communication selon l'une quelconque des revendications 20 à 22, caractérisé en ce qu'il est adapté, pour transmettre ledit besoin de bande passante à destination du dispositif de communication suivant sur ledit chemin, à transmettre une information représentative d'un service requis pour ladite transmission en mode connecté. 24. Dispositif de communication selon la revendication 23, caractérisé en ce qu'il comporte un moyen de détermination de paramètres de communication dépendant du service requis, et en ce qu'il est adapté à mettre à jour la table de charge en prenant en compte lesdits paramètres. 25. Dispositif de communication selon l'une quelconque des revendications 20 à 24, caractérisé en ce qu'il est adapté, pour mettre fin à une transmission en mode connecté, à diffuser une information représentative du relâchement de la connexion, à destination de tous les dispositifs de communication du réseau, afin que chaque dispositif de communication dudit réseau mette à jour une table de charge des liens du réseau. 26. Dispositif de communication selon l'une quelconque des revendications 20 à 25, caractérisé en ce qu'il est adapté, pour l'établissement à déterminer l'intégralité du chemin destiné à être suivi par l'information à transmettre en mode connecté. 27. Dispositif de communication selon l'une quelconque des revendications 20 à 26, caractérisé en ce que, pour transmettre une information représentative dudit besoin de bande passante à destination du dispositif de communication suivant sur ledit chemin, il est adapté à transmettre une information représentative dudit chemin. 28. Dispositif de communication selon l'une quelconque des revendications 20 à 27, caractérisé en ce qu'il est adapté à faire suivre à l'information représentative dudit besoin de bande passante un arbre de recouvrement du réseau dont au moins la moitié des feuilles sont des dispositifs de communication intermédiaires ou le dispositif de communication destinataire, sur le chemin associé à la connexion. 29. Dispositif de communication selon l'une quelconque des revendications 20 à 28, caractérisé en ce qu'il est adapté à diffuser, avec l'information représentative dudit besoin de bande passante, une information représentative de l'intégralité du chemin associé à ladite connexion. 30. Dispositif de communication selon l'une quelconque des revendications 20 à 29, caractérisé en ce que ladite mémoire est adaptée à conserver, dans chaque table de charge, pour chaque lien du réseau, une référence concernant chaque chemin qui comporte ledit lien et qui est associé à une connexion. 31. Dispositif de communication selon la revendication 30, caractérisé en ce que ladite mémoire est adaptée à conserver, dans ladite table de charge, pour chaque lien du réseau, une information représentative de la bande passante disponible sur ledit lien. 32. Dispositif de communication selon l'une quelconque des revendications 20 à 31, caractérisé en ce que ladite mémoire est adaptée à conserver, dans chaque table de charge, pour chaque chemin, une référence concernant chaque lien qu'il comporte. 33. Dispositif de communication selon la revendication 32, caractérisé en ce que ladite mémoire est adaptée à conserver, dans chaque table de charge, associée à chaque chemin, une information représentative de la bande passante disponible sur ledit chemin. 34. Dispositif de communication selon les revendications 31 et 33, caractérisé en ce que ladite mémoire est adaptée à conserver, dans chaque table de charge, une information représentative de bande passante disponible sur ledit chemin égale à l'information de bande passante disponible sur le lien le moins disponible dudit chemin. 35. Dispositif de communication selon l'une quelconque des revendications 32 à 34, caractérisé en ce qu'il est adapté, pour déterminer une chemin, à choisir le chemin dont la disponibilité est la plus élevée. 36. Dispositif de communication selon l'une quelconque des revendications 20 à 35, caractérisé en ce qu'il comporte un moyen de détermination de taille du paquets à transmettre sur le réseau adapté à prendre en compte la charge sur ledit réseau. 37. Dispositif de communication selon l'une quelconque des revendications 20 à 36, caractérisé en ce qu'il comporte un moyen de détermination de fréquence d'émission de paquets à transmettre sur le réseau adapté à prendre en compte la charge sur ledit réseau. 38. Dispositif selon l'une quelconque des revendications 20 à 37, caractérisé en ce qu'il est adapté à effectuer chaque transmission d'information par commutation de paquet. 39. Dispositif de communication selon l'une quelconque des revendications 20 à 38, sur un réseau comportant des dispositifs de communication susceptibles, chacun, de déterminer le chemin à faire suivre à chaque information qu'il a à transmettre, caractérisé en ce qu'il est adapté, lorsqu'il a besoin d'une connexion associée à un chemin, pour effectuer une transmission d'information à destination d'un dispositif de communication destinataire: - à faire transmettre, par le moyen de transmission, à destination de chaque dispositif de communication dudit chemin, un message de demande d'établissement de connexion, et - à réception d'un message d'acceptation de connexion en provenance du dispositif de communication destinataire, à faire diffuser, par ledit moyen de transmission, à tous les dispositifs de communication du réseau, un message d'information d'établissement de la connexion. 40. Ordinateur, caractérisé en ce qu'il comporte un dispositif de communication selon l'une quelconque des revendications 20 à 39 41. Caméra, caractérisée en ce qu'elle comporte un dispositif de communication selon l'une quelconque des revendications 20 à 39. 42. Télécopieur, caractérisé en ce qu'il comporte un dispositif de communication selon l'une quelconque des revendications 20 à 39. 43. Appareil photographique, caractérisé en ce qu'il comporte un dispositif de communication selon l'une quelconque des revendications 20 à 39. 44. Téléviseur, caractérisé en ce qu'il comporte un dispositif de communication selon l'une quelconque des revendications 20 à 39. 45. Imprimante, caractérisée en ce qu'elle comporte un dispositif de communication selon l'une quelconque des revendications 20 à 39. 46. Scanner, caractérisé en ce qu'il comporte un dispositif de communication selon l'une quelconque des revendications 20 à 39. 47. Lecteur audio/vidéo, caractérisé en ce qu'il comporte un dispositif de communication selon l'une quelconque des revendications 20 à 39.