FR2780838A1 - Procede et dispositif de communication d'information - Google Patents

Abstract

Le procédé de l'invention s'applique à la communication entre des dispositifs de communication qui déterminent le chemin à la source. Il comporte :- pour chaque dispositif source, qui a besoin d'une connexion associée à un chemin, pour effectuer une transmission d'information à destination d'un dispositif destinataire, une demande d'établissement de connexion à destination de chaque dispositif dudit chemin (251),- lorsque l'établissement de ladite connexion est possible, par au moins le dispositif destinataire, une transmission, à destination du dispositif source d'une acceptation de connexion (252), - par le dispositif source, une diffusion, à tous les dispositifs, d'une information d'établissement de la connexion (253), - par chaque dispositif dudit chemin, à réception de ladite information d'établissement, une confirmation d'établissement, et- par chaque dispositif en dehors dudit chemin, à réception de ladite information d'établissement, une mise en mémoire d'une information représentative de ladite connexion.

Description

La présente invention concerne un procédé et un dispositif de

communication d'information.

Elle s'applique, en particulier, à un réseau a 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, l'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 dispositif de communication 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 I'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 à '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 decrite 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 ressource principale, en l'occurrence le médium de communication. Cette simplicité implique aussi l'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 I'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,042,027 décrit une méthode de communication organisée autour d'un système centralisé pour collecter des

informations de charge sur le réseau afin d'optimiser la sélection des chemins.

Le document US-A-5,347,511 décrit une organisation détaillée des informations de charge sur les liens en fonction des classes de services, ces

informations étant stockées dans une base de données.

Dans les deux cas, le bon fonctionnement de ces méthodes repose sur la validité des informations de charge et donc sur la rapidité de mise à jour de ces informations. Cette mise à jour constitue un objet de la présente invention. L'invention vise à permettre, sur un réseau à commutation de paquets, d'une part, la synchronisation de la mise à jour de tables de charge pour chaque noeud et de l'établissement de cette connexion, et, d'autre part, de limiter

les échanges de messages de contrôle utilisés pour cette synchronisation.

Dans son application à un réseau commuté, la présente invention vise aussi: - à garantir un accès équitable aux ressources du réseau comprenant plusieurs équipements multimédias; - à organiser le transfert de paquets afin que certains de ces paquets traversent le réseau avec un temps de latence inférieur à une valeur maximale garantie; - à garantir, pour un groupe de paquets formant un flux, une valeur de bande passante déterminée; - à privilégier l'émission de certains paquets dont le contenu décrit des messages dits "de contrôle", - à optimiser l'utilisation de la bande passante effective du réseau, - à détecter et à circonvenir les congestions du réseau, et - à affranchir les commutateurs des noeuds intermédiaires de tout

traitement concernant l'organisation du séquencement des paquets.

A cet effet, la présente invention vise un procédé de communication sur un réseau, entre 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 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 de transmission à 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.

Grâce à ces dispositions, la même information, diffusée à tous les dispositifs de communication du réseau sert, d'une part, à confirmer l'établissement de la connexion auprès de tous les dispositifs de communication du réseau qui se trouvent sur le chemin associé à la connexion et, d'autre part, à informer tous les dispositifs de communication qui ne sont pas sur ledit

chemin, de l'établissement de la connexion.

Ainsi, chaque dispositif de communication du réseau est informé de chaque établissement de connexion et peut donc déterminer l'opportunité d'une transmission ou d'une diffusion sur ledit réseau. Des congestions du

réseau peuvent donc être ainsi évités.

La cohérence de l'information du réseau est ainsi renforcée.

Selon des caractéristiques particulières, chaque dispositif de communication dudit chemin effectue, à réception de la demande d'établissement de connexion, une opération de vérification de la possibilité

d'établissement de ladite connexion.

Grâce à ces dispositions, les dispositifs de communication

intermédiaires évitent les congestions du réseau.

Selon d'autres caractéristiques particulières, chaque dispositif de communication dudit chemin, lorsque, au cours de l'opération de vérification, la possibilité d'établissement de la connexion a été vérifiée, effectue une opération

de réservation de ressources nécessaires à ladite connexion.

Grâce à ces dispositions, ces ressources sont réservées jusqu'à ce que, à réception de l'information diffusée par le dispositif de communication

source, la connexion soit prise en compte.

Ainsi, des risques de conflit d'établissement de connexion sont

