FR2794918A1 - Procede et dispositif d'emission, de traitement et de reception d'un paquet de donnees dans un reseau de communication - Google Patents

Abstract

L'invention est relative à un procédé de traitement d'un paquet de données dans un réseau de communication comportant deux ponts dits d'extrémités séparés l'un de l'autre par au moins un pont dit intermédiaire, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit procédé comporte les étapes suivantes :- recevoir ledit paquet de données par un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru par ledit paquet contient un nombre maximum d'informations d'identification dudit chemin et/ ou le champ d'informations d'identification du chemin à parcourir par ledit paquet est vide,- faire intervenir, d'une part, une première zone mémoire (1265; 1314) dans ledit pont relais et qui comporte un champ d'informations d'identification d'un chemin entre ledit pont relais et un autre pont et, d'autre part, au moins un index (b1, f1) dans le paquet de données et qui permet de retrouver ladite zone mémoire dans ledit pont relais.

Description

La présente invention concerne un procédé et un dispositif de traitement d'un paquet de données dans un réseau de communication comportant deux ponts dits d'extrémités séparés l'un de l'autre par au moins un pont dit intermédiaire, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau.

On connaît des réseaux de communication qui sont formés de plusieurs bus de communication série conformes à la norme IEEE 1394.

Ces bus sont organisés en réseau, c'est-à-dire qu'ils sont reliés entre eux par des équipements ou ensembles d'équipements que l'on nomme des "ponts" ("bridges" en terminologie anglo-saxonne).

Un pont permet de transférer des paquets de données d'une première partie du réseau ou premier sous-réseau vers une deuxième partie du réseau ou deuxième sous-réseau par liaison filaire, optique, radio ou par tout autre type de liaison physique envisageable.

Une partie d'un réseau est également appelée sous-réseau.

Les ponts reliant entre eux des bus de communication série font plus particulièrement l'objet de la norme P1394.1 qui est en cours de discussion.

Dans le cadre de cette norme, un pont comporte plus particulièrement au moins deux équipements d'interconnexion appelés "portals" en terminologie anglo-saxonne et permettant de relier entre eux au moins deux bus de communication série 1394. Un équipement d'interconnexion ou "portal" est un ensemble de ports conformes à la norme 1394 et connectés à un bus de communication série 1394.

Chaque bus de communication série d'un tel réseau relie différents équipements ou périphériques entre eux tels que des imprimantes, ordinateurs, serveurs, scanners, magnétoscopes, décodeurs (connus en terminologie anglo-saxonne sous le terme de "set top box"), téléviseurs, caméras numériques, caméscopes, appareils photographiques numériques...

Ces périphériques sont également appelés noeuds.

Chaque équipement ou périphérique situé sur un bus du réseau peur vouloir communiquer des informations à un autre équipement du réseau situé sur un autre bus du réseau, les deux bus sur lesquels ces équipements sont situés étant séparés par un ou plusieurs ponts.

Ainsi, chacun de ces ponts sera donc amené à transférer de manière sélective ou non les informations échangées entre les deux périphériques depuis l'un des bus connecté à l'un des équipements d'interconnexion ou "portals" dudit pont vers un autre bus disposé de l'autre côté dudit pont et connecté à un autre équipement d'interconnexion ou "portal" de ce même pont.

Chaque bus peut être connecté à plusieurs autres bus par l'intermédiaire de plusieurs ponts différents.

Lorsqu'un équipement d'interconnexion ou "portal" reçoit un paquet de données il doit donc pouvoir identifier si le paquet qu'il reçoit est destiné à un périphérique présent sur son bus ou à un ou plusieurs des équipements d'interconnexion ou "portals" présents sur son bus.

Pour ce faire, les informations véhiculées sur les différents bus du chemin que parcourt le paquet de données doivent indiquer la destination du paquet et chaque équipement d'interconnexion ou "portal" doit être capable d'analyser cette destination pour transmettre les informations au périphérique destinataire.

Dans les réseaux conformes à la norme IEEE-1394, l'adresse de la destination est codée dans l'en-tête du paquet de données dans un premier champ d'informations de longueur fixe et dit d'identification, appelé champ destination, et l'adresse de la source dudit paquet de données est codée dans un deuxième champ d'informations de l'en-tête, dit d'identification et de longueur fixe, appelé champ source. Ces deux champs sont distincts et leur longueur dépend du protocole de communication.

Dans les réseaux conformes à la norme IEEE-1394, le champ destination est par exemple codé sur 16 bits et le champ source également. Ces 16 bits sont séparés en 10 bits réservés au codage de l'identificateur du bus sur lequel se trouve le périphérique destinataire du paquet de données et 6 bits réservés au codage de l'identificateur du périphérique destinataire sur ce bus.

De tels réseaux de transfert de paquets de données nécessitent un équipement centralisé (connu sous le terme "prime portal" en terminologie anglo-saxonne) qui, lors de l'initialisation du réseau, va attribuer un numéro à chaque bus du réseau. Ensuite, après cette étape de numérotation automatique, chaque équipement d'interconnexion ou "portal" de chaque pont va configurer une table de routage qui lui est propre en fonction des différents messages qu'il aura vu passer.

Cette table de routage est par exemple représentée par une succession de bits où chaque bit correspond à un bus du réseau.

Chaque bit sera positionné à la valeur binaire 0 ou 1, 0 si le pont ne doit pas transférer des données destinées à un périphérique présent sur le bus correspondant à ce bit dans la table, et 1 si le pont doit transférer des données destinées à un périphérique présent sur le bus correspondant à ce bit dans la table.

Ces réseaux sont configurés pour pouvoir interconnecter un nombre maximal de 1024 bus. Chaque table de routage doit donc comporter 1023 bits et chaque pont doit donc comporter deux tables de routage de 1023 bits puisque chaque portal est relié à des bus différents et doit donc, de ce fait, posséder sa propre table.

Dans un tel réseau, lorsque le paquet de données arrive dans le pont, celui-ci lit le champ destination placé dans l'en-tête de ce paquet de données et lit sa table de routage afin de déterminer s'il peut transmettre le paquet au bus destinataire, c'est-à-dire si le bit correspondant à ce bus est positionné à "1" dans la table de routage.

On connaît des procédés de transfert de paquets de données tels que celui décrit dans le brevet US 5 442 881, permettant de coder l'en-tête à la source. Le périphérique ou noeud source qui veut émettre un paquet de données connaît le chemin qui le sépare du périphérique destinataire auquel il veut transférer des données. Ce chemin est codé dans un champ de l'en-tête du paquet de données qui comporte toutes les adresses ou identifications des différents nceuds du réseau rencontrés par ledit paquet de données sur son chemin.

Lorsqu'un équipement de ce réseau, chargé du transfert des paquets, reçoit le paquet de données, il décode cet en-tête et transmet le paquet au périphérique destinataire aprés avoir modifié cet en-tête.

On connaît également le brevet US 5 613 069 qui décrit un procédé de transfert de paquets dans un réseau à commutation de paquets, chaque paquet comprenant un champ d'en-tête de longueur variable pour décrire le chemin à parcourir ainsi qu'un champ de fin de paquet de longueur variable pour décrire le chemin parcouru.

Toutefois, ce système s'applique à la commutation de paquets où chaque port d'un commutateur est relié à un seul autre port d'un autre commutateur alors qu'un pont peut être relié à plusieurs autres ponts via un même bus.

Ainsi, une telle solution n'est pas adaptée à être mise en oeuvre dans un réseau du type de ceux présentés ci-dessus, conformes à la norme IEEE 1394. Dans ces réseaux, l'en-tête de chaque paquet de données comporte un champ destination et un champ source, dont 10 bits seulement sont réservés dans chacun d'eux au codage de l'identificateur du bus sur lequel se trouve le périphérique destinataire ou source.

En effet, dans un réseau du type conforme à la norme IEEE 1394, dans le cas où le nombre maximal autorisé de chaque équipement d'interconnexion ou "portal" d'un pont sur un bus est de trois, il faut deux bits pour coder l'adresse ou l'identificateur de chaque équipement d'interconnexion ou "portal" de façon unique.

Le champ destination de l'en-tête des paquets de données peut donc contenir en théorie quatre identificateurs d'équipements d'interconnexion ou "portais" différents.

Le nombre maximal théorique de ponts séparant la source et la destination est donc, dans cet exemple, de quatre.

- Ceci est restrictif et l'on constate que plus le nombre d'équipements d'interconnexion ou "portais" autorisés sur un bus augmente, plus il est nécessaire d'avoir un nombre élevé de bits pour coder l'identificateur de ces équipements d'interconnexion ou "portais" et donc plus la distance maximale entre la source d'un paquet de données et sa destination est faible.

D'une manière générale, il serait par conséquent intéressant de pouvoir augmenter la distance entre la source et la destination d'un paquet de données lorsque le champ dudit paquet qui est réservé à l'identification du chemin de ce paquet dans le réseau a une taille limitée.

La présente invention vise ainsi à remédier à ce problème en proposant un procédé de traitement d'un paquet de données dans un réseau de communication comportant deux ponts dits d'extrémités séparés l'un de l'autre par au moins un pont dit intermédiaire, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit procédé comporte les étapes suivantes - recevoir ledit paquet de données par un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru par ledit paquet contient un nombre maximum d'informations d'identification dudit chemin et/ou le champ d'informations d'identification du chemin à parcourir par ledit paquet est vide, - faire intervenir, d'une part, une première zone mémoire dans ledit pont relais et qui comporte un champ d'informations d'identification d'un chemin entre ledit pont relais et un autre pont et, d'autre part, au moins un index dans le paquet de données et qui permet de retrouver ladite zone mémoire dans ledit pont relais.

Corrélativement, l'invention vise un dispositif de traitement d'un paquet de données dans un réseau de communication comportant deux ponts dits d'extrémités séparés l'un de l'autre par au moins un pont dit intermédiaire, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit dispositif comporte les étapes suivantes - recevoir ledit paquet de données par un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru par ledit paquet contient un nombre maximum d'informations d'identification dudit chemin et/ou le champ d'informations d'identification du chemin à parcourir par ledit paquet est vide, - faire intervenir, d'une part, une première zone mémoire dans ledit pont relais et qui comporte un champ d'informations d'identification d'un chemin entre ledit pont relais et un autre pont et, d'autre part, au moins un index b1,f1 dans le paquet de données et qui permet de retrouver ladite zone mémoire dans ledit pont relais.

Il convient de noter qu'un pont relais est défini différemment selon que le paquet est un paquet de diffusion, un paquet de réponse à un paquet de diffusion ou bien un paquet asynchrone.

En effet, si le paquet est un paquet de diffusion alors il n'existe pas encore de chemin établi pour le paquet et un pont relais est défini comme étant un pont au niveau duquel le chemin parcouru par ledit paquet contient un nombre maximum d'informations d'identification dudit chemin.

Ceci signifie soit que le chemin parcouru par le paquet, lorsque ce dernier est arrivé au niveau du pont considéré, occupe en totalité la longueur prédéterminée du champ d'informations d'identification, soit que l'espace restant disponible dans ledit champ pour coder un nouvel identificateur de routage d'un pont n'est plus suffisant. En revanche, si le paquet est un paquet de réponse à un paquet de diffusion ou bien un paquet asynchrone, il existe un chemin établi (au moins dans un sens du parcours) pour le paquet dans le réseau et un pont relais est alors défini comme étant un pont au niveau duquel le chemin à parcourir par ledit paquet est vide.

Par ailleurs, le stockage et la gestion des index et des zones mémoires référencées par ces index sont effectués au niveau des ponts relais et ne sont donc pas centralisés. Ceci permet notamment de répartir dans tous les ponts relais la capacité mémoire nécessaire.

L'invention permet d'augmenter la distance entre la source et la destination d'un paquet de données. _ En outre, cet avantage est également obtenu indépendamment du nombre de ponts connectés à chaque partie du réseau, chaque partie étant par exemple un bus de communication.

Selon un premier mode de réalisation de l'invention, le procédé comporte les étapes suivantes - allocation de ladite zone mémoire et récupération dudit index b1 , - écriture dans ladite zone mémoire des informations d'identification du chemin parcouru par le paquet depuis l'autre pont jusqu'audit pont relais , - écriture dudit index dans le paquet.

Selon une caractéristique, le procédé comporte une étape d'écriture dans ladite zone mémoire d'un autre index b0 permettant de retrouver ultérieurement dans l'autre pont appelé également pont relais une zone mémoire comportant des informations d'identification du chemin parcouru par le paquet pour parvenir jusqu'à cet autre pont relais .

Selon une caractéristique, le procédé comporte une étape d'utilisation de l'index b1 écrit dans le paquet pour retrouver dans ledit pont relais les informations d'identification du chemin à parcourir par ledit paquet depuis ledit pont relais jusqu'à l'autre pont . Selon une caractéristique, l'étape d'utilisation de l'index b1 écrit dans le paquet permet également de retrouver l'index b0 qui sera utilisé ultérieurement dans l'autre pont pour retrouver la zone mémoire comportant des informations d'identification du chemin à parcourir à partir de cet autre pont.

Selon une caractéristique, le procédé comporte une étape d'écriture de l'index b0 dans le paquet à la place de l'index b1.

Selon une caractéristique, le procédé comporte une étape d'écriture, dans le paquet, d'informations d'identification du chemin à parcourir à la place d'informations d'identification du chemin parcouru.

Selon une caractéristique, le procédé comporte les étapes suivantes allocation d'une deuxième zone mémoire dans ledit pont relais référencé par un autre index f2 donné, _ - écriture dans ladite deuxième zone mémoire d'informations d'identification du chemin parcouru par le paquet depuis l'autre pont jusqu'audit pont relais, - écriture dudit index f2 dans le paquet.

Selon un deuxième mode de réalisation, le procédé comporte une étape d'écriture dans la deuxième zone mémoire du pont relais d'un index b2 permettant de retrouver ultérieurement dans l'autre pont une zone mémoire comportant des informations d'identification du chemin parcouru par le paquet depuis ledit pont relais jusqu'audit autre pont .

Selon une caractéristique, le procédé comporte une étape d'utilisation de l'index f1 écrit dans le paquet pour retrouver dans la zone mémoire dudit pont relais les informations d'identification du chemin à parcourir depuis ledit pont relais jusqu'à un autre pont.

Selon une autre caractéristique, l'étape d'utilisation de l'index f1 écrit dans le paquet permet également de retrouver un deuxième index f2 qui sera utilisé ultérieurement dans l'autre pont appelé pont relais pour retrouver une zone mémoire comportant des informations d'identification du chemin à parcourir à partir de cet autre pont relais.

Selon une caractéristique, le procédé comporte une étape d'écriture de l'index f2 dans le paquet à la place de l'index f1. Selon une caractéristique, ledit paquet de données comporte au moins deux champs d'informations dits d'identification du chemin respectivement à parcourir et parcouru par ledit paquet de données, lesdits au moins deux champs d'informations ayant chacun une longueur donnée, ledit procédé comportant les étapes suivantes lors du transfert dudit paquet de données à travers un pont - suppression d'au moins une première information d'au moins un premier champ d'informations, réduisant ainsi la longueur dudit premier champ d'informations d'une longueur correspondant à celle de ladite première information, - ajout d'au moins une deuxième information dans au moins un deuxième champ d'informations, augmentant ainsi la longueur dudit deuxième champ d'informations d'une longueur correspondant à celle de ladite deuxième information.

Selon une caractéristique particulière, le dispositif de traitement selon l'invention comporte une zone mémoire référencée par un index et comportant, d'une part, des informations d'identification du chemin parcouru par le paquet depuis l'autre pont jusqu'audit pont relais et, d'autre part, un index permettant de retrouver ultérieurement dans ledit autre pont une zone mémoire comportant des informations d'identification du chemin parcouru par le paquet pour parvenir jusqu'à cet autre pont.

Selon une autre caractéristique particulière, le dispositif de traitement selon l'invention comporte une zone mémoire référencée par un index comportant, d'une part, des informations d'identification du chemin à parcourir parle paquet depuis ledit pont relais jusqu'à l'autre pont et, d'autre part, un index permettant de retrouver ultérieurement dans cet autre pont des informations d'identification du chemin à parcourir par le paquet depuis cet autre pont jusqu'à un deuxième autre pont.

Selon un deuxième aspect, l'invention vise un procédé d'émission d'un paquet de données dans un réseau de communication entre deux ponts dits d'extrémités séparés l'un de l'autre par plusieurs ponts dits intermédiaires, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit procédé comporte une étape d'émission dudit paquet de données à partir d'un premier pont d'extrémité, ledit au moins un champ contenant des informations d'identification du chemin à parcourir depuis ledit premier pont d'extrémité jusqu'à un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru par ledit paquet contient un nombre maximum d'informations d'identification dudit chemin et/ou le champ d'informations d'identification du chemin à parcourir par ledit paquet est vide, ledit paquet de données comportant également un index permettant de retrouver au niveau dudit pont relais des informations représentatives du chemin à parcourir depuis ledit pont relais jusqu'au deuxième pont d'extrémité.

Corrélativement, l'invention vise un dispositif d'émission d'un paquet de données dans un réseau de communication entre deux ponts dits d'extrémités séparés l'un de l'autre par plusieurs ponts dits intermédiaires, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit dispositif comporte des moyens d'émission dudit paquet de données à partir d'un premier pont d'extrémité, ledit au moins un champ contenant des informations d'identification du chemin à parcourir depuis ledit premier pont d'extrémité jusqu'à un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru contient un nombre maximum d'informations d'identification dudit chemin et/ou le champ d'informations d'identification du chemin à parcourir est vide, ledit paquet de données comportant également un index permettant de retrouver au niveau dudit pont relais des informations représentatives du chemin à parcourir depuis ledit pont relais jusqu'au deuxième pont d'extrémité.

Selon un troisième aspect, l'invention vise un procédé de réception d'un paquet de données émis sur un réseau de communication entre deux ponts dits d'extrémités séparés l'un de l'autre par plusieurs ponts dits intermédiaires, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit procédé comporte une étape de réception au niveau d'un premier pont d'extrémité dudit paquet de données émis par un deuxième pont d'extrémité, ledit au moins un champ contenant des informations d'identification du chemin parcouru depuis un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru par ledit paquet contient un nombre maximum d'informations d'identification dudit chemin et/ou le champ d'informations d'identification du chemin à parcourir par ledit paquet est vide, ledit paquet comportant également un index permettant de retrouver. au niveau dudit pont relais des informations représentatives du chemin parcouru depuis le deuxième pont jusqu'audit pont relais.

Corrélativement, l'invention vise un dispositif de réception d'un paquet de données émis sur un réseau de communication entre deux ponts dits d'extrémités séparés l'un de l'autre par plusieurs ponts dits intermédiaires, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit dispositif comporte des moyens de réception au niveau d'un premier pont d'extrémité dudit paquet de données émis par un deuxième pont d'extrémité, ledit au moins un champ contenant des informations d'identification du chemin parcouru depuis un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru contient un nombre maximum d'informations d'identification dudit chemin et/ou le champ d'informations d'identification du chemin à parcourir est vide, ledit paquet comportant également un index permettant de retrouver au niveau dudit pont relais des informations représentatives du chemin parcouru depuis le deuxième pont jusqu'audit pont relais.

Selon un quatrième aspect, l'invention vise un pont relais d'un réseau de communication disposé entre deux ponts dits d'extrémités et interconnectant au moins deux parties dudit réseau de communication, caractérisé en ce que ledit pont comporte un dispositif de traitement d'un paquet de données conforme à ce qui précède.

Selon un cinquième aspect, l'invention vise un pont d'extrémité d'un réseau de communication interconnectant au moins deux parties dudit réseau de communication, caractérisé en ce qu'il comporte un dispositif d'émission et/ou un dispositif de réception d'un paquet de données comme exposé ci-dessus.

Selon un sixième aspect, l'invention vise un appareil de traitement de données, caractérisé en ce qu'il comporte un dispositif de traitement d'un paquet de données conforme au bref exposé qui précède.

Selon un septième aspect, l'invention _ vise un appareil de traitement de données, caractérisé en ce qu'il comporte un dispositif d'émission et/ou un dispositif de réception d'un paquet de données comme exposé ci- dessus.

Selon un huitième aspect, l'invention vise un appareil de traitement de données, caractérisé en ce qu'il comporte un pont conforme à ce qui précède.

L'appareil de traitement est, par exemple, une imprimante. L'appareil de traitement est, par exemple, un serveur. L'appareil de traitement est, par exemple, un ordinateur. L'appareil de traitement est, par exemple, un télécopieur. L'appareil de traitement est, par exemple, un scanner. L'appareil de traitement est, par exemple, un magnétoscope. L'appareil de traitement est, par exemple, un décodeur (connu en terminologie anglo-saxonne sous le terme de "set top box"). L'appareil de traitement est, par exemple, un téléviseur.

L'appareil de traitement est, par exemple, un caméscope. L'appareil de traitement est, par exemple, une caméra numérique. L'appareil de traitement est, par exemple, un appareil photographique numérique. Selon un neuvième aspect, l'invention vise un réseau de communication comportant au moins deux parties interconnectées par au moins un pont, caractérisé en ce que ledit pont est conforme à ce qui précède.

Selon un dixième aspect, l'invention vise un réseau de communication, caractérisé en ce qu'il comporte un appareil de traitement de données tel qu'exposé ci-dessous.

L'invention vise par ailleurs un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un ordinateur ou un processeur contenant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en ceuvre du procédé de traitement et/ou d'émission et/ou de réception d'un paquet de données tel que brièvement exposé ci-dessus. _ L'invention vise en outre un moyen de stockage d'informations, éventuellement totalement ou partiellement amovible, lisible par un ordinateur ou un processeur contenant des données provenant de la mise en oeuvre du procédé de traitement et/ou d'émission et/ou de réception d'un paquet de données tel que brièvement exposé ci-dessus.

L'invention vise également une interface permettant de recevoir les instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre du procédé de traitement et/ou d'émission et/ou de réception d'un paquet de données tel que brièvement exposé ci-dessus.

L'invention vise en outre un signal comportant des instructions utilisables par un ordinateur et adaptées à configurer un dispositif programmable en un dispositif de traitement et/ou d'émission et/ou de réception d'un paquet de données tel qu'exposé ci-dessus.

L'invention vise par ailleurs un signal comportant des instructions utilisables par un ordinateur et adaptées à faire fonctionner un dispositif programmable pour mettre en couvre un procédé de traitement et/ou d'émission et/ou de réception d'un paquet de données tel qu'exposé ci-dessus.

