FR2923969A1 - Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants - Google Patents

Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants Download PDF

Info

Publication number
FR2923969A1
FR2923969A1 FR0759111A FR0759111A FR2923969A1 FR 2923969 A1 FR2923969 A1 FR 2923969A1 FR 0759111 A FR0759111 A FR 0759111A FR 0759111 A FR0759111 A FR 0759111A FR 2923969 A1 FR2923969 A1 FR 2923969A1
Authority
FR
France
Prior art keywords
tunnel
subnet
address
list
current
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0759111A
Other languages
English (en)
Other versions
FR2923969B1 (fr
Inventor
Du Fretay Tristan Halna
Philippe Boucachard
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Priority to FR0759111A priority Critical patent/FR2923969B1/fr
Priority to US12/258,104 priority patent/US7855955B2/en
Publication of FR2923969A1 publication Critical patent/FR2923969A1/fr
Application granted granted Critical
Publication of FR2923969B1 publication Critical patent/FR2923969B1/fr
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4633—Interconnection of networks using encapsulation techniques, e.g. tunneling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/45—Network directories; Name-to-address mapping
    • H04L61/4505—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols
    • H04L61/4511—Network directories; Name-to-address mapping using standardised directories; using standardised directory access protocols using domain name system [DNS]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computer Security & Cryptography (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

Il est proposé un procédé de gestion de trames dans un réseau global de communication comprenant une pluralité de sous-réseaux reliés entre eux par des tunnels aux extrémités desquels se trouvent des têtes de tunnel, au moins un des sous-réseaux comprenant au moins un dispositif source relié à une desdites têtes de tunnel via ledit sous-réseau, chaque dispositif source étant associé à une adresse. Lorsque une tête de tunnel courante reçoit, en provenance du sous-réseau auquel ladite tête de tunnel courante appartient, dit sous-réseau local, une trame courante émise par un dispositif source courant dans le réseau global, la tête de tunnel courante effectue les étapes suivantes : obtention (700), à partir de ladite trame courante, d'une adresse, dite adresse courante, de dispositif source correspondant au dispositif source courant; vérification (703) que l'adresse courante est comprise dans une première liste d'adresses comprenant des adresses associées à des dispositifs sources appartenant au ou aux sous-réseau(x) distant(s), le(s) sous-réseau(x) distant(s) étant le(s) sous-réseau(x) du réseau global distinct(s) du sous-réseau local; en cas de vérification positive, destruction (705) de ladite trame courante.

Description

Procédé de gestion de trames dans un réseau global de communication, produit programme d'ordinateur, moyen de stockage et tête de tunnel correspondants. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication. Plus précisément, l'invention concerne une technique de gestion de trames transitant entre réseaux de communications locaux par des tunnels de communication. Plus précisément encore, l'invention concerne une technique permettant d'éviter des boucles de chemins de données. 2. ARRIÈRE-PLAN TECHNOLOGIQUE La technologie des Réseaux Privés Virtuels (RPV, ou VPN pour Virtual Private Network en anglais) permet de communiquer de manière transparente en temps réel et de manière sécurisée entre des individus partageant un même domaine d'intérêt tout en utilisant l'infrastructure réseau Internet peu sûre mais bon marché.
Pour communiquer de manière transparente et s'affranchir des adresses non routables, les RPVs utilisent une encapsulation particulière (appelée tunnellisation , ou tunneling en anglais) qui crée ce que l'on appelle un tunnel. 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, B étant un protocole de couche ( layer en anglais) supérieure ou égale à A, dans un modèle en couches tel le modèle OSI qui décrit les services offerts par chacune de ces couches et leurs interactions. Dans la suite de la description, on considère, à titre d'exemple uniquement, les RPVs de niveau 2, c'est-à-dire d'encapsulation dans un tunnel de niveau 2 (tunnel de niveau 2 signifie que le protocole embarqué est un protocole de la couche 2 du modèle OSI). Les RPVs (VPN) sont fréquemment utilisés pour interconnecter deux réseaux LAN (pour Local Area Network en anglais) afin de créer un réseau local virtuel composé de l'union des deux réseaux LAN originaux. Les RPVs sécurisés incluent un algorithme de cryptographie et d'authentification pour garantir le secret des données transportées. Une configuration typique de RPV basée sur une technique de tunnellisation est illustrée sur la figure la (décrite en détail par la suite). Dans cet exemple, les têtes de tunnel ( Tunnel End Point en anglais) ne sont pas intégrées aux passerelles. Le tunnel est établi entre deux têtes de tunnel, et chaque paquet (aussi appelé trame) envoyé à un équipement connecté au réseau LAN distant est encapsulé par la tête de tunnel locale, puis envoyé à la tête de tunnel distante qui va le désencapsuler et l'envoyer sur le réseau LAN distant. Pour les équipements, ils sont virtuellement connectés à un même réseau LAN. Un équipement ne peut alors pas en fonction de l'adresse source d'une trame reçue déterminer si celle-ci est originaire du LAN local ou d'un LAN distant. Une communication entre deux équipements via le tunnel est appelée communication de bout en bout ( end-to-end communication en anglais). Classiquement, on utilise un équipement, appelé pont (ou bridge en anglais), pour relier deux segments (réseaux LANs) disjoints d'un réseau. Un tel équipement correspond à la couche 2 du modèle OSI. En effet, un pont permet de filtrer les trames du réseau en fonction de leur adresse de destination sans toutefois regarder leur contenu.
Ceci permet donc d'augmenter la distance maximale entre deux stations (aussi appelées dispositifs sources ou équipements sources), mais aussi de diminuer la charge observée sur chaque segment. En outre, le pont permet de diminuer les collisions, ce qui permet d'accroître les performances de chaque segment, et donc du réseau global. Par contre, le pont ne permet pas un filtrage des trames diffusées (du type broadcast ou multicast ), et nécessite le calcul d'un arbre de recouvrement (ou spanning free en anglais) pour éviter les boucles de chemins de données, qui créent notamment des problèmes de duplication de message. Des algorithmes de détermination d'arbre de recouvrement (ou spanning tree ) sont bien connus de l'Homme du Métier et donc pas décrits en détail. On trouve par exemple la description d'un tel algorithme dans la norme IEEE 802.1D. Un algorithme de détermination d'arbre de recouvrement (ou spanning tree ) consiste à sélectionner un pont racine et déterminer depuis cette racine un arbre de chemin(s) de données sans boucle permettant de communiquer par message de type broadcast avec l'ensemble des noeuds du réseau de communication, en bloquant dans les ponts certains ports connectés à des chemins redondants. L'inconvénient d'une telle technique de détermination d'arbre de recouvrement (ou spanning tree ) est que, dans certain cas, le chemin de données non bouclant n'est pas optimisé alors qu'il pourrait être plus court. Ainsi, la latence peut augmenter. On rappelle que la latence est le temps que prend une trame pour voyager entre la station d'origine et la destination finale sur le réseau. De plus, les techniques de détermination d'arbre de recouvrement (ou spanning tree ) nécessitent la mise en oeuvre de protocoles longs et complexes afin d'obtenir les informations de topologie nécessaires à la détection des boucles et à la configuration des différents noeuds en vue de l'élimination de ces boucles. Une deuxième technique connue, permettant d'éviter les boucles de chemins de données, consiste à sélectionner une seule tête de tunnel active par réseau LAN (plusieurs tunnels pouvant être reliés à cette tête de tunnel active), et à configurer cette dernière afin d'interdire tout transfert de trame de tunnel à tunnel. Les seuls transferts de trame autorisés étant d'un LAN vers un ou plusieurs tunnels qui lui sont reliés, et d'un tunnel relié à un LAN vers ce LAN. Plus précisément, si plusieurs stations sont actives simultanément sur un même réseau LAN, alors l'une d'elles est sélectionnée pour créer et gérer les tunnels, tandis que les autres stations désactivent leurs fonctionnalités de tête de tunnel. Cette deuxième technique est notamment présentée dans le document de brevet US 5,870,386. L'inconvénient majeur de cette deuxième technique connue réside dans le fait qu'elle ne permet pas de faire fonctionner simultanément plusieurs têtes de tunnel sur un même réseau LAN. Selon cette technique, une seule station (dite station active) doit supporter toute la charge de gestion des tunnels. Cette technique est donc mal adaptée au cas des stations actives ne possédant que des ressources en calcul et en traitement limitées telles que, par exemple, les caméscopes, les appareils photo, ou encore les imprimantes.
Une troisième technique, notamment présentée dans le document de brevet US 6,343,330, propose de mettre en oeuvre un mécanisme de type proxy . Un tel mécanisme permet d'éviter les boucles de chemins de données, en remplaçant l'adresse source d'une trame arrivant d'un tunnel vers un réseau LAN par l'adresse de la tête de tunnel d'arrivée. Cette troisième technique connue repose donc sur le fait que chaque tête de tunnel a connaissance de l'adresse des autres têtes de tunnel présentes sur le réseau LAN. Ainsi, les têtes de tunnel savent décider si une trame doit ou non être transmise sur le tunnel. Par exemple, si l'adresse source de la trame est celle d'une autre tête de tunnel, alors le paquet est détruit par la tête de tunnel l'ayant reçu. Cependant, cette troisième technique connue présente un certain nombre d'inconvénients.
Tout d'abord, cette technique est complexe (remplacement d'adresses sources) et coûteuse (coût du mécanisme de proxy , latence induite). Par ailleurs, dans certains cas, ces mécanismes de proxy ne sont pas adaptés aux communications de bout en bout, notamment du fait qu'ils impliquent une compromission de la sécurité de bout en bout (notamment la sécurité de couche réseau telle que l'IPsec) notamment en ce qu'ils modifient une partie des trames qui transitent par leur intermédiaire. 3. OBJECTIFS DE L'INVENTION L'invention, dans au moins un mode de réalisation, a notamment pour objectif de pallier ces différents inconvénients de l'état de la technique.
Plus précisément, dans au moins un mode de réalisation de l'invention, un objectif est de fournir une technique de gestion de trames, permettant d'éviter des boucles de chemins de données et qui soit simple à mettre en oeuvre et peu coûteuse. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique pouvant être mise en oeuvre dans les têtes de tunnel, et qui soit donc transparente pour les équipements source et destination. Un autre objectif d'au moins un mode de réalisation de l'invention est de fournir une telle technique permettant de répartir au mieux la charge de gestion des tunnels sur les équipements présents sur un réseau LAN donné. Un objectif complémentaire d'au moins un mode de réalisation de l'invention est de fournir une telle technique qui soit notamment bien adaptée au cas des communications de bout en bout. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, il est proposé un procédé de gestion de trames dans un réseau global de communication comprenant une pluralité de sous-réseaux reliés entre eux par des tunnels aux extrémités desquels se trouvent des têtes de tunnel, au moins un des sous-réseaux comprenant au moins un dispositif source relié à une desdites têtes de tunnel via ledit sous-réseau, chaque dispositif source étant associé à une adresse. Lorsque une tête de tunnel courante reçoit, en provenance du sous-réseau auquel ladite tête de tunnel courante appartient, dit sous-réseau local, une trame courante émise par un dispositif source courant dans le réseau global, la tête de tunnel courante effectue les étapes suivantes : -obtention, à partir de ladite trame courante, d'une adresse, dite adresse courante, de dispositif source correspondant au dispositif source courant ; - vérification que l'adresse courante est comprise dans une première liste d'adresses comprenant des adresses associées à des dispositifs sources appartenant au ou aux sous-réseau(x) distant(s), le(s) sous-réseau(x) distant(s) étant le(s) sous-réseau(x) du réseau global distinct(s) du sous-réseau local ; - en cas de vérification positive, destruction de ladite trame courante. Ainsi, l'invention repose sur une approche tout à fait nouvelle et inventive de la gestion d'une trame transitant dans un tunnel de communication. En effet, l'invention s'appuie sur l'identification de l'origine de la trame à partir de l'adresse source contenue dans la trame qui identifie le dispositif source qui a émis la trame. L'invention propose donc d'utiliser une liste d'adresses comprenant les adresses des dispositifs sources présents sur les sous-réseaux (ou LAN) distants. Dans un mode de réalisation particulier, chaque tête de tunnel d'un sous-réseau possède une telle liste et a donc connaissance de l'identité de chaque dispositif source distant (c'est-à-dire qui est présent sur un sous-réseau distant). Ainsi, lorsqu'une trame, reçue par une tête de tunnel en provenance du sous-réseau (ou LAN) auquel elle appartient, est originaire d'un dispositif source qui se trouve sur un sous-réseau distant (c'est-à-dire si l'adresse source du dispositif source est comprise dans la liste), la trame est détruite par la tête de tunnel.
Cette technique permet d'éviter des boucles de chemins de données tout en conservant une simplicité dans l'architecture des têtes de tunnel (pas de mécanisme de de type proxy et de modification des trames traitées). De façon avantageuse, la tête de tunnel courante obtient la première liste d'adresses en effectuant les étapes suivantes : - pour chaque tête de tunnel du sous-réseau local, distincte de la tête de tunnel courante, obtention, à partir d'informations reçues de ladite tête de tunnel, d'une deuxième liste d'adresses, comprenant des adresses associées à des dispositifs sources appartenant au ou aux sous-réseau(x) distant(s) relié(s) audit sous-réseau local par ladite tête de tunnel ; -détermination d'une troisième liste d'adresses, comprenant des adresses associées à des dispositifs sources appartenant au ou aux sous-réseau(x) distant(s) reliés audit sous-réseau local par ladite tête de tunnel courante ; - génération de ladite première liste d'adresses à partir desdites deuxièmes et troisième listes d'adresses. La liste (appelée première liste) utilisée pour l'identification de l'origine de la trame est obtenue en concaténant les informations contenues dans des sous- listes distinctes (appelées deuxièmes et troisième listes). Plus précisément, chaque tête de tunnel du réseau local reçoit des autres têtes de tunnel du réseau local une sous-liste d'adresses de dispositifs sources, ces dispositifs sources étant connectés sur les sous-réseaux distants reliés au sous-réseau local par lesdites autres têtes de tunnel du réseau local. De cette manière, la tête de tunnel courante reçoit les listes des autres têtes de tunnel présentes sur le réseau local. Ainsi, la tête de tunnel courante peut générer la liste (appelée première liste) comprenant les adresses sources des dispositifs sources présents sur les réseaux distants, en combinant les adresses des deuxièmes listes et celles de la troisième liste, la troisième liste étant la liste des adresses des dispositifs connectés au(x) sous-réseau(x) relié(s) au sous-réseau local par l'intermédiaire de tunnels dont la tête de tunnel courante est une extrémité. Avantageusement, lorsque une tête de tunnel reçoit une trame émise par un dispositif source, ladite trame arrivant à ladite tête de tunnel par l'un des tunnels, dit tunnel d'arrivée, ledit tunnel d'arrivée reliant le sous-réseau auquel ladite tête de tunnel appartient au sous-réseau distant auquel le dispositif source appartient, ladite tête de tunnel effectue les étapes suivantes : - obtention, à partir de ladite trame, d'une adresse, dite adresse distante, de dispositif source correspondant audit dispositif source ayant émis ladite trame; -vérification que l'adresse distante est comprise dans une quatrième liste d'adresses comprenant des adresses associées à des dispositifs sources appartenant au sous-réseau distant relié au sous-réseau local par ledit tunnel d'arrivée ; - en cas de vérification négative, mise à jour de la quatrième liste avec ladite adresse distante. et ladite première liste d'adresses est générée à partir de : - la ou les quatrième(s) liste(s) d'adresses gérée(s) par chaque tête de tunnel du sous- réseau local, distincte de la tête de tunnel courante, chaque quatrième liste gérée par une tête de tunnel distincte de ladite tête de tunnel courante étant associée à un tunnel d'arrivée distinct ; et - la ou les quatrième(s) liste(s) d'adresses gérée(s) par la tête de tunnel courante, chaque quatrième liste gérée par ladite tête de tunnel courante étant associée à un tunnel d'arrivée distinct. Ainsi, une tête de tunnel détermine les adresses des dispositifs sources connectés sur le ou les sous-réseau(x) distant(s) relié(s) au sous-réseau local par un(des) tunnel(s) dont ladite tête de tunnel est une extrémité, en analysant les trames en provenance de ce(s) sous-réseau(x) distant(s).
Selon une caractéristique avantageuse, une tête de tunnel envoie, à chaque autre tête de tunnel du sous-réseau auquel ladite tête de tunnel appartient, une information représentative d'une présence d'un nouveau dispositif source dans un sous-réseau distant relié au sous-réseau local par ladite tête de tunnel. Ainsi, quand une trame arrive d'un tunnel sur le sous-réseau local, la tête de tunnel extrémité de ce tunnel sur le sous-réseau local, informe les autres têtes de tunnel du sous-réseau local de la détection d'un nouveau dispositif source inconnu jusqu'alors. Les autres têtes de tunnel peuvent ainsi mettre à jour la liste des dispositifs sources des sous-réseaux distants (première liste), et ainsi empêcher que cette trame ne soit renvoyée vers un autre tunnel, ce qui formerait alors une boucle dans le réseau global.
Avantageusement, lorsque une tête de tunnel reçoit une trame en provenance d'un tunnel, dit tunnel d'arrivée, dont ladite tête de tunnel est une extrémité, ladite tête de tunnel enclenche un mécanisme de retard de transmission de ladite trame sur ledit sous-réseau local, tant que chaque autre tête de tunnel du sous-réseau auquel ladite tête de tunnel appartient n'est pas informée que le dispositif source appartient au sous-réseau distant relié au sous-réseau local par ledit tunnel d'arrivée.
Ainsi, la tête de tunnel extrémité du tunnel en provenance duquel la trame considérée est parvenue sur le sous-réseau local, assure que les autres têtes de tunnel peuvent ainsi mettre à jour la liste des dispositifs sources des sous-réseaux distants (première liste) avant de mettre cette trame à disposition sur le réseau.
Dans un autre mode de réalisation, l'invention concerne un produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, ledit produit programme d'ordinateur comprend des instructions de code de programme pour la mise en oeuvre du procédé dans au moins des modes de réalisation précités, lorsque ledit programme est exécuté sur un ordinateur. Dans un autre mode de réalisation, l'invention concerne un moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé dans au moins des modes de réalisation précités.
Dans un autre mode de réalisation, l'invention concerne une tête de tunnel destinée à mettre en oeuvre un procédé de gestion de trames dans un réseau global de communication comprenant une pluralité de sous-réseaux reliés entre eux par des tunnels aux extrémités desquels se trouvent des têtes de tunnel, au moins un des sous-réseaux comprenant au moins un dispositif source relié à une desdites têtes de tunnel via ledit sous-réseau, chaque dispositif source étant associé à une adresse. Ladite tête de tunnel comprend des moyens de réception, en provenance du sous-réseau auquel ladite tête de tunnel appartient, dit sous-réseau local, d'une trame courante émise par un dispositif source courant dans le réseau global. La tête de tunnel comprend : - des moyens d'obtention, à partir de ladite trame courante, d'une adresse, dite adresse courante, de dispositif source correspondant au dispositif source courant ; - des moyens de vérification que l'adresse courante est comprise dans une première liste d'adresses comprenant des adresses associées à des dispositifs sources appartenant au ou aux sous-réseau(x) distant(s), le(s) sous-réseau(x) distant(s) étant le(s) sous-réseau(x) du réseau global distinct(s) du sous-réseau local ; -des moyens de destruction de ladite trame courante, activés en cas de vérification positive par lesdits moyens de vérification.
De façon avantageuse, la tête de tunnel comprend des moyens d'obtention de ladite première liste d'adresses comprenant eux-mêmes : - des moyens d'obtention, pour chaque tête de tunnel du sous-réseau local distincte de la tête de tunnel courante, et à partir d'informations reçues de ladite tête de tunnel, d'une deuxième liste d'adresses comprenant des adresses associées à des dispositifs sources appartenant au ou aux sous-réseau(x) distant(s) relié(s) audit sous-réseau local par ladite tête de tunnel ; -des moyens de détermination d'une troisième liste d'adresses comprenant des adresses associées à des dispositifs sources appartenant au ou aux sous-réseau(x) distant(s) reliés audit sous-réseau local par ladite tête de tunnel courante ; - des moyens de génération de ladite première liste d'adresses à partir desdites deuxièmes et troisième listes d'adresses. Avantageusement, lesdits moyens de détermination de ladite troisième liste d'adresses comprennent : - des moyens de réception d'une trame émise par un dispositif source, ladite trame arrivant à ladite tête de tunnel par l'un des tunnels, dit tunnel d'arrivée, ledit tunnel d'arrivée reliant le sous-réseau auquel ladite tête de tunnel appartient au sous-réseau distant auquel le dispositif source appartient ; - des moyens d'obtention, à partir de ladite trame, d'une adresse, dite adresse distante, de dispositif source correspondant audit dispositif source ayant émis ladite trame; - des moyens de vérification que l'adresse distante est comprise dans une quatrième liste d'adresses comprenant des adresses associées à des dispositifs sources appartenant au sous-réseau distant relié au sous-réseau local par ledit tunnel d'arrivée ; - des moyens de mise à jour de la quatrième liste avec ladite adresse distante, activés en cas de vérification négative par lesdits moyens de vérification ; - des moyens de génération de ladite troisième liste d'adresses à partir de la ou les quatrième(s) liste(s) d'adresses gérée(s) par ladite tête de tunnel, chaque quatrième liste étant associée à un tunnel d'arrivée distinct.
Selon une caractéristique avantageuse, la tête de tunnel comprend des moyens de transmission, à chaque autre tête de tunnel du sous-réseau auquel ladite tête de tunnel appartient, d'une information représentative d'une présence d'un nouveau dispositif source dans un sous-réseau distant relié au sous-réseau local par ladite tête de tunnel. Avantageusement, la tête de tunnel comprend : - des moyens de réception d'une trame en provenance d'un tunnel, dit tunnel d'arrivée, dont ladite tête de tunnel est une extrémité ; - des moyens d'activation, sur détection d'une trame par lesdits moyens de détection, d'un mécanisme de retard de transmission de ladite trame sur ledit sous-réseau local, tant que chaque autre tête de tunnel du sous-réseau auquel ladite tête de tunnel appartient n'est pas informée que le dispositif source appartient au sous- réseau distant relié au sous-réseau local par ledit tunnel d'arrivée. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de modes de réalisation de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif (tous les modes de réalisation de l'invention ne sont pas limités aux caractéristiques et avantages des modes de réalisation décrits ci-après), et des dessins annexés, dans lesquels : - la figure la illustre une configuration typique de réseau privé virtuel (VPN) mettant en oeuvre un tunnel ; - la figure lb présente un exemple de modèle en couche classique d'une tête de tunnel dans laquelle peut être mis en oeuvre le procédé selon l'invention ; - la figure 2 présente un exemple de configuration dans laquelle s'applique la présente invention ; - la figure 3 présente un organigramme illustrant les étapes du procédé, selon un mode de réalisation particulier de l'invention, exécutées par une tête de tunnel à l'initialisation ; - la figure 4 présente un format, selon un mode de réalisation particulier de l'invention, d'une entrée de la liste des tunnels actifs sur une tête de tunnel ; - la figure 5 présente un organigramme illustrant les étapes du procédé, selon un mode de réalisation particulier de l'invention, exécutées par une tête de tunnel après qu'un nouveau tunnel associé à cette tête de tunnel a été établi avec succès ; 25 30 - la figure 6 présente un algorithme de réception d'une trame provenant d'un tunnel, selon un mode de réalisation particulier du procédé selon l'invention ; -la figure 7 présente un algorithme de réception par une tête de tunnel d'une trame provenant du réseau LAN local auquel la tête de tunnel appartient, selon un mode de réalisation particulier du procédé selon l'invention ; - la figure 8 présente le format des différents messages utilisés dans le cadre de la présente invention ; - la figure 9 présente un schéma d'une tête de tunnel générique apte à mettre en oeuvre le procédé de gestion de trames selon un mode de réalisation particulier de l'invention. 6. DESCRIPTION DÉTAILLÉE Sur toutes les figures du présent document, les éléments et étapes identiques sont désignés par une même référence numérique. La présente invention concerne une technique permettant d'éviter les boucles de 15 chemins de données à travers des tunnels de communication. L'invention propose de bloquer la transmission d'une trame donnée provenant d'un premier tunnel à travers un second tunnel connecté au réseau local LAN sur lequel le premier tunnel transmet la trame donnée. Plus précisément, dans le cas où une pluralité de têtes de tunnel est connectée à un réseau LAN local, l'invention permet à chacune de ces têtes de tunnel de 20 déterminer si une trame, diffusée sur le réseau local LAN, est effectivement originaire du réseau LAN local ou si elle provient d'un réseau LAN distant (c'est-à-dire si la trame est arrivée via un autre tunnel que celui sur lequel elle est sur le point d'être transmise), et ainsi de déterminer si la trame doit être transmise à un autre réseau LAN par l'intermédiaire d'un tunnel. 25 Le principe général de l'invention consiste donc à ce qu'une tête de tunnel gère une liste d'adresses MAC Ethernet d'équipements connectés au réseau LAN distant (celui qui si trouve connecté à l'autre bout du tunnel). Cette liste est transmise à toutes les têtes de tunnel du réseau LAN local. Ainsi, chaque tête de tunnel du réseau LAN local peut, avant de transmettre une trame sur un tunnel qui lui est attaché, vérifier si 30 l'adresse source de cette trame est comprise dans la liste d'adresses MAC Ethernet d'équipements précitée. En cas de vérification positive, cela signifie que la trame a 10 atteint le réseau LAN local par le biais d'un autre tunnel (en d'autres termes, la trame provient d'un réseau LAN distant), on empêche la transmission de cette trame par le biais des tunnels associés à la tête de tunnel considérée. La figure la illustre une configuration typique de réseau privé virtuel (VPN) mettant en oeuvre un tunnel 100 entre une tête de tunnel 101 et une tête de tunnel 102, à travers un réseau de communication 107 (Internet par exemple). Ce tunnel 100 interconnecte deux réseaux locaux LAN A 103 et LAN B 104. Chacun des réseaux locaux LAN 103 et 104 comporte un équipement d'accès Internet haut débit (passerelle domestique, ou Home Gateway , pouvant intégrer un pare-feu ( Firewall ) 105 et 106, des équipements de type PC 109 et 111, des serveurs 110 et 113 permettant le stockage et le partage de medias numériques (de type audio, vidéo, photo), ainsi que des équipements de restitution des médias numériques 108 et 112. Une tête de tunnel peut être intégrée dans un équipement audiovisuel comme un téléviseur numérique. Elle peut aussi être présente dans un équipement de type PC sous la forme d'un programme réalisant les fonctions associées à celle-ci. Une fois que le tunnel 100 est établi, les équipements 108, 109, et 110, connectés au réseau LAN A 103, sont capables de communiquer avec les équipements 111, 112 et 113, connectés au réseau LAN B 104. Par exemple, le client 108 connecté au réseau LAN A 103 peut communiquer avec le serveur 113 connecté au réseau LAN B 104.
Dans cette figure la, on a représenté un réseau de communication simple avec un seul tunnel, mais il est bien entendu qu'une même tête de tunnel peut être amenée à gérer plusieurs tunnels (à destination d'autant de têtes de tunnel) pour interconnecter un premier réseau LAN à plusieurs autres réseaux LAN, et qu'un même réseau LAN peut comprendre plusieurs têtes de tunnel. En outre, dans un souci de simplification, n'ont pas été représentés les équipements d'infrastructure dans le réseau Internet tels que les routeurs Internet. En relation avec la figure lb, nous allons maintenant décrire le cheminement d'une trame Ethernet issue d'un des équipements 108, 109, 110 (connectés au réseau LAN B 103) et qui va entrer dans le tunnel 100. Pour ce faire, on va utiliser un modèle en couches décrivant les couches de protocoles nécessaires à la mise en oeuvre de ce tunnel 100. Dans ce modèle ne sont pas représentés les éléments de protocole nécessaires aux fonctions autres que la mise en oeuvre du tunnel. Par exemple, ne sont pas représentés les éléments de protocole associés à une architecture UPnP lorsqu'une tête de tunnel 101 est intégrée dans un équipement conforme à la norme UPnP. La tête de tunnel 101 comporte une interface physique Ethernet 122 qui remet les trames Ethernet issues des équipements 108, 109, 110 à la couche liaison 121 pour routage : vers la couche réseau 120, pour les trames Ethernet à destination de l'équipement comportant la tête de tunnel, ou vers la couche de pont ( bridge ) 123, pour les autres trames Ethernet. La couche de pont 123 réalise les opérations classiques d'un pont Ethernet telles que le filtrage des trames Ethernet et le relais de ces trames vers le ou les port(s) Ethernet de sortie approprié(s). Le filtrage des trames Ethernet est classiquement réalisé par une couche de pont ( bridge ) en vérifiant la présence de l'adresse de destination d'une trame (mono-destinataire) dans une liste. En effet, à chacune des interfaces du pont est associée une liste contenant les adresses MAC des noeuds joignables par cette interface. On entend par noeuds joignables par une interface de pont donnée, les noeuds qui sont connectés sur le même LAN que l'interface de pont donnée ou sur un LAN connecté au LAN local par l'intermédiaire d'au moins un pont, autre que le pont de l'interface donnée. Ces listes sont obtenues par analyse des paquets provenant du LAN auquel l'interface est connectée. Les adresses sources des paquets déposés sur le LAN, autres que ceux déposés par l'interface donnée, sont récupérées pour former cette liste. Il est à noter que la liste ainsi formée pour une interface de pont donnée ne permet pas de distinguer les adresses des noeuds connectés au même LAN que l'interface donnée de celles des noeuds connectés à un autre LAN séparé par un autre pont. Ainsi, l'adresse de destination d'une trame entrant par l'une des interfaces d'un pont est comparée au contenu des listes associées aux autres interfaces de ce même pont. Si l'adresse de destination d'une trame est présente dans l'une de ces listes, la trame est envoyée vers son destinataire par le biais de l'interface correspondante (uniquement). Sinon, la trame est envoyée vers toutes les interfaces du pont. Sur le pont sont attachées une interface Ethernet 121 et au moins une interface virtuelle 124 ayant le comportement d'un contrôleur Ethernet. Une interface virtuelle 30 124 est créée pour chaque tunnel instancié par l'application 114 à qui elle remet les trames Ethernet qui doivent transiter sur les tunnels respectivement instanciés. D'une manière générale, le protocole d'encapsulation du tunnel représenté par l'application 114 réalise les opérations nécessaires à la mise en oeuvre de chaque tunnel, parmi lesquelles on trouvera notamment la configuration, le filtrage et l'encapsulation (formation d'un paquet tunnel) et l'extraction d'une trame. Comme on le verra par la suite, le procédé selon l'invention est mis en oeuvre par l'application 114. Les trames reçues de l'interface virtuelle 124, après traitement par l'application 114, sont remises sous la forme d'un paquet (ou trame) de données à travers une interface applicative ( socket en anglais) 115 à un protocole de transport fiable TCP 117 ou non fiable UDP 119, respectivement sécurisés par les protocoles SSL 116 et DTLS 118. Après traitement par un protocole de transport pour former le paquet (ou trame) tunnel, on passe celui-ci à la couche réseau 120. Le datagramme IP ainsi formé avec le paquet (ou trame) tunnel peut maintenant être transmis sur le réseau LAN à travers les couches liaison 121 et physique 122. La réception d'une trame en provenance du tunnel 100 suivra dans la tête de tunnel le cheminement inverse à celui présenté ci-dessus. En relation avec la figure 2, on présente un exemple de configuration dans laquelle s'applique la présente invention.
Comme illustré, un réseau LAN local 200, noté LAN A , comprend deux têtes de tunnel 201 et 202 et deux équipements 209 et 210. La première tête de tunnel 201 du réseau LAN A, noté TEP A , gère un premier tunnel 203 vers un premier réseau LAN distant 211, noté LAN B . La deuxième tête de tunnel 202 du réseau LAN A, noté TEP B , gère un deuxième tunnel 204 vers un deuxième réseau LAN distant 212, noté LAN C . Les réseaux LAN B et LAN C sont connectés entre eux par le biais d'un troisième tunnel 213. Les premier 203, deuxième 204 et troisième tunnels 213 forment un maillage complet et sont susceptibles de créer une boucle de chemins de données entre les réseaux LAN A, LAN B et LAN C. Dans cet exemple, le procédé selon l'invention est mis en oeuvre sur le réseau LAN A, de façon à supprimer cette boucle de chemins de données. Il pourrait bien sûr être mis en oeuvre de manière similaire sur le réseau LAN B et/ou le réseau LAN C.
De manière classique, chaque tête de tunnel (201 et 202) du réseau LAN A comprend une interface virtuelle (205 et 207) lui permettant de gérer le tunnel qui lui est associé, et une interface physique (206 et 208) lui permettant de gérer sa connexion au réseau LAN A. Chaque tête de tunnel implémente une fonctionnalité de pont ( bridge ) Ethernet, de façon à permettre la mise en communication de l'interface virtuelle 205 et de l'interface physique 206, et de l'interface virtuelle 207 et de l'interface physique 208. A chaque interface virtuelle est associé un identifiant (unique au sein d'une même tête de tunnel), noté VI id , utilisé dans la suite de cette description pour identifier un tunnel et ses ressources associées au sein d'une tête de tunnel. On présente désormais, en relation avec la figure 3, un organigramme illustrant les étapes du procédé, selon un mode de réalisation particulier de l'invention, exécutées par une tête de tunnel (par exemple celle référencée TEP A sur la figure 2) à l'initialisation.
Dans l'étape 300, on initialise la tête de tunnel TEP A. Selon l'invention, la tête de tunnel TEP A doit se faire connaître auprès des autres têtes de tunnel (par exemple, la tête de tunnel référencée TEP B sur la figure 2) potentiellement présentes sur le réseau LAN local (LAN A), et recenser de façon exhaustive ces autres têtes de tunnel. Pour ce faire, chaque tête de tunnel implémente les protocoles Multicast Domain Name Server (ou mDNS ) et DNS-based service discovery (ou DNS-SD ), tels que décrits dans le cadre du protocole de configuration d'appareils réseaux Zeroconf . Les protocoles précités sont bien connus de l'Homme du Métier et donc pas décrits en détail. Les différentes têtes de tunnel vont se reconnaître par le biais de ces protocoles en publiant chacune une entité du service tep.tcp.local. . Cette entité doit avoir un nom unique. Ainsi, par exemple, ce nom est obtenu par la concaténation du champ TEP- et de l'adresse MAC de la tête de tunnel concernée. Par exemple, l'entité du service tep.tcp.local. présent sur la tête de tunnel et qui a pour adresse MAC l'adresse 5E.FF.56.A2.AF.15 aura pour nom TEP-5EFF56A2AF15 . On note qu'une étape de vérification d'unicité (ou probing en anglais) du protocole mDNS n'est pas nécessaire, du fait que l'unicité de l'adresse MAC garantit l'unicité du nom de l'entité.
Il est important de noter que les étapes 301 à 305 décrites ci-après sont exécutées par la tête de tunnel TEP A, et les étapes 306 à 309 par les autres têtes de tunnel présentes sur le réseau LAN A, par exemple la tête de tunnel TEP B. Dans l'étape 301, on génère une déclaration de service mDNS (ou announcing en anglais). Cette déclaration est ensuite transmise, sous la forme d'un message multi-destinataire (ou multicast en anglais), vers les autres têtes de tunnel présentes sur le réseau LAN A, par exemple la tête de tunnel TEP B. Ce message multidestinataire comporte une adresse destination de groupe ( multicast address en anglais). Chaque noeud d'un réseau intéressé par ce type de message est sensible à cette adresse. Afin d'assurer que seules les têtes de tunnel présentent sur le LAN A reçoivent cette déclaration (ainsi que la requête générée à l'étape 302), les trames contenant une telle adresse de destination de groupe seront filtrées à l'entrée des tunnels (tel que ci-après décrit en relation avec l'étape 704 de la figure 7). Dans l'étape 302, on génère une requête mDNS (ou mDNS query en anglais) pour le service tep.tcp.local. . Cette requête est ensuite transmise, sous la forme d'un message multi-destinataire, vers les autres têtes de tunnel présentes sur le réseau LAN A, par exemple la tête de tunnel TEP B. Dans l'étape 308, chacune des autres têtes de tunnel présentes sur le réseau LAN A, par exemple la tête de tunnel TEP B, reçoit la requête mDNS générée à l'étape 302.
Dans l'étape 309, on génère une réponse mDNS comprenant le nom de son entité de service tep.tcp.local. . Dans le présent exemple, le nom est TEP-5EFF56A2AF15 . Cette réponse est ensuite envoyée à la tête de tunnel TEP A. Puis, on continue à l'étape 303. Dans l'étape 303, on reçoit une réponse mDNS provenant de chacune des autres têtes de tunnel présentes sur le réseau LAN A, par exemple la tête de tunnel TEP B. Chaque réponse comprend le nom de son entité de service tep.tcp.local. . La tête de tunnel TEP A possède donc une liste des noms des entités de service tep.tcp.local. présentes sur le réseau LAN A. Ainsi, la tête de tunnel TEP A peut extraire de cette liste les adresses MAC des autres têtes de tunnel (ces adresses MAC étant contenues dans le nom des entités).
Dans l'étape 304, on génère une liste L1 (appelée liste des têtes de tunnel locales) comprenant les adresses MAC de toutes les têtes de tunnel (TEP A, TEP B, etc.) présentes sur le réseau LAN A, à partir des adresses MAC extraites à l'étape 303. Dans l'étape 305, on génère une liste L2 (appelée liste des tunnels actifs sur la tête de tunnel) comprenant une entrée par tunnel actif sur la tête de tunnel TEP A. Cette liste L2 est vide pour le moment. Dans l'étape 306, chacune des autres têtes de tunnel présentes sur le réseau LAN A, par exemple la tête de tunnel TEP B, reçoit la déclaration de service mDNS générée à l'étape 301.
Dans l'étape 307, on met à jour la liste L1 générée à l'étape 304. La figure 4 présente un format, selon un mode de réalisation particulier de l'invention, d'une entrée 400 de la liste des tunnels actifs sur la tête de tunnel (liste L2 générée à l'étape 305) qui comporte : un champ d'identification 401 comprenant l'identifiant VI id du tunnel associé à l'entrée 400, dit tunnel courant ; un champ 402 comprenant un pointeur qui pointe vers une liste L3 404 comprenant elle-même des adresses MAC d'équipements connectés à un réseau LAN distant, ce dernier étant connecté au tunnel courant. La liste L3 peut, dans un autre mode de réalisation, contenir des pointeurs sur d'autres listes, permettant de gérer différentes catégories d'adresses ou d'équipements. A titre d'exemple, en référence au schéma de la figure 2, pour la tête de tunnel TEP B, la liste L3 associée au tunnel 204 (tunnel courant) comprend les adresses MAC des équipements connectés au réseau LAN C 212 ; un champ 403 comprenant un pointeur qui pointe vers une liste L4 405 comprenant elle-même des adresses MAC d'équipements connectés à d'autres réseaux LAN distants, ces derniers étant connectés aux autres tunnels (distincts du tunnel courant) du réseau de communication. La liste L4 peut, dans un autre mode de réalisation, contenir des pointeurs sur d'autres listes, permettant de gérer différentes catégories d'adresses ou d'équipements. A titre d'exemple, en référence au schéma de la figure 2, pour la tête de tunnel TEP B, la liste L4 20 25 30 comprend les adresses MAC des équipements connectés au réseau LAN B 211. Plus précisément, la liste L4 comporte deux champs : o un premier champ 407 comprenant une adresse MAC d'un équipement connecté à un réseau LAN distant (distinct de celui connecté au tunnel courant) ; o un deuxième champ 406 comprenant un identifiant, noté T_id , permettant d'identifier le tunnel à travers lequel l'appareil associé à l'adresse MAC contenue dans le champ 407 est accessible. Dans un mode de réalisation particulier, l'identifiant T_id est obtenu par la concaténation d'un identifiant TEP_id et de l'identifiant VI_id représentatif de l'interface virtuelle correspondant à ce tunnel dans la tête de tunnel qui lui est associée sur le réseau local LAN. L'identifiant TEP id est un identifiant de la tête de tunnel, comme par exemple, son adresse MAC. La combinaison des identifiants TEP_id et VI_id permet l'identification sans ambiguïté un tunnel connecté à un réseau local LAN. On présente désormais, en relation avec la figure 5, un organigramme illustrant les étapes du procédé, selon un mode de réalisation particulier de l'invention, exécutées par une tête de tunnel courante (par exemple celle référencée TEP A sur la figure 2) après qu'un nouveau tunnel a été établi avec succès.
Dans l'étape 501, on génère la liste L3 associée au nouveau tunnel, et crée une nouvelle entrée dans la liste L2. Plus précisément, on initialise le champ MAC 402 de cette nouvelle entrée avec un pointeur qui pointe vers la liste L3 générée et associée au nouveau tunnel. Dans l'étape 502, on génère la liste L4 associée au nouveau tunnel, et initialise le champ MAC 403 de la nouvelle entrée de la liste L2 (créée à l'étape 501) avec un pointeur qui pointe vers la liste L4 générée et associée au nouveau tunnel. Dans l'étape 503, on parcoure la liste L2, et pour chaque entrée de la liste L2 (autre que celle associée au nouveau tunnel), on met à jour la liste L4 associée au nouveau tunnel à partir des informations contenues dans les listes L3 associées aux autres tunnels du réseau LAN local (LAN A). A titre d'exemple, en référence au schéma de la figure 2, étant donné que la liste L2 de la tête de tunnel TEP B ne comporte qu'une entrée correspondant au tunnel 204, aucune nouvelle entrée n'est ajoutée à la liste L4. Dans l'étape 504, on parcoure la liste L1 des têtes de tunnel présentes sur le réseau LAN local (LAN A). Pour chaque entrée de la liste L1, on envoie à la tête de tunnel correspondante, dite tête de tunnel de réception, un message de déclaration de nouveau tunnel. Dans l'étape 508, la tête de tunnel de réception reçoit le message de déclaration de nouveau tunnel. Dans l'étape 509, la tête de tunnel de réception génère une liste temporaire LTemp qui, une fois remplie, contiendra l'ensemble des adresses MAC des équipements connectés aux réseaux LAN distants, accessibles par les tunnels partant de cette même tête de tunnel. Dans l'étape 510, on parcoure la liste L2, et pour chaque entrée de la liste L2, on ajoute dans la liste temporaire LTemp le contenu de la liste L3 correspondante. Le format des entrées de la liste temporaire LTemp est le même que celui des entrées de la liste L4 (précédemment décrit avec la figure 4). Ainsi, chaque entrée de la liste temporaire LTemp comporte des premier et deuxième champs. Le premier champ étant constitué de l'identifiant du tunnel concerné (déterminé grâce à un pointeur sur les listes L1 et L2 permettant d'obtenir l'information T_id qui est la concaténation de l'identifiant de tête de tunnel TEP id et de l'identifiant d'interface virtuelle de tête de tunnel VI id). Le second champ contient les adresses MAC des dispositifs présents dans les listes L3 parcourues. Dans l'étape 511, on génère un message de réponse à partir de la liste temporaire LTemp (remplie à l'étape 510).
Dans l'étape 512, on envoie le message de réponse (généré à l'étape 511) à la tête de tunnel courante. Puis, on continue à l'étape 505. Dans l'étape 505, on reçoit le message de réponse provenant de la tête de tunnel de réception. Dans l'étape 506, on complète la liste L4 avec les adresses MAC contenues dans le message de réponse (reçu à l'étape 505). A titre d'exemple, en référence au schéma de la figure 2, la liste L4 du tunnel 204 sera complétée avec les adresses MAC contenues dans la liste L3 du tunnel 203. On présente maintenant, en relation avec la figure 6, un algorithme de réception d'une trame provenant d'un tunnel, selon un mode de réalisation particulier du procédé selon l'invention. Lorsqu'une trame arrive à une tête de tunnel (appelée ci-après tête de tunnel courante) depuis un tunnel, on vérifie si son adresse source est connue, c'est-à-dire présente dans la liste L3 associée à ce tunnel dans la tête de tunnel courante, de sorte qu'en cas de vérification négative on met à jour la liste L3 concernée d'adresses MAC ainsi que des autres têtes de tunnel présentes sur le réseau LAN local. Dans l'étape 600, on reçoit la trame provenant du tunnel, puis on analyse son adresse source. Dans un premier mode de réalisation, la trame reçue du tunnel est temporairement bloquée par la tête de tunnel courante, de façon à mettre à jour toutes les listes d'adresses MAC des autres têtes de tunnel présentes sur le réseau LAN local avant que la trame ne les atteigne. Ce blocage peut avoir une durée égale à une temporisation prédéfinie, estimée de manière à laisser une marge temporelle suffisante aux autres têtes de tunnel présentes sur le réseau LAN local afin d'effectuer les mises à jour nécessaires de leurs listes d'adresses. Dans un second mode de réalisation, tel que décrit ci-après à l'étape 605, ce blocage dure le temps de recevoir un acquittement de mise à jour des listes L4, en provenance de chacune des autres têtes de tunnel du réseau LAN local. Dans un troisième mode de réalisation, la tête de tunnel courante envoie d'abord un message de mise à jour des listes L4 (tel que décrit ci-après) et ensuite la trame ayant déclenchée cette mise à jour des listes L4. Il est alors de la responsabilité des têtes de tunnel autres que la tête de tunnel courante d'effectuer la mise à jour des listes L4 avant le traitement de la trame en question. Cela peut-être fait en bloquant la trame (pour laquelle le dispositif identifié par l'adresse source contenue dans la trame n'a pas été trouvé dans une des listes L4 internes) pendant un délai prédéterminé, estimé de manière à laisser une marge temporelle suffisante à la tête de tunnel courante de transmettre (ou retransmettre) la mise à jour des listes L4.
Dans l'étape 601, on vérifie si l'adresse source de la trame reçue est comprise dans la liste L3 associée au tunnel d'arrivée de la trame. En cas de vérification négative, on passe à l'étape 602, sinon on passe à l'étape 606. Comme indiqué précédemment, la liste L3 comprend les adresses MAC des équipements connectés au réseau LAN distant, accessible via le tunnel d'arrivée de la trame. On note que pour retrouver la liste L3, on utilise le pointeur du champ de première adresse MAC 402 de l'entrée de la liste L2 associée au tunnel d'arrivée de la trame (qui est repéré par l'identifiant VI_id de l'interface virtuelle correspondante à ce tunnel d'arrivée, l'identifiant VI_id permettant ainsi de sélectionner la bonne entrée dans la liste L2).
Dans l'étape 602, on met à jour la liste L3 avec l'adresse MAC contenue dans le champ représentatif de l'adresse source de la trame reçue. En d'autres termes, on ajoute l'adresse source de la trame dans la liste L3. Dans l'étape 603, on parcoure la liste L2, et pour chaque entrée de la liste L2 (autre que celle associée au tunnel d'arrivée de la trame), on met à jour la liste L4 associée au tunnel d'arrivée de la trame, comme suit : - le champ 406 est initialisé avec l'identifiant T_id du tunnel d'arrivée de la trame, composé de l'identifiant TEP id de la tête de tunnel courante et de l'identifiant VI id du tunnel d'arrivée de la trame ; - le champ 407 est initialisé avec l'adresse source de la trame reçue, c'est-à-dire l'adresse MAC du dispositif ayant émis la trame. Dans l'étape 604, on parcoure la liste L1 des têtes de tunnel présentes sur le réseau LAN local. Pour chaque entrée de la liste L1, on envoie à chacune des autres têtes de tunnel présentes sur le réseau LAN local un message de mise à jour des listes L4 , comprenant l'adresse MAC du nouveau dispositif détecté et l'identifiant T_id du tunnel par lequel ce dispositif est accessible à partir du réseau local LAN de la tête de tunnel courante. Dans l'étape 608, chacune des autres têtes de tunnel présentes sur le réseau LAN local reçoit le message de mise à jour des listes L4 (envoyé à l'étape 604 par la tête de tunnel courante).
Dans l'étape 609, chacune des autres têtes de tunnel parcoure la liste L2 qui lui est associée. Pour chaque entrée de la liste L2, on ajoute dans la liste L4 (associée à la tête de tunnel donnée) l'adresse MAC et l'identifiant T_id contenus dans le message de mise à jour (reçu à l'étape 608). Dans l'étape 610, chacune des autres têtes de tunnel envoie un message de réponse (acquittement de transaction) à la tête de tunnel courante. Puis, on continue à l'étape 605. On notera que le message de réponse doit être envoyé seulement après la mise à jour de toutes les listes L4, la mise à jour de ces listes devant préférentiellement être effectuée avant que la trame reçue ne soit émise sur le réseau LAN local par la tête de tunnel courante. Dans l'étape 605, la tête de tunnel courante reçoit un message de réponse de la part de chacune des autres têtes de tunnel. Dans l'étape 606, la trame reçue, qui a été temporairement bloquée (étape 600), est débloquée. La trame débloquée est ensuite aiguillée, par la fonctionnalité de pont ( bridge ) de la tête de tunnel courante vers le réseau LAN local mais pas vers un autre tunnel relié à la tête de tunnel courante.
On note que dans un second mode de réalisation, il est possible d'envisager de parcourir la liste L4 (listant les adresses sources MAC des équipements situés sur d'autres réseaux LAN accessibles par le biais des autres tunnels) avant de débloquer la trame reçue, de façon à vérifier que l'adresse de destination de la trame ne s'y trouve pas. En cas de vérification négative (c'est-à-dire si l'adresse de destination se trouve dans la liste L4), on peut en déduire que la trame reçue est à destination d'un autre réseau LAN distant et peut donc être détruite. On présente maintenant, en relation avec la figure 7, un algorithme de réception d'une trame diffusée sur le réseau LAN local, selon un mode de réalisation particulier du procédé selon l'invention. Les étapes décrites ci-après sont mises en oeuvre par une tête de tunnel. Dans l'étape 700, on reçoit une trame diffusée sur le réseau LAN local et qui est potentiellement à destination d'un tunnel (appelé tunnel de destination). Dans l'étape 701, on récupère l'adresse source de la trame reçue. Dans l'étape 702, on compare l'adresse source de la trame reçue avec les entrées de la liste L4 associée au tunnel de destination. On note que pour retrouver la liste L4, on utilise le pointeur du champ de deuxième adresse MAC 403 de l'entrée de la liste L2 associée au tunnel de destination (qui est repéré par l'identifiant VI id de l'interface virtuelle du bridge qui a reçu la trame). Dans l'étape 703, on vérifie si l'adresse source de la trame reçue est comprise dans la liste L4 associée au tunnel de destination. En cas de vérification négative, on passe à l'étape 704, sinon on passe à l'étape 705. On rappelle que si la trame reçue est comprise dans la liste L4 (cas de la vérification positive), cela signifie que l'équipement qui a envoyé la trame ne se trouve pas sur le réseau LAN local, mais sur un réseau LAN situé à l'autre extrémité de l'un des tunnels partant du réseau LAN local. En d'autres termes, la trame est arrivée sur le réseau LAN local par le biais d'un autre tunnel.
Dans l'étape 704, on vérifie si la trame contient une déclaration mDNS de service tep.tcp.local. , une requête mDNS de service tep. tcp.local. , OU une réponse à ce type de requête (trame multi-destinataire pour la déclaration et la requête, mono-destinataire pour la réponse, dont les champs sont formatés suivant les spécifications mDNS). En cas de vérification négative, on passe à l'étape 706, sinon on passe à l'étape 705. Les réquêtes mDNS de service tep.tcp.local. sont filtrées à l'entrée du tunnel, car, comme précédemment décrit, elles permettent aux têtes de tunnel d'un même LAN de se faire connaître les uns des autres comme appartenant au même LAN. Elles ne doivent donc pas passer d'un LAN à l'autre par le biais des tunnels. Dans l'étape 706, on autorise la transmission de la trame à travers le tunnel de destination. Dans l'étape 705, on empêche la transmission de la trame à travers le tunnel de destination, et on détruit cette trame. De manière générale, les têtes de tunnel connectées à un même réseau LAN local communiquent entre elles au moyen du protocole TCP/IP.
La figure 8 présente les formats des différents messages utilisés dans le cadre de la présente invention. Les messages Ml de déclarations (décrits en relation avec la figure 5) et les messages M4 de réponse à une mise à jour de la liste L4 (décrits en relation avec la figure 6) comprennent : -une entête Ethernet 700 ; - une entête IP 701 ; - une entête TCP 702 ; et - un champ type de message 703. Comme on le verra par la suite, ce champ est présent dans tous les messages Ml, M2, M3 et M4. Le champ type de message 703 permet d'identifier le type de message et prend une valeur différente suivant le type de message identifié. Les messages M2 de réponse à un message de déclaration (décrits en relation avec la figure 5) comprennent : - une entête Ethernet 700 ; - une entête IP 701 ; - une entête TCP 702 ; - un champ type de message 703 (décrit ci-dessus) ; -un champ nombre d'éléments 704. Ce champ comprend le nombre d'éléments présents dans la liste contenue dans un champ liste 705 (décrit ci-après) ; et - le champ liste 705. Ce champ comprend une liste d'éléments utilisant le même format que les éléments de la liste L4. La construction et le contenu de cette liste sont décrits en relation avec la figure 5. Les messages M3 de mise à jour de la liste L4 (décrits en relation avec la figure 6) comprennent : - une entête Ethernet 700 ; - une entête IP 701 ; - une entête TCP 702 ; - un champ type de message 703 (décrit ci-dessus) ; - un champ T_ID 706 ; et - un champ adresse MAC 707. Le contenu et l'utilisation de chacun des champs 706 et 707 sont décrits en relation avec la figure 6 et correspondent au même format que les éléments de la liste L4. On pourra noter que, dans une variante du mode de mise en oeuvre particulier de l'invention, un message M3 de mise à jour de la liste L4 (décrits en relation avec la figure 6) peut comprendre plusieurs éléments utilisant le même format que les éléments de la liste L4. C'est par exemple le cas lorsque plusieurs messages, ayant pour origine de multiples dispositifs émetteurs non encore répertoriés, parviennent par un tunnel à un réseau LAN par une tête de tunnel, et que cette tête de tunnel regroupe les déclarations de ces nouveaux dispositifs à répertorier dans un seul message M3. Dans ce cas, le message de type M3 a un format équivalent au message de type M2, le champ type de message 703 permettant de dissocier l'un de l'autre. On présente, en relation avec la figure 9, un schéma d'une tête de tunnel générique 900 apte à mettre en oeuvre le procédé de gestion de trames selon un mode de réalisation particulier de l'invention.
Par exemple les têtes de tunnel 101 et 102 (cf. figure la) sont identiques à la tête de tunnel générique 900. Cette tête de tunnel générique 900 peut notamment être reliée à tout moyen de stockage d'image, de vidéos ou de sons délivrant à la tête de tunnel générique 900 des données multimédia.
Ainsi, la tête de tunnel générique 900 comporte un bus de communication 902 auquel sont reliés : - une unité centrale de traitement 903 (qui est par exemple un microprocesseur référencé CPU) ; - une mémoire morte 904 référencée ROM, pouvant comporter le ou les logiciel(s) précité(s) et référencé(s) Prog ; - une mémoire vive 906 (mémoire cache référencée RAM), comportant des registres adaptés à enregistrer des variables et paramètres créés et modifiés au cours de l'exécution du ou des logiciel(s) précité(s) ; - un écran 908 permettant de visualiser des données et/ou de servir d'interface graphique avec l'administrateur réseau qui pourra interagir avec le ou les logiciel(s) selon l'invention, à l'aide d'un clavier 910 ou de tout autre moyen tel qu'un dispositif de pointage, comme par exemple une souris 911 ou un crayon optique ; - une interface de communication 918 reliée à un réseau de communication distribué 920, par exemple le réseau LAN 103, l'interface étant apte à transmettre et à recevoir des données. 25 30 La tête de tunnel générique 900 comprend également (mais ceci est optionnel) : - un disque dur 912 pouvant comporter le ou les logiciel(s) précité(s) et référencé(s) Prog ; - un lecteur de périphérique externe 914 adapté à recevoir une clé mémoire USB 916 et à y lire ou à y écrire des données traitées ou à traiter conformément au procédé de réservation de ressource selon le mode de réalisation particulier de l'invention. Bien entendu, au lieu de la clé mémoire USB 916, on peut mettre en oeuvre tout support d'information lisible par un ordinateur ou par un microprocesseur, intégré ou non à l'appareil, éventuellement amovible, et adapté à mémoriser le ou les logiciel(s) selon le mode de réalisation particulier de l'invention (par exemple, un disque compact (CD-ROM) ou une carte mémoire (Memory-Stick, CompactFlash, ...)). Le bus de communication 902 permet la communication et l'interopérabilité entre les différents dispositifs inclus dans la tête de tunnel générique 900 ou reliés à cet équipement. De manière plus générale, grâce au bus de communication 902, l'unité centrale 903 est susceptible de communiquer des instructions à tout dispositif inclus dans la tête de tunnel générique 900 directement ou par l'intermédiaire d'un autre dispositif de la tête de tunnel générique 900. Le code exécutable de chacun du ou des logiciel(s) précités permettant à la tête de tunnel générique 900 de mettre en oeuvre le procédé de gestion de trames selon l'invention, peut être stocké, par exemple, dans le disque dur 912 ou dans la mémoire morte 904.
L'unité centrale 903 commande et dirige l'exécution des instructions ou portions de code logiciel du ou des logiciel(s) selon l'invention. Lors de la mise sous tension, le ou les logiciels qui sont stockés dans une mémoire non volatile (par exemple le disque dur 912 ou la mémoire morte 904), sont transférés dans la mémoire vive 906 qui contiendra alors le code exécutable du ou des logiciel(s) selon l'invention, ainsi que des registres pour mémoriser les variables et paramètres nécessaires à la mise en oeuvre du procédé de détermination selon l'invention.
Il convient de noter que l'équipement comprenant la tête de tunnel selon l'invention peut également être un équipement programmé. Cet équipement contient alors le code du ou des programmes informatiques par exemple figé dans un circuit intégré à application spécifique (ASIC).

Claims (12)

REVENDICATIONS
1. Procédé de gestion de trames dans un réseau global de communication comprenant une pluralité de sous-réseaux reliés entre eux par des tunnels aux extrémités desquels se trouvent des têtes de tunnel, au moins un des sous-réseaux comprenant au moins un dispositif source relié à une desdites têtes de tunnel via ledit sous-réseau, chaque dispositif source étant associé à une adresse, caractérisé en ce que, lorsque une tête de tunnel courante reçoit, en provenance du sous-réseau auquel ladite tête de tunnel courante appartient, dit sous-réseau local, une trame courante émise par un dispositif source courant dans le réseau global, la tête de tunnel courante effectue les étapes suivantes : - obtention (700), à partir de ladite trame courante, d'une adresse, dite adresse courante, de dispositif source correspondant au dispositif source courant ; - vérification (703) que l'adresse courante est comprise dans une première liste d'adresses comprenant des adresses associées à des dispositifs sources appartenant au ou aux sous-réseau(x) distant(s), le(s) sous-réseau(x) distant(s) étant le(s) sous- réseau(x) du réseau global distinct(s) du sous-réseau local ; - en cas de vérification positive, destruction (705) de ladite trame courante.
2. Procédé selon la revendication 1, caractérisé en ce que la tête de tunnel courante obtient la première liste d'adresses en effectuant les étapes suivantes : - pour chaque tête de tunnel du sous-réseau local, distincte de la tête de tunnel courante, obtention, à partir d'informations reçues de ladite tête de tunnel, d'une deuxième liste d'adresses, comprenant des adresses associées à des dispositifs sources appartenant au ou aux sous-réseau(x) distant(s) relié(s) audit sous- réseau local par ladite tête de tunnel ; - détermination d'une troisième liste d'adresses, comprenant des adresses associées à des dispositifs sources appartenant au ou aux sous-réseau(x) distant(s) reliés audit sous-réseau local par ladite tête de tunnel courante ; - génération de ladite première liste d'adresses à partir desdites deuxièmes et troisième listes d'adresses.
3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que lorsque une tête de tunnel reçoit une trame émise par un dispositif source, ladite tramearrivant à ladite tête de tunnel par l'un des tunnels, dit tunnel d'arrivée, ledit tunnel d'arrivée reliant le sous-réseau auquel ladite tête de tunnel appartient au sous-réseau distant auquel le dispositif source appartient, ladite tête de tunnel effectue les étapes suivantes : - obtention (600), à partir de ladite trame, d'une adresse, dite adresse distante, de dispositif source correspondant audit dispositif source ayant émis ladite trame; - vérification (601) que l'adresse distante est comprise dans une quatrième liste d'adresses comprenant des adresses associées à des dispositifs sources appartenant au sous-réseau distant relié au sous-réseau local par ledit tunnel d'arrivée ; - en cas de vérification négative, mise à jour (602) de la quatrième liste avec ladite adresse distante. et en ce que ladite première liste d'adresses est générée à partir de : - la ou les quatrième(s) liste(s) d'adresses gérée(s) par chaque tête de tunnel du sous- réseau local, distincte de la tête de tunnel courante, chaque quatrième liste gérée par une tête de tunnel distincte de ladite tête de tunnel courante étant associée à un tunnel d'arrivée distinct ; et - la ou les quatrième(s) liste(s) d'adresses gérée(s) par la tête de tunnel courante, chaque quatrième liste gérée par ladite tête de tunnel courante étant associée à un tunnel d'arrivée distinct.
4. Procédé selon l'une quelconque des revendications 2 ou 3, caractérisé en ce qu'une tête de tunnel envoie, à chaque autre tête de tunnel du sous-réseau auquel ladite tête de tunnel appartient, une information représentative d'une présence d'un nouveau dispositif source dans un sous-réseau distant relié au sous-réseau local par ladite tête de tunnel.
5. Procédé selon l'une quelconque des revendications 3 et 4, caractérisé en ce que, lorsque une tête de tunnel reçoit une trame en provenance d'un tunnel, dit tunnel d'arrivée, dont ladite tête de tunnel est une extrémité, ladite tête de tunnel enclenche un mécanisme de retard de transmission de ladite trame sur ledit sous-réseau local, tant que chaque autre tête de tunnel du sous-réseau auquel ladite tête de tunnel appartient n'est pas informée que le dispositif source appartient au sous-réseau distant relié au sous- réseau local par ledit tunnel d'arrivée.
6. Produit programme d'ordinateur téléchargeable depuis un réseau de communication et/ou enregistré sur un support lisible par ordinateur et/ou exécutable par un processeur, caractérisé en ce qu'il comprend des instructions de code de programme pour la mise en oeuvre du procédé selon au moins une des revendications 1 à 5, lorsque ledit programme est exécuté sur un ordinateur.
7. Moyen de stockage, éventuellement totalement ou partiellement amovible, lisible par un ordinateur, stockant un jeu d'instructions exécutables par ledit ordinateur pour mettre en oeuvre le procédé selon au moins une des revendications 1 à 5.
8. Tête de tunnel destinée à mettre en oeuvre un procédé de gestion de trames dans un réseau global de communication comprenant une pluralité de sous-réseaux reliés entre eux par des tunnels aux extrémités desquels se trouvent des têtes de tunnel, au moins un des sous-réseaux comprenant au moins un dispositif source relié à une desdites têtes de tunnel via ledit sous-réseau, chaque dispositif source étant associé à une adresse, ladite tête de tunnel comprenant des moyens de réception, en provenance du sous-réseau auquel ladite tête de tunnel appartient, dit sous-réseau local, d'une trame courante émise par un dispositif source courant dans le réseau global, caractérisée en ce que la tête de tunnel comprend : - des moyens d'obtention, à partir de ladite trame courante, d'une adresse, dite adresse courante, de dispositif source correspondant au dispositif source courant ; - des moyens de vérification que l'adresse courante est comprise dans une première liste d'adresses comprenant des adresses associées à des dispositifs sources appartenant au ou aux sous-réseau(x) distant(s), le(s) sous-réseau(x) distant(s) étant le(s) sous-réseau(x) du réseau global distinct(s) du sous-réseau local ; - des moyens de destruction de ladite trame courante, activés en cas de vérification positive par lesdits moyens de vérification.
9. Tête de tunnel selon la revendication 8, caractérisée en ce qu'elle comprend des moyens d'obtention de ladite première liste d'adresses comprenant eux-mêmes : - des moyens d'obtention, pour chaque tête de tunnel du sous-réseau local distincte de la tête de tunnel courante, et à partir d'informations reçues de ladite tête de tunnel, d'une deuxième liste d'adresses comprenant des adresses associées à des dispositifssources appartenant au ou aux sous-réseau(x) distant(s) relié(s) audit sous-réseau local par ladite tête de tunnel ; - des moyens de détermination d'une troisième liste d'adresses comprenant des adresses associées à des dispositifs sources appartenant au ou aux sous-réseau(x) distant(s) reliés audit sous-réseau local par ladite tête de tunnel courante ; - des moyens de génération de ladite première liste d'adresses à partir desdites deuxièmes et troisième listes d'adresses.
10. Tête de tunnel selon la revendication 9, caractérisée en ce que lesdits moyens de détermination de ladite troisième liste d'adresses comprennent : - des moyens de réception d'une trame émise par un dispositif source, ladite trame arrivant à ladite tête de tunnel par l'un des tunnels, dit tunnel d'arrivée, ledit tunnel d'arrivée reliant le sous-réseau auquel ladite tête de tunnel appartient au sous-réseau distant auquel le dispositif source appartient ; - des moyens d'obtention, à partir de ladite trame, d'une adresse, dite adresse distante, de dispositif source correspondant audit dispositif source ayant émis ladite trame; - des moyens de vérification que l'adresse distante est comprise dans une quatrième liste d'adresses comprenant des adresses associées à des dispositifs sources appartenant au sous-réseau distant relié au sous-réseau local par ledit tunnel d'arrivée ; - des moyens de mise à jour de la quatrième liste avec ladite adresse distante, activés en cas de vérification négative par lesdits moyens de vérification ; - des moyens de génération de ladite troisième liste d'adresses à partir de la ou les quatrième(s) liste(s) d'adresses gérée(s) par ladite tête de tunnel, chaque quatrième liste étant associée à un tunnel d'arrivée distinct.
11. Tête de tunnel selon l'une quelconque des revendications 9 et 10, caractérisée en ce qu'elle comprend des moyens de transmission, à chaque autre tête de tunnel du sous-réseau auquel ladite tête de tunnel appartient, d'une information représentative d'une présence d'un nouveau dispositif source dans un sous-réseau distant relié au sous-réseau local par ladite tête de tunnel.
12. Tête de tunnel selon l'une quelconque des revendications 10 et 11, caractérisée en ce qu'elle comprend : des moyens de réception d'une trame en provenance d'un tunnel, dit tunnel d'arrivée, dont ladite tête de tunnel est une extrémité ; - des moyens d'activation, sur détection d'une trame par des moyens de détection, d'un mécanisme de retard de transmission de ladite trame sur ledit sous-réseau local, tant que chaque autre tête de tunnel du sous-réseau auquel ladite tête de tunnel appartient n'est pas informée que le dispositif source appartient au sous-réseau distant relié au sous-réseau local par ledit tunnel d'arrivée.
FR0759111A 2007-11-16 2007-11-16 Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants Expired - Fee Related FR2923969B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR0759111A FR2923969B1 (fr) 2007-11-16 2007-11-16 Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
US12/258,104 US7855955B2 (en) 2007-11-16 2008-10-24 Method for managing frames in a global-area communications network, corresponding computer-readable storage medium and tunnel endpoint

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0759111A FR2923969B1 (fr) 2007-11-16 2007-11-16 Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants

Publications (2)

Publication Number Publication Date
FR2923969A1 true FR2923969A1 (fr) 2009-05-22
FR2923969B1 FR2923969B1 (fr) 2012-11-23

Family

ID=39521477

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0759111A Expired - Fee Related FR2923969B1 (fr) 2007-11-16 2007-11-16 Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants

Country Status (2)

Country Link
US (1) US7855955B2 (fr)
FR (1) FR2923969B1 (fr)

Families Citing this family (51)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9716672B2 (en) 2010-05-28 2017-07-25 Brocade Communications Systems, Inc. Distributed configuration management for virtual cluster switching
US9270486B2 (en) 2010-06-07 2016-02-23 Brocade Communications Systems, Inc. Name services for virtual cluster switching
US8867552B2 (en) 2010-05-03 2014-10-21 Brocade Communications Systems, Inc. Virtual cluster switching
US9769016B2 (en) 2010-06-07 2017-09-19 Brocade Communications Systems, Inc. Advanced link tracking for virtual cluster switching
US9807031B2 (en) 2010-07-16 2017-10-31 Brocade Communications Systems, Inc. System and method for network configuration
US9450870B2 (en) 2011-11-10 2016-09-20 Brocade Communications Systems, Inc. System and method for flow management in software-defined networks
US9374301B2 (en) 2012-05-18 2016-06-21 Brocade Communications Systems, Inc. Network feedback in software-defined networks
US8930585B2 (en) * 2012-05-29 2015-01-06 Mediatek Inc. USB host controller and scheduling methods thereof
US9401872B2 (en) 2012-11-16 2016-07-26 Brocade Communications Systems, Inc. Virtual link aggregations across multiple fabric switches
US9565099B2 (en) 2013-03-01 2017-02-07 Brocade Communications Systems, Inc. Spanning tree in fabric switches
US9912612B2 (en) 2013-10-28 2018-03-06 Brocade Communications Systems LLC Extended ethernet fabric switches
US9548873B2 (en) 2014-02-10 2017-01-17 Brocade Communications Systems, Inc. Virtual extensible LAN tunnel keepalives
US10581758B2 (en) 2014-03-19 2020-03-03 Avago Technologies International Sales Pte. Limited Distributed hot standby links for vLAG
US10476698B2 (en) 2014-03-20 2019-11-12 Avago Technologies International Sales Pte. Limited Redundent virtual link aggregation group
US10063473B2 (en) 2014-04-30 2018-08-28 Brocade Communications Systems LLC Method and system for facilitating switch virtualization in a network of interconnected switches
US9800471B2 (en) 2014-05-13 2017-10-24 Brocade Communications Systems, Inc. Network extension groups of global VLANs in a fabric switch
US10616108B2 (en) 2014-07-29 2020-04-07 Avago Technologies International Sales Pte. Limited Scalable MAC address virtualization
US9807007B2 (en) 2014-08-11 2017-10-31 Brocade Communications Systems, Inc. Progressive MAC address learning
US10003552B2 (en) 2015-01-05 2018-06-19 Brocade Communications Systems, Llc. Distributed bidirectional forwarding detection protocol (D-BFD) for cluster of interconnected switches
US9942097B2 (en) 2015-01-05 2018-04-10 Brocade Communications Systems LLC Power management in a network of interconnected switches
US9967906B2 (en) * 2015-01-07 2018-05-08 Cisco Technology, Inc. Wireless roaming using a distributed store
US10038592B2 (en) 2015-03-17 2018-07-31 Brocade Communications Systems LLC Identifier assignment to a new switch in a switch group
US10579406B2 (en) 2015-04-08 2020-03-03 Avago Technologies International Sales Pte. Limited Dynamic orchestration of overlay tunnels
US9985837B2 (en) 2015-07-23 2018-05-29 Cisco Technology, Inc. Refresh of the binding tables between data-link-layer and network-layer addresses on mobility in a data center environment
US10439929B2 (en) 2015-07-31 2019-10-08 Avago Technologies International Sales Pte. Limited Graceful recovery of a multicast-enabled switch
US10171303B2 (en) 2015-09-16 2019-01-01 Avago Technologies International Sales Pte. Limited IP-based interconnection of switches with a logical chassis
US9912614B2 (en) * 2015-12-07 2018-03-06 Brocade Communications Systems LLC Interconnection of switches based on hierarchical overlay tunneling
US10326204B2 (en) 2016-09-07 2019-06-18 Cisco Technology, Inc. Switchable, oscillating near-field and far-field antenna
US10237090B2 (en) 2016-10-28 2019-03-19 Avago Technologies International Sales Pte. Limited Rule-based network identifier mapping
US10440723B2 (en) 2017-05-17 2019-10-08 Cisco Technology, Inc. Hierarchical channel assignment in wireless networks
US10555341B2 (en) 2017-07-11 2020-02-04 Cisco Technology, Inc. Wireless contention reduction
US10440031B2 (en) 2017-07-21 2019-10-08 Cisco Technology, Inc. Wireless network steering
US10735981B2 (en) 2017-10-10 2020-08-04 Cisco Technology, Inc. System and method for providing a layer 2 fast re-switch for a wireless controller
US10375667B2 (en) 2017-12-07 2019-08-06 Cisco Technology, Inc. Enhancing indoor positioning using RF multilateration and optical sensing
US10673618B2 (en) 2018-06-08 2020-06-02 Cisco Technology, Inc. Provisioning network resources in a wireless network using a native blockchain platform
US10505718B1 (en) 2018-06-08 2019-12-10 Cisco Technology, Inc. Systems, devices, and techniques for registering user equipment (UE) in wireless networks using a native blockchain platform
US10873636B2 (en) 2018-07-09 2020-12-22 Cisco Technology, Inc. Session management in a forwarding plane
US10671462B2 (en) 2018-07-24 2020-06-02 Cisco Technology, Inc. System and method for message management across a network
US11252040B2 (en) 2018-07-31 2022-02-15 Cisco Technology, Inc. Advanced network tracing in the data plane
US10735209B2 (en) 2018-08-08 2020-08-04 Cisco Technology, Inc. Bitrate utilization feedback and control in 5G-NSA networks
US10623949B2 (en) 2018-08-08 2020-04-14 Cisco Technology, Inc. Network-initiated recovery from a text message delivery failure
US10284429B1 (en) 2018-08-08 2019-05-07 Cisco Technology, Inc. System and method for sharing subscriber resources in a network environment
US10949557B2 (en) 2018-08-20 2021-03-16 Cisco Technology, Inc. Blockchain-based auditing, instantiation and maintenance of 5G network slices
US10374749B1 (en) 2018-08-22 2019-08-06 Cisco Technology, Inc. Proactive interference avoidance for access points
US10567293B1 (en) 2018-08-23 2020-02-18 Cisco Technology, Inc. Mechanism to coordinate end to end quality of service between network nodes and service provider core
US10230605B1 (en) 2018-09-04 2019-03-12 Cisco Technology, Inc. Scalable distributed end-to-end performance delay measurement for segment routing policies
US10652152B2 (en) 2018-09-04 2020-05-12 Cisco Technology, Inc. Mobile core dynamic tunnel end-point processing
US10779188B2 (en) 2018-09-06 2020-09-15 Cisco Technology, Inc. Uplink bandwidth estimation over broadband cellular networks
US11558288B2 (en) 2018-09-21 2023-01-17 Cisco Technology, Inc. Scalable and programmable mechanism for targeted in-situ OAM implementation in segment routing networks
US10285155B1 (en) 2018-09-24 2019-05-07 Cisco Technology, Inc. Providing user equipment location information indication on user plane
US10601724B1 (en) 2018-11-01 2020-03-24 Cisco Technology, Inc. Scalable network slice based queuing using segment routing flexible algorithm

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1992012587A1 (fr) * 1991-01-09 1992-07-23 Digital Equipment Corporation Procede et appareil permettant d'etablir un pont transparent de trafic par-dessus des reseaux longue portee
US20030147405A1 (en) * 2002-02-01 2003-08-07 Uzi Khill Protecting the filtering database in virtual bridges
US6788681B1 (en) * 1999-03-16 2004-09-07 Nortel Networks Limited Virtual private networks and methods for their operation

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6343330B1 (en) * 1999-05-25 2002-01-29 Cisco Technology, Inc. Arrangement for preventing looping of explorer frames in a transparent bridging domain having multiple entry points
US20040213237A1 (en) * 2000-06-29 2004-10-28 Toshikazu Yasue Network authentication apparatus and network authentication system
US7134012B2 (en) * 2001-08-15 2006-11-07 International Business Machines Corporation Methods, systems and computer program products for detecting a spoofed source address in IP datagrams
ES2285379T3 (es) * 2004-07-16 2007-11-16 Alcatel Lucent Metodo para asegurar la comunicacion en un conmutador de red de area lcal.

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1992012587A1 (fr) * 1991-01-09 1992-07-23 Digital Equipment Corporation Procede et appareil permettant d'etablir un pont transparent de trafic par-dessus des reseaux longue portee
US6788681B1 (en) * 1999-03-16 2004-09-07 Nortel Networks Limited Virtual private networks and methods for their operation
US20030147405A1 (en) * 2002-02-01 2003-08-07 Uzi Khill Protecting the filtering database in virtual bridges

Also Published As

Publication number Publication date
US20090129389A1 (en) 2009-05-21
US7855955B2 (en) 2010-12-21
FR2923969B1 (fr) 2012-11-23

Similar Documents

Publication Publication Date Title
FR2923969A1 (fr) Procede de gestion de trames dans un reseau global de communication, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
WO2017220892A1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
FR2919778A1 (fr) Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
FR2930100A1 (fr) Procede d'etablissement d'un chemin de communication dans un reseau etendu de communication, tetes de tunnel,produit programme d'ordinateur et moyen de stockage correspondants
FR2936387A1 (fr) Procede de gestion d'espaces d'adressage lors d'une ouverture d'un tunnel de communication, tete de tunel, produit programme d'ordinateur et moyen de stockage correspondant.
FR3110795A1 (fr) Procédé de configuration d’un équipement pare-feu dans un réseau de communication, procédé de mise à jour d’une configuration d’un équipement pare-feu, dispositif, équipement d’accès, équipement pare-feu et programmes d’ordinateur correspondants.
WO2020260813A1 (fr) Procédé de gestion d'une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en oeuvre du procédé
FR3066062A1 (fr) Technique d'execution d'un service dans un reseau local a travers un reseau de communication etendu
EP2979222B1 (fr) Procédé de stockage de données dans un système informatique effectuant une deduplication de données
EP2847939A1 (fr) Systeme de transmission de donnees
EP2579545B1 (fr) Méthode d'attribution d'une adresse réseau publique à un équipement disposant d'une adresse réseau privée
CA3153796A1 (fr) Procede de connexion d'un noeud de communication, et noeud de communication correspondant
WO2010072953A1 (fr) SYSTEME D'ACHEMINEMENT D'UN PAQUET DE DONNEES IPv4
EP3991392A1 (fr) Procede de gestion d'une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede
FR3023098A1 (fr) Procede et systeme de traitement d'une demande de resolution d'un nom d'un serveur, emise par une application cliente sur un reseau de communication.
EP3811578A1 (fr) Procédé de découverte de fonctions intermédiaires et de sélection d'un chemin entre deux équipements de communication
FR3091128A1 (fr) Procédé et système de gestion de serveurs dhcp
FR2913841A1 (fr) Procede d'acces a distance a un reseau,produit programme d'ordinateur,moyen de stockage et dispositifs correspondants
EP3672209B1 (fr) Procédé d'identification de noeud de communication
EP1432213B1 (fr) Plate-forme de médiation et réseau de transport de messages
FR3019417A1 (fr) Procede de traitement d'un message dans un dispositif d'interconnexion
EP3149902A1 (fr) Technique d'obtention d'une politique de routage de requêtes émises par un module logiciel s'exécutant sur un dispositif client
FR3118561A1 (fr) Procede de configuration d'une interface securisee entre un reseau de transport et un reseau elementaire d'une pluralite de reseaux elementaires federes a travers le reseau de transport ; interface associee
EP3070911A1 (fr) Procédé de contrôle d'accès à un réseau privé
WO2023111432A1 (fr) Mécanismes de communication avec un service accessible via un réseau de télécommunication prenant en compte la mobilité des services, des utilisateurs et des équipements

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140731