FR2791502A1 - Procede et dispositif de determination d'un chemin d'un paquet de donnees dans un reseau de communication - Google Patents

Abstract

L'invention concerne un procédé de détermination d'un chemin d'un paquet de données dans un réseau de communication (10) comportant au moins deux bus de communication série (503, 523) reliés par eux par au moins un pont (508), caractérisé en ce qu'il comporte les étapes suivantes :- réception au niveau dudit pont (508) d'un paquet de données dit de diffusion, émis sur un premier bus (503) par un pont dit source (510) et comportant au moins un champ d'un premier type identifiant au moins un périphérique (D) auquel est destiné ledit paquet et au moins un champ d'un deuxième type comportant des informations représentatives d'un chemin parcouru par ledit paquet depuis ledit pont source jusqu'audit pont,- comparaison dudit au moins un champ de premier type par rapport à au moins une valeur prédéterminée dite de fin de transfert de paquet afin de déterminer si la paquet réceptionné est destiné à l'un des périphériques reliés audit premier bus.

Description

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

détermination d'au moins un chemin d'un paquet de données dans un réseau de communication comportant au moins deux bus de communication série

reliés entre eux par au moins un pont.

La présente invention concerne aussi bien le transfert d'informations entre deux parties d'un réseau qui sont des sous réseaux de constitution et de performances différentes que le transfert d'information entre

deux sous réseaux de même nature.

Une partie d'un réseau est également appelée sous-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 que l'on nomme des "ponts" ("bridges" en

terminologie anglo-saxonne).

On entend par pont tout équipement de liaison entre deux ou

plusieurs parties d'un réseau.

Le pont permet ainsi 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.

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 est plus particulièrement un équipement comportant au moins deux portions constitutives dudit pont, appelées "portais" en terminologie anglosaxonne et permettant de relier entre eux au moins deux bus de communication série 1394. Un "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 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 généralement appelés noeuds.

Chaque périphérique situé sur un bus du réseau peut vouloir communiquer avec un autre périphérique du réseau situé sur un autre bus du reseau, les deux bus sur lesquels ces périphériques 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 "portals" dudit pont vers un autre bus disposé de l'autre côté dudit pont et connecté à un autre "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 "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 "portais" 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 portai 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, I'adresse de la destination est codée dans un premier champ d'informations dit d'identification de l'en-tête du paquet de données de longueur fixe, appelé champ destination, et l'adresse de la source dudit paquet de données est codée dans un deuxième champ d'informations dit d'identification de l'en-tête 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 "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 portai est relié à des bus différents et doit donc, de ce fait,

30. 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.

Ces réseaux de transfert de paquets de données présentent plusieurs inconvénients, à commencer par la complexité des mécanismes de configuration, aussi bien pour l'attribution des numéros de bus que pour la

gestion de ces numéros dans la table de routage.

En outre, ces réseaux nécessitent une gestion centralisée qui doit

déterminer, lors de l'initialisation du réseau, la topologie dudit réseau, c'est-à-

dire la façon dont sont reliés entre eux les différents bus. Pour ce faire, il est nécessaire d'établir un protocole d'échange entre les différents bus afin de

mettre en place cette gestion centralisée.

Ces réseaux doivent attribuer un numéro à chaque bus et ce

numéro est unique dans un réseau donné.

Il convient de noter que lorsque deux réseaux sont interconnectés par un pont afin de former un seul et même réseau, chaque réseau formant une partie dudit réseau final, il faut d'abord élire celui des deux équipements centralisés ou "prime portais" des deux réseaux qui va devenir l'équipement

centralisé ou "prime portal" du réseau final.

Ensuite, étant donné qu'un numéro a déjà été attribué à chaque bus de chaque réseau préalablement à leur réunion, la numérotation de chaque bus devra donc être corrigée pour garder l'unicité de numérotation des bus et

toutes les tables de routage devront être reconfigurées.

Par ailleurs, ces réseaux génèrent des trafics d'informations dites protocolaires d'autant plus importants que lesdits réseaux sont constitués d'un nombre important d'éléments, ce qui pénalise considérablement la capacité du

réseau à véhiculer des informations utiles pour les périphériques dudit réseau.

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 noeuds 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, I'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 portion constitutive d'un pont ou "portal" sur un bus est de trois, il faut deux bits pour coder l'adresse ou

I'identificateur de chaque "portai" de façon unique.

Le champ destination de l'en-tête des paquets de données peut

donc contenir quatre identificateurs de "portals" différents.

Le nombre maximal 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 de "portals" autorisés sur un bus augmente, plus il est nécessaire d'avoir un nombre élevé de bits pour coder l'identificateur de ces portais et donc plus la distance

maximale entre la source d'un paquet de données et sa destination est faible.

Le brevet US 5 613 069 précédemment mentionné, décrit également un procédé de détermination de chemin qui met en oeuvre des commutateurs particuliers qui ont une connaissance de la topologie. L'inconvénient d'un tel système est la gestion de ces commutateurs particuliers

et les mécanismes de découvertes de topologie qui leur sont associés.

On connaît aussi des mécanismes de détermination de chemin ne nécessitant pas d'équipements centralisés tels que par exemple ceux utilisés dans les réseaux de type Ethernet, plus connu sous le nom d'ARP ou protocole

de résolution d'adresse, ("Address Resolution Protocol" en terminologie anglo-

saxonne). Cependant un tel protocole ne s'applique pas à un mécanisme de

routage a la source.

D'une manière générale, lorsqu'un périphérique dit source souhaite communiquer avec un autre périphérique dit destination d'un réseau de communication de bus série, il es nécessaire de connaître le chemin entre

ces deux périphériques.

En fait, il faut surtout connaître le chemin entre deux ponts dits respectivement source et destination qui sont connectés respectivement à deux

bus auxquels les périphériques source et destination sont reliés.

Par ailleurs, le chemin doit être déterminé en utilisant un mécanisme de routage à la source pour s'affranchir de la connaissance

préalable de la topologie du réseau.

La présente invention vise ainsi à résoudre ce problème en proposant un procédé de détermination d'un chemin d'un paquet de données dans un réseau de communication comportant au moins deux bus de communication série reliés par eux par au moins un pont, caractérisé en ce qu'il comporte les étapes suivantes: - réception au niveau dudit pont d'un paquet de données dit de diffusion, émis sur un premier bus par un pont dit source et comportant au moins un champ d'un premier type identifiant au moins un périphérique auquel est destiné ledit paquet et au moins un champ d'un deuxième type comportant des informations représentatives d'un chemin parcouru par ledit paquet depuis ledit pont source jusqu'audit pont, comparaison dudit au moins un champ de premier type par rapport à au moins une valeur prédéterminée dite de fin de transfert afin de déterminer si la paquet réceptionné est destiné à l'un des périphériques reliés

audit premier bus.

Corrélativement, l'invention vise un dispositif de détermination d'un chemin d'un paquet de données dans un réseau de communication comportant au moins deux bus de communication série reliés par eux par au moins un pont, caractérisé en ce qu'il comporte: - des moyens de réception au niveau dudit pont d'un paquet de données dit de diffusion, émis sur un premier bus par un pont dit source et comportant au moins un champ d'un premier type identifiant au moins un périphérique auquel est destiné ledit paquet et au moins un champ d'un deuxième type comportant des informations représentatives d'un chemin parcouru par ledit paquet depuis ledit pont source jusqu'audit pont, -des moyens de comparaison dudit au moins un champ de premier type par rapport à au moins une valeur prédéterminée dite de fin de transfert afin de déterminer si la paquet réceptionné est destiné à l'un des

périphériques reliés audit premier bus.

Avantageusement, I'invention propose d'émettre à partir du pont source un paquet de diffusion qui, au fur et à mesure de son transfert à travers différents ponts du réseau, élabore le chemin parcouru par ledit paquet jusqu'au

dernier pont traversé.

Lorsque le paquet est réceptionné au niveau du pont considéré, ledit paquet renferme déjà en lui-même les informations représentatives du chemin parcouru et l'invention prévoit de réaliser un test sur le champ de premier type afin de déterminer si le paquet a atteint le pont destination et donc si ce paquet détient ainsi les informations sur le chemin parcouru entre le pont

source et le pont destination.

On notera que le problème résolu par l'invention énoncée ci-

dessus peut être considéré comme un sous-problème d'un problème consistant, plus précisément, à connaître le chemin permettant d'aller du pont

source au pont destination.

A cet effet, les informations représentatives du chemin parcouru jusqu'au pont destination vont, par exemple, pouvoir être utilisées pour envoyer en retour au pont source un paquet de réponse qui, lui, contiendra alors les informations nécessaires pour émettre des données du pont source au pont destination. Selon une première caractéristique, la valeur prédéterminée de fin de transfert est représentative de l'identification de tous les périphériques

connectés au premier bus.

Avantageusement, ceci permet de savoir si le paquet a atteint le

bus sur lequel se trouve le périphérique destinataire.

Selon une autre caractéristique, l'étape de comparaison fait

intervenir au moins le champ de deuxième type.

Ainsi si le champ de second type est entièrement consommé, alors le paquet ne peut atteindre le périphérique destinataire et la distance entre

les deux périphériques est trop importante.

En outre, la valeur prédéterminée de fin de transfert est

représentative d'une fin de chemin.

De plus, la détermination du chemin prend fin lorsque le nombre d'informations représentatives du chemin parcouru atteint ladite valeur prédéterminée. Avantageusement, ceci permet de savoir si l'on a atteint le bus destinataire. Selon une autre caractéristique, le champ d'informations d'identification comporte au fur et à mesure du transfert du paquet de réponse dans le réseau, des informations représentatives du chemin parcouru par ledit

paquet depuis le pont destination.

Ceci permet de construire facilement le chemin au fur et a mesure

de la propagation du paquet.

Selon une caractéristique particulière, le procédé comporte une étape de réception dudit paquet de réponse au niveau du pont source, ledit paquet comportant la totalité des informations représentatives du chemin parcouru depuis le pont destination jusqu'au pont source et qui déterminent le

chemin recherché.

Ceci permet au pont source de connaitre le chemin de la source vers le destinataire en récupérant le chemin dans ce paquet de réponse. Selon une autre caractéristique, le procédé comporte un test sur des informations représentatives du chemin à parcourir dans le paquet de réponse afin de s'assurer que ledit pont réceptionnant ledit paquet est le pont source. Ceci permet effectivement au pont source de recevoir la réponse

et non pas à un autre pont présent aussi sur le pont source.

Selon une autre caractéristique, le procédé comporte une étape

de réception d'un autre paquet de réponse de manière décalée dans le temps.