Les avantages et caractéristiques propres aux procédés et dispositifs d'émission et de réception, au dispositif de traitement d'un paquet de données, au pont interconnectant au moins deux parties d'un réseau et comportant de tels dispositifs, à l'appareil de traitement de données comportant de tels dispositifs, audit réseau comportant un tel pont et audit réseau comportant un tel appareil de traitement de données, ainsi qu'aux moyens de stockage d'informations étant les mêmes que ceux exposés ci-dessus concernant le procédé de traitement d'un paquet de données selon l'invention, ils ne seront pas rappelés ici. D'autres caractéristiques et avantages apparaîtront au cours de la description qui va suivre donnée à titre d'exemple illustratif et non limitatif, et faite en référence aux dessins annexés sur lesquels - la figure 1 est une vue schématique d'un réseau de bus de communication série ; - la figure 2 est une vue schématique représentant la structure d'un paquet de données asynchrone tel que défini dans la norme IEEE 1394 95 ; - la figure 3 est une vue schématique détaillée d'un appareil de traitement de données comportant un pont référencé 66 sur la figure 1 ; - la figure 4 est une vue schématique représentant différents registres stockés dans la mémoire RAM de l'appareil de traitement de données de la figure 3 ; - la figure 5 est une vue schématique illustrant le transfërt d'un paquet de données à travers le pont intermédiaire référencé 66 la figure 1 - la figure 6 est une vue schématique illustrant le transfert d'un paquet de données à travers le pont destinataire référencé 67 sur la figure 1 ; - la figure 7 est une vue schématique illustrant le transfert d'un paquet de données à travers le pont source référencé 67 sur la figure 1 ; - la figure 8 est une vue schématique détaillée représentant une table de routage stockée dans la mémoire RAM de l'appareil de traitement de données de la figure 3 ; - les figures 9 et 10 représentent une vue schématique des algorithmes des procédés, d'une part, de récupération d'un descripteur de chemin à partir d'un index dans la table de routage et, d'autre part, de récupération d'un index à partir d'un descripteur de chemin ; - la figure 11 est une vue schématique de l'algorithme d'un procédé de transfert de paquets ; - la figure 12 est une vue schématique d'un réseau de bus lors de la diffusion d'un paquet de résolution d'adresse d'une part, et de son paquet réponse correspondant d'autre part ; _ - la figure 13 est une vue schématique représentant la structure d'un paquet de données de résolution d'adresse ; - la figure 14 est une vue schématique représentant la structure d'un paquet de données asynchrone de réponse au paquet décrit en figure 13 ; - la figure 15 est une vue schématique détaillée représentant une table de vérification stockée dans la mémoire RAM de la figure 3 ; - la figure 16 est une vue schématique de l'algorithme d'un procédé de réception d'un paquet de résolution d'adresse au niveau d'un équipement d'interconnexion d'un pont ; - la figure 17 est une vue schématique de l'algorithme d'un procédé de réception d'un paquet de données de réponse au paquet de résolution d'adresse au niveau d'un équipement d'interconnexion d'un pont ; - la figure 18 est une vue schématique de l'algorithme d'un procédé de gestion de la longueur des identificateurs ou labels de routage au niveau d'un bus en fonction de la capacité du bus ; - la figure 19 est une vue schématique de l'algorithme d'un procédé de gestion de la longueur des identificateurs ou labels de routage au niveau d'un bus en fonction du nombre de ponts connectés sur le bus, - la figure 20 est une vue schématique représentant un réseau de communication selon l'invention, - la figure 21 illustre de manière schématique le cheminement d'un paquet de résolution d'adresse dans le réseau de communication représenté à la figure 1, - la figure 22 représente un algorithme sur lequel est basé le procédé de traitement d'un paquet de données selon l'invention et qui est mis en oeuvre au niveau d'un pont intermédiaire du réseau représenté à la figure 20, - la figure 23 illustre de manière schématique le cheminement d'un paquet de réponse au paquet de résolution d'adresse représenté à la figure 21 à travers le réseau de la figure 20, - la figure 24 représente un algorithme sur lequel est basé le procédé de traitement d'un paquet de données selon l'invention et qui est mis en oeuvre au niveau d'un pont du réseau de communication représenté à la figure 20, - la figure 25 illustre de manière schématique le cheminement d'un paquet de requête asynchrone à travers le réseau de communication de la figure 20, - la figure 26 représente un algorithme sur lequel est basé le procédé de traitement d'un paquet de données asynchrone selon l'invention et qui est mis en couvre au niveau d'un pont du réseau de communication de la figure 20, - la figure 27 illustre de manière schématique le cheminement d'un paquet de réponse asynchrone à travers le réseau de communication de la figure 20.

La figure 1 représente une vue schématique d'un réseau de bus de communication série dans le cadre duquel s'applique l'invention. Un ensemble de bus de communication série 51, 52, 53, 54, 55, 56, 57, 58 et 59, interconnectés par plusieurs ponts 60, 61, 62, 63, 64, 65, 66 et 67, permettent à des périphériques situés sur des bus différents d'échanger des paquets de données asynchrones.

Ainsi, un périphérique 68, connecté au bus 52, peut initier une transaction avec un périphérique 69 qui, lui, se trouve connecté au bus 59, par échanges de paquets asynchrones. Le transfert de paquets d'un bus à l'autre est assuré par un procédé de transfert de paquets.

La structure d'un paquet asynchrone, largement décrite dans la norme IEEE 1394-95, est illustrée à la figure 2. Les paquets asynchrones sont entre autre utilisés pour effectuer des transactions entre un périphérique source et un périphérique destination. Une transaction est effectuée en émettant un paquet de type "Requête" de la source vers la destination, puis un paquet de type "Réponse" de la destination vers la source.

Le champ "destination ID" 80 de la figure 2 ("Destination Identifier" en terminologie anglo-saxonne), représenté sur 16 bits, contient l'information de routage permettant d'atteindre le périphérique destination. Ce champ est composé de deux sous _ champs 80a "destination Bus ID" représenté sur 10 bits et 80b "destination_Node ID" représenté sur 6 bits.

Le champ 80a est appelé champ d'identification du chemin à parcourir par le paquet de données.

Le champ "source -ID" 81 ("Source Identifier" en terminologie anglo-saxonne), représenté sur 16 bits, contient l'information de routage permettant d'atteindre le périphérique source. Ce champ est composé de deux sous champs 81a "source Bus_ID" représenté sur 10 bits et 81b "sou rce_Node_ID" représenté sur 6 bits.

Le champ 81a est appelé champ d'identification du chemin parcouru par le paquet de données.

La présence de ces deux champs 80 et 81 favorise le déroulement d'une transaction entre la source et la destination.

II convient de noter que les deux champs d'informations d'identification d'un paquet de données ne sont pas nécessairement placés dans l'en-tête dudit paquet, comme c'est la cas dans cet exemple, mais peuvent être situés à l'extrémité opposée de ce paquet, c'est-à-dire en fin de paquet.

Le champ "t1" 82 ("Transaction Label" en terminologie anglo- saxonne), représenté sur 6 bits, permet de numéroter une transaction entre des périphériques. Le champ "rt" 83 ("Retry Code" en terminologie anglo-saxonne), représenté sur 2 bits, permet d'identifier les tentatives d'émission d'un même paquet asynchrone.

Le champ "tcode" 84 ("Transaction Code" en terminologie anglo- saxonne), représenté sur 4 bits, permet d'identifier un type de paquet asynchrone, tel que par exemple le type de la transaction.

Le champ "pri" 85 ("Priority" en terminologie- anglo-saxonne), représenté sur 4 bits, permet d'identifier la priorité associée au paquet asynchrone.

Les champs 86, 87, 88, 89 et 90 sont pour certains optionnels et sont relatifs à l'interprétation des données véhiculées par le paquet asynchrone. La figure 3 représente la structure schématique d'un appareil de traitement de données tel qu'un ordinateur 11 comportant, par exemple, le pont 66 représenté à la figure 1. Ainsi, tous les ponts du réseau représentés à la figure 1 ont par exemple cette structure.

L'appareil de traitement de données pourrait également prendre la forme d'une imprimante, d'un serveur, d'un télécopieur, d'un scanner, d'un magnétoscope, d'un décodeur (connu en terminologie anglo-saxonne sous le terme de "set top box"), d'un téléviseur, d'un caméscope, d'une caméra numérique ou d'un appareil photographique numérique.

Tous les ponts de la figure 1 peuvent être par exemple être intégrés dans un appareil de traitement de données de ce type ou bien constituer l'appareil lui-même.

Le pont constitue, dans cet exemple, un dispositif de transfert de paquets. Ce pont comporte une unité de calcul CPU 12, une mémoire de stockage permanent 14 (ROM) qui contient les différentes- instructions des algorithmes représentés aux figures 9, 10, 11, 16, 17, 18, 19, 23, 24 et une mémoire de stockage temporaire 16 (RAM). Ces trois éléments 12, 14 et 16 communiquent au moyen de bus d'adresses et de données respectifs notés 18, 20, 22, avec un bloc noté 24 et connu de l'homme de l'art sous le nom de pont PCI. L'ordinateur 11 comporte également un écran 13, un clavier 15, un lecteur de disquettes 17, un lecteur de CD-ROM 19 et une interface réseau 21 (figure 3).

L'interface réseau 21 peut recevoir, par exemple, par l'intermédiaire d'un réseau local (non représenté) de type Ethernet les instructions d'un programme informatique permettant la mise en oeuvre du procédé selon l'invention.

De telles instructions peuvent également être contenues dans le lecteur de disquettes ou le lecteur de CD-ROM.

Le bloc 24 est en fait un ensemble de composants PCI tel que l'ensemble Intel 440LX AGP ("Intel 440LX AGPset" dans la terminologie anglo- saxonne) commercialisé par la société INTEL. Ainsi, le bloc 24 comporte, par exemple, un composant 82443LX (non représenté) qui assure l'interface avec la mémoire 16 via le bus mémoire 22 et avec l'unité de calcul CPU 12 via le bus local 18. Le composant 82443LX est lui-même relié à un composant 82371AB (non représenté) qui fournit une interface avec le bus ISA 20 relié à la mémoire 14 et aux différentes extensions de périphériques : écran 13, clavier 15, lecteur de disquette 17, lecteur de CD-ROM 19 et interface de réseau 21. Un contrôleur d'interruption IOAPIC Intel 82093AA (non représenté) connecté à l'unité de calcul CPU 12 gère les interruptions pouvant survenir dans le système.

Ce bloc 24 permet notamment d'échanger des données au moyen du bus standard PCI 26 (PCI signifiant en terminologie anglo-saxonne "Peripheral Component Interconnect") avec un autre composant d'interface PCI noté 28. Le bus 26 peut également connecter entre eux d'autres éléments, non représentés sur la figure, eux-mêmes pourvus d'une interface PCI et pouvant mettre en oeuvre par exemple des fonctions de traitement de données.

Le composant 28 est un composant dénommé AMCC5933QC et est commercialisé par la société Applied Micro Circuits Corporation.

Il convient de noter que le dispositif de transfert de paquets ne correspond pas nécessairement au pont lui-même. II peut ainsi, en effet, en représenter un sous-ensemble formé, par exemple, des différents éléments permettant de mettre en pauvre les fonctions de traitement de l'en-tête d'un paquet de données, de prise en compte d'au moins un identificateur de pont, et de transfert de paquets asynchrones.

Les fonctions de traitement d'en-tête sont mises en ceuvre par l'unité de calcul CPU 12 et les mémoires ROM 14 et RAM 16.

La fonction de transfert d'un paquet asynchrone après traitement de l'en-tête est mise en oeuvre par un bloc logique de contrôle 34 et des composants 30, 32 sur ordre de l'unité de calcul CPU 12.

Le pont 66 représenté à la figure 3 comporte également deux ensembles de composants appelés aussi blocs 30 et 32 servant respectivement d'interfaces avec les bus de communication série 1394, par exemple notés 56 et 58 sur la figure 1. Chaque bloc ou ensemble de composants PHYILINK 1394 est par exemple constitué d'un composant PHY TSB21 LV03A et d'un composant LINK TSB12LV01A commercialisés par la société Texas Instruments et de connecteurs 1394, par exemple commercialisés par la société Molex, par exemple sous la référence 53462.

Le pont 66 comporte deux équipements d'interconnexion du pont qui forment chacun ce que l'on appelle un "portal" en terminologie anglo- saxonne.

Sur la figure 3 les éléments du pont qui sont référencés 12,14,16,18,20,22,24,26,28,34,36,38,40,42 et 44 sont communs à chacun des équipements d'interconnexion ou "portais" de ce pont et seuls les blocs de composants PHYLINK 1394 notés 30 et 32 sont spécifiques respectivement à chaque équipement d'interconnexion.

