Brevet FR2945690A1 — publié le 20101119

La présente invention se rapporte aux réseaux de communication. Les réseaux de communication se sont développés considérablement en particulier en raison de la démocratisation d'Internet haut-débit et de l'apparition d'équipements audiovisuels grand public ayant une connectivité réseau. Il est ainsi de plus en plus souvent nécessaire d'établir des connexions réseaux quasi-permanentes entre des individus qui présentent par exemple un même domaine d'intérêt afin qu'ils partagent des informations de tout type (audio, vidéo, photo, texte, etc.). On connaît déjà des technologies telles que la technologie des Réseaux Privés Virtuels, RPV (ou VPN pour � Virtual Private Network � en anglais) pour répondre à cette attente. Cette technologie permet par exemple de mettre en communication deux réseaux de type LAN (� Local Area Network � en anglais), ou bien un réseau de type LAN avec un équipement distant, afin de créer un réseau de type LAN virtuel composé de l'union des deux réseaux de type LAN originaux ou de l'union du réseau de type LAN original avec l'équipement distant. Pour réaliser cette mise en communication, la technologie RPV utilise une méthode d'encapsulation particulière appelée �tunnellisation � (� tunneling � en anglais) qui crée un tunnel entre un � pont � (bridge en anglais) d'un réseau de type LAN avec un élément à connecter à ce réseau (par exemple un autre réseau muni d'un pont similaire ou bien un équipement). Cette opération consiste à encapsuler un protocole de niveau A (protocole embarqué) dans un protocole de niveau B (protocole de transport) grâce à un protocole d'encapsulation C. Le protocole de transport B traite le protocole A comme s'il s'agissait de données utiles. On connaît déjà des ponts qui implémentent des protocoles de tunnellisation décrits par exemple par la norme IEEE 802.1 D. Chaque segment Ethernet est relié au pont par l'intermédiaire d'un port, chaque port permettant ainsi de connecter les différentes interfaces réseaux, que ces interfaces soient réelles (dans le cas d'une connexion locale) ou virtuelles (dans le cas d'une connexion par tunnel vers un réseau ou un équipement distant). A chaque nouvelle ouverture de port, le pont doit s'assurer qu'il n'introduit pas de �boucle� dans le réseau Ethernet résultant de l'interconnexion des différents réseaux Ethernet. En effet, si la topologie du réseau résultante décrit une boucle (c'est- à-dire qu'il existe deux chemins différents possibles pour atteindre un même équipement), le résultat entraînerait une surcharge importante et inutile des différents équipements du réseau, voire un écroulement total du réseau. Plus particulièrement, dans le cas de trames de diffusion, une trame reçue sur l'un des ports serait dupliquée et émise sur les autres ports du pont. Ainsi, dans le cas où une boucle existe, l'une des trames émises par le pont lui reviendrait alors sur l'un de ses ports et cette trame serait alors, à son tour, dupliquée et réémise sur tous les ports du pont (autres que celui par lequel le pont l'a reçue). Dans cette situation, l'émission d'une unique trame va congestionner le réseau par l'envoi de ces différentes répliques. Ce phénomène connu sous le nom de tempête de diffusion (� Broadcast storm �, en anglais) est fortement nuisible à la stabilité du réseau. On connaît déjà pour éviter la création de boucle, un protocole inclus dans le protocole IEEE 802.1D appelé protocole de création d'un arbre de recouvrement (�Spanning Tree Protocol� en anglais). Ce protocole transforme une topologie réseau de type graphe (possédant des chemins redondants) en un arbre (dépourvu de tels chemins). Ce protocole prévoit de fermer certains ports sur certains ponts du réseau afin de couper les chemins redondants. Pour ce faire, ce protocole STP détermine un pont � racine � (�root bridge�, en anglais), puis garantit un chemin sans boucle depuis le pont racine vers tous les autres ponts du réseau Ethernet. Lorsque sur un pont, deux ports sont détectés comme faisant partie d'une boucle, un des deux ports passe dans un état interdisant le relais de trame via ce port (le port est alors bloqué). Pour déterminer les ports faisant partie d'une boucle, le pont racine émet un paquet appelé BPDU (� Bridge Paquet Data Unit �, en anglais) qui est relayé par les ponts du réseau. Si, sur un pont, ce paquet est reçu sur plus d'un port, cela signifie qu'il existe une boucle entre ces ports et un seul de ces ports doit rester ouvert. Toutefois, les relais par les ponts du réseau des paquets BPDU n'étant pas immédiats (relais soumis à une temporisation typiquement égale à 2 secondes) et la topologie du réseau pouvant être complexe, le protocole STP définit un temps d'attente (� Forward Delay � en anglais). Durant ce temps les ponts doivent attendre (phase d'écoute) d'éventuels paquets BPDU sur leurs différents ports pour détecter la présence éventuelle de boucles. Ce temps d'attente possède une valeur par défaut définie par la norme IEEE 802.1 D et qui est de 15 secondes. On connaît déjà des protocoles améliorés (tels que le protocole RSTP défini par la norme IEEE 802.1W ou encore le protocole défini dans le brevet US 6,628,624) dans lesquels le pont est paramétré par avance pour que certains ports s'ouvrent sans temps d'attente lorsque la topologie du réseau le permet. L'invention vise un procédé de paramétrage d'un pont à mettre en communication avec au moins un élément d'un réseau de communication, qui soit à la fois plus performant et tout aussi fiable que les techniques proposées dans l'état de la technique. Elle propose à cet effet, un procédé de paramétrage, au sein d'un réseau de communication, d'un pont à mettre en communication avec au moins un élément à connecter audit pont, ledit pont comprenant au moins un port créé, caractérisé en ce qu'il comporte les étapes suivantes : - détermination, en fonction d'au moins une information de topologie dudit réseau, d'un paramètre représentatif d'un temps d'attente prédéterminé et correspondant à un temps de détection par ledit pont, pendant une phase d'écoute des données reçues par ledit au moins un port créé, de la présence d'une éventuelle boucle de communication au sein dudit réseau ; - activation d'un filtrage dudit au moins un port créé, ledit filtrage étant adapté à empêcher l'émission et la réception par ledit au moins un port créé de messages de gestion inter-ponts ; - configuration du pont avec ledit paramètre ainsi déterminé ; - création d'un nouveau port dudit pont en vue d'établir la communication avec ledit au moins un élément ; et - désactivation dudit filtrage. On entend ici par réseau de communication tout ensemble formé d'au moins deux éléments (chaque élément étant soit un équipement soit un réseau de type LAN) et d'un réseau intermédiaire (tel que le réseau internet) pour mettre en communication ces deux éléments. La détermination du temps d'attente à partir d'une information de topologie permet de choisir comme valeur pour ce délai une valeur qui est spécifiquement adaptée à l'environnement du pont avec lequel la communication doit être établie. Ceci contribue à réduire le temps d'attente global avant que les données puissent être échangées entre l'élément à connecter et le pont auquel il sera connecté. Le temps d'attente est ainsi ni trop court (risque de rater la détection d'une boucle) ni trop important (ralentissement inutile du système) mais est ainsi spécifiquement adapté au port à créer. L'utilisation d'un filtrage permet, pour sa part, d'isoler temporairement le pont à configurer du reste du réseau. Ceci permet de configurer le pont avec la valeur du paramètre déterminée précédemment, que ce pont soit racine ou non, et ceci sans que les autres ponts n'en soient affectés. Ce n'est qu'une fois que le port a été créé que le filtre est désactivé. Ce procédé permet ainsi de configurer spécifiquement chacun des ports à créer, et cela pour chaque pont, ce qui contribue à réduire significativement le temps d'attente global lors de chaque nouvelle ouverture d'un port. Ceci permet en particulier d'envisager des ouvertures de tunnels et des utilisations dans le cadre d'une transmission ponctuelle et de courte durée (par exemple lors de la transmission d'un seul fichier) avec un délai d'attente relativement court si la configuration le permet, de sorte qu'il n'y a aucun risque que l'utilisateur considère cette attente à tort comme un blocage du système. De plus, la détermination du temps d'attente est effectuée à chaque nouvelle création de port, prenant ainsi en compte la topologie du réseau au moment de cette ouverture, alors que dans les protocoles de l'état de la technique il était nécessaire de connaître par avance les caractéristiques topologiques du réseau, l'administrateur devant effectuer un paramétrage manuel de chaque pont selon la topologie du réseau. Le procédé selon l'invention offre ainsi une configuration dynamique de chaque pont (par opposition aux configurations déjà connues). Enfin, ce procédé est un procédé de contrôle du pont qui présente également la possibilité avantageuse d'être externalisé au pont en étant par exemple implémenté dans un contrôleur de ce pont. Selon une autre caractéristique, l'étape de détermination d'un paramètre représentatif d'un temps d'attente prédéterminé est obtenue en fonction d'au moins une information de topologie du réseau relative audit élément. Selon une autre caractéristique, l'étape de détermination d'un paramètre représentatif d'un temps d'attente prédéterminé est également obtenue en fonction d'au moins une information de topologie du réseau relative audit pont. La détermination du paramètre représentatif du temps d'attente à partir d'au moins une information de topologie de l'élément à connecter au pont et éventuellement à partir d'au moins une information de topologie du pont lui- même permet de définir ce temps d'attente avec une très grande précision. Selon une autre caractéristique, le procédé comporte une étape de mise à jour de chaque information de topologie. Les informations de topologie sont ainsi réactualisées à chaque ouverture de port de façon à correspondre fidèlement à la topologie réelle du réseau. Selon une autre caractéristique, dans le cas où le pont est racine, l'étape de configuration du pont est mise en oeuvre par une configuration directe du pont. Selon une autre caractéristique dans le cas où le pont n'est pas racine, l'étape de configuration du pont comporte une étape de détermination, au sein du réseau, du chemin vers le pont racine associé à ce pont et une étape de génération d'un message de gestion inter-ponts simulant un message de gestion inter-ponts provenant dudit pont racine associé. Ainsi, si la configuration directe du pont n'est pas possible (pont non racine), la génération d'un message de gestion inter-pont simulé permet malgré tout de configurer le pont en question ce qui rend possible d'appliquer le procédé de paramétrage selon l'invention à tous les ponts du réseau de communication qu'ils soient racine ou non. Selon une autre caractéristique, l'étape de configuration comporte également une étape de réception dudit message de gestion inter-ponts via une interface virtuelle dudit pont. Ceci permet ainsi au pont de recevoir ce message bien qu'un filtrage des messages soit mis en oeuvre. Selon une autre caractéristique, la mise en communication dudit pont avec ledit élément à connecter audit pont est mise en oeuvre par l'établissement d'un tunnel entre ledit nouveau port et ledit élément. Selon une autre caractéristique, ledit pont est associé à une tête de tunnel adaptée à établir ledit tunnel. La mise en communication par l'établissement d'un tunnel permet ainsi de communiquer de manière transparente en temps réel et, éventuellement de façon sécurisée. Selon une autre caractéristique, l'étape de détermination du temps d'attente est également mise en oeuvre à partir d'au moins une autre information obtenue à partir des requêtes échangées entre le pont et l'élément à connecter audit pont avant l'établissement de ladite communication. Il est ainsi avantageusement tiré profit de l'échange des requêtes entre le pont et l'élément à connecter pour recueillir des informations sur le réseau permettant de déterminer avec encore davantage de précision le temps d'attente nécessaire. On peut ainsi, dans un premier exemple, utiliser des messages échangés entre le pont et l'élément à connecter pour déterminer (ou calculer) un temps de transit d'une donnée entre le pont et l'élément à connecter (ou un temps d'aller-retour). On peut aussi, dans un second exemple, utiliser les messages d'établissement de tunnel entre le pont et l'élément à connecter pour faire transiter (et obtenir) des informations, telles que des informations représentatives de la topologie relative à l'élément à connecter ou bien des informations relatives à un temps de transit d'une donnée entre le pont et l'élément à connecter (ou un temps d'aller-retour). Dans le même but que celui indiqué plus haut, la présente invention présente également un dispositif de paramétrage, au sein d'un réseau de communication, d'un pont à mettre en communication avec au moins un élément à connecter audit pont, ledit pont comprenant au moins un port créé, caractérisé en ce qu'il comporte : - des moyens pour déterminer, en fonction d'au moins une information de topologie dudit réseau, un paramètre représentatif d'un temps d'attente prédéterminé et correspondant à un temps de détection par ledit pont, pendant une phase d'écoute des données reçues par ledit au moins un port créé, de la présence d'une éventuelle boucle de communication au sein dudit réseau; - des moyens pour activer un filtrage dudit au moins un port créé, ledit filtrage étant adapté à empêcher l'émission et la réception par ledit au moins un port créé de messages de gestion inter-ponts ; - des moyens pour configurer le pont avec ledit paramètre ainsi déterminé ; - des moyens pour créer un nouveau port dudit pont en vue d'établir la communication avec ledit au moins un élément ; et - des moyens pour désactiver ledit filtrage. Toujours dans le même but, la présente invention vise aussi un moyen de stockage d'informations, lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé de paramétrage tel qu'exposé ci-dessus. Toujours dans le même but, la présente invention vise aussi un produit programme d'ordinateur, pouvant être chargé dans un appareil programmable, caractérisé en ce qu'il comporte des séquences d'instructions pour mettre en oeuvre un procédé de paramétrage tel qu'exposé ci-dessus, lorsque ce programme est chargé et exécuté par l'appareil programmable. Les caractéristiques particulières et les avantages du dispositif de paramétrage, du moyen de stockage d'informations et du produit programme d'ordinateur étant similaires à ceux du procédé de paramétrage, ils ne sont pas rappelés ici. L'exposé de l'invention sera maintenant poursuivi par la description détaillée d'un exemple de réalisation, donné ci-après, à titre illustratif mais non limitatif, en référence aux dessins annexés sur lesquels : - la figure 1 est une représentation schématique de deux réseaux de type LAN mis en communication par l'intermédiaire d'un tunnel ; - la figure 2 est une vue similaire à la figure 1, mais dans laquelle sont représentés trois réseaux de type LAN, dont deux seulement comportent un pont ; - la figure 3 est un exemple de modèle en couche d'une tête de tunnel dans laquelle est mise en oeuvre le procédé selon l'invention ; - la figure 4 est un organigramme décrivant l'enchaînement des opérations réalisées par une tête de tunnel implémentant le procédé selon l'invention lors de l'ouverture d'un port ; - la figure 5 est une représentation schématique des échanges de données entre deux têtes de tunnel ; - la figure 6 est un organigramme précisant de façon détaillée l'une des étapes illustrées en figure 4 ; - la figure 7 est un organigramme présentant de façon détaillée une autre des étapes représentées en figure 4 ; - la figure 8 décrit une table contenant les informations relatives à chaque tunnel ouvert sur une tête de tunnel locale ; et - la figure 9 représente de façon schématique un mode particulier de réalisation d'un dispositif susceptible de mettre en oeuvre la présente invention. On va tout d'abord décrire à l'aide de la figure 1 une configuration typique de réseau privé virtuel dans lequel est mis en oeuvre un tunnel. Un tel tunnel 1 est établi sur la figure 1 entre une tête de tunnel 2 d'un premier réseau 3 (LAN A) et une tête de tunnel 4 d'un deuxième réseau 5 (LAN B) à travers un réseau de communication 6 tel qu'Internet (pour simplifier la figure, les équipements d'infrastructure du réseau Internet 6 tels que les routeurs n'ont pas été représentés). Le réseau 3 (respectivement le réseau 5) comporte un module 7 (respectivement 8) permettant d'accéder au réseau internet haut-débit 6, cet équipement comporte une passerelle domestique et un pare-feu. Des éléments de type PC 10 et 11, des serveurs 12 et 13 permettant le stockage et le partage de médias numériques ainsi que d'autres équipements tels que des afficheurs multimédia (� media players � en anglais) 14 et 15 sont également compris dans ces réseaux de type LAN. Le tunnel est établi entre les deux têtes de tunnel 2 et 4, et chaque paquet (aussi appelé trame) envoyé par un équipement connecté à l'un des deux réseaux est encapsulé par la tête de tunnel de ce réseau puis envoyé à la tête de tunnel de l'autre réseau qui va le désencapsuler pour permettre à ces données d'être lues. L'établissement du tunnel 1 permet ainsi aux équipements 10 à 15 des deux réseaux de communiquer entre eux même si ils n'appartiennent pas 25 au même réseau de type LAN. Par exemple, le PC 10 du réseau 3 peut communiquer avec le serveur 13 du réseau 5 par l'intermédiaire du tunnel 1. On va maintenant décrire en détails les différents éléments permettant d'établir un tunnel à l'aide de la figure 2. 30 Sur cette figure sont représentés trois réseaux de type LAN 20 (LAN A), 21 (LAN B), et 22 (LAN C) similaires aux réseaux 3 et 5 de la figure 1, c'est- à-dire qu'ils possèdent chacun une passerelle (non représentée sur la figure 2) donnant accès au réseau internet, L'ensemble de ces réseaux, auxquels s'ajoute le réseau internet, constitue un réseau de communication au sens de l'invention. Le réseau 20 (respectivement 21 et 22) comporte une tête de tunnel 23 (respectivement 24 et 25). Entre les têtes de tunnel 23 et 24 est établi un tunnel 26 tandis qu'entre les têtes de tunnel 23 et 25 est établi un tunnel 27. Le transit des donnés s'effectue d'une tête de tunnel à l'autre par l'intermédiaire des passerelles du type de celles représentées sur la figure 1. Les têtes de tunnel 23 et 24 possèdent chacune un pont (respectivement 30 et 31) permettant de relayer des trames issues des tunnels vers des équipements connectés sur le réseau de type LAN de la tête de tunnel correspondante et réciproquement. On rappelle ici que chaque pont gère un ensemble d'au moins une table d'adresses MAC, chaque table étant associée à un port du pont et indiquant l'ensemble des adresses MAC connues sur le segment Ethernet connecté à ce port. Chaque table résulte d'un mécanisme d'apprentissage permettant au pont de mettre à jour les adresses MAC à chaque réception de trame Ethernet via le port associé à cette table. Le pont doit s'assurer que les trames émises par un équipement connecté sur un segment Ethernet, à destination d'un équipement situé sur un autre segment, soient correctement relayées par ce dernier. Ainsi, cela permet aux équipements situés sur deux segments différents d'être interconnectés par le pont. Cependant, un pont ne relaie une trame Ethernet présentée sur un de ses ports vers un autre de ses ports que selon certaines conditions. Ceci est réalisé afin de ne pas polluer inutilement les différents segments avec des trames Ethernet uniquement utiles à la communication de deux équipements qui, par exemple, appartiendraient au même segment Ethernet. Ainsi, un pont ne relaie une trame que si l'une des trois conditions suivantes est remplie : - le destinataire de la trame reçue sur un port est connu, et il figure dans l'une des tables d'adresses MAC du pont associée à un autre port que celui sur lequel a été reçue la trame ; - l'adresse de destination de la trame est inconnue du pont (n'appartient à aucune des tables d'adresses MAC) ; - l'adresse de destination est une adresse de diffusion (� Broadcast � en anglais) prévue pour être diffusée sur l'ensemble du réseau. Le pont doit également s'assurer, comme on l'a vu précédemment, qu'il ne doit pas créer de boucle au sein du réseau à chaque nouvelle ouverture de port. Dans l'exemple illustré, le pont 30 (respectivement 31) possède des ports 34, 35 et 36 (respectivement 37 et 38) permettant de connecter les différentes interfaces réseaux, que ces interfaces soient réelles (dans le cas d'une connexion locale) ou virtuelles (dans le cas d'une connexion par tunnel vers un réseau ou un équipement distant). Pour ouvrir une nouvelle connexion par tunnel sur une de ces têtes de tunnel, celle-ci doit ajouter un nouveau port au pont correspondant. Ce port sera vu par le pont comme l'interface vers le réseau distant. Ainsi sur la figure 2, à l'ouverture du tunnel 26 par exemple, la tête de tunnel 23 a créé le port 35 dans le pont 30 et la tête de tunnel 24 a créé le port 37 dans le pont 31. Une fois les ports créés et la phase d'écoute achevée, le pont peut relayer les trames entre les ports, permettant ainsi au tunnel de fonctionner. Ainsi, pour les équipements, tout se passe comme s'ils étaient connectés à un même réseau, les communications entre deux équipements via le tunnel étant appelées des communications de bout-en-bout (en anglais, � end-to-end communication �). La tête de tunnel 25, quant à elle, est dépourvue de pont et est intégrée à un équipement 32. Cette tête de tunnel échange directement des trames entre l'application 33 de cet équipement 32 et la tête de tunnel 23 par l'intermédiaire du tunnel 27 qui a pu être ouvert par la création du port 36 sur le pont 30. L'équipement 32 est ainsi connecté aux réseaux de type LAN 20 et 21 et peut communiquer via les tunnels 26 et 27 avec d'autres équipements des réseaux 20 et 21. Lorsque tous les tunnels sont établis, les réseaux 20, 21 et l'équipement 32 sont ainsi réunis en formant un réseau global de communication. Par contre, la tête de tunnel 25 ne possédant pas de pont, le réseau 22 ne fait pas partie du réseau de communication formé par les réseaux 20, 21, et l'équipement 32. On notera qu'une même tête de tunnel, telle que la tête 23 peut être amenée à gérer plusieurs tunnels à destination d'autres têtes de tunnel pour interconnecter un premier réseau de type LAN à plusieurs autres réseaux. On notera également que les réseaux peuvent posséder des ponts autres que ceux inclus dans la tête de tunnel selon l'invention, comme c'est le cas du pont 39 du réseau 21 illustré en figure 2 et/ou que les équipements tels que l'équipement 32 ne sont pas nécessairement raccordés à un réseau tel que le réseau 22. On notera enfin que le procédé de paramétrage selon l'invention permet ainsi de mettre en communication un pont, tel que le pont 30, avec un élément à connecter à ce pont, tel qu'un autre pont (le pont 31) ou tel qu'un équipement (l'équipement 32). On va maintenant décrire à l'aide de la figure 3 le cheminement des trames Ethernet qui vont transiter au travers des tunnels établis entres les têtes de tunnel selon l'invention. Cette figure illustre les couches de protocole implémentées dans les têtes de tunnel 23 à 25 qui sont nécessaires à l'établissement des tunnels, les éléments de protocole nécessaires aux fonctions autres que l'établissement du tunnel n'étant pas représentés ici. Chaque tête de tunnel comporte ainsi une interface physique Ethernet 50 qui transmet les trames Ethernet provenant des équipements du réseau de type LAN auquel appartient la tête de tunnel à une couche de liaison Ethernet 51 pour routage. Cette couche de liaison transmet les trames, soit vers une couche réseau 53 pour les trames destinées à l'équipement comportant la tête de tunnel, soit vers la couche 54 du pont que comporte cette tête pour les autres trames. La couche de pont 54 réalise des opérations de filtrage des trames Ethernet et le relais de ces trames vers le ou les port(s) Ethernet approprié(s). Cette couche de pont coopère avec la couche Ethernet 51 qui constitue l'interface physique du pont ainsi qu'avec une interface de réseau virtuel 52 qui simule un contrôleur Ethernet virtuel et qui est créée pour chaque tunnel. Cette interface virtuelle est créée pour chaque tunnel par une application de tunnel 55 que comporte la tête de tunnel afin de remettre à cette interface les trames Ethernet qui doivent transiter sur les tunnels. L'application de tunnel 55 réalise également l'ensemble des opérations nécessaires à la mise en oeuvre de chaque tunnel, telles que notamment la configuration, le filtrage, l'encapsulation et l'extraction (ou désencapsulation) de trames. Dans le cas d'une trame du réseau de type LAN (tel que le réseau 3 illustré sur la figure 1) destinée à être envoyée via un tunnel sur l'autre réseau de type LAN (le réseau 5), cette trame traverse les couches 50 et 51 pour atteindre le pont qui, en détectant que cette trame est destinée au tunnel, transfère celle-ci sur l'interface virtuelle 52 pour être encapsulée par l'application de tunnel 55 de la tête de tunnel 2. Cette trame traitée par l'application 55 est remise sous la forme de paquets à travers une interface applicative 56 à un protocole de transport fiable 59 (TCP) ou non fiable 60 (UDP) respectivement sécurisés par les protocoles 57 (SSL) et 58 (DTLS). Les paquets ainsi transportés sont remis au réseau de type LAN après passage des couches réseau 53, 51 et 50 pour être transférés au travers de la passerelle domestique du module 7 vers le réseau de type LAN 5 par le tunnel 1 (figure 1). La réception d'une trame en provenance d'un tunnel suivra, dans la tête de tunnel, le cheminement inverse à celui présenté ci-dessus. La trame encapsulée sera ainsi extraite par l'application 55 après qu'elle ait traversé les couches 50, 51, 53, 59 ou 60 et 57 ou 58 et sera reçue ensuite sur l'interface virtuelle 52 qui la remettra à la couche de pont 54 pour que celui-ci la redirige vers le réseau de type LAN 3 après avoir traversé les couches 51 et 52. On va maintenant décrire à l'aide des figures 4 et 5 l'enchaînement des opérations réalisées par une tête de tunnel 70, créant un port pour établir une connexion par tunnel avec une autre tête de tunnel 71. Selon une première étape S72, cette tête de tunnel 70 (tête de tunnel client) établit une porteuse avec la tête de tunnel 71 avec laquelle elle souhaite établir la connexion (tête de tunnel serveur). Cette porteuse peut par exemple être une session TCP permettant d'échanger des trames entre les têtes de tunnel. Pour cela, et comme illustré schématiquement en figure 5 une première trame 78 � TCP Syn � est envoyée par le client 70 vers le serveur 71. A réception de cette trame 78, la tête de tunnel 71 qui assume le rôle de serveur envoie en réponse une trame d'acquittement 79 � TCP Syn Ack � vers la tête de tunnel client. A la réception de cette trame par le client est mise en oeuvre l'étape suivante S73 dans laquelle le client demande au serveur l'ouverture d'un tunnel. Pour cela, le client envoie une seconde trame 80 � Open Tunnel � et le serveur répond, à la réception de cette trame 80 par une trame 81 d'acceptation d'ouverture du tunnel � Open Tunnel Ack �. Un type de protocole pour ces échanges est par exemple le protocole L2TP (� Layer Two Tunnel Protocol �). Ces échanges protocolaires sont mis à profit pour déterminer une valeur d'un temps d'aller-retour de bout en bout dans le réseau (connu en anglais sous l'acronyme RTT pour � Round Trip Time �). En effet, si l'on considère que le temps de traitement entre la réception d'une trame requête et l'envoi d'une trame réponse (en réponse à la trame requête) est négligeable devant la valeur de RTT (ce qui est très largement le cas sur des réseaux longue portée tels que le réseau Internet, mais aussi pour des réseaux de type LAN), la valeur du RTT peut être considérée comme sensiblement égale au temps écoulé entre l'émission de la trame requête et la réception de la trame réponse. Ainsi, dans le cas de l'échange illustré en figure 5, le client 70 fait une première évaluation de la valeur du RTT en mesurant le temps écoulé entre l'émission de la trame 78 et la réception de la trame 79. Le client 70 pourra affiner cette valeur en mesurant le temps écoulé entre l'émission de la trame 80 et la réception de la trame 81, puis en moyennant cette valeur avec la valeur de RTT déjà évaluée. Le serveur 71, quant à lui, peut déterminer une valeur du RTT en mesurant le temps écoulé entre l'émission de la trame 79 et la réception de la trame 80. Ces échanges protocolaires permettent également d'échanger des informations sur la topologie des réseaux client et serveur. La trame 80 comprend des informations sur la topologie du réseau auquel est connecté le client 70, tandis que la trame 81 comprend des informations sur la topologie du réseau auquel est connecté le serveur 71, de sorte que sont ainsi connues au niveau du client 70 et au niveau du serveur 71 les informations de topologie des deux réseaux de type LAN. Les informations sur la topologie ainsi véhiculées peuvent prendre trois valeurs : - le type � équipement � qui indique que la tête de tunnel correspondante (client 70 ou serveur 71) ne possède pas de pont, telle que par exemple la tête de tunnel 25 illustrée en figure 2 ; ce type de topologie correspond par exemple à des équipements mobiles pouvant embarquer une tête de tunnel (téléphone, appareil photos, caméscope, etc.) ; - le type � topologie simple � qui indique que la tête de tunnel correspondante comporte un pont mais que le réseau de type LAN auquel appartient cette tête ne possède aucun autre pont ni aucun autre tunnel ; et - le type � topologie complexe � qui indique que la tête de tunnel correspondante comporte un pont et que le réseau de type LAN auquel appartient cette tête possède au moins un autre pont ou un autre tunnel vers des réseaux simples ou complexes. Chaque tête de tunnel présente ainsi son propre type de topologie qui, comme on le verra ci-après, peut évoluer au cours du temps en fonction 10 des ouvertures/fermetures de tunnel. D'autres informations sont également échangées pour permettre, comme on le verra ci-après, une détermination fine de la valeur du temps d'attente du pont : par exemple le diamètre du réseau (nombre maximal de segments de réseau séparant deux équipements de réseau), l'identifiant du 15 pont racine du réseau, ou encore le RTT maximum mesuré entre la tête de tunnel et un équipement du réseau local (auquel est connectée la tête de tunnel). L'ensemble de ces informations est stocké localement dans une table de données 85 illustrée en figure 8. 20 Cette table contient les informations relatives à chaque tunnel ouvert sur une même tête de tunnel (une ligne par tunnel) à l'exception de la première ligne (d'indice tunnel 0) qui correspond aux données du réseau local (auquel est connectée la tête de tunnel). Le champ 86 est un identifiant unique alloué par la tête de tunnel lors 25 de l'ouverture d'un réseau, (cet identifiant est dans l'exemple illustré un compteur incrémenté à chaque ouverture de tunnel). La valeur 0 est réservée au réseau local (auquel est connectée la tête de tunnel). Le champ 87 correspond au diamètre du réseau distant (le réseau du serveur si le réseau local (auquel est connectée la tête de tunnel) est le réseau 30 client et inversement sinon) correspondant au tunnel dont l'identifiant est égal au champ 86. Le champ 88 correspond au RTTmax du réseau distant (temps maximum aller-retour de communication entre la tête de tunnel locale et tout équipement connecté à ce réseau distant). Le champ 89 contient l'identifiant du pont racine du réseau distant (la plus petite valeur de l'identifiant des ponts du réseau distant). Le champ 90 contient la valeur de la variable de complexité de la tête de tunnel distante, cette valeur correspondant à la complexité de la topologie du réseau distant. Le champ 91 correspond au numéro de port du pont associé au tunnel dont la valeur d'identifiant est égale au champ 86. A la réception de la trame 80 pour le serveur et de la trame 81 pour le client, la tête de tunnel 70 ou 71 ajoute une ligne dans la table 85 des tunnels. La valeur du champ 87 est celle reçue dans la trame 80 pour le serveur et dans la trame 81 pour le client augmentée de 1 pour tenir compte du tunnel. La valeur du champ 88 est celle reçue dans la trame 80 pour le serveur et dans la trame 81 pour le client augmentée de la valeur du RTT entre le client et le serveur déterminée précédemment grâce aux échanges des requêtes 78 à 81. Ces échanges de requête permettent ainsi d'obtenir une information (RTT) qui sera, comme on le verra ci après, utile pour la détermination du paramètre FD (pour � Forward Delay � en anglais) représentatif du temps d'attente à appliquer sur ce pont lors de l'ouverture d'un nouveau port. Les autres valeurs véhiculées par la trame 80 pour le serveur et par la trame 81 pour le client sont stockées sans modification. Cette ligne de la table 85 correspondant au tunnel en cours d'ouverture est supprimée lors de la fermeture du tunnel. Une fois cette table ainsi renseignée, le ou les différents paramètres du pont que comporte la tête de tunnel sont déterminées à l'étape S74 et notamment le paramètre FD représentatif du temps d'attente à appliquer sur ce pont lors de l'ouverture d'un nouveau port. Cette étape sera détaillée ci-après à l'aide de la figure 6. Dans une étape S75 suivant l'étape S74, le pont est configuré avec son ou ses paramètre(s) déterminé(s) préalablement, que ce pont soit racine ou non et cela sans perturber le fonctionnement � normal � des algorithmes de détermination de l'arbre de recouvrement. Cette étape sera détaillée ci-après à l'aide de la figure 7. Au cours de l'étape suivante S76 un port virtuel est créé sur le pont afin de permettre l'échange de données. Cette étape sera également détaillée à l'aide de la figure 7. Enfin, l'étape suivante S77 démarre le processus permettant de transférer les données de l'interface virtuelle ainsi générée vers le tunnel ou pour en recevoir, permettant ainsi aux équipements des réseaux client et serveur de communiquer entre eux. Il est alors mis fin à l'algorithme de la figure 4. On va maintenant décrire à l'aide de la figure 6 la façon dont est déterminée la valeur du paramètre FD (correspondant au temps d'attente du pont à paramétrer) en fonction des informations contenues dans la table 85. Tout d'abord, l'étape S95 est mise en oeuvre pour déterminer les valeurs actuelles des paramètres du pont (détermination du type de protocole d'arbre de recouvrement sur le pont, détermination si cet arbre de recouvrement est actif ou non et détermination de la valeur du temps d'attente courante sur le pont) et ces informations sont ensuite stockées dans une mémoire locale. Dans l'exemple illustré le protocole utilisé est le protocole RSTP auquel a été ajouté le procédé de paramétrage de pont selon l'invention. A l'étape suivante S96, est lue dans la table 85 l'information de topologie distante correspondant à l'élément (un équipement ou un pont) à mettre en communication avec le pont considéré. Il s'agit de l'une des lignes dont la valeur du champ 86 est supérieure ou égale à 1, la ligne dont la valeur de ce champ est égale à 0 étant dédiée au réseau local. Cette étape prévoit de réaliser un test afin de déterminer le type de topologie distante et donc l'information de topologie associée. Si cette étape détermine que la topologie distante est du type � équipement �, cela signifie que la tête de tunnel distante est dépourvue de pont et qu'une seule liaison par tunnel est possible avec cet équipement, la création de boucle étant donc impossible. Dans le cas du protocole RSTP ici utilisé, l'étape S97 est ensuite exécutée. Au cours de cette étape, il est spécifié en utilisant l'interface d'administration du pont que le type de port correspond à une liaison avec un équipement (cas du protocole RSTP uniquement). Si le type de topologie distante est un type � simple �, cela signifie que la tête de tunnel distante comporte un pont, mais que ce pont est unique et qu'aucun autre tunnel par des réseaux simples ou complexes n'a encore été ouvert, alors l'étape S98 est réalisée et effectue une mise à jour de l'information de topologie locale en faisant passer le type de topologie locale à la valeur complexe. En effet, en cas de topologie du réseau distant de type simple, il n'y a pas de risque immédiat de création de boucle, mais tout autre création de port pour le pont en question pourrait être source de boucle, par conséquent le type de topologie locale doit devenir complexe quelle que soit sa valeur courante. Ensuite l'étape S99 est exécutée et fait associer au type de port la valeur � lien � qui indique que le port relie deux segments de réseau (cas du protocole RSTP uniquement). A l'issue de l'étape S97 ou S99, l'étape S100 est exécutée et positionne la valeur paramètre FD à 0 (ouverture immédiate du port). En effet, la topologie du réseau distant (de type simple ou équipement) ne risque pas d'entraîner la création de boucle de sorte qu'aucune attente n'est nécessaire pour détecter la présence de celle-ci. Il est donc possible d'ouvrir ce nouveau port sans aucun temps de latence. Par contre, si l'étape S96 a conduit à déterminer que le type de topologie du réseau distant est � complexe �, cela signifie qu'il faut déterminer en détail la topologie du réseau local pour savoir si l'ouverture d'un tunnel vers un réseau complexe peut générer une boucle. L'étape S101 est alors exécutée et réalise un test afin de déterminer le type de topologie locale. Pour ce faire, il est prévu de lire l'information de topologie locale, cette information étant présente au niveau de la première ligne de la table 85 (valeur du champ 86 égale à 0) qui est dédiée au réseau local. L'information de topologie locale peut ainsi être directement lue sur cette table (champ 90 de cette première ligne). Si le résultat de l'étape S101 a déterminé que la topologie locale est de type � équipement �, cela signifie que cet équipement est dépourvu d'un pont à paramétrer localement (l'équipement comportant simplement une tête de tunnel) et l'algorithme prend fin. Si le résultat de l'étape S101 a déterminé que la topologie locale est de type � simple �, l'ouverture d'un tunnel vers une topologie de type complexe nécessite le changement de topologie locale. Celle-ci devient alors complexe puisque le pont local va être connecté à un autre pont à la suite de l'établissement du tunnel en cours d'ouverture. L'étape suivante S102 réalise ainsi une mise à jour de l'information de topologie locale et positionne alors la nouvelle valeur de topologie locale à � complexe �, puis passe à l'étape S103. De retour à l'étape S101, si le résultat du test a déterminé que la topologie locale était de type complexe, alors l'étape S103 est directement réalisée. Cette étape S103 détermine la valeur du paramètre FD (correspondant au temps d'attente) à appliquer au port à créer, cette valeur peut être alors calculée grâce à la formule suivante : FD = (4xHELLO + 3xDIA) 2 où DIA est le diamètre du réseau une fois le tunnel en cours d'ouverture ouvert et HELLO l'intervalle de temps entre deux envois de trame BPDU (typiquement égal à 1 seconde). Cette formule s'applique pour tous les types de protocoles de détermination de l'arbre de recouvrement et est celle utilisée dans la norme IEEE 802.1D pour obtenir la valeur par défaut de 15 secondes (soit une hypothèse retenue où DIA vaut 8 et HELLO vaut 1). Dans le procédé selon l'invention, cette valeur n'est pas une constante mais est recalculée à chaque nouvelle création de port grâce aux informations contenues dans la table 85. Ainsi, par exemple dans le cas d'un environnement domestique simple où le diamètre est généralement de 0 (tous les équipements sont sur le même segment) et en prenant pour le calcul de DIA la formule DIA = diamaxi + diamax2, où diamaxi et diamax2 sont les deux plus grandes valeurs de la table 85, on obtient DIA=0+1=1. En effet diamaxi est égal à 0 tandis que diamax2 = 1, la valeur 1 étant ajoutée pour tenir compte de l'ouverture du tunnel. Le temps d'attente FD est ainsi de 4 secondes (7/2 = 3.5 arrondi à 4). Ainsi, pour un tunnel reliant deux réseaux domestiques simples où tous les équipements sont reliés à un unique commutateur, le temps d'attente ainsi déterminé est inférieur de plus des deux tiers au temps d'attente (15s) conventionnellement utilisé ce qui permet de ne pas bloquer le transfert de données pendant un temps excessif qui pourrait être assimilé par l'utilisateur à un blocage du système. Une autre méthode de calcul de FD dans le cas du protocole RSTP est basée sur les valeurs de RTTmax FD = RTTmax1 + RTTmax2 où RTTmaxl et RTTmax2 sont les deux plus grandes valeurs de RTTmax de la table 85 (champ 88). Cette valeur de FD est en général très inférieure à un temps d'une seconde (quelques centaines de ms). Une fois la valeur de FD déterminée à l'étape S103, l'étape S104 active l'utilisation du protocole de détermination de l'arbre de recouvrement (RSTP dans l'exemple illustré) du pont via son interface d'administration. On va maintenant décrire à l'aide de la figure 7, les étapes S75 et S76 consistant à paramétrer le pont suite à la détermination du paramètre FD décrit précédemment et à réaliser la création du port correspondant. Dans un premier temps, l'étape S110 teste si un protocole de détermination d'un arbre de recouvrement est actif sur un pont. En effet, lorsqu'un tel protocole est actif et si le pont n'est pas racine, les valeurs de paramètres du pont (telles que la valeur de FD) ne peuvent lui être communiquées que par l'intermédiaire de l'envoi de trame de type BPDU à partir du pont racine. Par contre, si le protocole n'est pas actif une configuration directe du pont est possible et est mise en oeuvre à l'étape S111 indépendamment du fait que ce pont soit racine ou non. Si l'étape de test S110 détermine que le protocole RSTP est actif, alors l'étape S112 active un filtrage temporaire de tous les messages de gestion inter-ponts (les paquets de type BPDU). Ce filtrage empêche temporairement la réception de ces messages par le ou les ports du pont (qu'ils soient reçus sur une interface physique ou virtuelle du pont) ainsi que l'émission de tels messages par le pont. Ce filtrage ainsi activé permet de modifier les paramètres du pont considéré afin d'enregistrer la valeur du paramètre FD de ce pont nécessaire à l'ajout et à l'activation du nouveau port considéré. De plus, ce filtrage permet d'éviter la propagation vers les autres ponts de la valeur du paramètre FD temporaire et spécifique à la création d'un port donné pour ce pont. Pour cela, tous les tunnels déjà ouverts pour le pont considéré vont temporairement déterminer, par analyse de leur en-tête Ethernet, les trames de type BPDU reçues ou émises. Ces trames déterminées sont alors supprimées et ne seront donc pas transférées de la couche socket 56 à la couche interface virtuelle 52 et réciproquement. Suite à la mise en place de ce mécanisme de filtrage des paquets de type BPDU, le pont se retrouve ainsi très temporairement isolé du réseau (local ou distant) et toutes modifications des valeurs du temps d'attente et des autres paramètres ne seront donc pas répercutées sur les autres ponts du réseau. Un filtrage supplémentaire est également mis en place par l'ajout de règles sur le traitement des trames IP entrantes par le système d'exploitation. Ceci empêche d'éventuelles trames de type BPDU émises par un quelconque autre pont du réseau de modifier intempestivement les valeurs de paramètres 23 du pont avant que le nouveau port virtuel devant servir de support au tunnel en cours d'ouverture ne soit créé. Sous un système de type UNIX, un tel filtrage est mis en oeuvre par l'utilisation de commandes de paramétrages IPCHAINS. Une fois ce filtre mis en oeuvre, l'étape suivante de test S113 vérifie si le pont est un pont racine par l'interrogation de son interface d'administration. S'il est déterminé que le pont est racine, un paramétrage direct de ce pont est alors possible même si le protocole RSTP est actif et l'étape S114 est exécutée. Cette étape utilise l'interface d'administration du pont pour faire prendre à la valeur d'attente du pont la valeur FD déterminée à l'étape S103. De retour à l'étape S113, si le pont n'est pas racine, seule la réception de trames de type BPDU issues du pont racine (ou simulées comme telles) sont à même de modifier les paramètres du pont. Le filtrage étant actif la trame BPDU ne peut provenir réellement du pont racine. Il est par contre possible de simuler à partir de l'application de tunnel une trame pour faire en sorte que tout se passe comme si elle provenait du pont racine. Pour cela l'étape S115 détermine le chemin racine (c'est-à-dire le tunnel qui mène au pont racine) du pont considéré. Cette opération peut être réalisée en interrogeant le pont via son interface ou en consultant la table 85. Une fois que le numéro de port du pont qui permet de remonter au pont racine est identifié, on recherche dans cette table le tunnel associé et ce sera l'application de tunnel 55 correspondante qui sera responsable de la génération à l'étape suivante S116 (sur l'interface virtuelle 52 correspondant au port qui a été identifié) d'une trame de type BPDU de configuration du pont. Ce message de gestion inter-ponts simule ainsi un message de gestion inter-ponts provenant du pont racine associé. On notera qu'il n'existe pas de filtrage entre l'application 55 et l'interface 52 de sorte que le message de gestion inter-ponts, qui est reçu sur l'interface 52, n'est pas filtré et permet donc bien de configurer le pont. Cette trame BPDU contient la nouvelle valeur des paramètres que l'on veut affecter au pont ainsi que l'adresse MAC du pont racine et son identifiant. Ceci permettra à la trame d'être identifiée par le pont à configurer comme étant issue du pont racine. Les étapes S114, S115 et S116 permettent ainsi de configurer le pont avec le paramètre FD déterminé précédemment. Que le pont soit racine ou non, une fois les étapes S114 et S116 réalisées, l'étape S117 crée un nouveau port sur le pont (ajout d'une interface virtuelle pour le tunnel en cours d'ouverture) avec pour ce port la valeur du paramètre FD qui a été transmis par la trame BPDU au pont. En pratique la tête de tunnel associée au pont envoie une requête au pont pour que le port soit créé et attend que le pont l'informe en retour que cette opération est correctement achevée. Lorsque le port est créé, l'étape S118 renseigne la valeur du champ 86 de la nouvelle ligne créée pour ce port avec le nouveau numéro de port. Il est à noter que la durée de la phase pendant laquelle le pont n'est plus connecté aux autres ponts est très courte (de l'ordre de quelques millisecondes) puisque ce temps correspond au temps de traitement du pont pour l'ajout d'un nouveau port (et non son activation). C'est à la création du port que la valeur du paramètre FD est prise en compte pour ce port, et c'est la valeur de ce paramètre au moment de cette création qui définira le temps de la phase d'écoute sur ce port (à l'étape d'activation 120). En conséquence, à partir de cet instant il n'est plus nécessaire de conserver cette valeur et il est alors possible de remodifier la valeur de FD (pour ne pas perturber le fonctionnement du pont après la création de ce port) pour revenir à l'ancienne valeur sans que cela n'affecte le temps d'activation du port qui vient d'être créé. L'étape S119 est ensuite exécutée pour désactiver le filtrage mis en oeuvre à l'étape S112 dès lors que la création du nouveau port est effective. Le pont a donc retrouvé le même état que celui dans lequel il se trouvait avant l'ajout de ce nouveau port. Les mécanismes de détermination de l'arbre de recouvrement peuvent donc reprendre de façon normale et la phase d'écoute des données reçues pour le nouveau port créé (en attente de réception de trames BPDU) pendant un temps d'attente égal au paramètre FD prédéterminé (pour détecter la présence d'une éventuelle boucle) peut s'opérer. Il s'agit de la phase d'activation S120 du port. Une fois ce nouveau port créé et activé, le tunnel est ouvert et le pont est ainsi mis en communication avec l'élément à connecter à ce pont. L'étape S77 de transfert effectif des données (figure 4) peut donc être mise en oeuvre. Au cours de cette étape les données transitent au travers du tunnel. Une fois cet échange achevé, et si il n'est plus nécessaire de conserver le tunnel pour d'autres transferts de données, il est alors possible de fermer le ou les ports qui avaient été ouverts pour établir cette connexion. A la fermeture de ces ports, les informations de topologie distante et locale sont mises à jour en conséquence dans la table 85 afin de prendre en compte la nouvelle topologie des réseaux une fois le tunnel fermé. La figure 9 illustre un mode particulier de réalisation d'un dispositif 150 de communication apte à fonctionner conformément à la présente invention. Les têtes de tunnel décrites précédemment sont identiques au dispositif 150. Le dispositif 150 illustré sur la figure 9 peut comporter tout ou partie des moyens de mise en oeuvre d'un procédé de paramétrage conforme à la présente invention, et qui correspondent notamment à des moyens permettant de mettre en oeuvre chaque étape du procédé, à savoir : - des moyens pour déterminer, en fonction d'au moins une information de topologie dudit réseau, un paramètre représentatif d'un temps d'attente prédéterminé et correspondant à un temps de détection par ledit pont, pendant une phase d'écoute des données reçues par ledit au moins un port, de la présence d'une éventuelle boucle de communication au sein dudit réseau; - des moyens pour activer un filtrage dudit au moins un port, ledit filtrage étant adapté à empêcher l'émission et la réception par le ou lesdits ports du pont déjà créés de messages de gestion inter-ponts ; - des moyens pour configurer le pont avec ledit paramètre ainsi déterminé ; - des moyens pour créer un nouveau port dudit pont en vue d'établir la communication avec ledit au moins un élément ; et - des moyens pour désactiver ledit filtrage. Ce dispositif 150 comporte une interface de communication 151 reliée aux réseaux 152 et 153. Le dispositif 150 comporte également un moyen de stockage permanent 154, tel qu'un disque dur, ainsi qu'un lecteur de moyens de stockage d'informations temporaire tel qu'un lecteur 155 de disque externe 156 tel qu'une clé USB. La clé 156 et le disque dur 154 peuvent contenir des données d'implantation logicielle de l'invention ainsi que le code du ou des programme(s) d'ordinateur dont l'exécution par le dispositif 150 met en oeuvre la présente invention, ce code étant par exemple mémorisé sur le disque dur 154 une fois qu'il a été lu par le dispositif 150. En variante, le ou les programme(s) permettant au dispositif 150 de 20 mettre en oeuvre l'invention sont stockés dans une mémoire morte (par exemple du type ROM) 157. Selon une autre variante, ce ou ces programme(s) sont reçus totalement ou partiellement à travers les réseaux de communication pour être stockés comme indiqué. 25 Le dispositif 150 comprend également un écran 158 pour visualiser les informations et/ou servir d'interface graphique avec l'utilisateur, afin que l'utilisateur puisse interagir avec les programmes selon l'invention à l'aide du clavier 159 ou de tout autre moyen approprié de pointage et/ou de saisie tel qu'une souris, un crayon optique, etc. 30 Une unité de calcul ou unité centrale de traitement (CPU) 160 exécute les instructions relatives à la mise en oeuvre de l'invention, ces instructions étant stockées dans la mémoire morte ROM 157 ou dans les autres éléments de stockage décrits. Lors de la mise sous tension du dispositif 150, les programmes et méthodes de traitement stockés dans une des mémoires non-volatiles, par exemple la ROM 157, sont transférés dans une mémoire vive (par exemple du type RAM) 161, qui contient alors le code exécutable de l'invention ainsi que les variables nécessaires à la mise en oeuvre de l'invention. En variante, l'algorithme du procédé de paramétrage peut être stocké dans différents emplacements de stockage. De façon générale, un moyen de stockage d'information lisible par un ordinateur ou par un microprocesseur, intégré ou non au dispositif, éventuellement amovible, peut mémoriser un ou plusieurs programme(s) dont l'exécution met en oeuvre le procédé de paramétrage décrit précédemment. On peut faire évoluer le mode particulier de réalisation choisi pour l'invention, par exemple en ajoutant des procédés de paramétrage actualisés ou améliorés ; dans un tel cas, ces nouvelles méthodes peuvent être transmises au dispositif 150 par l'un des réseaux de communication 152 ou 153, ou chargées dans le dispositif 150 par l'intermédiaire d'une clé 156. Bien entendu, la clé 156 peut être remplacée par tout support d'information jugé approprié (CD-ROM, disquette, etc.). Un bus de communication 162 permet la communication entre les différents éléments du dispositif 150 et les éléments reliés à celui-ci. On notera que la représentation du bus 162 n'est pas limitative. En effet, l'unité centrale CPU 160 est, par exemple, susceptible de communiquer des instructions à tout élément du dispositif 150, directement ou par l'intermédiaire d'un autre élément de ce dispositif. On notera que pour le calcul de temps d'attente FD, d'autres formules de calcul que celles décrites ci-dessus peuvent être bien entendu envisagées. Selon une variante d'autres protocoles que le protocole RSTP peuvent être perfectionnés avec le procédé selon l'invention. Il peut par exemple s'agir du protocole STP (avec suppression des étapes S97 et S99 sur la figure 6). De nombreuses autres variantes sont possibles en fonction des circonstances, et l'on rappelle à cet égard que l'invention ne se limite pas aux exemples décrits et représentés. REVENDICATIONS1. Procédé de paramétrage, au sein d'un réseau de communication, d'un pont à mettre en communication avec au moins un élément à connecter audit pont, ledit pont comprenant au moins un port créé, caractérisé en ce qu'il comporte les étapes suivantes : - détermination (S74), en fonction d'au moins une information de topologie dudit réseau, d'un paramètre représentatif d'un temps d'attente prédéterminé et correspondant à un temps de détection par ledit pont, pendant une phase d'écoute des données reçues par ledit au moins un port créé, de la présence d'une éventuelle boucle de communication au sein dudit réseau ; - activation (S112) d'un filtrage dudit au moins un port créé, ledit filtrage étant adapté à empêcher l'émission et la réception par ledit au moins un port créé de messages de gestion inter-ponts ; - configuration (S114, S115, S116) du pont avec ledit paramètre ainsi déterminé ; - création (S117) d'un nouveau port dudit pont en vue d'établir la communication avec ledit au moins un élément ; et - désactivation (S119) dudit filtrage. 2. Procédé selon la revendication 1, caractérisé en ce que l'étape de détermination d'un paramètre représentatif d'un temps d'attente prédéterminé est obtenue en fonction d'au moins une information de topologie du réseau relative audit élément. 3. Procédé selon la revendication 2, caractérisé en ce l'étape de détermination d'un paramètre représentatif d'un temps d'attente prédéterminé est également obtenue en fonction d'au moins une information de topologie du réseau relative audit pont. 4. Procédé selon l'une quelconque des revendications 2 ou 3, caractérisé en ce qu'il comporte une étape de mise à jour de chaque information de topologie. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que, dans le cas où le pont est racine, l'étape de configuration du pont est mise en oeuvre par une configuration directe du pont (S114). 6. Procédé selon l'une quelconque des revendications 1 à 5, caractérisé en ce que, dans le cas où le pont n'est pas racine, l'étape de configuration du pont comporte une étape de détermination (S115), au sein du réseau, du chemin vers le pont racine associé à ce pont et une étape de génération (S116) d'un message de gestion inter-ponts simulant un message de gestion inter-ponts provenant dudit pont racine associé. 7. Procédé selon la revendication 6, caractérisé en ce que l'étape de configuration comporte également une étape de réception dudit message de gestion inter-ponts via une interface virtuelle dudit pont. 8. Procédé selon l'une quelconque des revendications 1 à 7, caractérisé en ce que la mise en communication dudit pont avec ledit élément à connecter audit pont est mise en oeuvre par l'établissement d'un tunnel entre ledit nouveau port et ledit élément. 9. Procédé selon la revendication 8, caractérisé en ce que ledit pont est associé à une tête de tunnel adaptée à établir ledit tunnel. 10. Procédé selon l'une quelconque des revendications 1 à 9, caractérisé en ce que l'étape de détermination du temps d'attente est également mise en oeuvre à partir d'au moins une autre information obtenue à partir des requêtes échangées entre le pont et l'élément à connecter audit pont avant l'établissement de ladite communication. 11. Dispositif de paramétrage, au sein d'un réseau de communication, d'un pont à mettre en communication avec au moins un élément à connecter audit pont, ledit pont comprenant au moins un port créé, caractérisé en ce qu'il comporte : - des moyens pour déterminer, en fonction d'au moins une information de topologie dudit réseau, un paramètre représentatif d'un temps d'attente prédéterminé et correspondant à un temps de détection par ledit pont, pendant une phase d'écoute des données reçues par ledit au moins un port créé, de la présence d'une éventuelle boucle de communication au sein dudit réseau; - des moyens pour activer un filtrage dudit au moins un port créé, ledit filtrage étant adapté à empêcher l'émission et la réception par ledit au moins un port créé de messages de gestion inter-ponts ; - des moyens pour configurer le pont avec ledit paramètre ainsi déterminé ; - des moyens pour créer un nouveau port dudit pont en vue d'établir la communication avec ledit au moins un élément ; et - des moyens pour désactiver ledit filtrage. 12. Dispositif selon la revendication 11, caractérisé en ce que la mise en communication dudit pont avec ledit élément à connecter audit pont est mise en oeuvre par l'établissement d'un tunnel entre ledit nouveau port et ledit élément. 13. Moyen de stockage d'informations lisible par un ordinateur ou un microprocesseur conservant des instructions d'un programme informatique, caractérisé en ce qu'il permet la mise en oeuvre d'un procédé de paramétrage selon l'une quelconque des revendications 1 à 10. 14. Produit programme d'ordinateur pouvant être chargé dans un appareil programmable, caractérisé en ce qu'il comporte des séquences d'instructions pour mettre en oeuvre un procédé de paramétrage selon l'une quelconque des revendications 1 à 10, lorsque ce programme est chargé et exécuté par l'appareil programmable.25