évités même si l'établissement d'une connexion n'a pas encore été confirmé.

Selon d'autres caractéristiques particulières, chaque dispositif de communication dudit chemin, lorsque, au cours de l'opération de vérification, la possibilité d'établissement de la connexion n'est pas vérifiée, effectue une opération de transmission, à destination du dispositif de communication source d'une information représentative de l'impossibilité de la mise en place de la

connexion par ledit dispositif de communication intermédiaire.

Grâce à ces dispositions, dès que l'établissement de la connexion envisagée s'avère impossible sur le chemin envisagé, le dispositif de

communication source en est informé.

Selon d'autres caractéristiques particulières, lorsque l'établissement de ladite connexion est possible, I'opération de transmission, à destination du dispositif de communication source, d'une information représentative d'une acceptation de connexion, est effectuée uniquement par le

dispositif de communication destinataire.

Grâce à ces dispositions, I'information représentative d'acceptation de connexion peut être émis par le dispositif de communication

destinataire selon tout mode de transmission, et sur tout chemin du réseau.

Ceci améliore l'efficacité de l'établissement de la connexion et supprime le traitement d'une information d'acceptation de connexion dans

chacun des dispositifs de communication intermédiaires.

Selon d'autres caractéristiques particulières, pour transmettre ladite information représentative d'une acceptation de connexion, le dispositif de communication destinataire effectue une opération de choix de chemin

indépendant du chemin associé à la connexion en cours d'établissement.

Ainsi, le chemin le moins chargé peut être choisi et l'efficacité de

l'établissement de la connexion peut être améliorée.

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 chaque dispositif de communication du réseau, une opération de mise à jour d'une table de charge contenant des informations représentatives de charges de liens du réseau incorporés dans un chemin

associé à une connexion.

Grâce à ces dispositions, chaque dispositif de communication possède une table de charge qui lui permet de déterminer la disponibilité de chaque lien ou de chaque chemin du réseau, soit pour les transmissions d'information qu'il pourrait avoir à effectuer soit à titre de dispositif de

communication intermédiaire ou de dispositif de communication destinataire.

Ainsi, la quantité d'information à traiter est limitée à celle qui correspond aux connexions valides. Selon d'autres caractéristiques particulières, I'opération de diffusion, à tous les dispositifs de communication du réseau, d'une information représentative de l'établissement de la connexion, opération effectuée par le dispositif de communication source, est effectuée sur 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.

Ainsi, on fait en sorte que l'opération d'information précède aussi souvent que possible l'opération de confirmation qui, dans ce cas, n'aura pas lieu si un dysfonctionnement du réseau intervient dans un dispositif de communication qui n'est pas sur le chemin associé à la connexion en cours d'établissement. Ainsi, certains problèmes de fonctionnement du réseau

peuvent être détectés.

Selon des caractéristiques particulières, la demande d'établissement de connexion émise par le dispositif de communication source comporte une information représentative du service requis pour la transmission

en mode connecté associée à ladite connexion.

Grâce à ces dispositions, chaque dispositif de communication peut

déterminer les paramètres de transmission qui dépendent du service requis.

Selon un deuxième aspect, la présente invention vise un dispositif de communication 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 à un moyen de transmission, a destination de chaque dispositif de communication dudit chemin, une information de demande d'établissement de connexion, et - à réception d'une information 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,

une information d'établissement de la connexion.

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'informations é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 a 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 , I'équipement 101 est un noeud "source", l'équipement 105 est un noeud "destinataire", I'é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 portsphysiques 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 sont reliés aux deux ports internes du composant commutateur/routeur 209 et sont, chacun, basés sur un composant référencé ST C101 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. ls 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.

u2780838

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 "userdata" 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 1 1).

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_inc'.

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 "cafllRequest_nack", 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 "connect_cfr", 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 "sendisoData_req" et de confirmation

d'émission du message de données "sendisoData_cff'.

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 "sendlsoData_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

"release_req" au moyen de communication du noeud source.

Le moyen de communication du noeud source émet alors: - un message de confirmation de relâchement "release_cftr" à 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 "sendSyncData_ind'. 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_cf?'. 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 "sendAsyncData_cfr'. 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 "connectreq" 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 "connectcf?' négatif) de communication à destination du moyen de traitement du noeud source. Ce message de refus "connect_cf?' 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 "releaseback", 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 "openCall_nack", 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 "openCail ack", correspondant à un message "connect cf" 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 "caliTerminate", "release_incd"' 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 "alarm_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_cfr", 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 à