Toutefois, dans certains cas les équipements d'interconnexion ou "portais" d'un pont sont physiquement éloignés (cas d'une liaison radio) et les autres éléments énoncés ci-dessus sont alors propres à chacun des équipements d'interconnexion.

Le bloc logique de contrôle noté 34 peut respectivement communiquer avec les blocs de composants 30 et 32 au moyen de bus notés 36 et 38, ainsi qu'avec le composant d'interface PCI 28 au moyen d'un bus 40. Des bus 42 et 44 permettent également les transferts de données respectivement entre le composant d'interface PCI 28 et le bloc logique de contrôle 34, ainsi que le bloc de composants PHYILINK 1394 référencé 30, d'une part, et, d'autre part, avec le bloc de contrôle logique 34 et le bloc de composants PHYILINK 1394 référencé 32.

Ce bloc logique de contrôle 34 permet de transmettre des paquets de données isochrones ou asynchrones venant du bus de communication série 56 par l'intermédiaire du bloc de composants PHYILINK 1394 noté 30 qui lui est associé et à destination de la mémoire RAM 16, sous le contrôle de la fonction mémoire à accès direct DMA ("Direct Memory Access" en terminologie anglo- saxonne) qui se trouve dans le composant d'interface PCI 28 et qui aura été préalablement initialisée par l'unité de calcul CPU 12.

Inversement, ce bloc 34 permet également de transmettre des paquets de données isochrones ou asynchrones provenant de la mémoire 16 vers l'autre bloc PHYILINK 1394 noté 32, en vue de sa transmission sur le bus de communication série qui lui est associé. Ceci a également lieu sous le contrôle de la fonction mémoire à accès direct DMA mentionné ci-dessus.

Le bloc logique de contrôle 34 permet en outre de déclencher une interruption PCI par exemple liée à la réception ou à l'émission d'un paquet asynchrone par l'intermédiaire du composant d'interface PCI 28 afin d'informer l'unité de calcul CPU 12. De la même manière, le bloc logique de contrôle 34 est susceptible de générer une interruption PCI pour d'autres types d'événements tels que la réception ou l'émission de tout autre paquet de données sur un bus 1394.

En outre, le bloc logique 34 permet d'accéder aux différents registres des blocs de composants 30 et 32 via le composant d'interface PCI 28.

Le bloc logique de contrôle 34 est un composant de type FPGA ("Field Programmable Gate Array" en terminologie anglo-saxonne) qui est par exemple commercialisé par la société Xilinx. A chaque bloc de composants 30 et 32 sont associés des registres représentés à la figure 4, utilisés pour la mise en oeuvre du procédé de transfert de paquets de données.

Dans la description qui suit, un registre dont le nom est suffixé par " 30" ou "-32" appartient aux blocs respectifs 30 et 32 décrits précédemment en référence à la figure 3.

Un registre 91 dénommé "routing label 30", représenté sur 8 bits, contient un identificateur ou adresse de routage qui identifie les paquets qui devront être transférés du bus 56 vers le bus 58 dans l'exemple du pont 66.

Un registre 92 dénommé "routing width_30", représenté sur 8 bits, est associé au registre 91 et indique le nombre de bits significatifs du registre 91. Les registres 91 et 92 sont associés au bloc de composants 30.

Un registre 93 dénommé "routing label 32", représenté sur 8 bits, contient un identificateur ou adresse de routage qui identifie les paquets qui devront être transférés du bus 58 vers le bus 56 dans l'exemple du pont 66.

Un registre 94 dénommé "routing width 32", représenté sur 8 bits, est associé au registre 93 et indique le nombre de bits significatifs du registre 93. Les registres 93 et 94 sont associés au bloc de composants 32.

Un registre 97 dénommé "max width", représenté par exemple sur 32 bits, contient la valeur maximale que peuvent prendre les registres 92 et 94. Ce registre n'est donc pas associé à un équipement d'interconnexion ou "portal" en particulier. A un instant donné, il contient la même valeur dans chaque pont du réseau considéré.

Dans le mode préféré de réalisation, la valeur des registres 92, 94 et 97 est prédéterminée et égale à "3" pour chaque registre.

Parmi l'ensemble des équipements d'interconnexion ou "portals" connectés à un même bus 1394 la norme P1394.1 prévoit la détermination d'un équipement d'interconnexion particulier appelé "alpha-portal".

Les moyens de détermination de "l'alpha-portal" sont connus et notamment décrits dans le chapitre 4.1 du projet de norme P1394.1 version 0.04, du 7 Février 1999. Ces moyens permettent notamment d'identifier de manière constante et unique les périphériques d'un même bus. Par extension ces moyens permettent aussi d'affecter de la même manière un identificateur ou label de routage constant et unique à chaque équipement d'interconnexion ou "portal" d'un même bus.

II convient de noter que chaque équipement (périphérique, équipement d'interconnexion...) relié à un bus est repéré par un identificateur dit physique et par un identificateur dit virtuel.

La correspondance entre l'identificateur physique et l'identificateur virtuel d'un équipement est établie dans une table de correspondance telle que celle représentée à la figure 21 et sur laquelle on reviendra plus en détail ultérieurement.

La valeur de l'identificateur virtuel d'un équipement connecté à un bus reste constante même si la topologie liée à ce bus est modifiée.

Ainsi, vues de l'extérieur du bus, les valeurs des identificateurs virtuels ne changent pas malgré une modification de la topologie du bus considéré.

Par ailleurs, les équipements d'interconnexion reliés à un bus possèdent également l'identificateur de routage mentionné ci-dessus.

Un identificateur de routage ainsi déterminé, par exemple pour l'équipement d'interconnexion du pont 66 qui est relié au bus 56, est stocké dans le registre 91 et identifie l'équipement d'interconnexion ou "portal" contenant le bloc 30 de la figure 3. De même, un identificateur de routage ainsi déterminé, par exemple pour l'équipement d'interconnexion du pont 66 qui est relié au bus 58, est stocké dans le registre 93 et identifie l'équipement d'interconnexion ou "portal" contenant le bloc 32 de la figure 3.

Un registre 95 dénommé "routing table 30" sur la figure 4, représenté sur 960 bits, représente une table de routage associée à l'équipement d'interconnexion ou "portal" contenant le bloc 30 et est utilisé lors du transfert de paquets émis depuis le bus 56, en ce qui concerne le pont 66.

Un registre 96 dénommé "routing table 32", représenté sur 960 bits, représente une table de routage associée à l'équipement d'interconnexion ou "portal" contenant le bloc 32 et est utilisé lors du transfert de paquets émis depuis le bus 58, en ce qui concerne le pont 66. La structure de cette table de routage est décrite en détail à la figure 8.

Un registre 98 dénommé "portal numbering 30" sur la figure 4 comporte, d'une part, au moins une table de correspondance dont la structure sera décrite ultérieurement en référence à la figure 21 et qui est associée à l'équipement d'interconnexion ou "portal" contenant le bloc 30.

Un registre 99 dénommé "portal numbering 32" sur la figure 4 comporte, d'une part, au moins une table de correspondance dont la structure sera décrite ultérieurement en référence à la figure 21 et qui est associée à l'équipement d'interconnexion ou "portal" contenant le bloc 32. Les registres 91, 92, 93, 94, 95, 96, 97, 98 et 99 représentés à la figure 4, sont situés dans la mémoire RAM 16 du pont 66 représenté à la figure 3.

Un paquet asynchrone, émis par un périphérique source situé sur un bus différent de celui sur lequel est situé le périphérique destinataire, est dit paquet asynchrone "distant", par opposition à un paquet asynchrone local.

En outre, lorsqu'un paquet asynchrone "distant" transite, par exemple depuis le périphérique 68 (figure 1) jusqu'au périphérique 69, via les ponts 61, 62, 64, 66 et 67, différents traitements sont appliqués par chacun de ces ponts en fonction de leur position relative par rapport au périphérique source et au périphérique destinataire.

Ainsi, lorsqu'aucun des équipements d'interconnexion ou "portais" d'un pont considéré n'est connecté ni au bus du périphérique source, ni au bus du périphérique destinataire, le pont est dit pont "intermédiaire". C'est le cas du pont 66 lorsque, par exemple, le périphérique 68 transmet un paquet asynchrone au périphérique 69.

La figure 5 illustre de manière schématique le traitement, qu'effectue le pont 66 en tant que pont "intermédiaire", sur les champs 80 et 81 du paquet asynchrone qu'il transfère depuis le bus 56 vers le bus 58, selon le sens indiqué par la flèche 219.

Le registre 76 est l'équivalent du registre 91 représenté à la figure 4 et a, par exemple, pour valeur "001" en représentation binaire sur 3 bits significatifs.

En outre, le registre 77 est l'équivalent du registre 93 représenté à la figure 4, et a, par exemple, pour valeur "011" en représentation binaire sur 3 bits significatifs. On va maintenant s'intéresser, en référence aux figures 5 et 6, au transfert d'un paquet asynchrone de données noté 199 du bus 56 au périphérique 69 du bus 59.

Le paquet asynchrone de données 199 transite sur le bus 56 et est transféré au bus 58, par le pont 66, après traitement, sous la forme d'un paquet 216. Les paquets asynchrones 199 et 216 sont conformes à la structure de paquet représentée à la figure 2 et ne diffèrent l'un de l'autre que par le contenu de leurs champs respectifs destination 80 et source 81.

Le champ 80 du paquet 199 est décomposé en plusieurs champs notés 200, 201, 202 et 203. Le champ 81 du paquet 199 est lui aussi décomposé en plusieurs champs notés 204, 205, 206, 207 et 208.

Les champs 201 et 202, tous les deux représentés sur 3 bits, contiennent les identificateurs de routage des équipements d'interconnexion ou "portals" à prendre en compte respectivement par les ponts 66 et 67 pour transférer le paquet asynchrone jusqu'au périphérique destinataire 69.

Les champs 208, 207 et 206, représentés chacun sur 3 bits, contiennent les identificateurs de routage des équipements d'interconnexion ou "portals" à prendre en compte respectivement par les ponts 64, 62 et 61 pour transférer un paquet asynchrone en retour jusqu'au périphérique source 68.

Le champ 203, représenté sur 6 bits, contient l'information qui permet au pont 67 d'identifier le périphérique destinataire 69 du paquet asynchrone parmi tous les périphériques du bus 59. De manière générale, il s'agit du champ 80b "destination-NOde-ID" de la figure 2. Le champ 204, représenté sur 6 bits, contient l'information qui permet au pont 61 d'identifier le périphérique source 68 du paquet asynchrone parmi tous les périphériques du bus 52. De manière générale, il s'agit du champ 81b "source_Node_ID" de la figure 2.

Les champs 200 et 205 dont l'ensemble est représenté sur 5 bits qui sont tous positionnés à<B>'T',</B> contiennent un marqueur délimitant les champs 202 et 201, d'une part, des champs 208, 207 et 206, d'autre part.

Les champs 201 et 202 forment ce que l'on appelle un premier champ d'informations et identifient le chemin qui est à parcourir par le paquet de données 199.

Les champs 206, 207 et 208 forment ce que l'on appelle un deuxième champ d'informations et identifient le chemin déjà parcouru par le paquet de données 199.

Les champs 200 et 205 forment ce que l'on appelle un troisième champ d'informations ou marqueur.

Dans le cas du paquet 216 issu du pont 66, le champ 80 comprend les champs 209, 210, 211 et 203 et le champ 81 comprend les champs 212, 213, 214, 215 et 204.

Le champ 211, représenté sur 3 bits, contient l'identificateur de routage à prendre en compte par le pont 67 pour transférer le paquet asynchrone jusqu'au périphérique destinataire 69. II correspond au champ 201 du paquet 199.

Les champs 215, 214 et 213, représentés chacun sur 3 bits, ainsi que les champs 209 et 212, dont l'ensemble est représenté sur 3 bits, contiennent les identificateurs de routage à prendre en compte respectivement par les ponts 66, 64, 62 et 61, pour transférer le paquet asynchrone, en retour, jusqu'au périphérique source 68. Les champs 213 et 214 correspondent respectivement aux champs 207 et 208 du paquet 199. Les champs 209 et 212 correspondent au champ 206 du paquet 199.

Le champ 210, représenté sur 5 bits, qui sont tous positionnés à "1", contient le marqueur délimitant le champ 211, d'une part, des champs 209 à 215, d'autre part. II correspond aux champs 205 et 200 du paquet 199. A la réception du paquet 199, le pont 66 lit et analyse la valeur du champ 202 qu'il compare avec le contenu du registre 76. Puisque les deux valeurs, exprimées sur le même nombre de bits significatifs, sont identiques, le paquet 199 va être transféré du bus 56 au bus 58 sous la forme du paquet 216.

On notera qu'entre le paquet 199 et le paquet 216, le pont 66 a, d'une part, supprimé du premier champ d'informations une première information constituée par les bits "001" appartenant au champ 202 et, d'autre part, ajouté au deuxième champ d'informations une deuxième information constituée par les bits "011" du registre 77 d'identification de l'équipement d'interconnexion ou "portal" considéré.

Sur la figure 5, il convient de noter que, d'une part, la suppression d'une première information (champ 202) du premier champ d'informations réduit la longueur de ce dernier et, d'autre part, l'ajout d'une deuxième information (champ 215) dans le deuxième champ d'informations augmente la longueur de ce dernier.

Cette deuxième information est représentée par le champ 215.

Le procédé de transfert de paquets procède également, après la suppression de la première information et avant l'ajout de la deuxième information, au décalage des premier, deuxième et troisième champs d'informations à l'intérieur des sous-champs 80a et 81a des champs 80 et 81.

Lorsque l'un des équipements d'interconnexion ou "portais" d'un pont est connecté au bus du périphérique destinataire, le pont est dit pont "destination". C'est le cas par exemple du pont 67 de la figure 1 lorsque le périphérique 69 reçoit un paquet asynchrone distant en provenance du périphérique 68.

La figure 6 illustre de manière schématique le traitement, qu'effectue le pont 67 en tant que pont "destination", sur les champs 80 et 81 du paquet asynchrone 216 qu'il transfère depuis le bus 58 vers le bus 59, selon le sens indiqué par la flèche 229.

Le registre 78 illustre, pour le pont 67, le registre 91 représenté à la figure 4 et dont la valeur, sur 3 bits significatifs, est "011" en représentation binaire. Par ailleurs, le registre 79 illustre, pour le pont 67, un registre 93 représenté figure 4 et dont la valeur, sur 3 bits significatifs, est "000" en représentation binaire.

Le paquet asynchrone 216 qui transite sur le bus 58, est transmis sur le bus 59, par le pont 67 après traitement, sous la forme d'un paquet 226. Les paquets asynchrones 216 et 226 sont conformes à la structure de paquet représentée à la figure 2 et ne diffèrent l'un de l'autre que par le contenu de leurs champs respectifs 80 et 81.

Dans le cas du paquet 226, le champ 80 est décomposé en plusieurs champs 220 et 221 et le champ 81 est lui aussi décomposé en plusieurs champs 223, 224 et 204.

Le champ 220, représenté sur 10 bits qui sont tous positionnés à "1", est représentatif d'un paquet asynchrone destiné au bus local et susceptible d'être reçu par l'un des périphériques du bus 59.

Le champ dénommé "offset" et noté 223 est ajouté par le pont 67 alors que le champ 224 contient l'identificateur de routage ou adresse de l'équipement d'interconnexion ou "portal" du pont 67 associé au bus 59 et stocké dans le registre 79.

A la réception du paquet 216, le pont 67 lit et analyse la valeur du champ 211 qu'il compare avec le contenu du registre 78. Puisque les deux valeurs, exprimées sur le même nombre de bits significatifs, sont identiques, le paquet 216 va être transféré du bus 58 au bus 59 sous la forme du paquet 226.

Lors du transfert du paquet 216 à travers le pont 67, ce dernier a supprimé d'un premier champ d'informations qui est formé du champ 211, une première information constituée par les bits "011" du champ 211 lui-même.

Ce premier champ d'informations identifie le chemin restant à parcourir au paquet 216 pour parvenir à destination.

Le pont 67 a ensuite sauvegardé dans la table de routage associée à l'équipement d'interconnexion ou "portal" comprenant le registre 79 un deuxième champ d'informations qui est formé de l'ensemble des champs 209, 212, 213, 214 et 215. Ce deuxième champ d'informations identifie le chemin parcouru par le paquet 216 et ce sera le chemin dit de "retour" qui lui permettra, éventuellement, d'être renvoyé au périphérique source.

Le pont 67 a ensuite renseigné ce deuxième champ d'informations alors formé par le champs 224, une deuxième information constituée par les bits "000" du registre 79 d'identification de l'équipement d'interconnexion ou "portal" considéré.

Le troisième champ d'informations correspond au marqueur noté 210 et précédemment évoqué.

Le procédé de transfert de paquets procède également, après la suppression de la première information et avant l'ajout de la deuxième information, à la sauvegarde du deuxième champ d'information, au stockage de l'index de cette sauvegarde dans le champ 223 et à la mise à "1" de tous les bits du champ 220..

Le champ 203, représenté sur 6 bits, permet au pont "destination" 67, d'identifier le périphérique destinataire 69 du paquet asynchrone parmi tous les périphériques du bus 59. Le champ 203 du paquet 216 a été remplacé, lors du transfert dans le pont 67, par le champ 221 dans le paquet 226. Le champ 221 identifie, par exemple, le périphérique 69 parmi tous les périphériques du bus 59, afin que le paquet 226 soit reçu par le périphérique 69. Le champ 203 contient l'identificateur virtuel du périphérique 69 alors que le champ 221 contient l'identificateur physique du périphérique 69 Le champ 204, représenté sur 6 bits, contient l'information qui permet au pont 61 d'identifier le périphérique source 68 émetteur du paquet asynchrone parmi tous les périphériques du bus 52. Le champ 204 est représentatif de l'identificateur virtuel du périphérique 68.

Lorsque l'un des équipements d'interconnexion ou "portals" d'un pont est connecté au bus du périphérique source le pont est dit pont "source". C'est le cas par exemple du pont 67 de la figure 1 lorsque le périphérique 69 transmet un paquet asynchrone "distant" à destination du périphérique 68, par exemple en réponse au paquet 226. La figure 7 illustre de manière schématique les modifications effectuées par le pont 67 en tant que pont "source", sur les champs 80 et 81 d'un paquet asynchrone qu'il transfère depuis le bus 59 vers le bus 58, selon le sens indiqué par la flèche 230.

Le paquet asynchrone 231 émis sur le bus 59 par le périphérique 69 est transféré sur le bus 58, par le pont 67, après traitement, sous la forme d'un paquet 240. Les paquets asynchrones 231 et 240 sont conformes à la structure de paquet représentée à la figure 2 et ne différent l'un de l'autre que par le contenu de leurs champs respectifs 80 et 81.

Dans le cas du paquet 231, le champ destination 80 est décomposé en plusieurs champs 232, 233 et 234 et le champ source 81 est également décomposé en plusieurs champs 235 et 236.

Le champ dénommé "offset" et noté 232 est utilisé par le pont 67 pour retrouver l'ensemble des identificateurs de routage à prendre en compte, respectivement par les ponts 66, 64, 62 et 61, pour transférer le paquet asynchrone jusqu'au périphérique destinataire 68. Le champ 233 contient l'identificateur de routage du pont 67 associé au bus 59 et stocké dans le registre 79.

Le champ 236, représenté sur 10 bits, qui sont tous positionnés à "1", est représentatif d'un paquet asynchrone émis par le bus local.

Dans le cas du paquet 240, le champ destination 80 est décomposé en plusieurs champs 241, 242, 243, 244 et 234 et le champ source 81 est également décomposé en plusieurs champs 246, 247, 248 et 249.

Les champs 244, 243 et 242, représentés chacun sur 3 bits, ainsi que les champs 241 et 246, dont l'ensemble est représenté sur 3 bits, contiennent les identificateurs de routage ou adresses des équipements d'interconnexion ou "portals" à prendre en compte respectivement par les ponts 66, 64, 62 et 61, pour transférer le paquet asynchrone jusqu'au périphérique destination 68.

Le champ 248, représenté sur 3 bits, contient l'identificateur de routage à prendre en compte par le pont 67 pour transférer en retour le paquet asynchrone jusqu'au périphérique source 69. Le champ 247, représenté sur 5 bits et dont tous les bits sont positionnés à<B>'T',</B> contient un marqueur délimitant les champs 241 à 244, 234 et 246, d'une part, du champ 248, d'autre part.

A la réception du paquet 231, le pont 67 lit et analyse la valeur du champ 233 qu'il compare avec le contenu du registre 79. Puisque les deux valeurs, exprimées sur le même nombre de bits significatifs, sont identiques, le paquet 231 va être transféré du bus 59 au bus 58 sous la forme du paquet 240.

On notera que dans le paquet 240, les identificateurs de routage 241, 242, 243, 244 et 246 représentatifs du chemin à parcourir jusqu'au périphérique destination 68 et le champ 248 représentatif du chemin parcouru depuis le périphérique source 69 ont été initialisés par le pont 67 dans le paquet 240. Pour cela, le pont utilise la valeur stockée dans le champ "offset" 232 du paquet 231 qu'il aura préalablement communiqué au périphérique source 69, par exemple, par l'intermédiaire d'un paquet asynchrone précédemment reçu. Ainsi, si, par exemple, le paquet 231 de la figure 7 constitue la réponse du périphérique 69 au paquet reçu 226 sur la figure 6, on notera que la valeur des champs 223 et 224 du paquet de données 226 est identique respectivement à la valeur des champs 232 et 233 du paquet 231 de la figure 7.

On notera aussi que dans ce cas, la valeur des champs 209, 210, 211 du paquet 216 de la figure 6 est respectivement égale à la valeur des champs 246, 247 et 248 du paquet 240 de la figure 7. De même, la valeur des champs 212, 213, 214 et 215 du paquet 216 est égale respectivement a la valeur des champs 241, 242, 243 et 244 du paquet 240.

Lors du transfert du paquet 231 à travers le pont 67, ce dernier a inséré le premier champ d'informations qui est formé des champs 244, 243, 242, 241 et 246. Ce premier champ d'informations identifie le chemin restant à parcourir au paquet de données 231 pour parvenir à destination.

Le pont 67 a ensuite ajouté dans un deuxième champ d'informations, vide au préalable, une deuxième information constituée par les bits "011" du registre 78 d'identification d'un équipement d'interconnexion ou "portal" considéré. Cette deuxième information est représentée par le champ 248.

Ce deuxième champ d'informations identifie le chemin parcouru par le paquet 231 depuis le périphérique 69 et ce sera le chemin d'informations dit de "retour" qui lui permettra, éventuellement, d'être renvoyé au périphérique source.

Le troisième champ d'informations correspond à une partie du champ 236 qui est transformée dans le paquet 240 en un champ 247 appelé "marqueur".

Le procédé de transfert de paquets procède également, après la suppression de la première information et avant l'ajout de la deuxième information, à la lecture de la table de routage associée à l'équipement d'interconnexion du registre 79.

Le contenu du champ 235, codé sur 6 bits, est représentatif de l'identificateur physique du périphérique 69 parmi tous les périphériques du bus 59. Le champ 235 du paquet 231 a été remplacé par le champ 249 dans le paquet 240. La valeur du champ 249 , est quant à elle représentative de l'identificateur virtuel du périphérique 69 parmi tous les périphériques du bus 59.

Le champ 234, codé sur 6 bits, est représentatif de l'identificateur virtuel du périphérique destinataire 68 du paquet asynchrone parmi tous les périphériques du bus 52.

On notera que la valeur du champ 234 est égale a la valeur du champ 204 des figures 5 et 6. De même, la valeur du champ 249 est égale à la valeur du champ 203 des figures 5 et 6 et la valeur du champ 235 est égale à la valeur du champ 221 de la figure 6.

Ainsi, on comprend que, lors du transfert d'un paquet par un pont intermédiaire, l'identificateur de routage de l'équipement d'interconnexion ou "portal" par lequel arrive le paquet est supprimé du premier champ d'informations car il est devenu inutile et l'identificateur de routage de l'équipement d'interconnexion ou "portal" par lequel le paquet quitte le pont est ajouté dans un deuxième champ d'informations afin de reconstruire le chemin parcouru par le paquet.

Les deux identificateurs ayant la même longueur, la longueur totale des premier, deuxième et troisième champs d'informations (figure 5) reste inchangée.

En réduisant la longueur du premier champ et en augmentant la longueur du deuxième champ au fur et à mesure du transfert du paquet par différents ponts du réseau on peut donc augmenter la- distance maximale parcourue par un paquet par rapport à l'art antérieur dans lequel la longueur de chaque champ destination et source reste fixe au cours du temps.

II convient de remarquer que le troisième champ ou marqueur a une longueur au moins égale au nombre de bits nécessaire pour coder un identificateur de routage d'un équipement d'interconnexion ou "portal".

Comme précédemment mentionné, le marqueur comporte une suite prédéterminée de bits qui peut être, par exemple, une suite consécutive de bits ayant tous un même état "0" ou"1 ".

L'utilisation et la gestion du champ "offset" par les ponts source et destination sont plus particulièrement décrites en référence aux figures 8, 9 et 10.

La figure 8 est une vue schématique détaillée d'une table de routage illustrée par chaque registre 95, 96 de la figure 4 et qui est stockée dans la mémoire RAM de chaque équipement d'interconnexion ou "portal" d'un pont source ou destination. Cette table a pour objectif d'associer à un index ("offset" en terminologie anglo-saxonne) unique sur le bus local, un chemin permettant d'atteindre un périphérique distant et vice-versa.

Cette table est composée d'un ensemble d'enregistrements élémentaires 250 à 259, chaque enregistrement élémentaire étant associé à un index dans la table. Les enregistrements 250, 251, 252, 253, 254, 255, 256, 257, 258 et 259 sont respectivement associés aux index "0", 11111, "2", "3", "4", "5", 186" "7", "8", "9"_ La structure d'un enregistrement élémentaire est par exemple constituée des champs suivants. Le champ 270 "path descriptor" correspond à un "descripteur de chemin", représenté sur 16 bits et qui contient l'information de routage permettant d'atteindre le périphérique destinataire distant.

Le champ 271 "activ" (raccourci de "activity", terminologie anglo- saxonne de "activité") représenté sur 16 bits, contient l'information concernant la gestion au niveau du bus local dudit descripteur de chemin.

Ce champ est notamment utilisé pour connaître, à un moment donné, combien de transactions de type "Requête" et "en attente de Réponse" sont en cours de traitement.

Ce champ peut également être utilisé afin de connaître depuis combien de temps l'enregistrement élémentaire n'a pas été consulté.

Pour ce faire, un compteur est incrémenté suivant une période prédéfinie par l'équipement d'interconnexion ou "portal" et est remis à zéro à chaque utilisation de l'information "descripteur de chemin" ou de l'index. Ce champ permet ainsi d'optimiser la gestion de la mémoire de la table de routage.

II convient de noter que les index ("offsets") des enregistrements élémentaires, non en cours d'utilisation et/ou n'ayant pas été utilisé depuis un certain temps, sont de préférence réutilisés en premier.

Le champ 272 "local-bus bit map", représenté sur 64 bits, permet de décrire quels sont les périphériques sur le bus local qui utilisent effectivement ce descripteur de chemin. Chacun des 64 bits, indexés de 0 à 63, correspond au périphérique dont l'identificateur physique a pour valeur l'index en question.

Comme précédemment mentionné, ce champ permet d'optimiser la gestion de la mémoire de la table, en évitant de réutiliser un index qui est utilisé, même peu souvent, par un nombre élevé de périphériques.

Ce champ présente surtout l'avantage de pouvoir déterminer, dans le cas où un index a été attribué à un autre enregistrement élémentaire, si l'index est toujours d'actualité pour un périphérique donné sur le bus local.

La figure 8 décrit par exemple une table de routage pouvant contenir jusqu'à dix enregistrements élémentaires qui sont alors indexés de 0 à 9. Chaque enregistrement élémentaire contient trois mots de 32 bits. La taille maximale des enregistrements élémentaires étant atteinte, une gestion de ceux-ci est nécessaire afin d'en libérer avant de pouvoir en ajouter.

On notera que la longueur des champs 270, 271 et 272 est indicative et peut être réduite ou augmentée suivant les capacités du réseau. Ainsi, par exemple, si l'on autorise un maximum de 32 périphériques par bus, ceci incluant les ponts, la longueur du champ 272 "local bus bit map" peut être réduite à 32 bits et le nombre total d'index peut être augmenté jusqu'à 15 pour une même occupation de la mémoire.

Cette gestion peut obéir à différentes politiques comme par exemple celle selon laquelle les enregistrements élémentaires non en cours d'utilisation et n'ayant pas été utilisé depuis une certaine durée sont libérés.

De même, le nombre de périphériques qui ont utilisé et qui sont encore susceptibles d'utiliser un enregistrement élémentaire donné peut avantageusement être pris en compte.

La figure 9 est une vue schématique de l'algorithme d'un procédé de récupération d'un descripteur de chemin à partir d'un index dans la table de routage décrite en figure 8.

Ce procédé est, par exemple, mis en oeuvre dans le pont 67 de la figure 7 lors du transfert du paquet 231 du bus 59 vers le bus 58.

Ces instructions ou étapes d'un tel procédé sont stockées dans la mémoire ROM du pont considéré.

Au cours d'une étape 301, le procédé prévoit de recevoir une requête de récupération d'un descripteur de chemin à partir d'un index donné. Au cours de l'étape 302, il est vérifié que l'index en question se réfère bien à un enregistrement élémentaire dans la table de routage. Dans le cas positif, le traitement se poursuit par l'étape 303. Dans le cas négatif, le procédé prévoit de retourner une information signifiant qu'aucun descripteur de chemin n'est valide pour ledit index (étape 305).

Au cours de l'étape 303, le procédé comporte une étape de vérification selon laquelle l'enregistrement élémentaire correspond bien à l'index présenté par le périphérique à l'origine de la requête. Il se peut en effet que l'enregistrement élémentaire correspondant audit index ait été supprimé de la table, puis que cette valeur d'index ait été réutilisée pour décrire un autre enregistrement élémentaire pour un autre périphérique.

Pour ce faire, un ensemble de 64 bits (indexés de 0 à 63) est utilisé pour dresser une carte des périphériques utilisant l'enregistrement élémentaire en question.

Chaque bit permet de savoir si, pour le périphérique dont l'identificateur physique a pour valeur l'index parmi les 64 bits, l'enregistrement élémentaire est valide ou non.

Dans le cas où l'information est dite non valide, le procédé prévoit de retourner une information signifiant qu'aucun descripteur de chemin n'est valide pour ledit index (étape 305).

Dans le cas où l'information est valide, l'étape 303 est suivie de l'étape 304.

Au cours de l'étape 304, le procédé effectue une lecture du descripteur de chemin, met à jour les informations de gestion relatives â l'enregistrement élémentaire, et retourne finalement le descripteur de chemin pour ledit index.

Parmi les informations de gestion relatives à l'enregistrement élémentaire, on peut notamment citer les deux actions suivantes Premièrement, quand une demande de récupération d'un descripteur de chemin à partir d'un index est issue d'une transaction de type "Requête", un compteur indiquant l'usage de cet enregistrement élémentaire est incrémenté si une transaction de type "Réponse" est attendue. Ce compteur sera décrémenté lors d'une prochaine demande de récupération d'un index à partir d'un descripteur de chemin issue d'une transaction de type "Réponse".

Deuxièmement, à chaque utilisation de l'enregistrement élémentaire, le compteur indiquant la durée écoulée depuis la dernière utilisation de cet enregistrement est remis à zéro.

Ce dernier compteur peut par exemple être incrémenté sur un événement temporel généré avec une période prédéfinie.

Après avoir retourné le descripteur de chemin ou l'absence de descripteur de chemin pour ledit index, le procédé prévoit de revenir à l'étape 301 pour traiter toute nouvelle demande de récupération d'un descripteur de chemin à partir d'un index dans la table de routage.

La figure 10 est une vue schématique de l'algorithme d'un procédé de récupération d'un index à partir d'un descripteur de chemin dans la table de routage décrite en figure 8.

Ce procédé est par exemple mis en #uvre dans le pont 67 de la figure 6 lors du transfert du paquet 216 du bus 58 vers le bus 59.

Les instructions ou étapes d'un tel procédé sont stockées dans la mémoire ROM du pont considéré.

Au cours d'une étape 311, le procédé prévoit de recevoir une requête de récupération d'un index à partir d'un descripteur de chemin donné. Au cours de l'étape suivante 312, le procédé prévoit de vérifier que le descripteur de chemin en question est présent dans la table de routage. Dans le cas positif, l'étape 312 est suivie de l'étape 315, au cours de laquelle on met à jour, le cas échéant, les informations de gestion relatives à l'enregistrement élémentaire, et l'index correspondant audit descripteur de chemin est retourné.

Concernant les informations de gestion relatives à l'enregistrement élémentaire, on peut notamment citer les deux actions suivantes Premièrement, quand une demande de récupération d'un descripteur de chemin à partir d'un index est issue d'une transaction de type "Réponse", le compteur indiquant l'usage de cet enregistrement élémentaire est décrémenté.

Deuxièmement, le compteur indiquant la durée écoulée depuis la dernière utilisation de cet enregistrement est remis à zéro.

Ce dernier compteur peut par exemple être incrémenté sur un événement temporel généré avec une période prédéfinie.

Dans le cas négatif, le procédé comporte une étape 313 au cours de laquelle il est vérifié si au moins un index (et donc un enregistrement élémentaire) est libre dans la table de routage. Dans le cas positif, au cours d'une étape 314, un index est affecté et utilisé pour stocker le descripteur de chemin d'informations.

Un bit parmi l'ensemble des 64 bits (indexés de 0 à 63) qui correspond à l'identificateur physique du périphérique à l'origine de la demande, est positionné afin de valider cet enregistrement élémentaire pour le périphérique en question. ' Si l'index n'est pas libre, le procédé procède à la libération d'un ou plusieurs index (et donc d'en registre ment(s) élémentaire(s)) dans la table de routage au cours d'une étape 316.

L'étape suivante 317 consiste à vérifier si l'étape de libération a pu se faire avec succès. Dans le cas positif, l'étape 314 précédemment décrite est à nouveau effectuée. Dans le cas négatif, au cours d'une étape 318, le procédé prévoit de retourner une information indiquant l'absence d'index (et donc d'enregistrement élémentaire) pour ledit descripteur de chemin. Ensuite, l'étape 311 est exécutée de nouveau.

La figure 11 représente un algorithme sur lequel est basé un procédé de routage des paquets asynchrones au niveau d'un pont.

Les instructions ou étapes d'un tel procédé sont stockées dans la mémoire ROM de chaque pont.

Cet algorithme concerne la prise de décision de routage desdits paquets ainsi que la transformation de leurs en-têtes, en fonction du résultat de l'analyse du contenu des en-têtes des paquets reçus.

Dans la suite de la description, des variables temporaires stockées dans la mémoire RAM du pont considéré (D BusID, S_BusID, in RI, out RI, path_register) ont été introduites pour faciliter la compréhension de l'algorithme sur lequel est basé le procédé.

Le procédé débute par une étape notée 100 sur la figure 11 consistant en l'attente de la réception d'un paquet asynchrone. Lorsqu'un tel paquet a été reçu et stocké en mémoire, on passe à l'étape 401 d'analyse de l'identificateur du bus de destination D BusID compris dans l'en-tête dudit paquet. Dans la suite de la description, D_BusID représente l'information du champ "destination Bus_ID" de la figure 2, de même S BusID représente l'information du champ "source-Bus-ID" de cette même figure.

Si ledit identificateur est égal à 3FF16, il s'agit alors soit d'un paquet émis sur le bus local et destiné à ce bus local, soit d'un paquet distant arrivé sur son bus de destination (comme décrit en figure 6). Dans ce cas d'égalité, l'étape 401 est suivie par l'étape 402 consistant, puisque ce paquet est destiné audit bus local, à rejeter le paquet sans autre traitement. L'étape 402 est suivie par l'étape 400 d'attente d'un nouveau paquet asynchrone.

*Lorsqu'au cours de l'étape 401 on trouve un identificateur du bus de destination différent de 3FF16, cela signifie que le paquet est au niveau d'un pont intermédiaire et les étapes 403 et 404 sont alors exécutées.

II convient de noter que, dans la suite de la description, selon le cas de figure envisagé, l'information ou identificateur (ou label) de routage du descripteur de chemin de destination est lu dans les bits de poids faibles du champ D BusID et l'information ou identificateur (ou label) de routage du descripteur de chemin parcouru est écrit dans les bits de poids faibles du champ S BusID, les bits étant décalés d'un champ à l'autre de façon appropriée.

Par exemple, on procède à un décalage à droite du champ D BusID et à un décalage à gauche du champ S BusID, chaque bit issu du décalage à gauche du bit de poids fort du champ S BusID étant inséré, après décalage à droite des bits du champ D-BusID , à la place du bit de poids fort du champ D-BusID.

D'autres variantes consistant à combiner lecture/écriture des informations de routage des descripteurs de chemin sur les poids forts/faibles des champs D BusID et S BusID avec les décalages appropriés ne sont pas décrites dans la présente description, mais peuvent être envisagées par l'homme du métier.

De retour à l'algorithme de la figure 11, l'étape 403 consiste à déterminer l'identificateur ou label de routage du descripteur de chemin de destination in RI. Pour ce faire l'identificateur ou label de routage est extrait du champ D BusID d'une longueur ou taille (en bits) égale au contenu du registre "routing width 30" 92 (figure 4) associé à l'équipement d'interconnexion ou "portal" d'entrée ("inbound portal" en terminologie anglo-saxonne).

Dans l'exemple de la figure 5 , le champ D BusID vaut "1111 011 0012", la valeur routing width 30 est égale à 3 et l'identificateur ou label de routage in RI est égal à 0012.

Une fois la valeur de l'idëntificateur ou label de routage in RI du paquet connue, l'étape 404 permet de la comparer au contenu du registre "routing label 30" 91 qui constitue l'unique identificateur ou label de routage affecté pour le bus considéré à l'équipement d'interconnexion ou "portal" sur lequel le paquet en question à été reçu.

Si les deux valeurs sont différentes, alors l'étape 405 est exécutée. Cette étape consiste à rejeter le paquet puis à passer à l'étape 400 décrite ci-dessus.

Dans le cas contraire, c'est-à-dire lorsque les valeurs in-RI et routing label 30 sont égales, l'étape 404 est suivie du test 406 afin d'analyser l'identificateur du bus source S BusID compris dans l'en-tête du paquet traité.

Si l'identificateur est égal à 3FF16 cela signifie que le paquet est situé au niveau d'un pont source, alors le paquet est dit "distant" (destinataire sur un bus distant) et est reçu de son bus source (comme par exemple le paquet référencé 231 en figure 7). L'en-tête de ce paquet sera alors traité suivant les étapes 410, 411, 412, 413 ou 414 et 415 décrites de façon plus en détail ci-dessous.

Dans le cas contraire, le paquet "distant" traité transite sur un bus intermédiaire entre son bus source et son bus de destination (comme par exemple le paquet référencé 216 en figure 5). Le traitement de l'en-tête du paquet suit alors les étapes 420 et 421 également décrites ci-dessous.

Pendant l'étape 410, on extrait du champ D BusID du paquet un index ("offset" en terminologie anglo-saxonne) de routage (précédemment défini lors de la description des figures 6 et 7) en tenant compte de la valeur routing width 30 mentionnée ci-dessus lors de l'explication de l'étape 403. Cet index ("offset") est constitué des (10 - routing width 30) bits de poids forts du champ D BusID, 10 étant la largeur dudit champ D BusID.

Par exemple, dans le cas où le champ D_BusID vaut "0001101 0002" et la valeur routing width 30 est égale à 3, l'index sera égal à 00011012.

Ensuite, pendant l'étape 411, l'index ("offset") est converti en descripteur de chemin selon le procédé de récupération d'un descripteur de chemin à partir d'un index dans la -table de routage, tel que décrit ci-dessus (figure 9, étapes 301 à 305).

Un test 412 consiste alors à vérifier si un tel descripteur de chemin a été trouvé au cours de l'exécution du procédé.

Dans le cas négatif, on exécute l'étape 413 consistant à rejeter le paquet traité.

Dans des variantes de mise en oeuvre de ce procédé, des méthodes de traitement d'erreur plus sophistiquées (dont le détail n'est pas reproduit sur les figures) peuvent être envisagées au cours de l'étape 413.

De telles méthodes consistent, par exemple, à envoyer un acquittement négatif au périphérique dont est issu le paquet pour lequel le descripteur de chemin est obsolète, permettant à celui-ci d'ajuster sa table de routage sans attendre l'expiration d'une certaine durée ("time-out" en terminologie anglo-saxonne).

L'étape 413 est suivie par l'étape 400 d'attente d'un nouveau paquet à traiter déjà décrite ci-dessus.

Dans le cas positif du test 412, le descripteur du chemin, retourné par l'étape 411, est stocké dans le registre "path_register" au cours de l'étape 414. Le registre "path_register" est utilisé pour la gestion des descripteurs de chemin (chemin destination et chemin parcouru) et est avantageusement composé de deux sous-champs, chacun de ces sous-champs correspondant aux informations respectivement contenues dans les champs D-BusID et S BusID.

Ensuite, au cours de l'étape 415, le procédé effectue, sur le registre "path register", le remplacement de l'identificateur physique du périphérique présent dans le champ de l'adresse source 235 du paquet de la figure 7 par l'identificateur virtuel correspondant, ceci en utilisant une table de correspondance appropriée établie lors de chaque réinitialisation ("bus reset" en terminologie anglo-saxonne) du bus source 52 de la figure 1. Cette table établissant la correspondance entre identificateurs physiques et virtuels des différents équipements (périphériques, ponts, ... ) connectés à un bus est bien connue de l'homme du métier et est d'ailleurs illustrée à la figure 21.

L'étape 415 est alors suivie par une étape 430 dont la description est faite plus loin.

De retour à l'étape 406, si l'identificateur est différent de 3FF16, alors cette étape est suivie d'une étape 420 de traitement d'un paquet reçu à partir d'un bus intermédiaire. L'étape 420 consiste à charger (mémorisation) le registre "path_register" à partir des identificateurs de bus D_BusID et S BusID extraits respectivement des champs "source-ID" 81 et "destin ation_ID" 80 de l'en-tête (figure 2) du paquet traité.

On rappelle ici que chacun des deux identificateurs du bus est constitué des 10 bits de poids fort du champ d'adresse correspondant (80 ou 81), tandis que les 6 bits restants desdits champs d'adresse représentent l'identificateur (soit physique, soit virtuel) du périphérique adressé sur le bus donné.

L'opération de chargement tient compte du mode de gestion des champs D BusID et S BusID mentionné précédemment comme, par exemple, le décalage à droite du champ D BusID et le décalage à gauche du champ S BusID, et où chaque bit issu du décalage à gauche du bit de poids fort du champ S BusID est inséré, après décalage à droite des bits du champ D_BusID, à la place du bit de poids fort du champ D_BusID.

Ensuite, au cours de l'étape 421, le contenu du registre "path_register" est transformé de la façon indiquée ci-après (pour une meilleure compréhension de cette étape, le lecteur est prié de se référer à la figure 5).

On repère tout d'abord une séquence de longueur maximale comportant au moins (2 max width - 1) bits consécutifs à "1" (max width étant la valeur du registre 97 de la figure 4) constituant un marqueur ou séparateur entre le champ identifiant le chemin de destination et le champ identifiant le chemin parcouru. Dans l'exemple du paquet 199 illustré à la figure 5, la séquence comporte 5 bits à<B>'T',</B> la séquence "011 0012" décrit le chemin de destination, et la séquence "011 010 0112" décrit le chemin parcouru.

II convient de noter ici qu'en séparant les trois champs cités de la manière précédemment décrite, on peut attribuer (de façon erronée) au marqueur d'éventuels bits adjacents appartenant au champ du chemin parcouru et/ou au champ du chemin de destination dans le cas où lesdits bits sont égaux à<B>'T'.</B> Ceci ne constitue toutefois pas un problème pour le fonctionnement correct de l'algorithme décrit.

On effectue ensuite un décalage dans le registre "path register', selon le mode de gestion adopté, des bits du champ descripteur du chemin de destination (identificateur du chemin à parcourir) d'un nombre de bits qui est égal à la valeur routing width 30.

Les bits non significatifs, suite au décalage, se trouvent positionnés à "1" et les bits du marqueur ne sont pas modifiés. Le registre "routing-width_30" 92 indique la longueur en bits de l'identificateur ou label de routage sur le bus d'entrée du paquet traité.

Ainsi, dans l'exemple de la figure 5, les bits du champ 202 ont disparu, les bits du champ 201 ont été décalé d'un nombre de bits égal à la valeur routing width 30 (à droite dans le champ "destination Bus_ID" 80a de la figure 2) et occupent maintenant le champ référencé 211, les bits devenus non significatifs du champ référencé 201 sont mis à "1", les bits du marqueur, référencé par les champs 200 et 205 restant inchangés.

II convient de noter que la taille ou longueur en bits du marqueur se trouve ainsi augmentée d'un nombre égal à la valeur routing width 30.

On effectue alors un décalage dans le registre "path register", selon le mode de gestion adopté, des bits du marqueur du chemin parcouru (identificateur du chemin parcouru) d'un nombre de bits qui est égal à la valeur routing width 32, un nombre de bits égal à la valeur routing width_32 des bits du marqueur se trouvant alors écrit. Rappelons ici que le registre "routing width 32" 94 associé à l'équipement d'interconnexion ou "portal" de sortie ("outbound portal" en terminologie anglo-saxonne) indique en fait la longueur en bits de l'identificateur ou label de routage sur le bus de sortie du paquet traité.

La valeur des bits décrivant l'identificateur ou label de routage pour le descripteur du chemin parcouru (identificateur du chemin parcouru) sera déterminée pendant l'étape 450 exécutée ultérieurement.

Dans l'exemple de la figure 5, les bits d'informations des champs 206, 207 et 208, décrivant le chemin parcouru, ont été décalé d'un nombre de bits égal à la valeur routing width_32 (à gauche dans le champ "source-Bus-ID" 81a de la figure 2 puis à droite dans le champ "destination Bus-ID" 80a de la figure 2) et occupent alors respectivement les champs 209 et 212 pour le premier, 213 pour le second et 214 pour le troisième. Les champs 209 et 212 faisant auparavant partie du marqueur contiennent désormais des informations décrivant le chemin parcouru. Le champ 215 va être affecté lors de l'opération décrite à l'étape 450.

Lors des différentes phases mentionnées ci-dessus et qui ont lieu au cours de l'étape 421, le marqueur s'est également trouvé déplacé par rapport à sa position antérieure à l'intérieur du registre "path_register".

Si la valeur routing width 32 est supérieure à la valeur routing width 30, alors la longueur du marqueur est réduite de la différence.

De façon similaire, si la valeur routing width 32 est inférieure à la valeur routing width 30, alors la longueur du marqueur est augmentée de la différence.

II convient de noter qu'en suivant cette règle, la longueur du marqueur reste supérieure ou égale à la valeur 4*max width - 1 - routing width 30 - routing width 32 (qui est toujours supérieure ou égale à 2*max width - 1) dans chaque pont traversé à condition que cette condition soit remplie initialement.

Ceci garantit que le marqueur reste identifiable par chaque pont. Dans l'exemple de la figure 5, le marqueur ou champ séparateur auparavant constitué des champs 200 et 205, se trouve, après passage du pont 66, représenté par le champ 210, sa longueur étant restée de 5 bits.

Dans la présente description, la taille ou longueur des identificateurs ou labels de routage est fixe dans tout le réseau bien que cela ne soit pas impératif. Ceci implique que les registres "routing width 30" 92, "routing width 32" 94 et "max width" 97 comportent la même valeur dans chaque pont du réseau. On notera que, pour ce faire, il suffit que le marqueur comporte au moins un nombre de bits égal à la valeur "max width" (au lieu de 2*max width - 1 bits dans l'hypothèse d'une longueur variable des identificateurs ou labels de routage).

Dans une variante de réalisation, les registres "routing width 30" 92, "routing width 32" 94 peuvent comporter des valeurs différentes pour un même pont du réseau.

On notera que la description faite en référence à la figure 1 et qui précède s'applique à cette variante.

L'étape 421 est suivie par les étapes 430 de lecture du champ composé des (routing width_32) bits du premier champ (équivalent de D BusID) du registre "path register" et par le test 431 afin de déterminer si tous les bits lus sont égaux à "1", c'est-à-dire si le paquet est arrivé sur son bus de destination. Dans l'affirmative, les étapes 440, 441, 442 et 443 sont exécutées, sinon on passe aux étapes 450 et 451.

Pour une meilleure compréhension de la description des étapes 440 à 443 du traitement d'un paquet arrivant sur son bus de destination 59, le lecteur est prié de se référer à la figure 6.

Lors de l'étape 440, le champ 203 de l'en-tête du paquet asynchrone constituant l'identificateur virtuel du périphérique ou équipement 69 destinataire dudit paquet sur le bus 59 est remplacé par l'identificateur physique 221 qui lui correspond en utilisant la table de correspondance appropriée.

L'étape 441 consiste à convertir l'identificateur du chemin parcouru contenu dans le registre "path_register" en index 223 ("offset") comme décrit ci-dessus en référence aux étapes 311 à 318 de la figure 10. Au cours de l'étape 442, le champ de l'en-tête identifiant le chemin parcouru est initialisé avec la concaténation dudit index 223 ("offset") et du contenu 224 du registre "routing_label 32" 93 (figure 4) en tenant compte du nombre des bits valides de l'identificateur ou label de routage, indiqué par le registre "routing width 32" 94.

Ensuite, au cours de l'étape 443, le champ de l'en-tête 220 identifiant le bus de destination est initialisé avec la valeur 3FF16. Ce traitement est suivi par l'étape 460. Au cours de l'étape 450 (lorsque les bits lus ne sont pas tous égaux à "1"), les bits identifiant le chemin parcouru du registre "path register, (nombre indiqué par la valeur routing width 32) sont initialisés avec l'identificateur ou label de routage 93 stocké dans le registre "routing label 32" associé à l'équipement d'interconnexion ou "portal" situé sur le bus de sortie du paquet traité.

Pendant l'étape 451 les champs identifiant le bus source, c'est-à- dire les champs 212, 213, 214, 215, 209 et le bus de destination, c'est-à-dire les champs 210 et 211 sont respectivement initialisés avec le contenu du registre "path_register". Ce traitement est également suivi par l'étape 460.

L'étape 460 consiste à transférer le paquet sur le bus 58 (figure 7), respectivement 59 (figure 6). Cette étape est suivie par l'étape 400 d'attente d'un nouveau paquet à traiter.

La figure 12 est une vue schématique d'un réseau de bus lors de la diffusion d'un paquet de résolution d'adresse d'une part, et de son paquet réponse correspondant d'autre part.

Ce réseau est composé des bus 501 à 505 interconnectés par les ponts 506 à 511.

Le paquet de résolution d'adresse est envoyé par un équipement source 513 afin d'obtenir un descripteur de chemin permettant ensuite d'accéder à l'équipement distant au moyen de paquets asynchrones tels que décrits dans le standard 1394-95. Ce paquet de résolution d'adresse est diffusé dans tout le réseau de bus ("broadcast" en terminologie anglo-saxonne). Un mécanisme complémentaire peut être mis en oeuvre au niveau de chaque équipement d'interconnexion ou "portal" d'un pont pour éviter que le paquet ne soit transmis plus d'une fois sur le même bus et ainsi éviter tout bouclage infini dans le réseau de bus. Ce mécanisme, connu de l'homme du métier et décrit par exemple dans le livre "DATA NETWORKS, second edition, by Bertsekas Gâllager, Prentice Hall International Editions, ISBN 0-13-201674- 5" dans le chapitre intitulé "Flooding and broacasting", s'appuie par exemple sur les principes suivants : le paquet en cours de diffusion est identifié de façon unique (par exemple à l'aide d'un numéro d'identification unique qui est le numéro EUI-64 de l'équipement source et d'un numéro de séquence identifiant ce paquet de manière unique dans ce même équipement source), quand un équipement d'interconnexion ou- "portal" diffuse ce paquet, il mémorise certaines d'informations qui lui permettront ensuite de savoir si un paquet de diffusion qu'il a reçu doit ou ne doit pas être diffusé sur l'autre équipement d'interconnexion ou "portal" du pont considéré, le cas échéant sur chacun des autres équipements d'interconnexion ou "portais" dudit pont, notamment en fonction d'une précédente réception de ce même paquet.

Les équipements d'interconnexion ou "portais" doivent, entre autre, à cette fin gérer une table de vérification dite de "diffusion" comme par exemple celle décrite à la figure 15.

Dans le cas où ce paquet doit être diffusé sur un bus, l'équipement d'interconnexion ou "portal" en question met à jour le descripteur de chemin qui permettra de diriger (router) directement le paquet réponse vers l'équipement qui est à l'origine du paquet de résolution d'adresse. La diffusion de ce paquet de résolution d'adresse est indiquée sur la figure 12 par les flèches 520, 521, 522 et 523.

Lorsque chaque équipement d'interconnexion ou "portal" d'un même pont est regroupé dans un seul et même dispositif tel que celui représenté à la figure 3, une seule table de vérification dite de "diffusion" commune peut être utilisée pour tous les équipements d'interconnexion ou "portais" d'un pont donné. Sur un bus donné, chaque équipement d'interconnexion ou "portal", possédant en interne une table des numéros EUI-64 des différents équipements connectés sur le bus, est en charge de vérifier, à la réception d'un paquet de résolution d'adresse, si l'équipement recherché est présent ou non sur le bus.

Dans le cas positif, l'équipement d'interconnexion ou "portal" du pont 506 par exemple celui connecté au bus 501 stoppe la diffusion du paquet de résolution d'adresse et émet un paquet de données asynchrone de réponse 530 vers le pont 508 qui transfère cette réponse sous la forme d'un paquet 531 au pont 510, à destination de l'équipement qui est à l'origine du paquet de résolution d'adresse.

Pour ce faire l'équipement d'interconnexion ou "portal" récupère dans le paquet de résolution d'adresse le descripteur de chemin mis à jour lors de la diffusion.

Le paquet de données asynchrone de réponse faisant route vers l'équipement 513 à l'origine du paquet de résolution d'adresse va construire le descripteur de chemin recherché. II en est de même pour l'équipement d'interconnexion ou "portal" du pont 507 qui va émettre un paquet de données asynchrone de réponse 533 vers le pont 510 (figure 12).

Il appartient à chaque équipement d'interconnexion ou "portal" des ponts du bus 504 , où se situe l'équipement 513 à l'origine du paquet de résolution d'adresse, de reconnaître les différents paquets de données asynchrones de réponse, de les filtrer et de n'en envoyer qu'un seul, référencé 534 sur la figure 12, vers l'équipement 513, dans le cas où celui-ci ne viendrait pas déjà d'un autre équipement d'interconnexion ou "portal" relié au bus 504.

Pour ce faire, l'équipement d'interconnexion ou "portal" doit mémoriser le fait que la requête de résolution d'adresse a été suivie d'une réponse, par exemple en sauvegardant à partir de la première réponse reçue, et ce pendant une certaine durée, des données comme le numéro EUI-64 de l'équipement recherché et le numéro de séquence identifiant le paquet de résolution d'adresse de manière unique dans cet équipement source, et en les comparant avec celles effectivement reçues dans les autres paquets réponses. Les éventuels paquets de données asynchrones de réponse s'avérant être des doublons sont simplement ignorés.

La figure 13 est une vue schématique représentant la structure d'un paquet de données de résolution d'adresse 550. Ce format de paquet est préférentiellement basé sur le format d'un paquet global de flux asynchrone (en terminologie anglo-saxonne "Global Asynchronous Stream Packet" ou en abrégé "GASP").

Les- champs 551 à 556 dénommés "data length", "tag", channel", "A161', "sy" et "header CRC" ont des valeurs constantes définies par le comité de normalisation 1394.

La valeur du champ 557 "source-ID" permet de spécifier l'adresse de l'équipement d'interconnexion ou "portal" émetteur du paquet.

Les champs 558 à 560 dénommés "specifiier ID hi", "specifiier ID 1o", et "version" ont des valeurs constantes définies par le comité de normalisation 1394.

Les champs 561 à 568 constituent une partie dénommée "champ de données" ("data field" en terminologie anglo-saxonne) d'un paquet GASP et sont utilisés de la façon indiquée ci-après.

Le champ descripteur de chemin 561 ("path descriptor" en terminologie anglo-saxonne), représenté sur 20 bits, contient l'information de routage élaborée lors du cheminement du paquet de résolution d'adresse vers l'équipement destination recherché. La valeur de ce champ est donc représentative du chemin parcouru. La taille utile de ce champ est définie à partir de la valeur des champs "max width" 97, "routing width 30" 92, et "routing width 32" 94 (figure 4) et des traitements effectués sur le chemin parcouru tels qu'explicités lors de la description de l'étape 421 de la figure 11. Par exemple, lorsqu'un paquet de résolution d'adresse présent sur le bus 56 de la figure 1 est susceptible d'être transféré par le pont 66 sur le bus 58 et que le champ 561 comporte, par exemple, les champs 200 et 205 à 208 de la figure 5, alors le contenu du champ 561 sera remplacé par les champs 210, 209 et 212 à 215 lors du transfert via le pont 66. Le champ dénommé "sequence-number" ("numéro de séquence") et noté 562, représenté sur 12 bits, permet d'identifier ce paquet de manière unique dans l'équipement source à l'origine de la requête de résolution d'adresse.

Les champs dénommés "SrC_EUI-64 hi" et "Src EUI 64 1o" ("EUI-64 source haut et bas") et notés respectivement 563 et 564, représentés chacun sur 32 bits, décrivent le numéro EUI-64 de l'équipement à l'origine de ce paquet de résolution d'adresse. Ce numéro EUI-64 est utile pour identifier de manière unique l'équipement source à l'origine de la requête de résolution d'adresse.

Les champs dénommés "Dev EUI 64 hi" et "Dev EUI 64_1o" ("EUI-64 équipement recherché haut et bas") et notés respectivement 565 et 566, représentés chacun sur 32 bits, décrivent le numéro EUI-64 de l'équipement recherché par l'équipement à l'origine de ce paquet de résolution d'adresse. Ce numéro EUI-64 identifie de manière unique l'équipement recherché.

Quand un équipement souhaite communiquer avec un équipement distant, celui-ci positionne, entre autres, les champs 563 et 564 ("Src EUI 64 hi" et "Src EUI 64 1o") avec son numéro EUI-64, et le champ numéro de séquence 562 avec une valeur unique pour cet équipement (valeur incrémentée, par exemple, après chaque émission d'un tel paquet).

En sauvegardant, pendant une durée prédéterminée par exemple égale à une seconde, ce numéro de séquence pour chaque équipement émetteur d'un paquet de résolution d'adresse, chaque équipement d'interconnexion ou "portal" du réseau peut ainsi éviter d'émettre à nouveau ce paquet sur le(s) bus adjacent(s).

Le champ dénommé "response packet type specific information" ("information spécifique pour le paquet réponse") et noté 567, représenté sur 48 bits, contient l'information nécessaire pour construire le paquet réponse en réponse au paquet de résolution d'adresse. Cette information est positionnée par l'équipement émetteur du paquet de résolution d'adresse. Ce champ spécifie notamment, dans le cas où le paquet réponse est basé, par exemple, sur un paquet primaire asynchrone ("asynchronous primary packet" en terminologie anglo-saxonne) de type écriture (décrit dans la norme 1394-95), l'adresse de destination dans l'équipement source qui est à l'origine du paquet de résolution d'adresse, adresse à laquelle l'équipement destinataire recherché pourra écrire des données en réponse à la requête. Le paquet de réponse est par exemple un paquet de type requête d'écriture d'un bloc de données ("write request for data block" en terminologie anglo-saxonne).

Un champ dénommé "reserved" ("réservé") et noté 568, représenté sur 16 bits, comme son nom l'indique, n'est pas utilisé pour l'instant. La valeur d'un champ dénommé "data CRC" et noté 569 est calculée en fonction de la valeur des champs 557 à 568 selon des règles prédéterminées parle comité de normalisation 1394.

La figure 14 est une vue schématique représentant la structure d'un paquet de données asynchrone 580 de réponse au paquet de résolution d'adresse 550 décrit précédemment. Le format d'un tel paquet est largement décrit dans le standard 1394-95 et est illustré en figure 2. Seuls les champs utiles dans le cadre du présent document sont décrits ci-après.

Comme il a été mentionné précédemment, la valeur d'un champ dénommé "tCode" et noté 585 peut par exemple correspondre à une requête du type "write request for data block".

Un champ dénommé "reserved" ("réservé") et noté 590, représenté sur 16 bits, comme son nom l'indique, n'est pas utilisé pour l'instant. Un champ dénommé "sequence number" ("numéro de séquence") et noté 591, représenté sur 12 bits, permet d'identifier le paquet de manière unique dans l'équipement qui est à l'origine de la requête de résolution d'adresse.

Des champs dénommés "Src_EUI 64_hi" et "Src EUI 64 1o" ("EUI-64 source haut et bas") et notés respectivement 592 et 593, représentés chacun sur 32 bits, décrivent le numéro EUI-64 de l'équipement à l'origine du paquet de résolution d'adresse. Ce numéro EUI-64 est utile pour identifier de manière unique l'équipement qui est à l'origine de la requête de résolution d'adresse. Les champs 592, 593 ("SrC-EUI 64 hi" et "Src EUI 64 1o") et le champ 591 ("sequence number") permettent notamment à chaque équipement d'interconnexion ou "portal" sur le bus dit "source" (bus où se situe l'équipement qui est à l'origine de la requête de résolution d'adresse) de savoir si une réponse a déjà été envoyée à l'équipement qui est à l'origine de la requête de résolution d'adresse.

Les équipements d'interconnexion ou "portals" sur le bus "source" doivent pour cela gérer une table de vérification dite de "réponse" comme par exemple celle décrite en figure 15.

On notera que la détection et le traitement du bouclage ("loop detection" en terminologie anglo-saxonne) concerne une amélioration apportée au procédé de routage d'un paquet de résolution d'adresse et qui utilise des procédés décrits dans l'état de l'art.

En effet, un traitement par défaut du bouclage est mis en oeuvre par le procédé de routage d'un paquet de résolution d'adresse lors du traitement associé au champ 561 : lorsque la totalité de la zone utile du champ 561 du paquet de résolution d'adresse est utilisée pour décrire le chemin parcouru, le procédé de transfert du paquet d'un bus à l'autre est stoppé.

Ainsi, le procédé de transfert de paquet va consommer, par insertion d'identificateurs ou labels de routage lors de chaque boucle, une partie de la zone utile du champ 561 du paquet de résolution d'adresse, jusqu'à remplir la totalité du champ, ce qui a pour effet de mettre fin au transfert du paquet.

La figure 15 est une vue schématique détaillée représentant une table de vérification 600 stockée dans- la mémoire RAM de la figure 3. Ce type de table peut être utilisé par les deux types de vérification précédemment décrits - diffusion d'un paquet de résolution d'adresse d'une part, - génération d'un seul et unique paquet de réponse correspondant à un paquet de résolution d'adresse sur le bus où se situe l'équipement qui est à l'origine de ce paquet de résolution d'adresse. La figure 15 illustre par exemple une table de vérification contenant un nombre limité d'enregistrements élémentaires notés 601 à 605.

Des champs dénommés "Src EUI 64_hi" et "Src EUI 64 1o" ("EUI-64 source haut et bas") et notés respectivement 610 et 611, représentés chacun sur 32 bits, décrivent le numéro EUI-64 de l'équipement qui est à l'origine du paquet de résolution d'adresse. Ce numéro EUI-64 est utile pour identifier de manière unique l'équipement qui est à l'origine du paquet de résolution d'adresse.

Un champ dénommé "sequence_number" ("numéro de séquence") et noté 612, représenté sur 12 bits, permet d'identifier ce paquet de manière unique dans l'équipement qui est à l'origine du paquet de résolution d'adresse.

Un champ dénommé "management" ("gestion") et noté 613, représenté sur 20 bits, permet d'associer des informations à chaque enregistrement de la table selon le type de la table envisagée.

Dans le cas d'une table de vérification dite de "diffusion" (utilisée pour gérer la diffusion d'un paquet de résolution d'adresse de telle sorte que ce paquet soit transmis sur chaque bus du réseau, une et une seule fois), le champ "management" peut par exemple contenir une information indiquant si un paquet de résolution d'adresse a déjà été soit reçu par l'équipement d'interconnexion ou "portal", soit transmis par celui-ci (une valeur booléenne peut par exemple être suffisante).

Dans le cas d'une table de vérification dite de "réponse" (utilisée pour gérer la non-duplication d'une réponse vers l'équipement qui est à l'origine d'un paquet de résolution d'adresse), le champ "management" peut, par exemple, contenir une information indiquant si un paquet réponse a déjà été soit reçu par l'équipement d'interconnexion ou "portal", soit transmis par celui-ci (une valeur booléenne peut par exemple être suffisante).

Selon une première variante non décrite ici, un compteur pourrait apporter des informations supplémentaires sur le fait que plusieurs réponses, c'est-à-dire plusieurs descripteurs de chemin, existent et donc qu'un choix pourrait être fait sur le descripteur de chemin à retenir selon des critères prédéfinis comme, par exemple, le plus court chemin.

Cette variante impose alors de définir un protocole de communication entre les différents équipements d'interconnexion ou "portals" afin d'effectuer le changement de descripteur de chemin à utiliser.

Dans une deuxième variante non décrite ici, c'est "l'alpha portal" qui centralise toutes les réponses reçues au niveau du bus local où se situe l'équipement qui est à l'origine du paquet de résolution d'adresse, qui décide de retenir, selon des critères prédéfinis comme, par exemple, le plus court chemin, un descripteur de chemin, et qui n'envoie finalement qu'un seul paquet réponse vers l'équipement qui est à l'origine du paquet de résolution d'adresse.

- Une troisième variante consiste à utiliser comme informations dans le champ "management", en plus de l'indicateur de passage de paquet de résolution d'adresse ou de paquet réponse déjà transmis, une valeur indiquant par exemple la durée en unités de temps correctement définie ("timeout" en terminologie anglo-saxonne) au-delà de laquelle cet enregistrement n'est plus significatif et peut donc être détruit.

Une quatrième variante consiste à n'utiliser qu'une seule table de vérification à la fois pour la "diffusion" et les "réponses". Dans ce cas, le champ "management" peut se décomposer entre deux champs, l'un contenant des informations relatives à la diffusion de paquet de résolution d'adresse, l'autre aux paquets réponses à ce paquet de résolution d'adresse.

La figure 16 est une vue schématique de l'algorithme d'un procédé de réception d'un paquet de résolution d'adresse au niveau d'un équipement d'interconnexion ou "portal" d'un -pont.

Les instructions ou étapes du procédé sont stockées dans la mémoire ROM de chaque pont du réseau.

Au niveau du bus source, le paquet de résolution d'adresse émis par l'équipement source est décrit en référence à la figure 13.

Ce paquet doit être compris par les équipements d'interconnexion ou "portals" sources qui vont le traduire en un paquet de résolution d'adresse tel que représenté sur la figure 13. Au cours d'une étape 701, un paquet de résolution d'adresse est reçu au niveau d'un équipement d'interconnexion ou "portal". Au cours de l'étape 702, les champs "EUI-64 source" et "sequence number" décrits précédemment en référence à la figure 13 sont lus.

Au cours de l'étape 703, le procédé prévoit de vérifier si un enregistrement élémentaire ayant le numéro EUI-64 source qui vient d'être lu dans le paquet reçu existe déjà dans la table de vérification 600, représentée à la figure 15, à partir des champs EUI-64 source haut et bas présents dans cette table.

Dans le cas où l'enregistrement n'existe pas, au cours de l'étape 704, le procédé prévoit d'en créer un avec les valeurs des champs "EUI-64 source" -et "sequence number" lus dans le paquet reçu, par exemple l'enregistrement 601 représenté à la figure 15, puis se poursuit par l'étape 709.

Dans la cas où l'enregistrement existe déjà dans la table de vérification, au cours de l'étape 705, le procédé prévoit de vérifier que le numéro de séquence lu à partir du paquet reçu est strictement supérieur au numéro de séquence courant de l'enregistrement, par exemple noté 612 en figure 15.

Dans le cas négatif (plus petit ou égal), lors de l'étape 706, le paquet de résolution d'adresse est ignoré ; il se peut par exemple que ce soit un paquet plus ancien et qui, de toute façon, n'est plus valide.

Dans le cas positif, le procédé procède à une mise à jour du numéro de séquence de l'enregistrement avec celui lu du paquet reçu, au cours de l'étape 707, ainsi que des informations de gestion (comme celles précédemment mentionnées,- telles que, par exemple, une valeur booléenne indiquant si un paquet de résolution d'adresse a déjà transité sur le bus vu par l'équipement d'interconnexion ou "portal", et/ou un compteur indiquant combien de paquets identiques de résolution d'adresse ont été détecté sur le bus vu par l'équipement d'interconnexion ou "portal", et/ou une valeur indiquant par exemple la durée en unités de temps correctement définie ("timeout" en terminologie anglo-saxonne) au-delà de laquelle cet enregistrement n'est plus significatif et peut donc être détruit), au cours de l'étape 708. Au cours de l'étape 709, le procédé prévoit de vérifier si l'équipement d'interconnexion ou "portal" a connaissance de l'équipement recherché, identifié par les champs "Dev-EUI 64 hi" et "Dev EUI 64 1o", notés respectivement 565 et 566 sur la figure 13.

Autrement dit, dans le cas où l'équipement recherché se situe sur le même bus (ce bus est dit "bus destination") que l'équipement d'interconnexion ou "portal" en- question, alors ce dernier possède son numéro EUI-64 dans une table interne qui n'est pas décrite dans ce contexte car elle est définie dans le cadre des spécifications en cours du standard pont 1394.

Dans le cas positif, au cours de l'étape 710, le procédé prévoit d'effectuer les opérations de création et/ou de mise à jour dans la table de routage précédemment décrite en référence aux figures 8 et 9, puis d'initier l'envoi d'un paquet réponse 580, tel que décrit en référence à la figure 14, audit paquet de résolution d'adresse.

Les champs de ce paquet réponse 580 sont notamment positionnés en utilisant les valeurs des champs du paquet de résolution d'adresse de la façon suivante - le champ descripteur de chemin 561 est utilisé pour positionner les champs 581, 582, 587 et 588, - le champ "response_packettype specifiçinformation" 567 est utilisé pour positionner le champ de même nom 589, - le champ "sequence number" 562 est utilisé pour positionner le champ de même nom 591, - les champs "Src EUI 64_hi" et "Src EUI 64 lo" respectivement notés 563 et 564 sont utilisés pour positionner les champs de mêmes noms 592 et 593.

Dans le cas négatif, au cours de l'étape 711, le procédé prévoit de vérifier si l'équipement d'interconnexion ou "portal" a reçu le paquet de résolution d'adresse du bus sur lequel il est situé (sinon cela signifie que le paquet a été reçu du (ou d'un) "portal" du pont auquel appartiennent ces "portals"). Dans le cas positif (paquet reçu du bus), le procédé mis en oeuvre au niveau de l'équipement d'interconnexion ou "portal" prévoit d'envoyer, au cours de l'étape 712, le paquet à (aux) l' (les) équipement(s) d'interconnexion ou "portal(s)" constituant le pont.

Dans le cas négatif (paquet reçu de l'équipement d'interconnexion ou - "portal"), le procédé mis en oeuvre au niveau de l'équipement d'interconnexion ou "portal", au cours de l'étape 713, met à jour le descripteur de chemin du paquet de résolution d'adresse et l'envoie sur le bus, propageant ainsi la diffusion du paquet à travers le réseau de bus.

Le descripteur de chemin ayant une taille finie, lorsque ce descripteur de chemin du paquet de résolution d'adresse ne peut plus être mis à jour, la transmission ou diffusion dudit paquet de résolution d'adresse est stoppée. Ce traitement permet de contrôler le mécanisme de propagation du paquet de résolution d'adresse et, par la même, permet de détecter et de résoudre les problèmes de bouclage.

Suite aux étapes 710, 712 et 713, le traitement du paquet de résolution d'adresse se trouve alors terminé et le procédé revient à son étape initiale (701) d'attente d'un nouveau paquet.

La figure 17 est une vue schématique de l'algorithme d'un procédé de réception d'un paquet de données de réponse, suite à l'émission d'un paquet de résolution d'adresse, au niveau d'un équipement d'interconnexion ou "portal" d'un pont situé sur le bus où se trouve l'équipement qui est à l'origine du paquet de résolution d'adresse.

Les instructions ou étapes d'un tel procédé sont stockées dans la mémoire ROM du pont considéré.

La réception d'un paquet de données de réponse peut revêtir deux formes<B>:</B> soit il s'agit d'un paquet de données de réponse émis par un équipement d'interconnexion ou "portal" distant signifiant la présence de l'équipement recherché sur son bus, soit il s'agit d'un paquet de données de réponse émis par un équipement d'interconnexion ou "portal" local au bus source et, dans ce cas, il s'agit du seul et unique paquet envoyé à l'équipement qui est à l'origine du paquet de résolution d'adresse. Au cours d'une étape 751, le procédé mis en ceuvre au niveau de l'équipement d'interconnexion ou "portal" du bus où se trouve l'équipement qui est à l'origine du paquet de résolution d'adresse, prévoit d'attendre un événement associé à un paquet de réponse, c'est-à-dire ou bien la réception d'un paquet de réponse ou alors l'écoulement d'une durée d'attente maximum prédéfinie depuis l'émission du paquet de résolution d'adresse.

Au cours de l'étape suivante 752, le procédé prévoit de vérifier si l'événement en question est effectivement un paquet de réponse au paquet de résolution d'adresse.

Dans le cas positif, au cours de l'étape 753, le procédé prévoit de vérifier si le type du paquet de réponse reçu est un paquet émis par un équipement d'interconnexion ou "portal" local au bus (paquet réponse unique envoyé à l'équipement qui est à l'origine du paquet de résolution d'adresse).

Dans le cas négatif, au cours de l'étape 754, le paquet de réponse est acquitté comme décrit dans le standard 1394-95 et le paquet de réponse étant basé sur un paquet primaire asynchrone de type requête ("request" en terminologie anglo-saxonne), celui-ci doit être acquitté par un paquet de type réponse ("response" en terminologie anglo-saxonne).

Dans le cas négatif de la vérification faite à l'étape 752, celle-ci est suivie par l'étape 760.

Au cours de l'étape 755, le procédé prévoit de vérifier si un paquet de réponse pour le paquet de résolution d'adresse a déjà été reçu par l'équipement d'interconnexion ou "portal" ou détecté sur le bus "source" ou si un acquittement négatif n'a pas déjà été généré sur le bus source.

Dans le cas négatif où, a priori, aucun paquet réponse n'est attendu, au cours de l'étape 758, le procédé prévoit d'ignorer le paquet et de revenir à l'étape initiale 751.

Dans le cas positif, où effectivement un paquet réponse est attendu, au cours de l'étape 756, le procédé prévoit de mémoriser la réception ou la détection d'un paquet réponse.

Puis, au cours de l'étape 757, dans le cas où le paquet réponse précédemment reçu n'était pas déjà un paquet réponse unique envoyé à l'équipement qui est à l'origine du paquet de résolution d'adresse, le procédé prévoit d'envoyer un paquet réponse unique à l'équipement qui est à l'origine du paquet de résolution d'adresse.

Au cours de l'étape 760, le procédé prévoit de vérifier si la durée d'attente maximum prédéfinie s'est écoulée depuis l'émission du paquet de résolution d'adresse. La durée d'attente doit être correctement choisie, par exemple de telle sorte qu'elle soit supérieure au temps du plus long parcours aller d'un paquet de résolution d'adresse additionné au temps de parcours de l'éventuel paquet réponse correspondant. Dans le cas négatif, le processus traite le cas d'erreur au cours de l'opération 761. Dans le cas positif, l'étape 760 est suivie d'une étape 762. - Au cours de l'étape 762, si aucune opération n'a été détectée sur le bus source, le procédé prévoit d'envoyer à l'équipement qui est à l'origine du paquet de résolution d'adresse un paquet de réponse signalant qu'aucun équipement répondant au champ "EUI-64 source" précisé dans le paquet de résolution d'adresse n'a été trouvé, et ce, pendant la durée d'attente maximum autorisée. Le procédé prévoit ensuite de revenir à l'étape initiale 751.

La figure 18 est une vue schématique de l'algorithme d'un procédé de gestion de la longueur des identificateurs de ponts ou labels de routage au niveau d'un bus en fonction de la capacité du bus. Les étapes ou instructions de ce procédé sont stockées dans une mémoire ROM d'au moins un des ponts reliés au bus.

II convient de noter que le pont considéré relie deux parties d'un réseau entre elles, l'une des parties étant constituée du bus relié audit pont.

Au cours d'une étape 901, le procédé prévoit de détecter un événement indiquant une première initialisation d'un bus auquel le pont est connecté.

Au cours de l'étape 902, on détermine pour ledit bus la capacité en bande passante (plus grande bande passante commune à tous les périphériques présents sur ce bus).

II convient de noter que la capacité en bande passante ou débit binaire du bus constitue une caractéristique de celui-ci. Ensuite, au cours de l'étape 903, le procédé prévoit de vérifier, pour le bus, si la capacité dudit bus en bande passante est inférieure au débit binaire référencé S400 par la norme 1394-95 (S400 signifiant un débit de 393,216 Mbitls).

Dans le cas négatif, au cours de l'étape 904, il est vérifié, pour le bus, si cette capacité du bus en bande passante est inférieure au débit référencé S800 par le standard 1394-95 (S800 signifiant un débit de 786,432 Mbit/s).

Selon la valeur de la capacité en bande passante dudit bus, le procédé prévoit de fixer, d'une part, la longueur en bits de l'identificateur ou label de routage au niveau dudit bus au cours des étapes 905, 907 et 909, puis, d'autre part, le nombre maximum de ponts ou d'équipements d'interconnexion de ponts ("portais") autorisés sur ledit bus ("max_bridge" en terminologie anglo- saxonne), ceci au cours des étapes 906, 908 et 910.

On notera que pour une longueur en bits de l'identificateur ou label de routage de n bits, seulement 2n -1 valeurs d'identificateurs ou labels de routage sont autorisées car une valeur particulière dite de séparation (marqueur ou séparateur) est réservée.

Au cours de l'étape 911, on affecte un identificateur de routage constant et unique à l'équipement d'interconnexion ou "portal" du pont connecté au bus. Cette valeur d'identificateur de routage est avantageusement calculée de façon similaire par tous les équipements d'interconnexion ou "portais" à partir de la connaissance des identificateurs virtuels associés à chaque équipement d'interconnexion ou "portal" du bus considéré. Par exemple, la valeur de l'identificateur de routage est définie pour chaque équipement d'interconnexion par ordre croissant de la valeur de l'identificateur virtuel et, ainsi, ("'alpha portal" se verra assigner un identificateur de routage de valeur'0'.

Au cours de l'étape 912, le procédé prévoit de vérifier, pour le bus, si la valeur de l'identificateur de routage affecté à l'équipement d'interconnexion ou "portal" du pont en question est inférieure au nombre maximum de ponts autorisés sur ledit bus. Dans le cas négatif, au cours de l'étape 914, le pont est positionné dans l'état "désactivé" ("disabled" en terminologie anglo-saxonne) et l'algorithme se poursuit par l'étape 915 et une valeur particulière représentative de cet "état" est définie pour l'identificateur de routage de l'équipement d'interconnexion ou "portal" considéré.

Par exemple, si le codage des identificateurs a lieu sur 3 bits, on ne peut pas identifier plus de sept ponts dans un champ d'informations d'identifications.

Ainsi, si l'on connecte un huitième pont au bus, celui-ci ne sera pas géré au niveau du bus et aucun identificateur de routage valide ne lui sera affecté (pont "désactivé").

Dans le cas positif, au cours de l'étape 913, les différents paramètres et variables permettant la mise en couvre du routage décrit dans le présent document sont initialisés. L'étape 915 consiste à attendre un événement de type initialisation de bus ("bus reset" en terminologie anglo-saxonne).

Dans le cas où cet événement se produit, au cours de l'étape 916, l'algorithme vérifie si la configuration des ponts au niveau du bus a changé (par exemple un pont a été nouvellement connecté ou un pont existant a été déconnecté).

Dans le cas négatif, on revient à l'étape précédente 915.

Dans le cas positif, au cours de l'étape 917, la mise en couvre du routage décrit dans le présent document est suspendue de telle sorte que plus aucun paquet ne peut entrer sur le bus ou sortir de ce bus par l'intermédiaire du pont.

L'étape 918 consiste à attendre pendant une durée suffisante prédéfinie ("time out" en terminologie anglo-saxonne) afin que tout périphérique utilisant ce pont dans son descripteur de chemin pour communiquer avec un périphérique "distant" considère ce descripteur de chemin comme obsolète. En conséquence, le périphérique doit par exemple générer à nouveau un paquet de résolution d'adresse avant de pouvoir reprendre toute communication.

L'étape 902 est ensuite exécutée.

Une autre variante, non décrite ici consiste, par exemple, pendant l'intervalle de temps entre la suspension de la mise en oeuvre du routage décrit dans le présent document (étape 917) et la revalidation de cette mise en oeuvre du routage, à acquitter d'une façon particulière tout paquet désirant transiter via le pont.

La figure 19 est une vue schématique de l'algorithme d'un procédé de gestion de la longueur des identificateurs de ponts ou labels de routage au niveau d'un bus en fonction du nombre de ponts et donc d'équipements d'interconnexion ou "portais" connectés au bus. Les étapes ou instructions de ce procédé sont stockées dans une mémoire ROM d'au moins un des ponts reliés au bus.

L'algorithme de ce procédé ressemble fortement à celui décrit précédemment en référence à la figure 18, la différence portant principalement sur la caractéristique du bus utilisée pour décider de la longueur de l'identificateur ou label de routage à utiliser.

Dans la figure 18, cette caractéristique est la capacité en bande passante ou débit binaire d'un bus donné, l'objectif étant d'éviter d'autoriser un trop grand nombre de communications transitant sur ledit bus. A cette fin, un pont est mis dans l'état "désactivé" pour qu'il ne puisse plus faire transiter d'information. On note que dans le procédé de la figure 18, on cherche à prévenir toute congestion.

Dans l'algorithme de la figure 19, la caractéristique du bus qui est prise en compte est le nombre de ponts ou d'équipements d'interconnexion ou "portais" connectés sur ledit bus. En fonction du nombre de ponts sur ledit bus, un certain nombre de bits est nécessaire afin de pouvoir tous les identifier de façon unique.

Cet algorithme veille également à ne pas utiliser de bit inutilement pour cette identification. L'algorithme permet aussi de mettre un pont dans l'état "désactivé" dans le cas où trop de bits sont nécessaires pour l'identification dudit pont.

D'autres variantes, non décrites dans le présent document, peuvent aisément être envisagées à partir d'autres caractéristiques d'une partie du réseau, par exemple un bus, qui seront prises en compte dans la décision d'affectation de la longueur de l'identificateur ou label de routage à utiliser. Au cours d'une étape 951, on détecte un événement indiquant une première initialisation d'un bus auquel le pont est connecté.

L'étape 952, détermine pour ledit bus le nombre de ponts ou d'équipements d'interconnexion ou "portais" présents sur ce bus.

Ensuite, le procédé prévoit de vérifier, pour ce bus, si le nombre de ponts est inférieur à 3 au cours de l'étape 953, sinon s'il est inférieur â 7 au cours de l'étape 954 et sinon s'il est inférieur à 15 au cours de l'étape 955. Dans la négative, l'algorithme se poursuit par l'étape 965.

Selon la valeur du nombre de ponts connectés audit bus, on fixe, d'une part, la longueur en bits de l'identificateur ou label de routage au niveau dudit bus au cours des étapes 956, 958 et 960, puis d'autre part, le nombre maximum de ponts ou d'équipements d'interconnexion ou "portais" autorisés sur ledit bus ("max_bridge" en terminologie anglo-saxonne), ainsi que le nombre minimal d'équipements d'interconnexion ou "portais" pour ladite longueur en bits de l'identificateur ou label de routage ("min_bridge" en terminologie anglo-saxonne), ceci au cours des étapes 957, 959 et 961.

Au cours de l'étape 911, on affecte un identificateur de routage constant et unique à l'équipement d'interconnexion ou "portal" du pont connecté au bus.

Cette valeur d'identificateur de routage est avantageusement calculée de façon similaire par tous les équipements d'interconnexion ou "portais", à partir de la connaissance des identificateurs virtuels associés à chaque équipement d'interconnexion ou "portal" du bus considéré.

Par exemple, la valeur de l'identificateur de routage est définie pour chaque équipement d'interconnexion par ordre croissant de la valeur de l'identificateur virtuel et, ainsi, ("'alpha portal" se verra assigner un identificateur de routage de valeur '0'.

Au cours de l'étape 963, le procédé prévoit de vérifier, pour ledit bus, si la valeur de l'identificateur de routage affecté à l'équipement d'interconnexion ou "portal" du pont en question est inférieure au nombre maximum de ponts autorisés sur ledit bus. Dans le cas négatif, au cours de l'étape 965, le pont est positionné dans l'état désactivé ("disabled" en terminologie anglo-saxonne) et une valeur particulière représentative de cet "état" est définie pour l'identificateur de routage de l'équipement d'interconnexion ou "portal" considéré, puis l'algorithme se poursuit par l'étape 966.

Dans le cas positif, au cours de l'étape 964, les différents paramètres et variables permettant la mise en oeuvre du routage décrit dans le présent document sont initialisés. L'étape 966 consiste à attendre un événement de type initialisation de bus ("bus reset" en terminologie anglo-saxonne). Dans le cas où cet événement se produit, au cours de l'étape 967, l'algorithme vérifie si la configuration des ponts au niveau du bus a changé (par exemple un pont a été nouvellement connecté ou un pont existant a été déconnecté) et si le nombre de ponts ou équipements d'interconnexion ("portais") est en dehors de l'intervalle défini précédemment par min_bridge et max bridge.

Dans le cas négatif, l'algorithme revient à l'étape précédente 966. Dans le cas positif, au cours de l'étape 968, la mise en oeuvre du routage décrit dans le présent document est suspendue de telle sorte que plus aucun paquet ne peut entrer sur le bus ou sortir de ce bus par l'intermédiaire dudit pont.

L'étape 969 consiste à attendre pendant une durée suffisante prédéfinie ("time out" en terminologie anglo-saxonne) afin que tout périphérique utilisant ce pont dans son descripteur de chemin pour communiquer avec un périphérique "distant" considère ce descripteur de chemin comme obsolète. En conséquence, le périphérique doit par exemple régénérer un paquet de résolution d'adresse avant de pouvoir reprendre toute communication. L'étape 952 est ensuite exécutée.

II convient de remarquer que lorsqu'un pont relie entre elles deux parties d'un réseau, deux longueurs d'identificateurs différentes peuvent être déterminées respectivement pour les deux équipements d'interconnexion ou "portais" du pont considéré en fonction de deux caractéristiques respectivement propres à chacune desdites deux parties du réseau. Ainsi, dans un tel cas de figure, le marqueur qui délimite deux champs d'informations d'identification, respectivement du chemin à parcourir et parcouru par le paquet de données, voit sa taille ou longueur varier en conséquence, afin que la différence de taille ou longueur entre les deux identificateurs des deux équipements d'interconnexion ou "portais" n'ait pas d'incidence sur la longueur totale du champ constitué du marqueur et des deux champs d'informations d'identification qui doit être fixe. La figure 20 est une vue schématique d'un réseau de communication noté 1200 selon l'invention, de type conforme à la norme IEEE 1394 et qui comporte plusieurs bus de communication série conformes à la norme IEEE 1394 et dont seul certains sont référencés sur cette figure.

Les bus de communication série notés 1202 à 1218 sont interconnectés deux à deux par des ponts dont seuls certains sont référencés sur la figure 20 et sont notés 1220 à 1232.

Il convient de noter que chaque pont de la figure 20 a par exemple l'allure du pont noté entre parenthèses 1226 et représenté à la figure 3.

Chaque pont comporte deux équipements d'interconnexion ou "portais" qui permettent respectivement de connecter les bus entre eux.

Sur la figure 3, les éléments du pont qui sont référencés 12, 14, 16, 18, 20, 22, 24, 26, 28, 34, 36, 38, 40, 42 et 44 sont communs à chacun des équipements d'interconnexion ou "portais" de ce pont et seuls les blocs de composants PHYLINK 1394 notés 30 et 32 sur cette figure sont spécifiques respectivement à chaque équipement d'interconnexion.

Ainsi, chaque équipement d'interconnexion d'un pont de la figure 20 comporte un bloc de composants PHYLINK 1394 identique au bloc 30 ou 32 de la figure 3, ainsi que les autres éléments énoncés ci-dessus et qui sont communs à chacun desdits équipements d'interconnexion. Toutefois, dans certains cas, les équipements d'interconnexion ou "portais" d'un pont sont physiquement éloignés les uns des autres (cas d'une liaison radio) et chacun desdits équipements d'interconnexion comporte alors ses propres éléments identiques à ceux énoncés ci-dessus et notés 12 à 44.

De manière identique à ce qui est représenté à la figure 3, les ponts notés 1220 à 1232 peuvent être intégrés dans un appareil de traitement de données (par exemple un ordinateur) ou bien constituer eux-mêmes ledit appareil.

Sur la figure 3, le pont 1226 est intégré dans un ordinateur 1227. Les ponts représentés à la figure 20 interconnectent chacun au moins deux parties du réseau 1200, lesdites parties étant, dans l'exemple représenté sur cette figure, les bus de communication série conformes à la norme IEEE 1394.

Par ailleurs, des équipements de type périphérique dits applicatifs sont également reliés aux bus de communication.

Deux de ces équipements particuliers, notés 1240 et 1242 sont respectivement reliés aux bus 1202 et 1218 de la figure 20.

Ces périphériques constituent respectivement ce que l'on appelle un périphérique source, noté 1240, et un périphérique destinataire, noté 1242. Ces deux périphériques sont reliés à des bus éloignés l'un de l'autre et qui sont séparés par plusieurs ponts.

Les ponts notés 1220 et 1221 sur la figure 20 constituent des ponts dits d'extrémités et ceux-ci sont séparés l'un de l'autre par plusieurs ponts appelés pont intermédiaires et notés 1222, 1224, 1226, 1228, 1230 et 1232.

Les ponts d'extrémités notés 1220 et 1221 constituent, au sens de l'invention, un premier et un deuxième ponts d'extrémités, le premier pont d'extrémité étant celui à partir duquel un paquet de données de type requête est émis sur le réseau.

Dans le cas représenté à la figure 20, le pont noté 1220 est qualifié de pont "source" et le pont noté 1221 est qualifié de pont "destinataire". Parmi les ponts intermédiaires représentés à la figure 20, deux d'entre eux notés 1226 et 1232 constituent ce que l'on appelle, au sens de l'invention, des ponts "relais".

La définition de ces ponts sera donnée ultérieurement.

Selon un premier mode de réalisation, lorsque le périphérique source 1240 souhaite communiquer un paquet de données au périphérique destinataire 1242 (figure 20) et qu'il ne connaît pas encore le chemin que le paquet de données doit emprunter pour parvenir à destination, alors on utilise le mécanisme d'établissement d'un chemin dans le réseau décrit en référence aux figures 12à17.

Ce mécanisme est basé sur l'émission par le périphérique source d'un paquet de données de résolution d'adresse conforme à la norme IEEE P1 394a (paquet "GASP").

Les ponts sources ont pour rôle de transformer ce paquet de résolution d'adresse en un paquet de résolution d'adresse dont la structure est celle représentée à la figure 13 et qui est diffusé dans tout le réseau de communication 1200.

Ce paquet de résolution d'adresse, une fois reçu au niveau du pont destinataire, déclenche l'émission d'un paquet dit de réponse au paquet de résolution d'adresse qui est retourné au périphérique source de la façon indiquée dans la description faite en référence aux figures 12 à 17.

La figure 21 illustre de manière très schématique le cheminement d'un paquet de données de résolution d'adresse à partir du pont source 1220 jusqu'au pont destination noté 1221.

Ce paquet -noté 1250 au niveau du pont source 1220 est successivement repéré par les références 1252 et 1253 -au niveau, respectivement des ponts relais 1226 et 1232.

Sur la partie droite de la figure 21, une vue très schématique d'une table de routage analogue à celle de la figure 8 est représentée en regard de chaque pont dont elle fait partie.

Plus particulièrement, chacune des tables de routage comporte plusieurs enregistrements élémentaires analogues à ceux représentés par les références 250 à 259 sur la figure 8 et dont un seul est représenté sur la figure 21 pour chacune desdites tables.

Chaque enregistrement élémentaire d'une table de routage comporte les champs référencés 270, 271 et 272 sur la figure 8 et une partie du champ noté 271, dénommé "activ", est réservée à deux champs supplémentaires notés respectivement "index" et "Bridge Type".

Les tables de routage contenues dans chacun des ponts 1220, 1226, 1232 et 1221, sont- respectivement référencées 1260, 1262, 1264 et 1266.

Dans les tables de routage notées 1262, 1264 et 1266, l'enregistrement élémentaire qui est utilisé pour illustrer le principe de la présente invention est respectivement noté 1263, 1265 et 1267.

La table de routage notée 1260 n'est pas utilisée dans la description faite en référence à la figure 21, mais le sera dans la description faite en référence à la figure 23 qui correspond au transfert dans le réseau d'un paquet de réponse audit paquet de résolution d'adresse.

Chaque paquet de résolution d'adresse comporte au moins un champ d'informations de longueur prédéterminée qui est réservé à des informations d'identification d'un chemin pour le paquet dans le réseau, ainsi qu'un champ supplémentaire réservé à un index.

Ces informations d'identification du chemin du paquet dans le réseau représentent le descripteur de chemin dénommé "path descriptor" en terminologie anglo-saxonne et qui est représenté sur les figures 8 et 13.

Ce descripteur de chemin comporte en fait un ensemble de trois champs d'informations : un premier champ d'informations qui représente les informations d'identification du chemin à parcourir par le paquet de données pour parvenir à sa destination (champs notés 201, 202 dans le paquet 199 de la figure 5), un deuxième champ qui représente les informations d'identification du chemin parcouru par le paquet dans le réseau (champs notés 206, 207, 208 dans le paquet de données 199 de la figure 5) et un troisième champ appelé marqueur qui sépare les premier et deuxième champs l'un de l'autre (champs notés 200 et 205 dans le paquet 199 de la figure 5). Les mécanismes de traitement d'informations ayant lieu entre les premier et deuxième champs au sein d'un même paquet de données, qui sont décrits en référence aux figures 1 à 17 et concernent, au niveau de chaque pont, respectivement la suppression d'une information dans le premier champ et l'ajout d'une information dans le deuxième champ, sont repris dans la description de la présente invention.

Il convient de noter que dans les paquets de résolution d'adresse représentés sur la figuré 21 le champ descripteur de chemin est illustré de manière très schématique au niveau de chaque paquet noté 1250, 1252 et 1253 par un bloc référencé respectivement 1250a, 1252a et 1253a.

II convient également de noter que les mécanismes décrits en référence à la figure 11 concernant le routage d'un paquet au niveau d'un pont et qui consistent notamment à déterminer si le pont au niveau duquel se trouve un paquet de données est considéré comme le pont destination sont également repris dans le cadre de la description de la présente invention.

La description de la figure 21 va être faite en référence à la figure 22 qui représente un algorithme sur lequel est basé le procédé de traitement d'un paquet de données selon l'invention et qui est mis en oeuvre au niveau de chaque pont, notamment les ponts dits relais du réseau de communication selon l'invention.

Les différentes instructions ou étapes de ce procédé font partie d'un programme informatique stocké dans la mémoire ROM de chaque pont qui est analogue à la mémoire ROM du pont de la figure 3.

Lors de la réception d'un paquet au niveau d'un pont, l'unité de calcul CPU de chaque équipement d'interconnexion ou "portal" ou de chaque pont, lorsque l'unité de calcul est partagée par les équipements d'interconnexion comme représenté à la figure 3, exécute le programme stocké dans la mémoire ROM et sur lequel est basé l'algorithme de la figure 22.

Lors de l'émission du paquet de données de résolution d'adresse 1250 par le pont source 1220, le champ 1250a du descripteur de chemin est représentatif du chemin parcouru et contient déjà l'identificateur de routage de l'équipement d'interconnexion ou "portal" par lequel le paquet est émis sur le réseau.

II convient également de noter que le paquet de données de résolution d'adresse 1250 comporte également un champ dénommé "index" noté 1250b et qui est par exemple contenu dans le champ noté 568 et dénommé "reserved" du paquet de résolution d'adresse 550 de la figure 13.

Le paquet de résolution d'adresse 1250 est émis à travers le réseau de communication 1200 selon l'invention et est transféré par les ponts intermédiaires 1222 et 1224 avant de parvenir au pont intermédiaire 1226 également appelé premier pont relais.

Lors du transfert de ce paquet de données par les ponts intermédiaires 1222 et 1224, le champ descripteur de chemin dudit paquet qui est rempli par ajout des informations d'identification du chemin retour permettant d'aller du pont relais 1226 au pont source 1220.

Ces informations concernent les identificateurs de routage des équipements d'interconnexion ou "portals" par lesquels le paquet quitte chacun des ponts intermédiaires.

Compte tenu du nombre de bits nécessaire pour coder l'identificateur de chaque équipement d'interconnexion d'un pont et du nombre de ponts présents sur chaque bus, ainsi que de la capacité de stockage limitée des champs d'informations d'identification du paquet, lorsque celui-ci est réceptionné au niveau du pont relais 1226, la taille ou longueur prédéterminée du champ d'informations d'identification du chemin parcouru par le paquet de données est occupée en totalité dans ledit paquet par les informations qui viennent d'être ajoutées (chemin complet) ou ne permet plus de stocker aucune information de routage élémentaire.

Cette condition détermine-le fait que le paquet de données de résolution d'adresse 1250 se situe au niveau d'un pont appelé pont relais.

A ce niveau, le paquet de résolution d'adresse ne peut normalement plus poursuivre son chemin puisque la place laissée libre pour y inscrire les informations d'identification du chemin parcouru est occupée ou du moins n'est plus suffisante pour stocker une information de routage élémentaire.

La présente invention vise justement à remédier à ce problème. L'algorithme représenté à la figure 22 est mis en oeuvre au niveau de chaque pont, mais il ne sera décrit que lorsqu'il est mis en oeuvre au niveau d'un pont relais par souci de simplification.

Ainsi, au niveau du pont relais 1226, lors de la réception du paquet de données 1250 de la figure 21, le procédé selon l'invention prévoit une étape 1270 d'analyse du type de paquet de données reçu.

Si le paquet reçu n'est pas un paquet de résolution d'adresse, alors il est prévu de se placer en attente de réception d'un nouveau paquet de données (le paquet reçu sera traité par un autre algorithme, décrit ultérieurement).

Au contraire, si le paquet reçu est un paquet de résolution d'adresse, comme c'est le cas du paquet 1250, alors l'étape 1270 est suivie d'une étape 1272 au cours de laquelle il est effectué un test quant à savoir si le descripteur de chemin est complet.

Ce test est réalisé en détectant que l'espace utilisé pour mémoriser le chemin parcouru est occupé en totalité ou n'est plus suffisant pour y stocker une information de routage élémentaire.

Dans la négative, cela signifie que le paquet a été reçu par un pont intermédiaire qui n'est pas un pont relais, comme par exemple les ponts notés 1222 et 1224 sur la figure 20, et alors l'étape 1272 est suivie d'une étape 1274 au cours de laquelle le paquet de données est traité de manière appropriée par le pont intermédiaire en question.

Ce traitement est effectué comme indiqué dans la description faite en référence aux figures 11 et 16.

Le paquet est ensuite transmis au pont intermédiaire suivant.

Au contraire, si le descripteur de chemin est complet, alors l'étape 1272 est suivie d'une étape 1276 au cours de laquelle il est vérifié s'il existe dans la table de routage notée 1262 sur la figure 21 un enregistrement correspondant au descripteur de chemin retour. Dans l'affirmative, il est prévu une étape 1278 de mise à jour de l'information de gestion contenue dans le champ dénommé "activ" noté 271 de la table de routage de la figure 8.

Cette étape de mise à jour est plus particulièrement explicitée dans la description faite en référence aux figures 8 et suivantes.

Le champ "activ" peut également être utilisé pour indiquer la durée au-delà de laquelle l'enregistrement n'est plus significatif.

De- retour à l'étape 1276, si cet enregistrement correspondant au chemin parcouru par le paquet jusqu'au pont considéré n'existe pas dans le table de routage 1262, alors l'algorithme comporte une étape 1280 au cours de laquelle un test est pratiqué quant à savoir si le pont considéré est un pont destination. _ Dans le cas présent, le paquet est au niveau du pont relais 1226 et l'étape 1280 est donc suivie d'une étape 1282 au cours de laquelle la variable "Bridge Type" est mise à 1, ce qui signifie que le pont est un pont dit relais.

L'étape suivante notée 1284 consiste à lire dans le paquet de données de résolution d'adresse 1250, d'une part, les informations d'identification du chemin parcouru par ledit paquet de données et correspondant au chemin retour et, d'autre part, un éventuel index.

Dans le cas présent, cet index est fixé à la valeur nulle comme représenté dans le bloc noté 1250b (figure 21), car il s'agit du premier pont relais.

Lors de l'étape 1284, le procédé prévoit également d'allouer une zone mémoire structurée ou enregistrement noté 1263 de la table de routage 1262 et de récupérer un index noté b0 et qui pointe sur la zone mémoire considérée.

Le procédé prévoit ensuite d'écrire dans cette zone mémoire structurée ou enregistrement des informations. Les informations représentatives du chemin parcouru jusqu'au pont relais 1226 (chemin retour) dénommé "backward 0" sont écrites dans le champ noté 1263a, l'éventuel index qui vient d'être lu est écrit dans le champ noté 1263b et la variable "Bridge Type" qui vient d'être déterminée à l'étape 1282 est écrite dans le champ noté 1263c de l'enregistrement 1263.

Dans toute la suite de la description et notamment celle faite en référence aux figures 23 à 27, on utilisera de préférence le terme d'enregistrement à la place de celui de zone mémoire structurée et l'étape d'allocation d'une zone mémoire structurée sera le plus souvent remplacée par une étape de création d'un enregistrement.

L'étape 1284 est alors suivie de l'étape 1278 décrite ci-dessus et d'une étape ultérieure 1286.

Au cours de cette étape 1286, il est procédé à l'effacement des informations représentatives du chemin parcouru par le paquet 1250 du pont 1220 au pont relais 1226 dans ce dernier, afin de libérer la place disponible pour stocker d'autres informations d'identification du chemin parcouru par le paquet de données lors de sa future progression dans le réseau.

Le paquet de données de résolution d'adresse qui va être prochainement émis par le pont relais 1226 est noté 1252 et comporte le bloc noté 1252a contenant l'information de descripteur de chemin qui, ici, contient déjà l'identificateur de routage de l'équipement d'interconnexion ou "portal" par lequel le paquet est émis sur le réseau.

Au cours de l'étape 1286, il est également procédé à l'écriture de la valeur de l'index b0 récupéré précédemment dans le paquet de résolution d'adresse 1252 à l'emplacement prévu à cet effet et représenté par le champ 1252b.

<B>Il</B> convient de noter que l'index b0 qui référence l'enregistrement 1263 contenant le champ 1263a représentatif du chemin parcouru par le paquet depuis le pont source jusqu'au pont relais 1226 permettra ultérieurement de retrouver au niveau de ce pont relais ces informations d'identification du chemin de retour jusqu'au pont source.

Le paquet 1252 est ensuite envoyé dans le réseau de communication et est transféré par les ponts intermédiaires 1228 et 1230 avant de parvenir au deuxième pont relais 1232. II convient de noter qu'au niveau des ponts intermédiaires notés 1228 et 1230, le programme informatique contenu dans la mémoire ROM de chacun des ces ponts et dont l'algorithme est celui de la figure 22 est mis en ceuvre à chaque réception du paquet de résolution d'adresse noté 1252.

Toutefois, étant donné que le descripteur de chemin de ce paquet de données n'est pas complet au niveau de chacun de ces ponts, seules les étapes 1270, 1272 et 1274 de l'algorithme sont exécutées.

- Dans l'exemple représenté sur la figure 21, le paquet de résolution d'adresse 1252 est reçu par le pont relais 1232 et les étapes successives 1270, 1272, 1276, 1280, 1282 et 1284 de l'algorithme de la figure 22 sont alors exécutées.

Au cours de l'étape 1284, il est prévu de lire dans le paquet 1252 le champ d'informations de longueur prédéterminée qui contient les informations d'identification du chemin parcouru par ledit paquet entre le premier pont relais 1226 et le deuxième pont relais 1232 (chemin retour) ainsi que l'index b0 récupéré au niveau du premier pont relais.

Une zone mémoire structurée ou enregistrement 1265 est alors alloué dans la table de routage 1264 du deuxième pont relais 1262 et un index b<B>,</B> référençant cet enregistrement dans ladite table est récupéré.

Au cours de cette même étape 1284, il est également prévu d'écrire dans un champ noté 1265a de l'enregistrement 1265 les informations représentatives du chemin parcouru par le paquet entre les premier et deuxième ponts relais et dénommées "backward_1 ".

Cet enregistrement comporte également deux autres champs notés 1265b et 1265c qui contiennent chacun respectivement l'index b0 récupéré au niveau du premier pont relais et la-variable "Bridge Type" mise à 1.

L'étape 1284 est suivie de l'étape 1278 ainsi que d'une étape 1279 au cours de laquelle un test est effectué sur la valeur de la variable "Bridge Type" par rapport à a valeur "0".

Si le résultat du test s'avère positif, cela signifie que le paquet est au niveau d'un pont destination et l'étape 1279 est suivie d'une étape 1281 au cours de laquelle l'unité de calcul CPU exécute l'algorithme de la figure 16 avant de se placer en attente de réception d'un autre paquet.

Si le résultat du test s'avère négatif, l'étape 1279 est suivie de l'étape ultérieure 1286 au cours de laquelle les informations dénommées "backward-1" sont effacées du champ descripteur de chemin du paquet de résolution d'adresse 1252.

Ainsi, la place occupée par ces précédentes informations est maintenant libérée pour venir y stocker de nouvelles informations d'identification du chemin parcouru par le paquet de données de résolution d'adresse, chemin qui sera élaboré lors de la progression de ce paquet à travers les ponts suivants.

Ces nouvelles informations d'identification de chemin seront stockées dans un bloc du paquet de résolution d'adresse 1253 qui va être émis par le pont relais 1232 au niveau d'un champ d'un bloc noté 1253a.

*L'étape 1286 prévoit également d'écrire la valeur de l'index b1 précédemment récupérée dans le paquet de données de résolution d'adresse 1253, et plus particulièrement au niveau d'un champ noté 1253b.

Le paquet de résolution d'adresse 1253 est alors diffusé sur le réseau en direction du pont destination 1221.

Au niveau de ce pont un traitement approprié effectué sur le paquet de résolution d'adresse 1253 permet de déterminer que celui-ci est arrivé sur le pont destination.

On se rapportera à cet effet à la description faite en référence aux figures 9 à 11 pour de plus amples informations concernant ce.

Il convient de noter que ce traitement est également effectué au niveau de chacun des ponts intermédiaires rencontrés par le paquet sur son chemin. Au niveau de ce pont, les étapes successives 1270, 1272 et 1276 de l'algorithme de la figure 22 sont de nouveau exécutées et comme le pont rencontré est un pont destination, l'étape suivante notée 1280 conduit à l'étape ultérieure notée 1288 au cours de laquelle la variable "Bridge Type" est mise à la valeur 0. L'étape suivante 1284 de l'algorithme sur lequel est basé le procédé selon l'invention prévoit de lire dans le paquet de résolution d'adresse 1253 reçu des informations représentatives du chemin parcouru par ledit paquet depuis le pont relais 1232 jusqu'au pont destination 1221, ainsi que la valeur de l'index noté b1 et créée au niveau dudit pont relais 1232.

Un enregistrement 1267 est alors créé dans la table de routage 1266 du pont destination 1221 et un index noté b2 référençant cet enregistrement est récupéré.

L'exécution de l'algorithme par l'unité de calcul CPU du pont considéré provoque l'écriture dans l'enregistrement noté 1267 des informations d'identification du chemin retour dénommées "backward 2" dans un champ noté 1267a de la valeur de l'index b1 lue dans le paquet 1253 et de la valeur de la variable "Bridge Type" mise récemment à la valeur 0 dans deux champs respectifs notés 1267b et 1267c.

L'étape 1284 est alors suivie de l'étape 1278.

Le paquet est ensuite envoyé après un traitement approprié tel que décrit en référence aux figures 11 et 16 sur le bus de communication série auquel est connecté le périphérique destination 1242.

Etant donné que le paquet de résolution d'adresse qui s'est propagé dans le réseau par diffusion a atteint le pont destination qui possède la connaissance du périphérique destination, il faut maintenant émettre à destination du pont source et du périphérique source un paquet dit de réponse au paquet de résolution d'adresse précédent.

La description qui va suivre faite en référence aux figures 23 et 24 concerne le cheminement d'un tel paquet depuis le pont destination jusqu'au pont source.

Le paquet de données asynchrone de réponse au paquet de résolution d'adresse précédemment décrit a la structure représentée sur la figure 14 sur laquelle, par exemple, le champ "reserved" noté 590 est utilisé pour stocker l'index supplémentaire 1290c, 1312c et 1316c.

II convient de noter que les deux index contenus dans chaque paquet de données asynchrone représenté à la figure 23 peuvent se trouver tous les deux dans le champ "reserved", ou l'un seulement dans ce champ et l'autre dans un autre champ créé à cet effet, ou encore tous les deux dans deux champs distincts prévus à cet effet.

Sur la figure 23, les parties grisées situées dans les paquets de données, d'une part, se rapportent aux index supplémentaires 1290c, 1312c et 1316c et, d'autre part, dans les tables de routage, font référence aux informations représentatives du chemin retour et qui ont été positionnées lors du cheminement du paquet de résolution d'adresse.

Sur la figure 23 on a représenté un paquet de données asynchrone émis par le pont destination 1221 en réponse au paquet de résolution d'adresse 1253 représenté sur la figure 21.

Ce paquet de réponse noté 1290 porte un champ descripteur de chemin noté 1290a qui contient l'information stockée dans le champ 1267a de l'enregistrement élémentaire 1267 qui est pointé par l'index b2, un champ 1290b contenant l'index b1 qui était stocké dans le champ 1267b de l'enregistrement élémentaire 1267 et un champ noté 1290c contenant l'index b2 lui-même.

L'information contenue dans le champ descripteur de chemin 1290a permet au paquet de réponse 1290 de remonter dans le réseau jusqu'au pont relais 1232.

Le paquet de réponse 1290, reçu au niveau du pont relais 1232, est traité au niveau dudit pont conformément au procédé de réception d'un paquet de réponse à un paquet de résolution d'adresse selon l'invention en tenant compte, bien entendu, des particularités propres à la gestion des index.

Le procédé selon l'invention est basé sur un algorithme représenté à la figure 24 et qui est mis en ceuvre au niveau de chaque pont du réseau de communication 1200 de la figure 20.

Les différentes instructions ou étapes de ce procédé font partie d'un programme informatique stocké dans la mémoire ROM de chacun de ces ponts, mémoire qui analogue à la mémoire ROM du pont 1226 représenté sur la figure 3. A la réception du paquet de réponse 1290, l'unité de calcul CPU du pont relais 1232, exécute le programme stocké dans la mémoire ROM de ce pont, comme représenté à la figure 3, et sur lequel est basé l'algorithme de la figure 24.

L'algorithme de la figure 24 comporte, tout comme celui de la figure 22, des étapes notées, pour la figure 24, 1292, 1294, 1296, 1298 et 1300 qui sont respectivement identiques aux étapes 1270, 1272, 1274, 1276 et 1278 de la figure 22 et ne seront donc pas reprises dans le cadre de la présente description.

II convient de noter que le test effectué à l'étape 1294 consiste à déterminer si le chemin à parcourir est vide.

Le procédé selon l'invention prévoit une étape 1302 consécutive à l'étape 1298 et au cours de laquelle il est vérifié si le pont au niveau duquel est reçu le paquet de réponse est un pont source.

Pour ce faire, il est procédé à un test sur la valeur de l'index contenu dans le champ 1290b.

Dans le cas présent, cette étape est suivie de l'étape 1304 analogue à l'étape 1282 de la figure 22 au cours de laquelle la variable "Bridge Type" est mise à la valeur 1.

Le procédé comporte également une étape 1306 au cours de laquelle un enregistrement élémentaire noté 1308 est créé dans la table de routage 1264 du pont relais 1232 et un nouvel index noté f2 pointant sur cet enregistrement est récupéré, tel que représenté à la figure 23.

L'étape 1306 comporte également une opération de lecture dans le paquet de réponse 1290 du descripteur de chemin contenu dans le champ 1290a et de l'index b1 contenu dans le champ 1290b, ainsi que l'index noté b2 contenu dans le champ 1290c.

Le descripteur de chemin dénommé "backward 2" identifiant le chemin à parcourir par le paquet 1290 depuis le pont destination 1221 jusqu'au pont relais 1232 est consommé au fur et à mesure de la progression dudit paquet dans le réseau et, par le biais du mécanisme décrit en référence aux figures 1 à 11, il se transforme, au niveau du pont relais 1232, en descripteur du chemin parcouru par le paquet 1290 entre le pont destination 1221 et le pont relais 1232 et qui est à parcourir pour parvenir du pont relais 1232 au pont destination 1221.

Ce nouveau descripteur de chemin obtenu lorsque le paquet 1290 est réceptionné au niveau du pont relais 1232 est dénommé "forward 2".

Au cours de l'étape 1306 du procédé selon l'invention, il est ensuite prévu d'écrire dans l'enregistrement 1308 de la table de routage 1264 le nouveau descripteur du chemin dénommé "forward 2" dans un champ noté 1308a dudit enregistrement élémentaire, la valeur de l'index b2 lue dans le paquet de données dans un champ noté 1308b et la valeur 1 de la variable "Bridge Type" dans un champ 1308c de ce même enregistrement élémentaire.

L'étape 1306 est ensuite suivie de l'étape 1300 et d'une étape 1301 au cours de laquelle un test est effectué sur la valeur de la variable "Bridge Type" par rapport à la valeur "0".

Si le résultat de ce test est positif, cela signifie que le paquet est au niveau d'un pont source et l'étape 1301 est suivie d'une étape 1303 au cours de laquelle l'unité de calcul CPU exécute l'algorithme représenté à la figure 17.

Si le résultat est négatif, l'étape 1300 est suivie de l'étape ultérieure 1310 au cours de laquelle on procède à une lecture, dans l'enregistrement élémentaire 1265, du prochain descripteur de chemin dénommé "backward_1" déterminé précédemment, en référence à la figure 21 au niveau du pont relais 1232.

Ce descripteur de chemin contient des informations d'identification du chemin à parcourir par le paquet pour parvenir du pont relais 1232 au pont relais 1226.

On procède également -à une lecture dans cet enregistrement de la valeur du prochain index noté b0 qui a également été déterminé au niveau du pont relais 1232 en référence à la figure 21.

L'étape 1310 comporte également une opération d'écriture dans le paquet de réponse noté 1312 destiné à être émis sur le réseau du prochain descripteur de chemin dénommé "backward_1 ", plus particulièrement dans un champ 1312a dudit paquet. On procède également à l'écriture du prochain index b0 dans un champ noté 1312b, ainsi que du nouvel index f2 dans un champ noté 1312c et qui permettra au futur paquet arrivant au niveau du pont relais de retrouver dans la table de routage 1264, le descripteur de chemin "forward 2" qui identifie le chemin à parcourir pour aller dudit pont relais 1232 au pont destination 1221.

Le paquet de réponse 1312 est ensuite émis par le pont relais en direction du prochain pont relais 1226.

De façon analogue à ce qui vient d'être décrit pour le paquet 1290 et le paquet 1312 au niveau du pont relais 1232, le pont relais 1226 procède au même traitement du paquet de réponse 1312 lors du transfert de ce paquet par ledit pont: Les étapes de l'algorithme de la figure 24 qui sont exécutées au niveau du pont relais 1226 sont les mêmes que celles exécutées au niveau du pont relais 1232.

Ainsi, une zone mémoire structurée ou enregistrement élémentaire 1314 comportant trois champs 1314a, 1314b et 1314c est alloué dans la table de routage 1262 du pont relais 1226 et un nouvel index f1 pointant sur cet enregistrement est récupéré.

Dans cet enregistrement, on trouve dans le champ 1314a le descripteur de chemin dénommé "fonward_1" correspondant au chemin à parcourir par un paquet de données pour parvenir du pont relais 1226 au pont relais 1232 et qui a été élaboré lors de la progression du paquet de données 1312 vers le pont relais 1226 par consommation du descripteur de chemin dénommé "backward_1" dudit paquet 1312.

Le descripteur de chemin dénommé "backward 0" déterminé précédemment en référence à la figure 21 au niveau du pont relais 1226 est écrit dans le paquet réponse 1316 au niveau d'un champ noté 1316a.

La valeur nulle de l'index stockée dans le champ 1263b déterminé précédemment en référence à la figure 21 est écrite dans un champ 1316b du paquet 1316 et l'index f1, est également écrit dans un champ noté 1316c du paquet de réponse 1316. Cet index permet de retrouver, au niveau du pont relais 1226, directement, le chemin à parcourir pour parvenir du pont relais 1226 au pont relais 1232, via le descripteur de chemin "forward_1 ", et indirectement, le chemin à parcourir pour parvenir du pont relais 1232 au pont destination 1221, par l'intermédiaire de l'index f2.

Ainsi, les index f1 et f2 permettent de retrouver les informations d'identification du chemin à parcourir par un paquet de données sur le réseau pour parvenir du pont relais 1226 au pont destination 1221.

Le paquet de réponse 1316 est ensuite émis sur le réseau en direction du pont source 1220 et la progression dudit paquet vers le pont source permet, par la consommation du descripteur de chemin "backward 0", d'élaborer le chemin de retour dénommé "forward 0" qui, ajouté aux descripteurs de chemin précédents dénommés "forward_1" et "forward 2" identifie le chemin à parcourir par un paquet de données issu du pont source et destiné au pont destination 1221.

Lorsque le paquet de réponse 1316 est reçu par le pont source 1220, l'unité de calcul CPU dudit pont exécute l'algorithme de la figure 24 et plus particulièrement les étapes 1292, 1294, 1298 et 1302.

Etant donné que le paquet de réponse 1316 est arrivé au niveau du pont source, alors l'étape 1302 est suivie d'une étape 1318 au cours de laquelle la variable "Bridge Type" est mise à la valeur 0.

De façon analogue à ce qui vient d'être décrit au niveau des ponts relais 1226 et 1232, un enregistrement élémentaire 1320 est créé dans la table de routage 1260 du pont source 1220, et est référencé par l'index noté f0 pointant sur cet enregistrement.

Cet enregistrement contient trois champs 1320a, 1320b, 1320c qui contiennent respectivement le descripteur de chemin qui vient d'être élaboré dénommé "forward 0", l'index f1 provenant du paquet 1316 et la valeur 0 de la variable "Bridge Type".

Au niveau du pont source 1220, l'unité de calcul CPU de ce pont exécute l'algorithme de la figure 17. Lorsque le chemin permettant à un paquet de données issu du périphérique source 1240, de parvenir du pont source 1220 au pont destination 1221 est établi, alors on procède à l'émission d'un paquet de données asynchrone sur le réseau à destination du périphérique 1242, comme représenté à la figure 25.

Selon un deuxième mode de réalisation, le transfert d'un paquet de données asynchrone à travers le réseau de communication selon l'invention va maintenant être décrit en référence à la figure 25 et à la figure 26 qui représente l'algorithme sur lequel est basé le procédé de traitement d'un paquet de données asynchrone selon l'invention.

Cet algorithme est mis en oeuvre au niveau de chaque pont du réseau.

Les différentes instructions ou étapes de ce procédé font partie d'un programme informatique stocké dans la mémoire ROM de chacun des ponts du réseau, mémoire qui est analogue à la mémoire ROM du pont 1226 représenté à la figure 3.

Comme représenté sur la figure 25, un paquet de données 1350 émis par le périphérique source 1240 comporte des informations d'identification du chemin pour ledit paquet et qui sont contenues dans l'ensemble des champs d'informations 1350a.

Lorsque le paquet 1350 est réceptionné au niveau du pont source 1220, l'unité de calcul CPU dudit pont exécute l'algorithme représenté à la figure 26 et, au cours d'une étape 1352, vérifie que le paquet reçu est bien un paquet du type asynchrone.

Lorsque le paquet de données n'est pas un paquet de type asynchrone, il est traité au niveau du pont d'une manière différente de celle prévue par l'algorithme de la figure 26 et le procédé prévoit de se placer en attente de réception d'un autre paquet.

Au contraire, dans le cas présent, l'étape 1352 est suivie d'une étape 1354 au cours de laquelle on procède à un test quant à savoir si le paquet se situe au niveau d'un pont source. Dans l'exemple représenté à la figure 25, le paquet se situe au niveau du pont source 1220 et l'étape 1354 est alors suivie d'une étape 1353 au cours de laquelle on détermine si le paquet est un paquet de type requête.

Dans la négative, il s'agit d'un paquet de réponse et, au cours de l'étape suivante 1355, l'unité de calcul CPU exécute l'algorithme de la figure 11. Dans l'affirmative, au cours de l'étape suivante 1356, il est procédé à la lecture de la valeur de l'index notée f0 contenu dans l'ensemble des champs d'informations noté 1350a du paquet de données 1350.

La valeur de cet index permet ainsi de pointer dans la table de routage 1260 du pont source 1220 sur l'enregistrement élémentaire 1320 contenu dans cette table.

On procède alors à une opération d'écriture dans le paquet 1358 qui va être émis par le pont source et qui correspond au paquet 1350 après traitement par ledit pont source.

Plus particulièrement, on écrit dans un champ noté 1358a du paquet 1358 le descripteur de chemin dénommé "forward 0" et qui est contenu dans le champ 1320a de l'enregistrement élémentaire 1320, ainsi que l'index f1 dans un champ noté 1358b dudit paquet.

Cet index f1 a été déterminé précédemment lors de l'établissement du chemin et stocké dans l'enregistrement élémentaire 1320 au niveau du champ 1320b.

Le paquet 1358 est alors émis par le pont source sur le réseau en direction du pont relais 1226 qu'il atteint après avoir traversé les ponts intermédiaires 1222 et 1224.

Lorsque le paquet 1358 est réceptionné par le pont relais 1226, l'unité de calcul de celui-ci exécute l'algorithme représenté à la figure 26 et procède au test de l'étape 1352 qui a déjà été décrit ci-dessus.

Etant donné que le paquet 1358 est un paquet de type asynchrone, alors cette dernière étape est suivie de l'étape 1354 également décrite ci-dessus.

Comme le paquet se situe au niveau du pont relais 1226, cette dernière étape est suivie d'une étape 1360 au cours de laquelle on procède à un test afin de déterminer s'il reste des informations d'identification du chemin à parcourir, c'est-à-dire si le champ d'informations d'identification du chemin à parcourir est vide.

Ce test est réalisé en détectant la présence d'un marqueur dans le paquet de données.

II convient de noter que lorsque cette étape est exécutée au cours du transfert du paquet de données dans un pont intermédiaire tel que les ponts 1222 et 1224, alors le descripteur de chemin n'est pas complet et cette étape est suivie d'une étape 1362 au cours de laquelle on procède à un traitement approprié dudit paquet de données dans le pont intermédiaire considéré, comme décrit en référence à la figure 11.

Au niveau du pont relais 1226, le champ d'informations d'identifications du chemin à parcourir est vide et l'étape 1360 est suivie d'une étape 1364.

Lors de cette dernière étape, on procède à un test afin de déterminer s'il existe dans la table de routage 1262 du pont relais 1226 un enregistrement élémentaire correspondant à l'information descripteur de chemin du paquet de données 1358.

Si cet enregistrement représentatif du chemin retour n'existe pas au niveau de la table de routage, alors l'étape 1364 est suivie d'une étape 1366 au cours de laquelle on procède à l'émission d'un paquet d'erreur vers le pont source.

Au contraire, si comme on l'a vu précédemment, le chemin a bien été établi conformément à la description faite en référence aux figures 21 à 24, alors l'étape 1364 est suivie d'une étape 1368 au cours de laquelle on procède à un test sur la variable "Bridge Type" afin de déterminer si sa valeur est égale à 1 ou non.

Si cette valeur n'est pas égale à 1, alors cela signifie que le paquet se situe au niveau d'un pont destination, comme le pont noté 1221, et il est alors procédé à un traitement approprié du paquet de données en question au niveau de ce pont (étape 1370), de la manière indiquée dans la description faite en référence aux figures 9 à 11. Si au contraire, la valeur de la variable "Bridge Type" est égale à 1, alors cela signifie que le pont est un pont relais (ce qui est le cas du pont 1226) et cette étape est alors suivie d'une étape 1356.

Lors de cette dernière étape, on procède à une opération de lecture de la valeur de l'index f1 contenu dans le champ 1358b du paquet 1358 reçu, permettant ainsi de pointer dans la table de routage 1262 sur l'enregistrement élémentaire correspondant 1314 et ainsi de lire ledit enregistrement.

Au cours de cette même étape, on procède également à une opération d'écriture dans le paquet 1370 qui correspond au paquet 1358 après traitement par le pont relais.

Plus particulièrement, les informations représentatives du chemin à parcourir pour le paquet depuis le premier pont relais 1226 jusqu'au deuxième pont relais 1232, c'est-à-dire le descripteur de chemin dénommé "forward 1" sont écrites dans un champ noté 1370a du paquet 1370.

Ces informations d'identification de chemin pont été obtenues précédemment lors de la description faite en référence aux figures 21 à 24.

On procède également à l'écriture dans un champ noté 1370b du paquet 1370 de la valeur de l'index f2 déterminée également lors de l'établissement du chemin entre le pont source et le pont destination.

Ce paquet 1370 traité est ensuite émis par le premier pont relais 1226 vers le deuxième pont relais 1232 qu'il atteint après avoir été transféré par les ponts intermédiaires 1228 et 1230.

Dans ce deuxième pont relais, les étapes de l'algorithme de la figure 26 qui sont exécutées sont les mêmes que celles exécutées lors du traitement du paquet 1358 par le pont relais 1226 et il s'agit des étapes 1352, 1354, 1360, 1364, 1368 et 1356.

Au cours de l'étape 1356, on procède à la lecture de la valeur de l'index f2 contenu dans le paquet 1370 afin de pointer, à l'aide de cet index, dans la table de routage 1264 sur l'enregistrement élémentaire correspondant noté 1308 et l'on procède également à la lecture de cet enregistrement. Cet enregistrement contient, dans le champ noté 1308a, les informations d'identification du chemin à parcourir entre le pont relais 1232 et le pont destination 1221, également qualifiées de descripteur de chemin dénommé "forward 2", ainsi que la valeur de l'index b2 qui sera utilisée au niveau du pont destination.

Le descripteur de chemin "forward 2" et la valeur de l'index b2 ont été déterminés précédemment lors de l'établissement du chemin entre le pont source et le pont destination.

On procède alors à une opération d'écriture dans le paquet noté 1372 et qui correspond au paquet 1370 après traitement au niveau du pont relais 1232.

Les informations contenues dans le descripteur de chemin dénommé "forward 2" sont écrites dans un champ 1372a du paquet 1372 et la valeur de l'index b2 est également écrite dans un champ 1372b de ce même paquet.

Le paquet ainsi traité est ensuite émis par le deuxième pont relais 1232 vers le pont destination 1221 qui se trouve être le pont suivant (figure 20). L'unité de calcul CPU du pont destination 1221, analogue au pont 1226 représenté sur la figure 3, exécute l'algorithme de la figure 26 et plus particulièrement les étapes notées 1352, 1354, 1360, 1364, 1366, 1368 et 1370.

Les étapes 1352 et 1354 sont identiques à celles décrites précédemment lors du traitement des paquets de données au niveau des ponts relais et ne seront donc pas reprises ici.

L'étape 1360 procède à un test afin de déterminer si le descripteur de chemin du paquet considéré est "complet".

Plus particulièrement, il convient de noter que ce test est réalisé en pratique en détectant la présence du marqueur ou troisième champ d'informations dans l'ensemble des champs réservés aux informations d'identification de chemin.

Si le marqueur est détecté, cela signifie que le champ d'informations d'identification du chemin à parcourir est vide. Lors du transfert d'un paquet de type asynchrone, le test pratiqué à l'étape 1360 est toujours effectué de cette manière.

La description de la détection de ce marqueur qui a été faite en référence aux figures 9 à 11 peut être reprise dans la présente description. Lorsque les informations contenues dans le descripteur de chemin "forward 2" ont été consommées et que les informations contenues dans le descripteur de chemin retour dénommé "backward 2" ont été élaborées, on vérifie, au cours de l'étape suivante 1364, que-ce descripteur de chemin "backward 2" est bien présent dans un enregistrement de la table de routage 1266.

Dans le cas présent, ce descripteur de chemin est présent dans l'enregistrement élémentaire 1267 et plus particulièrement dans le champ 1267a de celui-ci et l'on trouve également la valeur de la variable "Bridge Type" égale à 0 dans le champ 1267c dudit enregistrement.

Ainsi, l'étape suivante 1368 de l'algorithme de la figure 26 est suivie de l'étape 1370 au cours de laquelle un traitement approprié identique à celui décrit en référence aux figures 9 à 11 est effectué au niveau du pont destination 1221 sur le paquet de données reçu 1372, et l'index b2 qui était présent dans le champ 1372b du paquet de données 1372 est alors inséré dans le paquet 1374 correspondant au paquet 1372 après traitement par le pont de destination 1221, et plus particulièrement dans l'ensemble des champs 1374a réservés aux informations d'identification du chemin dudit paquet.

Le paquet 1374 est ensuite transféré sur le bus de communication auquel est relié le pont 1221 et est envoyé sur le périphérique destination 1242. II convient de noter que les ponts relais 1226 et 1232 de la figure 25 contiennent chacun deux index respectivement b0 et f1 pour le pont 1226 et b1 et f2 pour le pont 1232.

Au niveau de chaque pont, l'un des index permet de retrouver les informations d'identification du chemin retour permettant de retourner au pont relais précédent ou au pont source, selon le cas de figure envisagé ("backward 0" et "backward_1 "), et l'autre permet de retrouver les informations d'identification du chemin aller jusqu'au prochain pont relais ou jusqu'au pont destination, selon le cas de figure envisagé ("forward_1" et "forward 2").

En revanche, les tables de routage des ponts source et destination ne comprennent qu'un index pointant chacun sur les informations d'identification permettant de retrouver soit le chemin aller jusqu'au prochain pont relais, soit le chemin retour jusqu'au dernier pont relais.

La figure 27 illustre le cheminement d'un paquet de données asynchrone de réponse au paquet 1374 précédemment reçu (figure 25) à travers le réseau de communication selon l'invention noté 1200.

L'algorithme représenté à la figure 27 et mis en oeuvre au niveau de chacun des ponts du réseau reste le même dans le cas présent.

Le paquet de données de réponse 1380 comporte un ensemble de champs réservés aux informations d'identification du chemin à parcourir par le paquet de données noté 1380a et qui contient l'index b2 précédemment décrit en référence à la figure 25.

II convient de noter que dans la description faite en référence à la figure 27 qui va suivre, on ne reviendra pas sur la description des étapes de l'algorithme de la figure 27 qui sont identiques à celles faites en référence à la description de la figure 25.

II convient toutefois de noter qu'au niveau de ce pont relais le champ d'informations d'identification du chemin à parcourir est vide (marqueur détecté) mais que le champ d'informations d'identification du chemin parcouru n'est pas complet contrairement à ce qui se passait au niveau des ponts 1226, 1232 et 1221 lors de l'émission du paquet asynchrone (figure 25).

L'index b2 contenu dans l'ensemble des champs d'informations 1380a permet de pointer, au niveau de la table de routage 1266, sur l'enregistrement élémentaire 1267 dans lequel sont mémorisées les informations d'identification contenues dans le descripteur de chemin "backward 2", permettant au paquet de données de parvenir du pont destination 1221 au pont relais 1232 et la valeur d'index b1 qui permet de retrouver au niveau du pont relais 1232 les informations d'identification contenues dans le descripteur de chemin pour parvenir dudit pont relais au pont relais suivant noté 1226.

Les information d'identification contenues dans le descripteur de chemin "backward 2" et la valeur de l'index b1 sont respectivement écrites dans deux champs d'un paquet de données 1382 qui est issu du paquet 1380 et obtenu après traitement par le pont destination 1221.

Plus particulièrement, les informations d'identification de chemin "backward 2" sont écrites dans un champ noté 1382a, tandis que la valeur de l'index b1 est écrite dans un champ noté 1382b.

Ce paquet 1382 est émis sur le réseau et parvient au pont relais 1232 au niveau duquel la valeur de l'index b1 est lue dans le paquet 1382, ce qui permet de pointer dans la table de routage 1264 sur l'enregistrement élémentaire 1265.

Cet enregistrement contient le descripteur de chemin dénommé "backward-1" permettant de parvenir du pont relais 1232 jusqu'au pont relais 1226 et la valeur de l'index b0 qui sera utilisée ultérieurement au niveau du pont relais 1226 afin de retrouver le descripteur de chemin permettant de remonter jusqu'au pont source 1220.

Les informations d'identification contenues dans le descripteur de chemin "backward_1" et la valeur de l'index b0 sont respectivement écrites dans deux champs du paquet de données 1384 qui est obtenu à partir du paquet 1382 après traitement dans le pont relais 1232 et sont respectivement notés 1384a et 1384b.

Ce paquet 1384 est émis par le pont relais 1232 et parvient au pont relais 1226 au niveau duquel la valeur de l'index b0 dudit paquet 1384 est lue et permet de pointer dans la table de routage 1262 sur l'enregistrement élémentaire 1263.

Cet enregistrement élémentaire contient le descripteur de chemin dénommé "backward 0" permettant de parvenir du pont relais 1226 au pont source 1220 et la valeur de l'index à 0.

Les informations d'identification contenues dans le descripteur de chemin "backward 0" et la valeur nulle de l'index sont écrites dans deux champs du paquet 1386 qui est obtenu à partir du paquet 1384 après traitement dans le pont relais 1226 et sont respectivement notés 1386a et 1386b.

Lorsque le paquet 1386 parvient au pont source 1220, le test de l'étape 1354 de l'algorithme de la figure 26 conduit à l'étape suivante 1353 au cours de laquelle on détermine s'il s'agit d'un paquet de requête.

Si c'est un paquet de requête, l'étape 1353 est suivie de l'étape 1356 déjà décrite plus haut.

Au contraire si, comme dans le cas présent (paquet réponse), il ne s'agit pas d'un paquet de requête, alors l'étape 1353 est suivie d'une étape 1355 au cours de laquelle un traitement approprié dudit paquet est effectué de manière identique à la description faite en référence à la figure 11.

II convient de noter que l'index présent dans chaque paquet de données de type asynchrone, comme représenté sur les figures 25 et 27, peut être contenu soit dans le champ noté "pri" 85 du paquet de données représenté à la figure 2, soit dans un champ dénommé "extended-tcode" non représenté de ce même paquet.

II convient de noter que le champ "pri" comporte quatre bits qui ne sont pas toujours utilisés selon l'environnement envisagé.

Par exemple, dans un environnement câble qui est défini dans le document "P1394, Draft 8.ov2, July 7, 1995", ce champ n'est pas utilisé.

Dans ce document, il et notamment expliqué que la topologie physique d'un environnement câble est un réseau non cyclique pourvu de branches finies et d'extensions.

II convient également de noter que le champ "extended-tcode" est partiellement utilisé : sur les 16 bits de ce champ seuls les quatre bits de poids faibles sont utilisés, laissant ainsi 12 bits vacants.

Toutefois, l'utilisation d'un tel champ pour stocker la valeur de l'index impose de transformer tout paquet de données de type "data quadlet", c'est-à-dire contenant quatre octets de données en paquet de données de type "data block", c'est-à-dire contenant n octets de données.

Ces définitions ressortent de la norme IEEE 1394-95

Claims (87)

<U>REVENDICATIONS</U>

1. Procédé de traitement d'un paquet de données dans un réseau de communication comportant deux ponts dits d'extrémités séparés l'un de l'autre par au moins un pont dit intermédiaire, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit procédé comporte les étapes suivantes - recevoir ledit paquet de données par un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru par ledit paquet contient un nombre maximum d'informations d'identification dudit chemin et/ou le champ d'informations d'identification du chemin à parcourir par ledit paquet est vide, -faire intervenir, d'une part, une première zone mémoire (1265 ; 1314) dans ledit pont relais et qui comporte un champ d'informations d'identification d'un chemin entre ledit pont relais et un autre pont et, d'autre part, au moins un index (b1, f1) dans le paquet de données et qui permet de retrouver ladite zone mémoire dans ledit pont relais.

2. Procédé selon la revendication 1, caractérisé en ce qu'il comporte les étapes suivantes - allocation de ladite zone mémoire et récupération dudit index (b 1), - écriture dans ladite zone mémoire des informations d'identification du chemin parcouru par le paquet depuis l'autre pont (1226 ; 1221) jusqu'audit pont relais (1232), - écriture dudit index (b1) dans le paquet.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce qu'il comporte une étape d'écriture dans ladite zone mémoire d'un autre index (b0) permettant de retrouver ultérieurement dans l'autre pont appelé également pont relais (1226) une zone mémoire (1263) comportant des informations d'identification du chemin parcouru par le paquet pour parvenir jusqu'à cet autre pont relais (1226).

4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'il comporte une étape d'utilisation de l'index (b1) écrit dans le paquet pour retrouver dans ledit pont relais (1232) les informations d'identification du chemin à parcourir par ledit paquet depuis ledit pont relais jusqu'à l'autre pont (1226).

5. Procédé selon la revendication 4, caractérisé en ce que l'étape d'utilisation de l'index (b1) écrit dans le paquet permet également de retrouver l'index (b0) qui sera utilisé ultérieurement dans l'autre pont (1226) pour retrouver la zone mémoire (1263) comportant des informations d'identification du chemin à parcourir à partir de cet autre pont.

6. Procédé selon la revendication 5, caractérisé en ce qu'il comporte une étape d'écriture de l'index (b0) dans le paquet à la place de l'index (b1).

7. Procédé selon l'une des revendications 1 à 6 , caractérisé en ce qu'il comporte une étape d'écriture, dans le paquet, d'informations d'identification du chemin à parcourir à la place d'informations d'identification du chemin parcouru.

8. Procédé selon l'une des revendications 1 à 7, caractérisé en ce qu'il comporte les étapes suivantes -allocation d'une deuxième zone mémoire (1308) dans ledit pont relais (1232) référencé par un autre index (f2) donné, - écriture dans ladite deuxième zone mémoire d'informations d'identification du chemin parcouru par le paquet depuis l'autre pont (1221) jusqu'audit pont relais (1232), - écriture dudit index (f2) dans le paquet.

9. Procédé selon la revendication 8, caractérisé en ce qu'il comporte une étape d'écriture dans la deuxième zone mémoire (1308) du pont relais (1232) d'un index (b2) permettant de retrouver ultérieurement dans l'autre pont (1221) une zone mémoire (1267) comportant des informations d'identification du chemin parcouru par le paquet depuis ledit pont relais (1232) jusqu'audit autre pont (1221).

10. Procédé selon l'une des revendications 1 à 9, caractérisé en ce qu'il comporte une étape d'utilisation de l'index (f1) écrit dans le paquet pour retrouver dans la zone mémoire (1314) dudit pont relais les informations d'identification du chemin à parcourir depuis ledit pont relais (1226) jusqu'à un autre pont (1232).

11. Procédé selon la revendication 10, caractérisé en ce que l'étape d'utilisation de l'index (f1) écrit dans le paquet permet également de retrouver un deuxième index (f2) qui sera utilisé ultérieurement dans l'autre pont appelé pont relais (1232) pour retrouver une zone mémoire (1308) comportant des informations d'identification du chemin à parcourir à partir de cet autre pont relais.

12. Procédé selon la revendication 11, caractérisé en ce qu'il comporte une étape d'écriture de l'index (f2) dans le paquet à la place de l'index <B>(fi).</B>

13. Procédé selon l'une des revendications 1 à 3, caractérisé en ce que le paquet de données est un paquet de diffusion.

14. Procédé selon l'une des revendications 1, 4 à 9, caractérisé en ce que le paquet de données est un paquet de réponse à un paquet dit de diffusion.

15.Procédé selon l'une des revendications 1, 10, 11, 12, caractérisé en ce que le paquet de données est un paquet asynchrone.

16. Procédé selon l'une des revendications 1 à 15, caractérisé en ce que ledit paquet de données comporte au moins deux champs d'informations dits d'identification du chemin respectivement à parcourir et parcouru par ledit paquet de données, lesdits au moins deux champs d'informations ayant chacun une longueur donnée, ledit procédé comportant les étapes suivantes lors du transfert dudit paquet de données à travers un-pont - suppression d'au moins une première information d'au moins un premier champ d'informations, réduisant ainsi la longueur dudit premier champ d'informations d'une longueur correspondant à celle de ladite première information, -ajout d'au moins une deuxième information dans au moins un deuxième champ d'informations, augmentant ainsi la longueur dudit deuxième champ d'informations d'une longueur correspondant à celle de ladite deuxième information.

17. Procédé selon la revendication 16, caractérisé en ce qu'un pont comportant au moins deux équipements d'interconnexion reliés chacun auxdites au moins deux parties du réseau, au moins un identificateur est affecté à chacun desdits au moins deux équipements d'interconnexion.

18. Procédé selon la revendication 17, caractérisé en ce que lesdits premier et deuxième champs d'informations contiennent des informations relatives audit au moins un identificateur de chaque équipement d'interconnexion du ou des ponts disposés sur le chemin du paquet de données dans le réseau.

19. Procédé selon la revendication 18, caractérisé en ce que ledit premier champ d'informations contient des informations relatives audit au moins un identificateur de chaque équipement d'interconnexion sur le chemin à parcourir parle paquet de données dans le réseau.

20. Procédé selon la revendication 17, caractérisé en ce que ladite au moins une première information supprimée dudit au moins un premier champ d'informations correspond audit au moins un identificateur de chaque équipement d'interconnexion du pont qui est relié à la partie du réseau par laquelle le paquet de données parvient audit pont.

21. Procédé selon l'une des revendications 17 à 20, caractérisé en ce que ledit deuxième champ d'informations contient des informations relatives audit au moins un identificateur de chaque équipement d'interconnexion du ou des ponts disposés sur le chemin parcouru par le paquet de données dans le réseau.

22. Procédé selon la revendication 21, caractérisé en ce que ladite au moins une deuxième information ajoutée audit au moins un deuxième champ d'informations correspond audit au moins un identificateur de l'équipement d'interconnexion pont qui est relié à la partie du réseau par laquelle le paquet de données quitte ledit pont.

23. Procédé selon l'une des revendications 16 à 22, caractérisé en ce que le paquet de données comporte un troisième champ d'informations dit marqueur qui délimite les premier et deuxième champs d'informations l'un par rapport à l'autre.

24. Procédé selon les revendications 17 et 23, caractérisé en ce que le marqueur a une longueur au moins égale au nombre de bits nécessaire pour coder un identificateur d'équipement d'interconnexion d'un pont dans l'un des champs d'informations.

25. Procédé selon la revendication 24, caractérisé en ce qu'il comporte, lors du transfert dudit paquet de données à travers un pont, une étape de décalage des premier, deuxième et troisième champs d'informations entre les étapes de suppression et d'ajout d'informations.

26. Procédé selon l'une des revendications 24 à 25, caractérisé en ce que la longueur totale des premier, deuxième et troisième champs est fixe.

27. Procédé selon l'une des revendications 1 à 26, caractérisé en ce que chaque partie du réseau à laquelle est connectée un pont comporte un bus de communication.

28. Procédé selon la revendication 27, caractérisé en ce que le bus de communication est du type conforme à la norme IEEE 1394.

29. Procédé d'émission d'un paquet de données dans un réseau de communication entre deux ponts dits d'extrémités séparés l'un de l'autre par plusieurs ponts dits intermédiaires, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit procédé comporte une étape d'émission dudit paquet. de données à partir d'un premier pont d'extrémité, ledit au moins un champ contenant des informations d'identification du chemin à parcourir depuis ledit premier pont d'extrémité jusqu'à un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru par ledit paquet contient un nombre maximum d'informations d'identification dudit chemin et/ou le champ d'informations d'identification du chemin à parcourir par ledit paquet est vide, ledit paquet de données comportant également un index permettant de retrouver au niveau dudit pont relais des informations représentatives du chemin à parcourir depuis ledit pont relais jusqu'au deuxième pont d'extrémité.

30. Procédé selon la revendication 29 caractérisé en ce que le paquet de données est un paquet dit de réponse à un paquet dit de diffusion émis par le deuxième pont d'extrémité.

31. Procédé selon la revendication 30, caractérisé en ce que les informations d'identification du chemin à parcourir depuis ledit premier pont d'extrémité jusqu'au pont relais sont obtenues à partir des informations d'identification du chemin parcouru par le paquet de données de diffusion depuis le pont relais jusqu'au premier pont d'extrémité.

32. Procédé selon la revendication 30 ou 31, caractérisé en ce que les informations d'identification du chemin à parcourir depuis le pont relais jusqu'au deuxième pont d'extrémité sont obtenues à partir d'un index permettant de retrouver au niveau dudit pont relais les informations représentatives du chemin parcouru depuis le deuxième pont d'extrémité jusqu'au pont relais.

33. Procédé selon la revendication 29, caractérisé en ce que le premier pont est appelé pont source et le deuxième pont est appelé pont destination.

34. Procédé selon l'une des revendications 29 à 32, caractérisé en ce que le premier pont est appelé pont destination et le deuxième pont est appelé pont source.

35. Procédé de réception d'un paquet de données émis sur un réseau de communication entre deux ponts dits d'extrémités séparés l'un de l'autre par plusieurs ponts dits intermédiaires, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit procédé comporte une étape de réception au niveau d'un premier pont d'extrémité dudit paquet de données émis par un deuxième pont d'extrémité, ledit au moins un champ contenant des informations d'identification du chemin parcouru depuis un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru par ledit paquet contient un nombre maximum d'informations d'identification dudit chemin et/ou le champ d'informations d'identification du chemin à parcourir par ledit paquet est vide, ledit paquet comportant également un index permettant de retrouver au niveau dudit pont relais des informations représentatives du chemin parcouru depuis le deuxième pont jusqu'audit pont relais.

36. Procédé selon la revendication 35, caractérisé en ce que le paquet de données est un paquet de diffusion.

37. Procédé selon la revendication 35, caractérisé en ce que le paquet de données est un paquet de réponse à un paquet dit de diffusion émis par le premier pont d'extrémité.

38. Procédé selon la revendication 37, caractérisé en ce que le paquet de réponse comporte la totalité des informations représentatives du chemin à parcourir depuis le premier pont d'extrémité jusqu'au deuxième pont d'extrémité, celles-ci étant obtenues à partir, d'une part, des informations d'identification du chemin parcouru depuis le pont relais jusqu'au premier pont d'extrémité et, d'autre part, de l'index.

39. Procédé selon la revendication 36, caractérisé en ce que le premier pont est appelé pont destination et le deuxième pont est appelé pont source.

40. Procédé selon l'une des revendications 37 à 38, caractérisé en ce que le premier pont est appelé pont source et le deuxième pont est appelé pont destination.

41. Dispositif de traitement d'un paquet de données dans un réseau de communication comportant deux ponts dits d'extrémités séparés l'un de l'autre par au moins un pont dit intermédiaire, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit dispositif comporte - des moyens pour recevoir ledit paquet de données par un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru par ledit paquet contient un nombre maximum d'informations d'identification dudit chemin et/ou le champ d'informations d'identification du chemin à parcourir par ledit paquet est vide, - des moyens pour faire intervenir, d'une part, une première zone mémoire (1265 ; 1314) dans ledit pont relais et qui comporte un champ d'informations d'identification d'un chemin entre ledit pont relais et un autre pont et, d'autre part, au moins un index (b1, f1) dans le paquet de données et qui permet de retrouver ladite zone mémoire dans ledit pont relais.

42. Dispositif selon la revendication 41, caractérisé en ce qu'il comporte - des moyens d'allocation de ladite zone mémoire et récupération dudit index (b1), - des moyens d'écriture dans ladite zone mémoire des informations d'identification du chemin parcouru par le paquet depuis l'autre pont (1226 ; 1221) jusqu'audit pont relais (1232), - des moyens d'écriture dudit index (b1) dans le paquet.

43. Dispositif selon la revendication 41 ou 42, caractérisé en ce qu'il comporte des moyens d'écriture dans ladite zone mémoire d'un autre index (b0) permettant de retrouver ultérieurement dans l'autre pont appelé également pont relais (1226) une zone mémoire (1263) comportant des informations d'identification du chemin parcouru par le paquet pour parvenir jusqu'à cet autre pont relais (1226).

44. Dispositif selon l'une des revendications 41 à 43, caractérisé en ce qu'il comporte des moyens pour retrouver dans ledit pont relais (1232) les informations d'identification du chemin à parcourir par ledit paquet depuis ledit pont relais jusqu'à l'autre pont (1226), à partir de l'index (b1) écrit dans le paquet.

45. Dispositif selon la revendication 44, caractérisé en ce qu'il comporte des moyens pour retrouver dans ledit pont relais (1232), à partir de l'index (b1) écrit dans le paquet, l'index (b0) qui sera utilisé ultérieurement dans l'autre pont (1226) pour retrouver la zone mémoire (1263) comportant des informations d'identification du chemin à parcourir à partir de cet autre pont.

46. Dispositif selon la revendication 45, caractérisé en ce qu'il comporte des moyens d'écriture de l'index (b0) dans le paquet à la place de l'index (b1).

47. Dispositif selon l'une des revendications 41 à 46, caractérisé en ce qu'il comporte des moyens d'écriture, dans le paquet, d'informations d'identification du chemin à parcourir à la place d'informations d'identification du chemin parcouru.

48. Dispositif selon l'une des revendications 41 à 47, caractérisé en ce qu'il comporte -des moyens d'allocation d'une deuxième zone mémoire (1308) dans ledit pont relais (1232) référencé par un autre index (f2) donné, - des moyens d'écriture dans ladite deuxième zone mémoire d'informations d'identification du chemin parcouru par le paquet depuis l'autre pont (1221) jusqu'audit pont relais (1232), - des moyens d'écriture dudit index (f2) dans le paquet.

49. Dispositif selon la revendication 48, caractérisé en ce qu'il comporte des moyens d'écriture dans la deuxième zone mémoire (1308) du pont relais (1232) d'un index (b2) permettant de retrouver ultérieurement dans l'autre pont (1221) une zone mémoire (1267) comportant des informations d'identification du chemin parcouru par le paquet depuis ledit pont relais (1232) jusqu'audit autre pont (1221).

50. Dispositif selon l'une des revendications 41 à 49, caractérisé en ce qu'il comporte des moyens pour retrouver dans la zone mémoire (1314) dudit pont relais les informations d'identification du chemin à parcourir depuis ledit pont relais (1226) jusqu'à un autre pont (1232), à partir de l'index (f1) écrit dans le paquet.

51. Dispositif selon la revendication 50, caractérisé en ce qu'il comporte des moyens pour de retrouver dans la zone mémoire (1314), à partir de l'index (f1) écrit dans le paquet, un deuxième index (f2) qui sera utilisé ultérieurement dans l'autre pont appelé pont relais (1232) pour retrouver une zone mémoire (1308) comportant des informations d'identification du chemin à parcourir à partir de cet autre pont relais.

52. Dispositif selon la revendication 51, caractérisé en ce qu'il comporte des moyens d'écriture de l'index (f2) dans le paquet à la place de l'index (f1).

53. Dispositif selon l'une des revendications 41 à 43, caractérisé en ce que le paquet de données est un paquet de diffusion.

54. Dispositif selon l'une des revendications 41, 44 à 49, caractérisé en ce que le paquet de données est un paquet de réponse à un paquet dit de diffusion.

55. Dispositif selon l'une des revend ications4l, <B>50, 51, 52,</B> caractérisé en ce que le paquet de données est un paquet asynchrone.

56. Dispositif selon l'une des revendications 41 à 55, caractérisé en ce qu'il comporte une zone mémoire (1265 ; 1314) référencée par un index (b0, b1, f1) et comportant, d'une part, des informations d'identification du chemin parcouru par le paquet depuis l'autre pont (1220 ; 1226 ; 1221) jusqu'audit pont relais (1226 ; 1232) et, d'autre part, un index (b0, f2) permettant de retrouver ultérieurement dans ledit autre pont une zone mémoire (1263) comportant des informations d'identification du chemin parcouru par le paquet pour parvenir jusqu'à cet autre pont.

57. Dispositif selon l'une des revendications 41 à 56, caractérisé en ce qu'il comporte une zone mémoire (1314 ; 1308) référencée par un index (f2) comportant, d'une part, des informations d'identification du chemin à parcourir par le paquet depuis ledit pont relais (1226 ; 1232) jusqu'à l'autre pont (1232 ; 1221) et, d'autre part, un index (b2) permettant de retrouver ultérieurement dans cet autre pont des informations d'identification du chemin à parcourir par le paquet depuis cet autre pont jusqu'à un deuxième autre pont (1221 ; 1232).

58. Dispositif selon l'une des revendications 41 à 57, caractérisé en ce que ledit paquet de données comportant au moins deux champs d'informations dits d'identification du chemin respectivement à parcourir et parcouru par ledit paquet de données, lesdits deux champs d'information ayant chacun une longueur donnée, ledit dispositif comportant - des moyens de suppression d'au moins une première information d'au moins un premier champ d'informations, réduisant ainsi la longueur dudit premier champ d'informations d'une longueur correspondant à celle de ladite première information, - des moyens d'ajout d'au moins une deuxième information dans au moins un deuxième champ d'informations, augmentant ainsi la longueur dudit deuxième champ d'informations d'une longueur correspondant à celle de ladite deuxième information.

59. Dispositif selon la revendication 58, caractérisé en ce qu'un pont comportant au moins deux équipements d'interconnexion reliés chacun auxdites au moins deux parties du réseau, au moins un identificateur est affecté à chacun desdits au moins deux équipements d'interconnexion.

60. Dispositif selon l'une des revendications 58 à 59, caractérisé en ce que lesdits premier et deuxième champs d'informations contiennent des informations relatives audit au moins un identificateur de chaque équipement d'interconnexion ou "portal" du ou des ponts disposés sur le chemin du paquet de données dans le réseau.

61. Dispositif selon l'une des revendications 58 à 60, caractérisé en ce que le paquet de données comporte un troisième champ d'informations dit marqueur qui délimite les premier et deuxième champs d'informations l'un par rapport à l'autre.

62. Dispositif selon la revendication 61, caractérisé en ce qu'il comporte des moyens de décalage des premier, deuxième et troisième champs d'informations.

63. Dispositif selon la revendication 61 ou 62, caractérisé en ce que la longueur totale des premier, deuxième et troisième champs est fixe.

64. Dispositif d'émission d'un paquet de données dans un réseau de communication entre deux ponts dits d'extrémités séparés l'un de l'autre par plusieurs ponts dits intermédiaires, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit dispositif comporte des moyens d'émission dudit paquet de données à partir d'un premier pont d'extrémité, ledit au moins un champ contenant des informations d'identification du chemin à parcourir depuis ledit premier pont d'extrémité jusqu'à un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru contient un nombre maximum d'informations d'identification dudit chemin et/ou le champ d'informations d'identification du chemin à parcourir est vide, ledit paquet de données comportant également un index permettant de retrouver au niveau dudit pont relais des informations représentatives du chemin à parcourir depuis ledit pont relais jusqu'au deuxième pont d'extrémité.

65. Dispositif selon la revendication 64, caractérisé en ce que le paquet de données est un paquet dit de réponse à un paquet dit de diffusion émis par le deuxième pont d'extrémité.

66. Dispositif de réception d'un paquet de données émis sur un réseau de communication entre deux ponts dits d'extrémités séparés l'un de l'autre par plusieurs ponts dits intermédiaires, chacun desdits ponts interconnectant au moins deux parties dudit réseau, ledit paquet comportant au moins un champ d'informations de longueur prédéterminée réservé à des informations d'identification d'un chemin dans le réseau, caractérisé en ce que ledit dispositif comporte des moyens de réception au niveau d'un premier pont d'extrémité dudit paquet de données émis par un deuxième pont d'extrémité, ledit au moins un champ contenant des informations d'identification du chemin parcouru depuis un pont intermédiaire appelé pont relais et au niveau duquel le champ d'informations d'identification du chemin parcouru contient un nombre maximum d'informations d'identification dudit chemin et/ou le champ d'informations d'identification du chemin à parcourir est vide, ledit paquet comportant également un index permettant de retrouver au niveau dudit pont relais des informations représentatives du chemin parcouru depuis le deuxième pont jusqu'audit pont relais.

67. Dispositif selon la revendication 66, caractérisé en ce que le paquet de données est un paquet de diffusion.

68. Dispositif selon la revendication 66, caractérisé en ce que le paquet de données est un paquet de réponse à un paquet dit de diffusion émis par le premier pont d'extrémité.

69. Dispositif selon la revendication 68, caractérisé en ce que le paquet de réponse comporte la totalité des informations représentatives du chemin à parcourir depuis le premier pont d'extrémité jusqu'au deuxième pont d'extrémité, celles-ci étant obtenues à partir, d'une part, des informations d'identification du chemin parcouru depuis le pont relais jusqu'au premier pont d'extrémité et, d'autre part, de l'index.

70. Pont relais d'un réseau de communication disposé entre deux ponts dits d'extrémités et interconnectant au moins deux parties dudit réseau de communication, caractérisé en ce qu'il comporte un dispositif de traitement d'un paquet de données selon l'une des revendications 41 à 63.

71. Pont d'extrémité d'un réseau de communication interconnectant au moins deux parties dudit réseau de communication, caractérisé en ce qu'il comporte un dispositif d'émission d'un paquet de données selon l'une des revendications 64 à 65 et/ou un dispositif de réception d'un paquet de données selon l'unes des revendications 66 à 69.

72. Appareil de traitement de données d'un réseau de communication, caractérisé en ce qu'il comporte un dispositif de traitement d'un paquet de données selon l'une des revendications 41 à 43.

73. Appareil de traitement de données d'un réseau de communication, caractérisé en ce qu'il comporte un dispositif d'émission d'un paquet de données selon l'une des revendications 64 à 65 et/ou un dispositif de réception d'un paquet de données selon l'unes des revendications 66 à 69.

74. Appareil de traitement de données, caractérisé en ce qu'il comporte un pont conforme à l'une des revendications 70 à 71.

75. Appareil selon la revendication 74, caractérisé en ce que ledit appareil est une imprimante.

76. Appareil selon la revendication 74, caractérisé en ce que ledit appareil est un serveur.

77. Appareil selon la revendication 74, caractérisé en ce que ledit appareil est un ordinateur.

78. Appareil selon la revendication 74, caractérisé en ce que ledit appareil est un télécopieur.

79. Appareil selon la revendication 74, caractérisé en ce que ledit appareil est un scanner.

80. Appareil selon la revendication 74, caractérisé en ce que ledit appareil est un magnétoscope.

81. Appareil selon la revendication 74, caractérisé en ce que ledit appareil est un décodeur.

82. Appareil selon la revendication 74, caractérisé en ce que ledit appareil est un téléviseur.

83. Appareil selon la revendication 74, caractérisé en ce que ledit appareil est une caméscope.

84. Appareil selon la revendication 74, caractérisé en ce que ledit appareil est une caméra numérique.

85. Appareil selon la revendication 74, caractérisé en ce que ledit appareil est un appareil photographique numérique.

86. Réseau de communication comportant au moins deux parties interconnectées par au moins un pont, caractérisé en ce que ledit pont est conforme à l'une des revendications 70 à 71.

87. Réseau de communication, caractérisé en ce que ledit réseau comporte un appareil de traitement de données selon l'une des revendications 72à85.