Avantageusement ceci permet de recevoir plusieurs réponses si les périphériques source et destination peuvent utiliser différents chemins pour communiquer. Selon une autre caractéristique lorsque le pont reçoit de manière décalée dans le temps, plusieurs paquets de réponse déterminant chacun un chemin parcouru, ledit procédé comporte une étape de sélection d'un des

chemins parcourus.

Avantageusement, ceci permet de contrôler la charge du réseau et de choisir le chemin en se basant sur différents critères comme la destination

la plus courte par exemple ou la moins utilisée par d'autres paquets.

De plus, lorsque plusieurs autres ponts sont reliés au bus auquel est connecté un périphérique dit source et le pont source, ledit procédé comporte au niveau dudit pont source une étape de détection d'un paquet de données destiné audit périphérique source et émis sur ledit bus par au moins

un autre pont.

Ceci permet avantageusement au périphérique source de ne recevoir qu'une seule réponse si plusieurs ponts présents sur le bus source ont reçu des paquets de réponse du pont destination et évite d'encombrer le bus

source par une pluralité de réponses inutiles.

Selon une autre caractéristique, le procédé comporte une étape d'émission sur un bus auquel est relié, d'une part, un périphérique dit source et, d'autre part, ledit pont source d'un paquet de données destiné audit

périphérique source.

Ainsi le périphérique source peut récupérer le chemin que le pont

source a reçu dans la réponse envoyée par le pont destinataire.

Selon une autre caractéristique, l'étape de réception d'un paquet de réponse précède l'étape d'émission d'un paquet de données destiné au

périphérique source.

Ainsi dès que le pont source a reçu la réponse du pont destinataire, il envoie cette réponse dans un paquet d'un autre format par

exemple au périphérique source.

Selon une autre caractéristique, lorsque plusieurs autres ponts sont reliés au bus auquel est connecté un périphérique dit source et le pont source, un seul parmi tous ces ponts est autorisé à émettre un paquet de

données destiné au périphérique source.

Ceci permet avantageusement au périphérique source de ne pas

avoir à faire le choix du chemin et lui simplifie le travail.

Selon une autre caractéristique les bus de communication série

sont conformes à la norme IEEE 1394.

Chaque bus de communication série d'un tel réseau relie différents 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...

Selon un deuxième aspect, I'invention vise un procédé de réception d'un paquet de données transmis dans un réseau de communication comportant au moins deux bus de communication série reliés entre eux par au moins un pont, caractérisé en ce qu'il comporte une étape de réception au niveau dudit pont appelé pont source, en provenance d'un premier bus, d'un paquet dit de réponse émis par un pont dit destination, en réponse à un paquet dit de diffusion émis par ledit pont source et comportant un champ d'informations dites d'identification comportant des informations représentatives d'un chemin parcouru par ledit paquet de diffusion jusqu'audit pont destination, ledit paquet de réponse comportant des informations représentatives du chemin qu'il a parcouru du pont destination au pont source. Selon une caractéristique particulière, caractérisé ledit paquet de données de réponse comporte deux extrémités opposées et 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'information ayant chacun une longueur donnée, caractérisé en ce que, lesdits au moins deux champs d'informations étant situés à une même extrémité du paquet de données, ledit procédé comporte les étapes suivantes lors du transfert dudit paquet de données à travers ledit 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. Avantageusement, I'invention permet d'étendre la taille ou

longueur du champ d'informations d'identification alloué à la description d'un

chemin, étant donné que la taille variable du premier champ compense celle du deuxième champ. Ceci permet d'augmenter, sur le chemin que parcourt le paquet de données, le nombre de ponts intermédiaires placés entre la source et

la destination du paquet.

Selon une caractéristique particulière, au moins un identificateur

est attribué audit pont.

Le fait d'attribuer un seul identificateur illustre la simplicité de la phase de configuration dans le procédé du transfert de paquets selon

l'invention. Grâce au procédé, il n'y a pas de configuration de tables de routage.

Selon une autre caractéristique, ledit pont comporte au moins deux portions reliées chacune auxdites au moins deux parties du réseau, au

moins un identificateur est attribué à chacune desdites au moins deux portions.

Ainsi, les deux portions du pont sont gérées de manière indépendante. Le fait que ces portions possèdent chacune leur propre

identificateur permet aussi de simplifier la configuration du réseau.

Selon une caractéristique particulière, lesdits premier et deuxième champs d'informations contiennent des informations relatives audit au moins un identificateur du ou des ponts disposés sur le chemin du paquet de données

dans le réseau.

Avantageusement, la décision sur le transfert d'un pont à l'autre

est effectuée sur une simple comparaison de l'identificateur.

Selon une autre caractéristique, ledit premier champ d'informations contient des informations relatives audit au moins un identificateur du ou des ponts disposés sur le chemin à parcourir par le paquet

de données dans le réseau.

Le routage à la source simplifie en effet la mise en oeuvre du routage dans les ponts intermédiaires placés entre la source et la destination du paquet. Selon une autre caractéristique, lorsque le pont considéré comporte au moins deux portions reliées chacune auxdites au moins deux parties du réseau et qu'au moins un identificateur est attribué à chacune desdites au moins deux portions, ladite au moins une première information supprimée dudit au moins un premier champ d'informations correspond audit au moins un identificateur de la portion du pont qui est reliée à la partie du réseau

par laquelle le paquet de données parvient audit pont.

Avantageusement, la consommation de l'information représentative du chemin à parcourir par le paquet entre la source et la destination est effectuée au niveau de chaque pont en fonction de la progression du paquet dans le réseau, ce qui permet de libérer la place utilisée

par l'information déjà traitée.

Selon une autre caractéristique, 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.

Avantageusement, le marqueur permet de déterminer qu'un champ est sur le point d'être totalement consommé par suite des suppressions consécutives d'informations dans ledit champ à chaque traversée d'un pont. Le marqueur sert ainsi au dernier bus pour savoir que le périphérique destinataire

est sur ledit bus.

Selon une autre caractéristique, lors du transfert dudit paquet de données à travers ledit 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. La zone d'informations libérée par suite de la suppression d'une information dans le premier champ d'informations est donc immédiatement

utilisée par le deuxième champ d'informations.

Ainsi, le marqueur est déplacé après chaque passage au travers d'un pont et sa position varie en fonction de la distance (exprimée en nombre

de ponts traversés) parcourue par le paquet entre la source et la destination.

Corrélativement, I'invention vise un dispositif de réception d'un paquet de données transmis dans un réseau de communication comportant au moins deux bus de communication série reliés entre eux par au moins un pont, caractérisé en ce qu'il comporte des moyens de réception au niveau dudit pont appelé pont source, en provenance d'un premier bus d'un paquet dit de réponse émis par un pont dit destination, en réponse à un paquet dit de diffusion émis par ledit pont source et comportant un champ d'informations dites d'identification comportant des informations représentatives d'un chemin parcouru par ledit paquet de diffusion jusqu'audit pont destination, ledit paquet de réponse comportant des informations représentatives du chemin qu'il a

parcouru du pont destination au pont source.

Selon un troisième aspect, I'invention vise un pont reliant au moins deux bus de communication série d'un réseau de communication de paquets de données, caractérisé en ce que ledit pont comporte un dispositif de détermination d'au moins un chemin d'un paquet de données comme exposé ci-dessus. Selon un quatrième aspect, I'invention vise un pont reliant au moins deux bus de communication série d'un réseau de communication de paquets de données, caractérisé en ce que ledit pont comporte un dispositif de

réception d'un paquet de données comme exposé ci-dessus.

Selon un cinquième aspect, I'invention vise un appareil de traitement des données, caractérisé en ce qu'il comporte un pont conforme au

bref exposé 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 sixième aspect, I'invention vise un réseau de communication de paquets de données comportant au moins deux bus de communication reliés par au moins un pont, caractérisé en ce que ledit pont est

conforme à ce qui précède.

Selon un septième aspect, I'invention vise un réseau de communication de paquets de données comportant au moins deux bus de communication reliés par au moins un pont, caractérisé en ce que ledit réseau

comporte un appareil de traitement de données tel que brièvement exposé ci-

dessus. 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 oeuvre du procédé de détermination d'un chemin d'un paquet de données dans un réseau ou du procédé 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 détermination d'un chemin d'un paquet de données dans un réseau de communication ou du procédé 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 détermination d'un chemin d'un paquet de données dans un réseau de communication ou du procédé de réception d'un

paquet de données tel que brièvement exposé ci-dessus.

Les avantages et caractéristiques propres au procédé et au dispositif de réception d'un paquet de données, au dispositif de détermination d'un paquet de données dans un réseau de communication, au pont reliant au moins deux bus de communication série d'un réseau et comportant de tels dispositifs, à l'appareil de traitement de données comportant un tel pont, 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 détermination d'un chemin d'un paquet de données dans un réseau de

communication 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 selon l'invention - 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 IEEE1394-95 - la figure 3 est une vue schématique détaillée d'un appareil de traitement de données comportant selon l'invention 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 transfert 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 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 du procédé de transfert de paquets selon l'invention; - 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 du procédé de réception d'un paquet de résolution d'adresse au niveau d'un portai d'un pont selon l'invention; la figure 17 est une vue schématique de l'algorithme du 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 portai d'un pont selon l'invention; - la figure 18 est une vue schématique de l'algorithme du 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 du 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 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, le périphérique 68, connecté au bus 52, peut initier une transaction avec le 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 le procédé de transfert de paquets selon l'invention.

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 "destinationID" 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 appelé champ d'identification du chemin à parcourir

par le paquet de données.

Le champ "source_lD" 81 ("Source Identifier" en terminologie anglosaxonne), représenté sur 16 bits, contient l'information de routage permettant d'atteindre le périphérique source. Ce champ 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.

11 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 "tl" 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.

L'invention concerne plus particulièrement l'analyse et le traitement des champs 80 et 81 d'un paquet asynchrone lors du transfert d'un

paquet entre un périphérique source et un périphérique destination.

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, 18 et 19 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 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 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 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 selon I'invention ne correspond pas nécessairement au pont lui-même. Il peut ainsi, en effet, en représenter un sous-ensemble formé, par exemple, des différents éléments permettant de mettre en oeuvre 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 oeuvre 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'entête est mise en oeuvre par un bloc logique de contrôle 34 et les

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 PHY/LINK 1394 est par exemple constitué d'un composant PHY TSB21LV03A et d'un composant LINK TSB12LV01A commercialisés par la société Texas Instruments et de connecteurs 1394, par exemple commercialisé par la société

Molex, par exemple sous la référence 53462.

Ces blocs physiques correspondent aux au moins deux portions du pont qui forment chacune ce que l'on appelle un "portai" en terminologie anglosaxonne. 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 PHY/LINK 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 PHY/LINK 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 PHY/LINK 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 PHY/LINK 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 ("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.

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 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 le 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 selon l'invention.