I'é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 "releaseback", à 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

"LinkTabLoad", 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 "LinkTabLoad" 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", l'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 "releaseback" à 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 "cncAckWaif' 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 "setUp_end" 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 des paramè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 inc"', 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 "caliReq_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 "callReqack", 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 "cncAckWair' 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 "cncAckWaif', 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 à 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 "LinkTabLoad" 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 "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 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 a la gestion de la connexion sont libérées.

On observe ici que le message 253 "LinkTabLoaa' 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 "LinkTabLoadc' 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 "LinkTabLoac' 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 a 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", "LinkTabLoacd"', "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 a 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 (1011, 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 spec_CPmax 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_CPF' 1112 durant l'intervalle de temps primaire considéré; - une information représentative de la durée "specCT"' 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 "dynCPF' 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 "VCstate" 1119 représentative de l'état dans lequel se trouve le canal virtuel, "libre", "actif' ou "endorm' (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_CP" 1112 - une information "spec_CPmax" 1116 représentative de la valeur maximale du nombre de paquets à émettre "spec CPF' 1112, ceci afin de permettre de diminuer la valeur de "spec _CP' 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

spec_CPmax 1116.

Enfin, chaque ligne, ou niveau de priorité, est affectée d'une information "priostate" 1120 représentative de l'état dans lequel se trouve l'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, l'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 "dyn_CP" 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 "specCP" 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 "dyn_CP" 1117 est incrémentée de la valeur de l'information "specCP'" 1112, - la valeur de l'information "dynCr' 1118 est incrémentée de la valeur de l'information "specCr' 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 temps secondaire 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 à 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é: - 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 "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

"prio_state" 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 I'émission du paquet considéré: - l'information "dyn_CP" 1117 est décrémentée, - si l'information "dyn_CP' 1117 est égale a zéro, la valeur de l'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

"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 "dyn_CF" 1117 est égale à zéro, la valeur de I'information "VCstate" 1119 prend la valeur "endorm?' 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, I'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 "spec_CP" 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 a 1113 pour le trafic connecté et 1111, 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é.

Claims (37)

REVENDICATIONS

1. Procédé de communication sur un réseau, entre 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 comporte: - effectuée par chaque dispositif de communication dit "source" (801), qui a besoin d'une connexion associée à un chemin, pour effectuer une transmission d'information à destination d'un dispositif de communication destinataire (802), une opération de demande de connexion (305), au cours de laquelle, le dispositif de communication source transmet, à destination de chaque dispositif de communication dudit chemin, une demande d'établissement de connexion (251), - lorsque l'établissement de ladite connexion est possible, effectuée par au moins le dispositif de communication destinataire, une opération de transmission (381), à destination du dispositif de communication source d'une acceptation de connexion (252), - effectuée par le dispositif de communication source, une opération de diffusion (313), à tous les dispositifs de communication du réseau, d'une information représentative de l'établissement de la connexion (253), - effectuée par chaque dispositif de communication dudit chemin (803, 804), à réception de ladite information représentative d'établissement de connexion, une opération de confirmation d'établissement (345) de ladite connexion, et - effectuée par chaque dispositif de communication en dehors dudit chemin (805 à 809), à 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 (418).

2. Procédé de communication selon la revendication 1, caractérisé en ce que chaque dispositif de communication dudit chemin (803, 804) effectue, à réception de la demande d'établissement de connexion (251), une opération

de vérification de la possibilité d'établissement de ladite connexion (1404).

3. Procédé de communication selon la revendication 2, caractérisé en ce que chaque dispositif de communication dudit chemin (803, 804), lorsque, au cours de l'opération de vérification (1404), la possibilité d'établissement de la connexion a été vérifiée, effectue une opération de réservation de ressources

nécessaires à ladite connexion (1407).

4. Procédé de communication selon la revendication 2, caractérisé en ce que chaque dispositif de communication dudit chemin (803,804), lorsque, au cours de l'opération de vérification (1404), la possibilité d'établissement de la connexion n'est pas vérifiée, effectue une opération de transmission (380), à destination du dispositif de communication source (801) d'une information représentative de l'impossibilité de la mise en place de la connexion par ledit

dispositif de communication intermédiaire.

5. Procédé de communication selon l'une quelconque des

revendications 1 à 4, caractérisé en ce que, lorsque l'établissement de ladite

connexion est possible, I'opération de transmission (381), à destination du dispositif de communication source, d'une information (252) représentative d'une acceptation de connexion, est effectuée uniquement par le dispositif de

communication destinataire (802).

6. Procédé de communication selon la revendication 5, caractérisé en ce que, pour transmettre ladite information représentative d'une acceptation de connexion (252), le dispositif de communication destinataire (802) effectue une opération de choix de chemin indépendant du chemin associé à la

connexion en cours d'établissement.

7. Procédé de communication selon l'une quelconque des

revendications 1 à 6, caractérisé en ce qu'il comporte, au cours de

l'établissement d'une connexion, effectué par chaque dispositif de communication du réseau (801 à 809), une opération de mise à jour d'une table de charge contenant des informations représentatives de charges de liens du

réseau incorporés dans un chemin associé à une connexion.

8. Procédé de communication selon la revendication 7, caractérisé en ce que, pour les dispositifs de communication du réseau intermédiaires (803, 804) et destinataire (802), l'opération de mise à jour de la table de charge est

effectuée à réception de la demande d'établissement de connexion (251).

9. Procédé de communication selon la revendication 8, caractérisé en ce que, pour les dispositifs de communication du réseau situés en dehors du chemin associé à la connexion en cours d'établissement (805 à 809), l'opération de mise à jour de la table de charge est effectuée à réception de

l'information représentative d'établissement de connexion.

10. Procédé de communication selon l'une quelconque des

revendications 1 à 9, caractérisé en ce que l'opération de diffusion (313), à tous

les dispositifs de communication du réseau (802 à 809), d'une information représentative de l'établissement de la connexion, opération effectuée par le dispositif de communication source (801), est effectuée sur 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.

11. Procédé de communication selon l'une quelconque des

revendications 1 à 10, caractérisé en ce que la demande d'établissement de

connexion (251), émise par le dispositif de communication source (801), comporte une information représentative du service requis pour la transmission

en mode connecté associée à ladite connexion.

12. Procédé de communication selon l'une quelconque des

revendications 1 à 11, caractérisé en ce que la demande d'établissement de

connexion (251), émise par le dispositif de communication source (801), comporte une information représentative du chemin associé à la connexion en

cours d'établissement.

13. Procédé de communication selon l'une quelconque des

revendications 1 à 12, caractérisé en ce que chaque dispositif de

communication (801 à 809) effectue chaque transmission d'information par

commutation de paquet.

14. Dispositif de communication sur un réseau comportant des dispositifs de communication (801 à 809) 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 à un moyen de transmission, à destination de chaque dispositif de communication (802 à 804) dudit chemin, une information de demande d'établissement de connexion (251), et - à réception d'une information d'acceptation de connexion (252) en provenance du dispositif de communication destinataire, à faire diffuser, par ledit moyen de transmission, à tous les dispositifs de communication du réseau

(802 à 809), une information d'établissement de la connexion (253).

15. Dispositif de communication selon la revendication 14, caractérisé en ce qu'il est adapté, lorsqu'il est le dispositif de communication destinataire (802) d'une demande d'établissement de connexion (251), à déterminer si l'établissement de ladite connexion est possible et, dans ce cas, à faire transmettre, au moyen de transmission, à destination du dispositif de

communication source (801), une information d'acceptation de connexion (252).

16. Dispositif de communication selon l'une quelconque des

revendications 14 ou 15, caractérisé en ce qu'il est adapté, lorsqu'il reçoit une

information d'établissement de la connexion (251) et qu'il est situé sur le chemin associé à la connexion en cours d'établissement, à confirmer l'établissement de

ladite connexion.

17. Dispositif de communication selon l'une quelconque des

revendications 14 à 16, caractérisé en ce qu'il est adapté, lorsqu'il reçoit une

information d'établissement de la connexion (253) et qu'il n'est pas situé sur le chemin associé à la connexion en cours d'établissement, à stocker en mémoire

une information représentative de ladite connexion.

18. Dispositif de communication selon l'une quelconque des

revendications 14 à 17, caractérisé en ce qu'il est adapté, lorsqu'il est un

dispositif de communication d'un chemin associé à une connexion en cours d'établissement (802 à 804), à vérifier la possibilité d'établissement de ladite connexion (1404), à réception de la demande d'établissement de connexion

(251).

19. Dispositif de communication selon la revendication 18, caractérisé en ce que, après avoir vérifier la possibilité d'établissement de la connexion (1404), ledit dispositif de communication (802 à 804) est adapté à réserver les ressources dont il dispose et qui sont nécessaires à ladite connexion.

20. Dispositif de communication selon la revendication 18, caractérisé en ce qu'il est adapté, lorsque la possibilité d'établissement de la connexion n'est pas vérifiée, à faire transmettre au moyen de transmission, à destination du dispositif de communication source (801), une information représentative de l'impossibilité de la mise en place de la connexion par ledit

dispositif de communication intermédiaire.

21. Dispositif de communication selon l'une quelconque des

revendications 14 à 20, caractérisé en ce que, lorsque l'établissement de ladite

connexion est possible, il est adapté à ne faire transmettre au moyen de transmission, à destination du dispositif de communication source (801), l'information représentative d'une acceptation de connexion (252), uniquement

lorsqu'il est dispositif de communication destinataire (802).

22. Dispositif de communication selon la revendication 21, caractérisé en ce que, pour faire transmettre ladite information représentative d'une acceptation de connexion (252), le dispositif de communication destinataire (802) est adapté à choisir un chemin indépendamment du chemin

associé à la connexion en cours d'établissement.

23. Dispositif de communication selon l'une quelconque des

revendications 14 à 22, caractérisé en ce qu'il comporte une mémoire (204A)

adaptée à conserver une table de charge contenant des informations représentatives de charges de liens du réseau incorporés dans un chemin associé à une connexion et en ce qu'il est adapté à mettre à jour ladite table de charge.

24. Dispositif de communication selon la revendication 23, caractérisé en ce qu'il est adapté, lorsqu'il est dispositif de communication intermédiaire (803, 804) ou destinataire (802), à mettre à jour la table de charge

à réception de la demande d'établissement de connexion (251).

25. Dispositif de communication selon la revendication 24, caractérisé en ce qu'il est adapté, lorsqu'il est situé en dehors du chemin associé à la connexion en cours d'établissement, à mettre à jour la table de charge à réception de l'information représentative d'établissement de connexion

(253).

26. Dispositif de communication selon l'une quelconque des

revendications 14 à 25, caractérisé en ce qu'il est adapté à faire diffuser, par le

moyen de transmission, à destination de tous les dispositifs de communication du réseau (802 à 809), une information représentative de l'établissement de la connexion (253), en faisant suivre, à cette information, 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.

27. Dispositif de communication selon l'une quelconque des

revendications 14 à 26, caractérisé en ce qu'il est adapté à ce que la demande

d'établissement de connexion (251), émise par le dispositif de communication source (801), comporte une information représentative du service requis pour la

transmission en mode connecté associée à ladite connexion.

28. Dispositif de communication selon l'une quelconque des

revendications 14 à 27, caractérisé en ce qu'il est adapté à ce que la demande

d'établissement de connexion (251), émise par le dispositif de communication source (801), comporte une information représentative du chemin associé à la

connexion en cours d'établissement.

29. Dispositif de communication selon l'une quelconque des

revendications 14 à 28, caractérisé en ce qu'il est adapté à fonctionner sur un

réseau à commutation de paquet.

30. Ordinateur, caractérisé en ce qu'il comporte un dispositif de

communication selon l'une quelconque des revendications 14 à 29

31. Caméra, caractérisée en ce qu'elle comporte un dispositif de

communication selon l'une quelconque des revendications 14 à 29.

32. Télécopieur, caractérisé en ce qu'il comporte un dispositif de

communication selon l'une quelconque des revendications 14 à 29.

33. Appareil photographique, caractérisé en ce qu'il comporte un

dispositif de communication selon l'une quelconque des revendications 14 à 29.

34. Téléviseur, caractérisé en ce qu'il comporte un dispositif de

communication selon l'une quelconque des revendications 14 à 29.

35. Imprimante, caractérisée en ce qu'elle comporte un dispositif

de communication selon l'une quelconque des revendications 14 à 29.

36. Scanner, caractérisé en ce qu'il comporte un dispositif de

communication selon l'une quelconque des revendications 14 à 29.

37. Lecteur audio/vidéo, caractérisé en ce qu'il comporte un

dispositif de communication selon l'une quelconque des revendications 14 à 29.