Dans la description, un registre dont le nom est suffixé par "_30"

ou "_32" appartient aux blocs respectifs 30 et 32 décrits précédemment en

figure 4.

Le registre 91 "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.

Le registre 92 "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 composant 30.

Le registre 93 "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. Le registre 94 "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 composant 32.

Le registre 97 "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 "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 dans le mode de

réalisation de l'invention.

Parmi l'ensemble des "portais" connectés à un même bus 1394 la

norme P1394.1 prévoit la détermination d'un "portal" 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'attribuer de la même manière un identificateur

de routage constant et unique à chaque "portai" d'un même bus.

Un identificateur de routage ainsi déterminé, par exemple par rapport au bus 56 pour le pont 66, est stocké dans le registre 91 et identifie le "portai" ou bloc de composants 30 de la figure 3. De même, un identificateur de routage ainsi déterminé, par exemple par rapport au bus 58 pour le pont 66, est stocké dans le registre 93 et identifie le "portai" ou bloc de composants 32 de la

figure 3.

Le registre 95 "routingtable_30" de la figure 4, représenté sur 960 bits, représente la table de routage associée au bloc de composants ou "portai" 30, utilisé lors du transfert de paquets émis depuis le bus 56, en ce qui

concerne le pont 66.

Le registre 96 "routingtable_32", représenté sur 960 bits, représente la table de routage associée au bloc de composants 32, 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.

Les registres 91, 92, 93, 94, 95, 96 et 97, représentés figure 4,

sont situés dans la 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 de destination, 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 destination.

Ainsi, lorsqu'aucun des "portais" d'un pont considéré n'est connecté ni au bus du périphérique source, ni au bus du périphérique de destination, 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.

La figure 5 illustre l'un des avantages de l'invention.

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 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 ou adresses des "portais" à prendre en compte respectivement par les ponts 66 et 67 pour transférer le paquet

asynchrone jusqu'au périphérique destination 69.

Les champs 208, 207 et 206, représentés chacun sur 3 bits, contiennent les identificateurs de routage ou adresses des "portais" à 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 champs 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.

Le champs 204, représenté sur 6 bits, contient l'information qui permet au pont 61 d'identifier le périphérique émetteur 68 du paquet

asynchrone parmi tous les périphériques du bus 52.

Les champs 200 et 205 dont l'ensemble est représenté sur 5 bits, dont tous les bits de des champs sont positionnés a "1", contiennent le 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 au sens de l'invention 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 au sens de l'invention et identifient le chemin

déjà parcouru par le paquet de données 199.

Il convient de noter que les premier et deuxième champs au sens

de l'invention peuvent inclure respectivement les champs 203 et 204.

Les champs 200 et 205 forment ce que l'on appelle, au sens de

l'invention, un troisième champ d'informations ou marqueur.

Dans le cas du paquet 216, 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és 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 de destination 69. Il 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, ensemble représentés 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, dont tous les bits sont positionnés à "1", contient le marqueur délimitant le champ 211, d'une part, des champs 209 à 215, d'autre part. Il correspond aux champs 205 et 200 du

paquets 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, mettant en oeuvre l'invention, a, d'une part, supprimé du premier champ d'informations au sens de l'invention 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 au sens de l'invention une deuxième information

constituée par les bits "011" du registre 77 d'identification du "portai" 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, I'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é selon l'invention 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 champs 80 et 81.

Lorsque l'un des "portais" du pont est connecté au bus du périphérique de destination, le pont est dit pont de "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 de "destination", sur les champs 80 et 81 du paquet asynchrone 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 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, 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, tous positionnés à "1", est

représentatif d'un paquet asynchrone destiné au bus local.

Le champ "offset" noté 223 est ajouté par le pont 67 alors que le champ 224 contient l'identificateur de routage ou adresse du "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.

On notera que dans le paquet 226, tous les bits du champ 80 sont positionnés à "1" afin d'identifier le paquet asynchrone 226 comme un paquet

asynchrone local, susceptible d'être reçu par l'un des périphériques du bus 59.

Lors du transfert du paquet 216 a travers le pont 67, ce dernier mettant en oeuvre le procédé selon l'invention, a supprimé d'un premier champ d'informations au sens de l'invention qui est formé du champ 211, et éventuellement du champ 203, 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.

Le pont 67 a ensuite ajouté dans un deuxième champ d'informations au sens de l'invention qui est formé des champs 213, 214 et 215, et éventuellement du champ 204, une deuxième information constituée par les bits "000" du registre 79 d'identification du "portai" considéré. Cette deuxième

information est représentée par le champ 224.

Ce deuxième champ d'informations identifie le chemin qu'a parcouru le paquet 216 et ce sera le chemin dit de "retour" qui lui permettra,

éventuellement, d'être renvoyé au périphérique source qui l'a émis.

Le troisième champ d'informations au sens de l'invention

correspond au marqueur noté 210 et précédemment évoqué.

Le procédé selon l'invention 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. 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 204, représenté sur 6 bits, contient l'information qui permet au pont 61 d'identifier le périphérique émetteur 68 du paquet

asynchrone parmi tous les périphériques du bus 52.

Lorsque l'un des "portals" du 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 du paquet asynchrone qu'il transfère depuis le bus 59 vers le bus 58, selon le sens

indiqué par la flèche 239.

Le paquet asynchrone 245 é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 245 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 245, le champ destination 80 est décomposé en plusieurs champs 241, 242 et 243 et le champ source 81 est

également décomposé en plusieurs champ 246 et 244.

Le champ "offset" 241 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 de destination 68. Le champ 242 contient l'identificateur de

routage du pont 67 associé au bus 59 et stocké dans le registre 79.

Le champ 246, représenté sur 10 bits, 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 230, 231, 232, 233 et 243 et le champ source

81 est également décomposé en plusieurs champs 234, 235, 236 et 238.

Les champs 233, 232 et 231, représentés chacun sur 3 bits, ainsi que les champs 230 et 234, ensemble représentés sur 3 bits, contiennent les identificateurs de routage ou adresses des "portais" à 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 236, 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 235, représenté sur 5 bits, dont tous les bits sont positionnés a "1", contient le marqueur délimitant les champs 230 a 234, d'une

part, du champ 236, d'autre part.

A la réception du paquet 245, le pont 67 lit et analyse la valeur du champ 242 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 245 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 230, 231, 232, 233 et 234 représentatifs du chemin à parcourir jusqu'au périphérique destination 68 et le champ 236 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" 241 du paquet 245 qu'il aura préalablement communiqué au périphérique émetteur 69, par exemple, par l'intermédiaire d'un paquet asynchrone. Ainsi, si, par exemple, le paquet 245 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 241 et 242 du paquet 245 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 234, 235 et 236 du paquet 240 de la figure 7. De même, la valeur des champs 212, 213, 214 et 215 du paquet 206 est égale respectivement a la

valeur des champs 230, 231, 232 et 233 du paquet 240.

Lors du transfert du paquet 245 à travers le pont 67, ce dernier mettant en oeuvre la procédé selon l'invention a supprimé, d'un premier champ d'informations au sens de l'invention qui est formé des champs "offset" 241 et 242, et éventuellement du champ 243, une première information constituée par les bits "000" du champ 242 lui-même. Ce premier champ d'informations

identifie le chemin restant à parcourir au paquet de données 245.

Le pont 67 a ensuite ajouté dans un deuxième champ d'informations au sens de l'invention qui est formé du champ 238, une deuxième information constituée par les bits "011" du registre 78 d'identification du "portai" considéré. Cette deuxième information est représentée par le champ 236. Ce deuxième champ d'informations identifie le chemin qu'a parcouru le paquet 216 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 qui l'a émis.

Le troisième champ d'information au sens de l'invention correspond à une partie du champ 246 qui est transformés dans le paquet 240

en un champ 235 appelé "marqueur".

Le procédé selon l'invention 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.

Ainsi, on comprend que, lors du transfert d'un paquet par un pont, l'identificateur du "portal" par lequel arrive le paquet est supprimé du premier champ d'informations car il est devenu inutile et l'identificateur du "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.

Il 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 "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".

Le champ 244, représenté sur 6 bits, identifie le périphérique 69 parmi tous les périphériques du bus 59. Le champ 244 du paquet 245 a été remplacé par le champ 238 dans le paquet 240. La valeur du champ 238 permet au pont 67 d'identifier le périphérique 69 parmi tous les périphériques

du bus 59.

Le champ 243, représenté sur 6 bits, contient l'information qui permettra au pont destination 61 d'identifier le périphérique destinataire 68 du

paquet asynchrone parmi tous les périphériques du bus 52.

L'utilisation et la gestion du champ "offset" 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 stockée dans la mémoire RAM de chaque 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, "1", "2", "3", "4",

"5", "6", "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 destination distant.

Le champ 272 "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", 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 le "portal" et est remis à zéro à chaque utilisation de l'information "descripteur de chemin d'informations" ou de l'index. Ce champ permet ainsi

d'optimiser la gestion de la mémoire de la table de routage.

Il 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 271 "local_busbit 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 formés par ces deux champs, 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é ré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 271 "local_busbitmap" 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 du 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 245 du bus 59 vers le bus 58.

Au cours de l'étape 801, le procédé comporte une étape de réception d'une requête de récupération d'un descripteur de chemin à partir

d'un index donné.

Au cours de l'étape 802, 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 803. Dans le cas négatif, le procédé retourne une information signifiant qu'aucun descripteur de chemin

n'est valide pour ledit index (étape 805).

Au cours de l'étape 803, 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, I'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 805).

Dans le cas o l'information est valide, l'étape 803 est suivie de

l'étape 804.

Au cours de l'étape 804, 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 la 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 801 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 du 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 oeuvre dans le pont 67 de la

figure 6 lors du transfert du paquet 206 du bus 58 vers le bus 59.

Au cours de l'étape 811, le procédé comporte une étape de réception d'une requête de récupération d'un index à partir d'un descripteur de

chemin donné.

Au cours de l'étape 812, le procédé comporte une étape de vérification que le descripteur de chemin en question est présent dans la table

de routage.

Dans le cas positif, l'étape 812 est suivie de l'étape 815, au cours de laquelle le procédé met à jour le cas échéant les informations de gestion relatives a l'enregistrement élémentaire, et retourne l'index correspondant audit

descripteur de chemin.

Concernant les informations de gestion relatives à l'enregistrement élémentaire, on peut notamment citer les deux actions suivantes: Premièrement, quand la 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 813 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 814, un index est alloué

et utilisé pour stocker le descripteur de chemin d'informations.

Le bit parmi l'ensemble des 64 bits (indexés de 0 à 63) correspondant à 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 au cours d'une étape 816, le procédé procède à la libération d'un ou plusieurs index (et donc d'enregistrement(s)

élémentaire(s)) dans la table de routage.

L'étape suivante 817 consiste à vérifier si l'étape de libération a pu se faire avec succès. Dans le cas positif, l'étape 814 précédemment décrite est à nouveau effectuée. Dans le cas négatif, au cours d'une étape 818, 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

811 est exécutée de nouveau.

La figure 11 représente un algorithme mettant en oeuvre le procédé de routage des paquets asynchrones au niveau d'un pont selon le

mode préféré de réalisation de l'invention.

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_BuslD, S_BuslD, in_RI, out_RI, path_register) ont été introduites pour faciliter la compréhension de

l'algorithme décrivant le procédé.

Le procédé débute par l'étape 100 de 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 101 d'analyse de l'identificateur

du bus de destination DBuslD compris dans l'en-tête dudit paquet.

Dans la suite de la description, D_BuslD représente l'information

du champ "destination_lD" 1 de la figure 2, de même S_BuslD représente

l'information du champ "source_lD" 3).

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 101 est suivie par l'étape 102 consistant, puisque ce paquet est local audit bus, à rejeter le paquet sans autre traitement. L'étape 102 est

suivie par l'étape 100 d'attente d'un nouveau paquet asynchrone.

Lorsqu'au cours de l'étape 101 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 103 et 104 sont exécutées.

Dans la suite de la description, selon le mode préféré de

réalisation de l'invention, I'information ou identificateur (ou label) de routage du descripteur de chemin de destination, est lue dans les bits de poids faibles du champ D_BuslD, l'information ou identificateur (ou label) de routage du descripteur de chemin parcouru, est écrite dans les bits de poids faibles du champ S_BuslD, les bits étant décalés d'un champ à l'autre de façon adéquate : Par exemple, décalage à droite du champ D_BuslD, décalage à gauche du champ S_BuslD, chaque bit issu du décalage à gauche du bit de poids fort du champ S_BuslD étant inséré, après décalage à droite des bits du champ

D_BuslD, à la place du bit de poids fort du champ D_BuslD.

D'autres variantes consistant à combiner lecture/écriture des informations de routage des descripteurs de chemin sur les poids fortslfaibles des champs DBuslD et S_BuslD avec les décalages adéquats ne sont pas

décrites dans la présente description.

L'étape 103 consiste à déterminer l'identificateur ou label de routage du descripteur de chemin de destination in_RI; pour ce faire l'identificateur ou information de routage est extraite du champ D_BuslD d'une longueur ou taille (en bits) égale au contenu du registre "routingwidth_30" 92

(figure 4) associé au "portal" d'entrée ("inbound portal" en terminologie anglo-

saxonne). Dans l'exemple de la figure 5, le champ D_BuslD vaut 1111 011 0012, la valeur "routing_width_30" étant égale à 3, le label de routage

in_RI est égal à 0012.

Une fois la valeur de l'identificateur ou label de routage in_RI du paquet connue, l'étape 104 permet de la comparer au contenu du registre "routing_label_30" 91 constituant l'identificateur ou label unique par bus affecté audit "portal" sur lequel le paquet en question à été reçu. Si les deux valeurs sont différentes, alors l'étape 105 est exécutée. Elle consiste à rejeter le paquet

puis à passer à l'étape 100 du début du procédé présenté.

Dans le cas contraire, c'est-à-dire lorsque les valeurs in_RI et "routinglabel_30" sont égales, l'étape 104 est suivie du test 106 afin d'analyser l'identificateur du bus de source SBuslD compris dans l'entête du paquet traité. Si ledit identificateur est égal à 3FF16, 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é 245 en figure 7); son en-tête sera traité suivant les étapes 110, 111, 112, 113 ou 114 et 115 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é 205 en figure 5). Le traitement de son en-tête suit

alors les étapes 120 et 121 également décrites ci-dessous.

Pendant l'étape 110, on extrait du champ DBuslD du paquet un index ("offset" en terminologie anglo-saxonne) de routage (précédemment

défini dans la description des figures 6 et 7) en tenant compte de la valeur

"routing_width_30" 92 mentionnée ci-dessus lors de l'explication de l'étape 103.

Cet index ("offset") est constitué des (10 - routingwidth_30) bits de poids forts

du champ D_BuslD, 10 étant la largeur dudit champ D_BuslD.

Par exemple, dans le cas o le champ D_BuslD vaut 0001101 0002 et la valeur "routingwidth_30" est égale à 3, l'index sera égal à

00011012.

Ensuite, pendant l'étape 111, ledit index ("offset") est converti en identificateur 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 801 à 805).

Le test 112 consiste à vérifier si un tel identificateur de chemin a été trouvé au cours du procédé cité. Dans le cas négatif, on exécute l'étape 113 consistant à rejeter le paquet traité. Dans des variantes de mise en oeuvre de la présente invention, des procédés de traitement d'erreur plus sophistiqués (non représentés dans les figures) peuvent être envisagés au cours de l'étape 113. De tels procédés pourraient consister, par exemple, à envoyer un acquittement négatif au périphérique originaire du 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 anglosaxonne).

L'étape 113 est suivie par l'étape 100 d'attente d'un nouveau

paquet à traiter.

Dans le cas positif du test 112, I'identificateur ou descripteur du chemin, retourné par l'opération 111, est stocké dans le registre path_register au cours de l'étape 114. Le registre path_register est utilisé pour la gestion des descripteurs de chemin (destination et parcouru) et est avantageusement composé de deux sous-champs, chacun de ces sous-champs correspondant aux informations respectivement contenues dans les champs DBuslD et SBuslD. Ensuite, au cours de l'étape 115, 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 244 du paquet de la figure 7 par l'identificateur virtuelcorrespondant, ceci en utilisant la table de conversion appropriée établie lors de chaque réinitialisation ("bus reset" en terminologie anglo-saxonne) du bus source 52 (figure 1). Cette table établissant la correspondance entre identificateurs physiques et virtuels est bien connue à l'homme du métier et n'est donc pas décrite ici. L'étape 115 est suivie par

l'étape 130 dont la description est faite plus loin.

De retour à l'étape 106, si l'identificateur est différent de 3FF16, alors celle-ci est suivie de l'étape 120 du traitement d'un paquet reçu à partir d'un bus intermédiaire qui consiste à charger (mémorisation) le registre path_register à partir des identificateurs de bus D_BuslD et S_BuslD extraits respectivement des champs "source_lD" 81 et "destination_lD" 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_BuslD et S_BuslD mentionné précédemment (comme par exemple, décalage à droite du champ D_BuslD, décalage à gauche du champ S_BuslD, chaque bit issu du décalage à gauche du bit de poids fort du champ S_BuslD étant inséré, après décalage à droite des bits du champ D_BuslD, à la place du

bit de poids fort du champ D_BuslD).

Ensuite, au cours de l'étape 121, le contenu du registre path_register est transformé de la façon énoncé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 la séquence de longueur maximale composée d'au moins 2*max_width 1 ("max_width" étant la valeur du registre 97 de la figure 4) bits consécutifs à "1" constituant le 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é en figure 5, la séquence comporte 5 bits à "1": la séquence "011 0012" décrit le chemin de destination, et la séquence "011 010 0112" décrit le chemin parcouru. On note 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 à "1"; ceci ne constitue toutefois pas un problème pour

le fonctionnement correct de l'algorithme décrit.

On effectue un décalage dans le registre path_register, selon le mode de gestion adopté, d'un nombre de bits égal à routing_width_30 des bits du champ descripteur du chemin de destination (identificateur du chemin à parcourir). Les bits non significatifs, suite au décalage, se trouvent positionnés a "1", les bits du marqueur n'étant 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 à routing_width_30 (à droite dans le champ "destinationbus _lD" 91 de la figure 2) et occupent maintenant le champ référencé 202, les bits devenus non significatif 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. On note que la taille ou longueur en bits du marqueur se trouve dans la manipulation précédente

augmenté d'un nombre égal à routing_width_30.

On effectue un décalage dans le registre path_register, selon le mode de gestion adopté, d'un nombre de bits égal à routing_width_32 des bits du marqueur du chemin parcouru (identificateur du chemin parcouru), un nombre de bits égal à routing_width_32 des bits du marqueur se trouvant alors écrits. Rappelons ici que le registre "routingwidth_32" 94 associé au "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 150 exécutée ultérieurement. Dans l'exemple de la figure 5, les bits d'informations des champs 205, 206 et 207, décrivant le chemin parcouru, ont été décalé d'un nombre de bits égal à routingwidth_32 (à gauche dans le champ "source_bus_lD" 93 de la figure 2 puis à droite dans le champ "destination_bus_lD" 91 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 150.

Lors des différentes phases mentionnées ci-dessus et qui ont lieu au cours de l'étape 121, 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érieur à la valeur routing_width_30, alors la longueur du marqueur est augmentée de la différence. On note 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, représenté

par le champ 210, sa longueur étant restée de 5 bits.

Dans le mode préféré de mise en oeuvre de la présente invention, la taille ou longueur des identificateurs ou labels de routage est fixe dans tout le réseau. Ceci implique que les registres "routing_width_30" 92, "routing_width_32" 94 et "maxwidth" 97 comportent la même valeur dans chaque pont du réseau. On notera que pour la mise en oeuvre de ce mode préféré de réalisation, 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

I'hypothèse d'une longueur variable des identificateurs ou labels de routage).

Dans une variante de réalisation, les registres "routingwidth_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 121 est suivie par les étapes 130 de lecture du champ composé des "routing_width_32" du premier champ (équivalent de D_BuslD) du registre path_register et par le test 131 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 140, 141, 142 et 143 sont exécutées, sinon on

passe aux étapes 150 et 151.

Pour une meilleure compréhension de la description des étapes

à 143 du traitement d'un paquet arrivant sur son bus de destination 69, le

lecteur est prié de se référer à la figure 6.

Lors de l'étape 140, le champ 216 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 conversion appropriée.

L'étape 141 consiste à convertir l'identificateur du chemin parcouru contenu dans le registre path_register en index 233 ("offset") selon le

procédé approprié décrit ci-dessus (figure 10, étapes 811 à 818).

Pendant l'étape 142, 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 "routinglabel_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 143, 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 160.

Au cours de l'étape 150 (lorsque les bits lus ne sont pas tous égaux à "1"), les bits identifiant le chemin parcouru du registre path_register (nombre indiqué par routing_width_32) sont initialisés avec l'identificateur ou label de routage 93 stocké dans le registre "routing_label_32" associé au

"portal" situé sur le bus de sortie du paquet traité.

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

l'étape 160.

L'étape 160 consiste à transférer le paquet sur le bus 58 respectivement 59. Cette étape est suivie par l'étape 100 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. Ce paquet dit de résolution d'adresse est envoyé par un équipement source 513 afin de d'obtenir le 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 portai 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 Gallager, 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 de l'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 portai 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 son autre portal, le cas échéant sur chacun de ses autres portals, notamment en fonction d'une précédente réception de ce même paquet. Les portais doivent entre autre à cette fin gérer une table de vérification dite de " diffusion " comme par exemple celle décrite en figure 15. Dans le cas o ce paquet doit être diffuser sur un bus, le portai en question met à jour le descripteur de chemin qui permettra de directement router le paquet réponse vers l'équipement à l'origine du paquet de résolution d'adresse. La diffusion de ce paquet de résolution

d'adresse est décrite dans la figure 12 par les flèches 520, 521, 522 et 523.

Lorsque chaque portai d'un même pont sont regroupés dans un seul dispositif tel que celui décrit figure 3, une seule table de vérification dite de

"diffusion" commune peut être utilisée pour les portais d'un pont donné.

Sur un bus donné, chaque portai, possédant en interne une table des EUI64 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 pas sur le bus. Dans le cas positif, le portai du pont 506 par exemple du bus 501 stoppe la diffusion du paquet de résolution d'adresse et émet un paquet de données asynchrone de réponse 530 au pont 508 qui transfert cette réponse sous forme d'un paquet 531 au pont 510, à destination de l'équipement à l'origine du paquet de résolution d'adresse; pour ce faire le portai 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é. Il en est de même pour le portai du pont 507 qui va émettre un paquet de données asynchrone de

réponse 533.

Il appartient à chaque portai 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à du bus 504,. Pour ce faire, le portai doit mémoriser que la requête de résolution d'adresse a été suivie d'une réponse, par exemple en sauvegardant de la première réponse reçue, et ce pendant une certaine durée, des données comme l'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 "datalength", "tag", channel", "A16", "sy", "racldHi", et "headerCRC" ont des valeurs constantes définies par

le comité de normalisation 1394.

La valeur du champ 557 "source_lD" permet de spécifier l'adresse

du portal émetteur du paquet.

Les champs 558 à 560 dénommés "specifiier ID hi", "specifiierIDlo", et "version" ont des valeurs constantes définies par le comité

de normalisation 1394.

Les champs 561 à 568 constituent la partie champ de données ("data field" en terminologie anglo-saxonne) d'un paquet GASP et sont utilisés

comme suit dans la présente invention.

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ésentatif 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 "routingwidth_32" 94 (figure 4) et des traitements effectués sur le chemin

parcouru tels qu'explicités dans l'étape 121 de la figure 11.

Par exemple, lorsqu'un paquet de résolution d'adresse présent sur le bus 56, et susceptible d'être transféré par le pont 66 sur le bus 58 de la figure 1, - et que le champ 561, comporte par exemple les champs 200, 205 à 208 décrit en figure 5, - alors le contenu du champ 561 sera remplacé par les champs 210, 209, 212

à 215 lors du transfert via le pont 66.

Le champ numéro de séquence 562 ("sequence_number" en terminologie anglosaxonne), 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 EUI-64 source haut et bas 563 et 564 ("SrcEUI_64_hi" et "Src_EUI_64_Io" en terminologie anglo-saxonne), représentés chacun sur 32 bits, décrivent l'EUI-64 de l'équipement à l'origine de ce paquet de résolution d'adresse. Cet 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 EUI-64 équipement recherché haut et bas 565 et 566 ("DevEUI_64_hi" et "Dev_EUI_64_10" en terminologie anglo-saxonne), représentés chacun sur 32 bits, décrivent l'EUI-64 de l'équipement recherché par l'équipement à l'origine de ce paquet de résolution d'adresse. Cet 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 ("SrcEUI_64_hi" et "Src_EUI_64_10") avec son 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 portai du réseau peut ainsi éviter d'émettre à

nouveau ce paquet sur le(s) bus adjacent(s).

Le champ "information spécifique pour le paquet réponse" 567 ("response packet type specific information" en terminologie anglo-saxonne), représenté sur 48 bits, contient l'information nécessaire pour construire le paquet réponse au paquet de résolution d'adresse. Cette information est positionné 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 à l'origine du paquet de résolution d'adresse, adresse à laquelle l'équipement 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 réservé 568 ("reserved" en terminologie anglo-

saxonne), représenté sur 16 bits, comme son nom l'indique, n'est pas utilisé

pour l'instant.

La valeur du champ 569 "data_CRC" est calculée en fonction de la valeur des champs 557 à 568 selon des règles prédéterminées par le 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. Ce format d'un tel paquet est largement décrit dans le standard 1394-95, et illustré en figure 2. Seuls les champs utiles

dans le cadre de la présente invention sont décrits ci-après.

Comme il a été mentionné précédemment, la valeur du champ

585 "tCode" peut par exemple être "write request for data block".

Un champ réservé 590 ("reserved" en terminologie anglo-

saxonne), représenté sur 16 bits, comme son nom l'indique, n'est pas utilisé

pour l'instant.

Le champ numéro de séquence 591 ("sequence_number" en terminologie anglosaxonne), représenté sur 12 bits, permet d'identifier ce paquet de manière unique dans l'équipement à l'origine de la requête de

résolution d'adresse.

Les champs EUI-64 source haut et bas 592 et 593 ("SrcEUI_64_hi" et "Src_EUI_64 1o" en terminologie anglo-saxonne), représentés chacun sur 32 bits, décrivent l'EUI-64 de l'équipement à l'origine du paquet de résolution d'adresse. Cet EUI-64 est utile pour identifier de manière

unique l'équipement à l'origine de la requête de résolution d'adresse.

Les champs 592, 593 ("SrcEUI 64_hi", "SrcEUI_64_1o") avec le champ numéro de séquence 591 permettent notamment à chaque portal sur le bus dit "source" (bus o se situe l'équipement à 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 à l'origine de la requête de résolution d'adresse. Les portais sur le bus dit "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 est une amélioration apportée à l'invention, 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 l'invention lors du traitement associés 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 de 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 stopper le 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 et un seul paquet réponse correspondant à un paquet de résolution d'adresse sur le bus o se situe l'équipement à l'origine de

ce paquet de résolution d'adresse.

La figure 15 décrit par exemple une table de vérification contenant

un nombre limité d'enregistrements élémentaires notés 601 à 605.

Les champs EUI-64 source haut et bas 610 et 611 ("SrcEUI_64_hi" et "Src_EUI_64 1o" en terminologie anglo-saxonne), représentés chacun sur 32 bits, décrivent l'EUI-64 de l'équipement à l'origine du paquet de résolution d'adresse. Cet EUI-64 est utile pour identifier de manière

unique l'équipement à l'origine du paquet de résolution d'adresse.

Le champ numéro de séquence 612 ("sequence_number" en terminologie anglo-saxonne), représenté sur 12 bits, permet d'identifier ce paquet de manière unique dans l'équipement à l'origine du paquet de résolution d'adresse.

Le champ de gestion 613 ("management" en terminologie anglo-

saxonne), représenté sur 20 bits, permet d'associer des informations à chaque

enregistrement de la table selon le type de la table.

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 gestion peut par exemple contenir une information indiquant si un paquet de résolution d'adresse a déjà soit été reçu par le portal, soit transmis

par ce portai (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-dupplication de réponse vers un équipement à l'origine d'un paquet de résolution d'adresse), le champ gestion peut par exemple contenir une information indiquant si un paquet réponse a déjà soit été reçu par le portal, soit transmis par ce portai (une valeur booléenne peut par exemple être suffisante); dans une variante non décrite dans la présente invention un compteur pourrait apporter des informations supplémentaires sur le fait que plusieurs réponses (donc 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 le plus court chemin par exemple, cette variante impose alors de définir un protocole de communication entre les différent portais afin d'effectuer le changement de descripteur de chemin à utiliser; dans une variante non décrite dans la présente invention, c'est l'alpha portai qui centralise toutes les réponses reçues au niveau du bus local o se situe l'équipement à l'origine du paquet de résolution d'adresse et qui décide de retenir, selon des critères prédéfinis comme le plus court chemin par exemple, un descripteur de chemin, et n'envoie finalement qu'un seul paquet réponse

vers l'équipement à l'origine du paquet de résolution d'adresse.

Une variante consiste à utiliser comme informations dans le champ de gestion, 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 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, I'autre

aux paquets réponses à ce paquet de résolution d'adresse.

La figure 16 est une vue schématique de l'algorithme du procédé de réception d'un paquet de résolution d'adresse au niveau d'un portal d'un pont selon l'invention. Au niveau du bus source, le paquet de résolution d'adresse émis par l'équipement source est décrit par la norme. Ce paquet doit être compris par les portais sources qui vont le traduire en un paquet de

résolution d'adresse tel que décrit par la figure 13.

Au cours de l'opération 701, le processus en charge, au niveau d'un portal, de la réception des paquets reçoit un paquet de résolution d'adresse. Au cours de l'opération 702, le processus lit les champs EUI64

source et numéro de séquence décrits précédemment.

Au cours de l'opération 703, le processus vérifie si un enregistrement élémentaire, ayant l'EUI-64 source lu dans le paquet reçu comme champs EUI-64 source haut et bas, existe déjà dans la table de vérification 600, décrite en figure 15. Dans la cas o l'enregistrement n'existe pas, au cours de l'opération 704, le processus en crée un avec les valeurs des champs EUI-64 source et numéro de séquence lus dans le paquet reçu, par exemple l'enregistrement 601 décrit en figure 15, puis se poursuit par I'opération 709. Dans la cas o l'enregistrement existe déjà dans la table de vérification, au cours de l'opération 705, le processus vérifie 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'opération 706, le paquet de résolution d'adresse est ignoré; il se peut par exemple que ce soit un paquet plus ancien et de toute façon n'étant plus valide. Dans le cas positif, le processus met à jour le numéro de séquence de l'enregistrement avec celui lu du paquet reçu, au cours de l'opération 707, ainsi que les informations de gestion (comme celles précédemment mentionnées par exemple, valeur booléenne indiquant si un paquet de résolution d'adresse a déjà transité sur le bus vu par le portal, et/ou un compteur indiquant combien de paquets identiques de résolution d'adresse ont été détecté sur le bus vu par le 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'opération 708.

Au cours de l'opération 709, le processus vérifie si le portal a connaissance de l'équipement recherché, identifié par les champs EUI-64 équipement recherché haut et bas ("Dev_EUI_64_hi" et "Dev_EUI_64_1o"), décrit en 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 dit "bus destination") que le portai en question, alors ce dernier possède son EUI-64 dans une table interne (cette table n'est pas décrite dans le contexte de l'invention car étant définie dans le cadre des spécifications en cours du standard pont 1394). Dans le cas positif, au cours de l'opération 710, le processus effectue les opérations de création et/ou mise à jour dans la table de routage précédemment décrite en figures 8 et 9, puis initie l'envoi d'un paquet réponse 580, tel que décrit en figure 14, audit paquet de résolution d'adresse; le processus positionne notamment les champs de ce paquet 580 en utilisant les valeurs des champs dudit paquet de résolution d'adresse comme suit: - le champ descripteur de chemin 561 est utilisé pour positionner les champs 581, 582, 587 et 588, le champ "information spécifique pour le paquet réponse" 567 est utilisé pour positionner le champ de même nom 589, - le champ numéro de séquence 562 est utilisé pour positionner le champ de même nom 591, -les champs EUI-64 source haut et bas 563 et 564 sont utilisés

pour positionner les champ de même noms 592 et 593.

Dans la cas négatif, au cours de l'opération 711, le processus vérifie si le 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) portai du pont

auquel appartiennent ces portais).

Dans le cas positif (paquet reçu du bus), le processus gérant le portai envoie, au cours de l'opération 712, le paquet au(x) portal(s) constituant le pont. Dans le cas négatif (paquet reçu du portai), le processus gérant le portai, au cours de l'opération 713, met à jour le descripteur de chemin du paquet de résolution d'adresse et l'envoie sur le bus continuant ainsi la diffusion

du paquet au travers du 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 résoudre

les problèmes de bouclage.

Suite aux opérations 710, 712 et 713, le traitement dudit paquet de résolution d'adresse se trouve alors terminé et le processus revient dans son

état initial, en attente d'un nouveau paquet, opération 701.

La figure 17 est une vue schématique de l'algorithme du 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 portai d'un pont situé sur le bus o se trouve l'équipement à l'origine du paquet de résolution d'adresse. La réception d'un paquet de données de réponse peut être de deux sortes: soit il s'agit d'un paquet de données de réponse émis par un portai 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 portai local au bus source et dans ce cas il s'agit du paquet réponse (un et un seul) envoyé a l'équipement à l'origine du paquet de

résolution d'adresse.

Au cours de l'opération 751, le processus, du portai du bus o se trouve l'équipement a l'origine du paquet de résolution d'adresse, se met en attente d'un paquet de réponse suite à l'émission d'un paquet de résolution d'adresse. Au cours de l'opération 752, le processus vérifie si un paquet de réponse audit paquet de résolution d'adresse a effectivement été reçu. Dans le cas positif, au cours de l'opération 753, le processus vérifie si le type du paquet de réponse reçu est un paquet émis par un portal local au bus (paquet réponse (un et un seul) envoyé a l'équipement à l'origine du paquet de résolution d'adresse). Dans le cas négatif, au cours de l'opération 754, le processus acquitte le paquet de réponse tel que décrit dans le standard 1394-95, le paquet 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, le processus poursuit le traitement par l'opération 760.

Au cours de l'opération 755, le processus vérifie si un paquet de réponse pour ledit paquet de résolution d'adresse a déjà été reçu par le portal ou détecté sur le bus "source" ou si un ack négatif n'a pas déjà été généré sur le bus source. Dans le cas négatif, o à priori aucun paquet réponse n'est attendu, au cours de l'opération 758, le processus ignore le paquet et revient dans l'état initial 751. Dans le cas positif, o effectivement un paquet réponse est attendu, au cours de l'opération 756, le processus mémorise la réception ou la détection d'un paquet réponse. Puis, au cours de l'opération 757, dans le cas o le paquet réponse précédemment reçu n'était pas déjà un paquet réponse (un et un seul) envoyé a l'équipement à l'origine du paquet de résolution d'adresse, le processus envoie le paquet réponse (un et un seul) à

l'équipement à l'origine du paquet de résolution d'adresse.

Au cours de l'opération 760, le processus vérifie si la durée d'attente maximum prédéfinie s'est écoulé. 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, Au cours de l'opération 762, si aucune opération n'a été détectée sur le bus source, le processus envoie à l'équipement à l'origine du paquet de résolution d'adresse un paquet de réponse signalant qu'aucun équipement répondant a l'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 processus

revient dans l'état initial 751.

La figure 18 est une vue schématique de l'algorithme du 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.

Il 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 de l'é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 a tous les

périphériques présents sur ce bus).

* Il 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 Mbit/s). Dans le cas négatif, au cours de l'étape 904, pour ledit bus, il est vérifié 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 de sections constitutives de ponts

("portais") autorisés sur ledit bus ("maxbridge" 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 2" -1 valeurs de label 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 au "portal" du pont connecté audit bus. Cette valeur d'identificateur de routage est avantageusement calculée de façon similaire par tous les "portais" d'un bus sous autorité de "l'alpha portal" défini plus haut, le rôle de ce dernier étant plus particulièrement de s'assurer de la cohérence des différentes informations entre les différents "portais" connectés au bus considéré. Au cours de l'étape 912, le procédé prévoit de vérifier, pour ledit bus, si la valeur de l'identificateur de routage affecté au 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. 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 (pont désactivé). Dans le cas positif, au cours de l'étape 913, 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 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 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 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.

On exécute ensuite l'étape 902.

Une autre variante, non décrite ici consiste, par exemple, pendant l'intervalle de temps entre la suspension (étape 917) de la mise en oeuvre du routage décrit dans le présent document 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 du 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 de "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 a 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 en débit binaire d'un bus donné, I'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 de "portals" 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, seront prises en compte dans la décision

d'affectation de la longueur de l'identificateur ou label de routage à utiliser.

Au cours de l'é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

"portais" présents sur ce bus.

Ensuite, le procédé prévoit de vérifier, pour ledit 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, sinon s'il est inférieur à 15 au cours de l'étape 955. Dans

la négative, I'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 de "portais" autorisés sur ledit bus ("maxbridge" en terminologie anglo-saxonne), ainsi que le nombre minimal de "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 962, on affecte un identificateur de routage constant et unique au "portai" du pont connecté audit bus. Cette valeur d'identificateur de routage est avantageusement calculée de façon similaire par tous les "portais" d'un bus sous autorité de "l'alpha portai" défini plus haut, le rôle de ce dernier étant plus particulièrement de s'assurer de la cohérence des différentes informations entre les différents "portais" connectés au bus

considéré.

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é au "portai" 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 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, I'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 ("portals") est en dehors de l'intervalle défini précédemment par minbridge et maxbridge. Dans le cas négatif, I'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.

On exécute ensuite l'étape 952.

Il 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 portions consécutives ("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 "portals" 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.5

Claims (116)

REVENDICATIONS

1. Procédé de détermination d'un chemin d'un paquet de données dans un réseau de communication comportant au moins deux bus de communication série reliés par eux par au moins un pont, caractérisé en ce qu'il comporte les étapes suivantes: - réception au niveau dudit pont d'un paquet de données dit de diffusion, émis sur un premier bus par un pont dit source et comportant au moins un champ d'un premier type identifiant au moins un périphérique auquel est destiné ledit paquet et au moins un champ d'un deuxième type comportant des informations représentatives d'un chemin parcouru par ledit paquet depuis ledit pont source jusqu'audit pont, -comparaison dudit au moins un champ de premier type par rapport à au moins une valeur prédéterminée dite de fin de paquet afin de déterminer si la paquet réceptionné est destiné à l'un des périphériques reliés

audit premier bus.

2. Procédé selon la revendication 1, caractérisé en ce que le champ de premier type identifie un seul périphérique auquel est destiné le

paquet de diffusion.

3. Procédé selon la revendication 1 ou 2, caractérisé en ce que la valeur prédéterminée de fin de transfert est représentative de l'identification de

tous les périphériques connectés au premier bus.

4. Procédé selon l'une des revendications 1 à 3, caractérisé en ce

que l'étape de comparaison fait intervenir au moins le champ de deuxième type.

5. Procédé selon la revendication 4, caractérisé en ce que la

valeur prédéterminée de fin de transfert est représentative d'une fin de chemin.

6. Procédé selon la revendication 5, caractérisé en ce que la détermination du chemin prend fin lorsque le nombre d'informations

représentatives du chemin parcouru atteint ladite valeur prédéterminée.

7. Procédé selon les revendications 3 et 6, caractérisé en ce que

lorsque le paquet de diffusion n'est pas destiné à un périphérique relié au premier bus et que le nombre d'informations représentatives du chemin parcouru n'a pas atteint ladite valeur prédéterminée, alors ledit procédé comporte une étape d'émission dudit paquet de diffusion sur le deuxième bus

relié au pont.

8. Procédé selon la revendication 1 caractérisé en ce que le champ de premier type identifie plusieurs périphériques auxquels est destiné le

paquet de diffusion.

9. Procédé selon l'une des revendications 1 à 5, caractérisé en ce

que lorsque le périphérique auquel est destiné le paquet de diffusion est identifié dans ladite valeur prédéterminée de fin de transfert, ledit procédé comporte une étape d'émission d'un paquet de réponse sur le premier bus vers le pont source et qui comporte un champ d'informations dites d'identification du chemin, ledit champ d'informations comportant les informations représentatives du chemin parcouru par le paquet de diffusion jusqu'au pont destination et qui constituent les informations représentatives du chemin à parcourir jusqu'au pont

source.

10. Procédé selon la revendication 9, caractérisé en ce que le champ d'informations d'identification comporte au fur et à mesure du transfert du paquet de réponse dans le réseau, des informations représentatives du

chemin parcouru par ledit paquet depuis le pont destination.

11. Procédé selon la revendication 9 ou 10, caractérisé en ce qu'il comporte une étape de réception dudit paquet de réponse au niveau du pont source, ledit paquet comportant la totalité des informations représentatives du chemin parcouru depuis le pont destination jusqu'au pont source et qui

déterminent un chemin recherché.

12. Procédé selon la revendication 11, caractérisé en ce qu'il comporte un test sur des informations représentatives du chemin à parcourir dans le paquet de réponse afin de s'assurer que ledit pont réceptionnant ledit

paquet est le pont source.

13. Procédé selon l'une des revendications 9 à 12, caractérisé en

ce que qu'il comporte une étape de réception d'un autre paquet de réponse de

manière décalée dans le temps.

14. Procédé selon la revendication 13, caractérisé en ce que les

deux paquets de réponse ont une structure différente l'une de l'autre.

15. Procédé selon la revendication 13 ou 14, caractérisé en ce que, lorsque le pont reçoit de manière décalée dans le temps, plusieurs paquets de réponse déterminant chacun un chemin parcouru, ledit procédé

comporte une étape de sélection d'un des chemins parcourus.

16. Procédé selon l'une des revendications 9 à 15, caractérisé en

ce que, lorsque plusieurs autres ponts sont reliés au bus auquel est connecté un périphérique dit source et le pont source, ledit procédé comporte au niveau dudit pont source une étape de détection d'un paquet de données destiné audit

périphérique source et émis sur ledit bus par au moins des autres ponts.

17. Procédé selon l'une des revendications 9 à 16, caractérisé en

ce qu'il comporte une étape d'émission sur un bus auquel est relié, d'une part, un périphérique dit source et, d'autre part, ledit pont source d'un paquet de

données destiné audit périphérique source.

18. Procédé selon la revendication 17, caractérisé en ce que l'étape de réception d'un paquet de réponse précède l'étape d'émission d'un

paquet de données destiné au périphérique source.

19. Procédé selon l'une des revendications 9 à 18, caractérisé en

ce que, lorsque plusieurs autres ponts sont reliés au bus auquel est connecté un périphérique dit source et le pont source, un seul parmi tous ces ponts est

autorisé à émettre un paquet de données destiné au périphérique source.

20. Procédé selon l'une des revendications 1 à 19, caractérisé en

ce que les bus de communication série sont conformes à la norme IEEE 1394.

21. Procédé selon l'une des revendications 1 à 20, caractérisé en

ce que ledit paquet de données de réponse comporte deux extrémités opposées et 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'information ayant chacun une longueur donnée et étant situés à une même extrémité du paquet de données, ledit procédé comportant les étapes suivantes lors du transfert dudit paquet de données à travers ledit 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.

22. Procédé selon la revendication 21, caractérisé en ce qu'au

moins un identificateur est attribué audit pont.

23. Procédé selon la revendication 22, caractérisé en ce que, ledit pont comportant au moins deux portions reliées chacune auxdits au moins deux bus du réseau, au moins un identificateur est attribué à chacune desdites au

moins deux portions.

24. Procédé selon l'une des revendications 22 à 23, caractérisé

en ce que lesdits premier et deuxième champs d'informations contiennent des informations relatives audit au moins un identificateur du ou des ponts disposés

sur le chemin du paquet de données dans le réseau.

25. Procédé selon la revendication 24, caractérisé en ce que ledit premier champ d'informations contient des informations relatives audit au moins un identificateur du ou des ponts disposés sur le chemin à parcourir par le

paquet de données dans le réseau.

26. Procédé selon la revendication 25, 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 dudit pont considéré.

27. Procédé selon la revendication 26, caractérisé en ce que, lorsque le pont considéré comporte au moins deux portions reliées chacune auxdits au moins deux bus du réseau et qu'au moins un identificateur est attribué à chacune desdites au moins deux portions, ladite au moins une première information supprimée dudit au moins un premier champ d'informations correspond audit au moins un identificateur de la portion du pont qui est reliée audit bus du réseau par lequel le paquet de données parvient

audit pont.

28. Procédé selon l'une des revendications 24 à 27, caractérisé

en ce que ledit deuxième champ d'informations contient des informations relatives audit au moins un identificateur du ou des ponts disposés sur le

chemin parcouru par le paquet de données dans le réseau.

29. Procédé selon la revendication 28, 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 dudit pont

considéré.

30. Procédé selon la revendication 29, caractérisé en ce que, lorsque le pont considéré comporte au moins deux portions reliées chacune auxdits au moins deux bus du réseau et qu'au moins un identificateur est attribué à chacune desdites au moins deux portions, 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 la portion du pont qui est reliée au bus du réseau par lequel le paquet de données quitte ledit pont.

31. Procédé selon l'une des revendications 21 à 30, 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.

32. Procédé selon les revendications 22 et 31, caractérisé en ce

que le marqueur a une longueur au moins égale au nombre de bits nécessaire

pour coder un identificateur dudit pont dans l'un des champs d'informations.

33. Procédé selon la revendication 32, caractérisé en ce qu'il comporte, lors du transfert dudit paquet de données à travers ledit 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.

34. Procédé selon l'une des revendications 32 à 33, caractérisé

en ce que la longueur totale des premier, deuxième et troisième champs est fixe.

35. Procédé de réception d'un paquet de données transmis dans un réseau de communication comportant au moins deux bus de communication série reliés entre eux par au moins un pont, caractérisé en ce qu'il comporte une étape de réception au niveau dudit pont appelé pont source, en provenance d'un premier bus, d'un paquet dit de réponse émis par un pont dit destination, en réponse à un paquet dit de diffusion émis par ledit pont source et comportant un champ d'informations dites d'identification comportant des informations représentatives d'un chemin parcouru par ledit paquet de diffusion jusqu'audit pont destination, ledit paquet de réponse comportant des informations représentatives du chemin qu'il a parcouru du pont destination au

pont source.

36. Procédé selon la revendication 35, caractérisé en ce que le champ d'informations d'identification comporte, au fur et à mesure du transfert du paquet de réponse dans le réseau, des informations représentatives du

chemin parcouru par ledit paquet depuis le pont destination.

37. Procédé selon la revendication 35 ou 36, caractérisé en ce qu'il comporte une étape de réception dudit paquet de réponse au niveau du pont source, ledit paquet comportant la totalité des informations représentatives du chemin parcouru depuis le pont destination jusqu'au pont source et qui

déterminent un chemin recherché.

38. Procédé selon la revendication 37, caractérisé en ce qu'il comporte un test sur des informations représentatives du chemin à parcourir dans le paquet de réponse afin de s'assurer que ledit pont réceptionnant ledit

paquet est le pont source.

39. Procédé selon l'une des revendications 35 à 38, caractérisé

en ce que qu'il comporte une étape de réception d'un autre paquet de réponse

de manière décalée dans le temps.

40. Procédé selon la revendication 39, caractérisé en ce que les

deux paquets de réponse ont une structure différente l'une de l'autre.

41. Procédé selon la revendication 39 ou 40, caractérisé en ce que, lorsque le pont reçoit de manière décalée dans le temps, plusieurs paquets de réponse déterminant chacun un chemin parcouru, ledit procédé

comporte une étape de sélection d'un des chemins parcourus.

42. Procédé selon l'une des revendications 35 à 41, caractérisé

en ce que, lorsque plusieurs autres ponts sont reliés au bus auquel est connecté un périphérique dit source et le pont source, ledit procédé comporte au niveau dudit pont source une étape de détection d'un paquet de données destiné audit périphérique source et émis sur ledit bus par au moins des autres ponts.

43. Procédé selon l'une des revendications 35 à 42, caractérisé

en ce qu'il comporte une étape d'émission sur un bus auquel est relié un périphérique dit source et ledit pont source d'un paquet de données destiné

audit périphérique source.

44. Procédé selon la revendication 43, caractérisé en ce que l'étape de réception d'un paquet de réponse précède l'étape d'émission d'un

paquet de données destiné au périphérique source.

45. Procédé selon l'une des revendications 35 à 44, caractérisé

en ce que, lorsque plusieurs autres ponts sont reliés au bus auquel est connecté un périphérique dit source et le pont source, un seul parmi tous ces ponts est autorisé à émettre un paquet de données destiné au périphérique

source.

46. Procédé selon l'une des revendications 35 à 45, caractérisé

en ce que les bus de communication série sont conformes à la norme IEEE 1394.

47. Procédé selon l'une des revendications 35 à 46, caractérisé

en ce que ledit paquet de données de réponse comporte deux extrémités opposées et 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'information ayant chacun une longueur donnée et étant situés à une même extrémité du paquet de données, ledit procédé comportant les étapes suivantes lors du transfert dudit paquet de données à travers ledit 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.

48. Procédé selon la revendication 47, caractérisé en ce qu'au

moins un identificateur est attribué audit pont.

49. Procédé selon la revendication 48, caractérisé en ce que, ledit pont comportant au moins deux portions reliées chacune auxdits au moins deux bus du réseau, au moins un identificateur est attribué à chacune desdites au

moins deux portions.

50. Procédé selon l'une des revendications 48 à 49, caractérisé

en ce que lesdits premier et deuxième champs d'informations contiennent des informations relatives audit au moins un identificateur du ou des ponts disposés

sur le chemin du paquet de données dans le réseau.

51. Procédé selon la revendication 50, caractérisé en ce que ledit premier champ d'informations contient des informations relatives audit au moins un identificateur du ou des ponts disposés sur le chemin à parcourir par le

paquet de données dans le réseau.

52. Procédé selon la revendication 51, 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 dudit pont considéré.

53. Procédé selon la revendication 52, caractérisé en ce que, lorsque le pont considéré comporte au moins deux portions reliées chacune auxdits au moins deux bus du réseau et qu'au moins un identificateur est attribué à chacune desdites au moins deux portions, ladite au moins une première information supprimée dudit au moins un premier champ d'informations correspond audit au moins un identificateur de la portion du pont qui est reliée audit bus du réseau par lequel le paquet de données parvient

audit pont.

54. Procédé selon l'une des revendications 51 à 53, caractérisé

en ce que ledit deuxième champ d'informations contient des informations relatives audit au moins un identificateur du ou des ponts disposés sur le

chemin parcouru par le paquet de données dans le réseau.

55. Procédé selon la revendication 54, 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 dudit pont

considéré.

56. Procédé selon la revendication 55, caractérisé en ce que, lorsque le pont considéré comporte au moins deux portions reliées chacune auxdits au moins deux bus du réseau et qu'au moins un identificateur est attribué à chacune desdites au moins deux portions, 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 la portion du pont qui est reliée au bus du réseau par lequel le paquet de données quitte ledit pont.

57. Procédé selon l'une des revendications 47 à 56, 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.

58. Procédé selon les revendications 48 et 57, caractérisé en ce

que le marqueur a une longueur au moins égale au nombre de bits nécessaire

pour coder un identificateur dudit pont dans l'un des champs d'informations.

59. Procédé selon la revendication 58, caractérisé en ce qu'il comporte, lors du transfert dudit paquet de données à travers ledit 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.

60. Procédé selon l'une des revendications 58 à 59, caractérisé

en ce que la longueur totale des premier, deuxième et troisième champs est fixe.

61. Dispositif de détermination d'un chemin d'un paquet de données dans un réseau de communication comportant au moins deux bus de communication série reliés par eux par au moins un pont, caractérisé en ce qu'il comporte: - des moyens de réception au niveau dudit pont d'un paquet de données dit de diffusion, émis sur un premier bus par un pont dit source et comportant au moins un champ d'un premier type identifiant au moins un périphérique auquel est destiné ledit paquet et au moins un champ d'un deuxième type comportant des informations représentatives d'un chemin parcouru par ledit paquet depuis ledit pont source jusqu'audit pont, -des moyens de comparaison dudit au moins un champ de premier type par rapport à au moins une valeur prédéterminée dite de fin de paquet afin de déterminer si la paquet réceptionné est destiné à l'un des périphériques reliés audit premier bus

62. Dispositif selon la revendication 61, caractérisé en ce que la valeur prédéterminée de fin de transfert est représentative de l'identification de tous les périphériques connectés au premier bus

63. Dispositif selon la revendication 61 ou 62, caractérisé en ce que la valeur prédéterminée de fin de transfert est représentative d'une fin de

chemin.

64. Dispositif selon les revendications 62 et 63, ledit dispositif

comporte des moyens d'émission dudit paquet de diffusion sur le deuxième bus

relié au pont.

65. Dispositif selon l'une des revendications 61 à 64, caractérisé

en ce qu'il comporte des moyens d'émission d'un paquet de réponse sur le premier bus vers le pont source et qui comporte un champ d'informations dites d'identification du chemin, ledit champ d'informations comportant les informations représentatives du chemin parcouru par le paquet de diffusion jusqu'au pont destination et qui constituent les informations représentatives du

chemin à parcourirjusqu'au pont source.

66. Dispositif selon la revendication 65, caractérisé en ce que le champ d'informations d'identification comporte, au fur et à mesure du transfert du paquet de réponse dans le réseau, des informations représentatives du

chemin parcouru par ledit paquet depuis le pont destination.

67. Dispositif selon la revendication 65 ou 66, caractérisé en ce qu'il comporte des moyens de réception dudit paquet de réponse au niveau du pont source, ledit paquet comportant la totalité des informations représentatives du chemin parcouru depuis le pont destination jusqu'au pont source et qui déterminent un chemin recherché

68. Dispositif selon l'une des revendications 61 à 67, caractérisé

en ce qu'il comporte des moyens pour réaliser un test sur des informations représentatives du chemin à parcourir dans le paquet de réponse afin de s'assurer que ledit pont réceptionnant ledit paquet est le pont source

69. Dispositif selon l'une des revendications 61 à 68, caractérisé

en ce que, lorsque le pont reçoit de manière décalée dans le temps, plusieurs paquets de réponse déterminant chacun un chemin parcouru, ledit dispositif

comporte des moyens de sélection d'un des chemin parcourus.

70. Dispositif selon l'une des revendications 61 à 69, caractérisé

en ce que, lorsque plusieurs autres ponts sont reliés au bus auquel est connecté un périphérique dit source et le pont source, ledit dispositif comporte des moyens de détection d'un paquet de données destiné audit périphérique

source et émis sur ledit bus par au moins un autre pont.

71. Dispositif selon l'une des revendications 61 à 69, caractérisé

en ce qu'il comporte des moyens d'émission sur un bus auquel est relié, d'une part, un périphérique dit source et, d'autre part, ledit pont source d'un paquet de

données destiné audit périphérique source.

72. Dispositif selon l'une des revendications 61 à 71, caractérisé

en ce que lorsque plusieurs autres ponts sont reliés au bus auquel est connecté un périphérique dit source et le pont source, un seul parmi tous ces ponts est

autorisé à émettre un paquet de données destiné au périphérique source.

73. Dispositif selon l'une des revendications 61 à 72, caractérisé

en ce que les bus de communication série sont conformes à la norme IEEE 1394.

74. Dispositif selon l'une des revendications 61 à 73, caractérisé

en ce que ledit paquet de données comportant deux extrémités opposées et 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 et étant situés à une même extrémité du paquet de données, 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.

75. Dispositif selon la revendication 74, caractérisé en ce qu'au

moins un identificateur est attribué audit pont.

76. Dispositif selon la revendication 75, caractérisé en ce que ledit pont comporte au moins deux portions reliées chacune auxdits au moins deux

bus du réseau.

77. Dispositif selon la revendication 76, caractérisé en ce qu'au

moins un identificateur est attribué à chacune desdites au moins deux portions.

78. Dispositif selon la revendication 76 ou 77, caractérisé en ce que chaque portion du pont comporte des moyens de suppression d'au moins une première information d'au moins un premier champ d'informations et des moyens d'ajout d'au moins une deuxième information dans au moins un

deuxième champ d'informations.

79. Dispositif selon l'une des revendications 75 à 78, caractérisé

en ce que lesdits premier et deuxième champs d'informations contiennent des informations relatives audit au moins un identificateur du ou des ponts disposés

sur le chemin du paquet de données dans le réseau.

80. Dispositif selon l'une des revendications 74 à 79, 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.

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

82. Dispositif selon la revendication 80 ou 81, caractérisé en ce

que la longueur totale des premier, deuxième et troisième champs est fixe.

83. Dispositif de réception d'un paquet de données transmis dans un réseau de communication comportant au moins deux bus de communication série reliés entre eux par au moins un pont, caractérisé en ce qu'il comporte des moyens de réception au niveau dudit pont appelé pont source, en provenance d'un premier bus, d'un paquet dit de réponse émis par un pont dit destination, en réponse à un paquet dit de diffusion émis par ledit pont source et comportant un champ d'informations dites d'identification comportant des informations représentatives d'un chemin parcouru par ledit paquet de diffusion jusqu'audit pont destination, ledit paquet de réponse comportant des informations représentatives du chemin qu'il a parcouru du pont destination au

pont source.

84. Dispositif selon la revendication 83, caractérisé en ce que le champ d'informations d'identification comporte, au fur et à mesure du transfert du paquet de réponse dans le réseau, des informations représentatives du

chemin parcouru par ledit paquet depuis le pont destination.

85. Dispositif selon la revendication 83 ou 84, caractérisé en ce qu'il comporte des moyens de réception dudit paquet de réponse au niveau du pont source, ledit paquet comportant la totalité des informations représentatives du chemin parcouru depuis le pont destination jusqu'au pont source et qui

déterminent un chemin recherché.

86. Dispositif selon la revendication 83 à 85, caractérisé en ce qu'il comporte des moyens pour réaliser un test sur des informations représentatives du chemin à parcourir dans le paquet de réponse afin de

s'assurer que ledit pont réceptionnant ledit paquet est le pont source.

87. Dispositif selon la revendication 83 à 86, caractérisé en ce que, lorsque le pont reçoit de manière décalée dans le temps, plusieurs paquets de réponse déterminant chacun un chemin parcouru, ledit dispositif

comporte des moyens de sélection d'un des chemin parcourus.

88. Dispositif selon la revendication 83 à 87, caractérisé en ce que,

lorsque plusieurs autres ponts sont reliés au bus auquel est connecté un périphérique dit source et le pont source, ledit dispositif comporte des moyens de détection d'un paquet de données destiné audit périphérique source et émis

sur ledit bus par au moins un autre pont.

89. Dispositif selon la revendication 83 à 88, caractérisé en ce qu'il comporte des moyens d'émission sur un bus auquel est relié, d'une part, un périphérique dit source et, d'autre part, ledit pont source d'un paquet de

données destiné audit périphérique source.

90. Dispositif selon la revendication 83 à 89, caractérisé en ce que lorsque plusieurs autres ponts sont reliés au bus auquel est connecté un périphérique dit source et le pont source, un seul parmi tous ces ponts est

autorisé à émettre un paquet de données destiné au périphérique source.

91. Dispositif selon la revendication 83 à 90, caractérisé en ce que

les bus de communication série sont conformes à la norme IEEE 1394.

92. Dispositif selon la revendication 83 à 91, caractérisé en ce que ledit paquet de données comportant deux extrémités opposées et 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 et étant situés à une même extrémité du paquet de données, ledit dispositif comporte: -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 a celle de

ladite deuxième information.

93. Dispositif selon la revendication 92, caractérisé en ce qu'au

moins un identificateur est attribué audit pont.

94. Dispositif selon la revendication 93, caractérisé en ce que ledit pont comporte au moins deux portions reliées chacune auxdits au moins deux

bus du réseau.

95. Dispositif selon la revendication 94, caractérisé en ce qu'au

moins un identificateur est attribué à chacune desdites au moins deux portions.

96. Dispositif selon la revendication 93 ou 94, caractérisé en ce que chaque portion du pont comporte des moyens de suppression d'au moins une première information d'au moins un premier champ d'informations et des moyens d'ajout d'au moins une deuxième information dans au moins un

deuxième champ d'informations.

97. Dispositif selon la revendication 92 à 96, caractérisé en ce que lesdits premier et deuxième champs d'informations contiennent des informations relatives audit au moins un identificateur du ou des ponts disposés

sur le chemin du paquet de données dans le réseau.

98. Dispositif selon la revendication 97, 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.

99. Dispositif selon l'une des revendications 93 à 98, caractérisé

en ce qu'il comporte des moyens de décalage des premier, deuxième et

troisième champs d'informations.

100. Dispositif selon la revendication 98 ou 99, caractérisé en ce

que la longueur totale des premier, deuxième et troisième champs est fixe.

101. Pont reliant au moins deux bus de communication série d'un réseau de communication de paquet de données, caractérisé en ce que ledit pont comporte un dispositif de détermination d'un chemin d'un paquet de

données selon l'une des revendications 61 à 73.

102. Pont reliant au moins deux bus de communication série d'un réseau de communication de paquets de données, caractérisé en ce que ledit pont comporte un dispositif de réception d'un paquet de données selon l'une

des revendications 83 à 100.

103. Appareil de traitement de données, caractérisé en ce qu'il comporte un pont selon la revendication 101 ou 102

104. Appareil selon la revendication 103, caractérisé en ce que

ledit appareil est une imprimante.

105. Appareil selon la revendication 103, caractérisé en ce que

ledit appareil est un serveur.

106. Appareil selon la revendication 103, caractérisé en ce que

ledit appareil est un ordinateur.

107. Appareil selon la revendication 103, caractérisé en ce que

ledit appareil est un télécopieur.

108. Appareil selon la revendication 103, caractérisé en ce que

ledit appareil est un scanner.

109. Appareil selon la revendication 103, caractérisé en ce que

ledit appareil est un magnétoscope.

110. Appareil selon la revendication 103, caractérisé en ce que

ledit appareil est un décodeur.

111. Appareil selon la revendication 103, caractérisé en ce que

ledit appareil est un téléviseur.

112. Appareil selon la revendication 103, caractérisé en ce que

ledit appareil est une caméscope.

113. Appareil selon la revendication 103, caractérisé en ce que

ledit appareil est une caméra numérique.

114. Appareil selon la revendication 103, caractérisé en ce que

ledit appareil est un appareil photographique numérique.

115. Réseau de communication de paquets de données comportant au moins deux bus de communication série reliés par au moins un pont, caractérisé en ce que ledit pont est conforme à la revendication 101 ou 102.

116. Réseau de communication de paquets de données comportant au moins deux bus de communication série reliés par au moins un

pont, caractérisé en ce que ledit réseau comporte un appareil de traitement de données selon l'une des revendications 103 à 114.5