FR2934735A1 - Procede d'etablissement d'un chemin de communication entre une premiere tete de tunnel et une seconde tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes. - Google Patents

Procede d'etablissement d'un chemin de communication entre une premiere tete de tunnel et une seconde tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes. Download PDF

Info

Publication number
FR2934735A1
FR2934735A1 FR0855306A FR0855306A FR2934735A1 FR 2934735 A1 FR2934735 A1 FR 2934735A1 FR 0855306 A FR0855306 A FR 0855306A FR 0855306 A FR0855306 A FR 0855306A FR 2934735 A1 FR2934735 A1 FR 2934735A1
Authority
FR
France
Prior art keywords
tunnel
head
tep
message
community
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
FR0855306A
Other languages
English (en)
Other versions
FR2934735B1 (fr
Inventor
Du Fretay Tristan Halna
Pascal Rousseau
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 FR0855306A priority Critical patent/FR2934735B1/fr
Publication of FR2934735A1 publication Critical patent/FR2934735A1/fr
Application granted granted Critical
Publication of FR2934735B1 publication Critical patent/FR2934735B1/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

Abstract

Il est proposé un procédé d'établissement d'un chemin de communication entre une première tête de tunnel et une seconde tête de tunnel par l'intermédiaire d'au moins une tête de tunnel intermédiaire, à une tête de tunnel donnée étant associée une communauté constituée d'un ensemble de têtes de tunnel, à chaque tête de tunnel d'une communauté étant associé un niveau de confiance de la tête de tunnel donné, Plus précisément, ce procédé consiste à établir un chemin par relais de communication entre la première tête de tunnel et la seconde tête de tunnel même lorsque la tête de tunnel intermédiaire n'appartient pas à la communauté de la première tête de tunnel (ou de la seconde tête de tunnel).

Description

Procédé d'établissement d'un chemin de communication entre une première tête de tunnel et une seconde tête de tunnel, produit programme d'ordinateur, moyen de stockage et têtes de tunnel correspondantes. 1. DOMAINE DE L'INVENTION Le domaine de l'invention est celui des réseaux de communication. Plus précisément, l'invention concerne la gestion d'interconnexions de réseaux locaux domestiques (appelés ci-après réseaux LAN, pour Local Area Network en anglais). La démocratisation d'internet haut débit d'une part et l'apparition d'équipements audiovisuels grand public ayant une connectivité réseau d'autre part vont créer de nouveaux comportements des utilisateurs. Parmi ces nouveaux comportements, il fait peu de doute que nous verrons apparaître des individus appartenant à des groupes de personnes ayants des domaines d'intérêts communs (loisirs, famille...) que nous pourrions appeler en liaison permanente . Ceux-ci établiront des connections quasi permanentes avec les autres individus d'un même domaine d'intérêt en établissant des communications audio et/ou vidéo, et partageant des informations de tout type (audio, vidéo, photo, texte ...). La technologie RPV (pour Réseaux Privés Virtuels en français ou VPN pour Viruual Private Network en anglais) offre une solution intéressante pour répondre à cette attente. En effet, elle permet de communiquer de manière transparente en temps réel, 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ûr mais bon marché. Pour communiquer de manière transparente et s'affranchir des adresses non routables, les RPV utilisent une encapsulation particulière appelée tunnellisation (ou tunneling en anglais) créant ce que l'on appelle classiquement un tunnel. Cette opération consiste à encapsuler un protocole de niveau A (protocole embarqué ou véhiculé ou passager) dans un protocole de niveau B (protocole de transport ou véhiculant) grâce à un protocole d'encapsulation C. Ainsi, le protocole de transport B traite le protocole embarqué A comme s'il s'agissait de données utiles.
La tunnellisation peut être utilisée pour transporter un protocole réseau sur un réseau qui ne le supporte pas. Elle peut aussi être utilisée pour fournir différents types de fonctionnalités RPV, comme par exemple l'adressage privé.
Les techniques de tunnel sont aujourd'hui de plus en plus utilisées par des fonctionnalités client d'accès à distance et des interconnexions de réseaux LAN. Les RPV sont fréquemment utilisés pour interconnecter deux réseaux LAN afin de créer un réseau local virtuel composé de l'union des deux réseaux LAN. Les RPV 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é sur une technique de tunnellisation est illustrée sur la figure 2a (décrite en détail par la suite). Dans cet exemple, les têtes de tunnel (ou TEP pour 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é a un 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. Une communication entre deux équipements via le tunnel est appelée communication de bout en bout (ou end-to-end communication en anglais). Ce principe d'interconnexion de réseaux LAN par le biais de tunnels peut aussi être étendu à plus de deux réseaux LAN. En effet, un réseau LAN A peut être relié à un réseau LAN B par un tunnel AB, et le réseau LAN B au réseau LAN C par le biais d'un tunnel BC. Dans ce cas, chaque équipement du réseau virtuel ABC ainsi créé peut communiquer avec tous les autres, et les trames émis par un équipement sur l'un des réseaux LAN A, B, ou C sont envoyées sur les autres réseaux LAN. Par exemple, une trame émis par un équipement sur le réseau LAN A sera envoyé sur le réseau LAN B par le biais du tunnel AB, puis relayé vers le réseau LAN C par le tunnel BC (on pourra dire ici que le réseau LAN B est un relais entre les réseaux LAN A et C).
Ceci n'est cependant pas toujours un avantage. En effet, on peut imaginer que dans certains cas, un équipement connecté à un réseau LAN A et communiquant avec un équipement connecté à un réseau LAN B ne souhaite pas que ses trames se retrouvent sur un réseau LAN C. Pour palier à ce problème, il existe des techniques bien connues permettant de bloquer la retransmission d'une trame arrivée sur un réseau LAN par le biais d'un tunnel, vers un second tunnel partant de ce même réseau LAN, par apprentissage et filtrage d'adresses par exemple.
Dans la suite de la description, on considérera le cas où une unique tête de tunnel gère l'ensemble des tunnels partant d'un même réseau LAN, et où par défaut le relais des trames entre tunnels est bloqué. Les tunnels ne forment pas toujours un maillage complet entre les réseaux LAN (c'est-à-dire qu'il n'existe pas un tunnel entre chaque paire de réseaux LAN). De plus, l'établissement d'un nouveau tunnel entre deux têtes de tunnel présentes sur deux réseaux LAN distincts entre lesquels on désire établir un chemin de communication n'est pas toujours possible. C'est notamment le cas lorsque, par exemple, une tête de tunnel ne possède pas assez de ressources nécessaires à l'établissement d'un tunnel supplémentaire. On peut donc être amené à chercher à établir un chemin, dit chemin par relais, entre les deux têtes de tunnel en utilisant les têtes de tunnel présentes sur un ou plusieurs autres réseaux LAN. Ces autres têtes de tunnel sont appelées têtes de tunnel relais. Ces têtes de tunnel relais doivent notamment filtrer les trames pour autoriser de manière sélective une communication entre un premier tunnel vers un second tunnel (par défaut le relais des trames entre tunnels est bloqué). Pour ce faire, ce filtrage se base sur une notion de communauté. Cette notion de communauté s'applique au niveau des réseaux LAN eux-mêmes. Par exemple, la communauté d'un réseau LAN I est la communauté de la tête de tunnel qui y est connectée, la communauté d'une tête de tunnel étant constituée par l'ensemble des têtes de tunnel avec lesquelles elle a précédemment établi un tunnel, même si le tunnel a été désactivé depuis. Il n'y a pas besoin que le tunnel soit toujours actif pour que la tête de tunnel associée fasse partie de la communauté. La communauté d'une tête de tunnel peut aussi comprendre des têtes de tunnel issues d'une configuration, par exemple par l'utilisateur, des communications autorisées. Grâce à cette notion de communauté, il est défini qu'une trame émise par un équipement connecté à un premier réseau LAN A ne doit pas être réémise sur un réseau LAN distant n'appartenant pas à la communauté du réseau LAN A. Dans ce cas, pour utiliser un réseau LAN I intermédiaire comme relais sur un chemin entre une première tête de tunnel (TEP S) et une seconde tête de tunnel (TEP D), il faut que la tête de tunnel connectée au réseau LAN I appartienne à la fois aux deux communautés des têtes de tunnel (TEP S et TEP D). En effet, il s'agit de la condition à laquelle une trame originaire des réseaux LAN S ou D est autorisée à transiter sur le réseau LAN I. Classiquement, pour établir un chemin par relais, un message de découverte de chemin est émis depuis la première tête de tunnel (TEP S) sur les tunnels qui lui sont rattachés. Chaque tête de tunnel qui reçoit ce message de découverte ajoute ensuite son identifiant dans le message et le retransmet aux têtes de tunnel avec lesquelles elle a un tunnel actif (établi) et qui appartiennent aux deux communautés des deux têtes de tunnel (TEP S et TEP D). Lorsque ce message de découverte atteint la seconde tête de tunnel (TEP D), la seconde tête de tunnel (TEP D) renvoie alors vers la première tête de tunnel (TEP S) une réponse contenant les identifiants des têtes de tunnel constituant le chemin de la première tête de tunnel (TEP S) vers la seconde tête de tunnel (TEP D). Sur réception de cette réponse, la première tête de tunnel (TEP S) envoie alors une requête vers les têtes de tunnel constituant le chemin pour que chaque tête de tunnel active sa fonction relais afin de relayer les trames allant de la première tête de tunnel (TEP S) vers la seconde tête de tunnel (TEP D), et vice-versa. 2. ARRIÈRE-PLAN TECHNOLOGIQUE Un document de brevet américain n° US 6760330 présente un équipement de réseau comprenant plusieurs interfaces, chacune étant associée à un ensemble de communauté. Des tables contenues dans l'équipement listent l'ensemble des appareils réseaux connectés à chacune des interfaces, et les communautés associées à ces appareils. Chaque trame entrant ou sortant de l'équipement par le biais de ses interfaces est filtrée dans le but d'assurer que les appareils source et destination de ladite trame sont associés à au moins une communauté en commun (c'est-à-dire que leurs ensembles de communautés associés ont une intersection non nulle), et que ces communautés en commun sont incluses dans l'ensemble des communautés associées aux interfaces d'entrée et de sortie de la trame. Dans cet art antérieur, il est vérifié le respect des communautés entre les appareils sources et destinations lors des échanges de trames, ainsi que le respect des communautés attachées aux équipements traversés par les trames sur leur chemin. En revanche, si les communautés associées à l'un des équipements intermédiaires sur le chemin des trames ne permettent pas le transfert, aucune solution de chemin alternatif n'est envisagée. 3. OBJECTIFS DE L'INVENTION L'invention dans au moins un mode de réalisation, a notamment pour objectif de pallier cet inconvénient 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 permettant le transfert de trames et ce même dans le cas où: - l'établissement d'un tunnel entre une première tête de tunnel et une seconde tête de tunnel échoue par manque de ressources, par exemple, sur la seconde tête de tunnel, la première tête de tunnel étant celle requérant l'établissement du tunnel ; et - la recherche de chemins par relais intra-communautaire entre ces mêmes têtes de tunnel source et destination échoue du fait qu'une des têtes de tunnel relais n'appartient pas à la communauté de la première tête de tunnel (ou de la seconde tête de tunnel). Au moins un mode de réalisation de l'invention a également pour objectif de fournir une telle technique qui soit simple à mettre en oeuvre. 4. EXPOSÉ DE L'INVENTION Dans un mode de réalisation particulier de l'invention, l'invention concerne un procédé d'établissement d'un chemin de communication entre une première tête de tunnel connectée à un premier sous-réseau et une seconde tête de tunnel connectée à un second sous-réseau par l'intermédiaire d'au moins une tête de tunnel intermédiaire connectée à un sous-réseau intermédiaire, chaque tête de tunnel permettant l'interconnexion du sous-réseau où elle est connectée à au moins un autre sous-réseau au moyen d'au moins un tunnel de communication, à une tête de tunnel donnée étant associée une communauté constituée d'un ensemble de têtes de tunnel, à chaque tête de tunnel d'une communauté étant associé un niveau de confiance de la tête de tunnel donné. De manière remarquable, ce procédé est effectué par une tête de tunnel intermédiaire et comprend les étapes consistant à : recevoir, en provenance directe ou indirecte de la première tête de tunnel, d'un premier message de découverte de chemin de communication entre la première et la seconde tête de tunnel ; - dans le cas où la seconde tête de tunnel appartient à la communauté de ladite tête de tunnel intermédiaire avec un niveau de confiance supérieur ou égal à un seuil prédéterminé et où la première tête de tunnel n'appartient pas à la communauté de ladite tête de tunnel intermédiaire, établir un tunnel auxiliaire entre la première tête de tunnel et ladite tête de tunnel intermédiaire ; - activer le chemin de communication entre les première et seconde têtes de tunnel par utilisation du tunnel auxiliaire établi. Le principe général de l'invention consiste ainsi à établir un chemin par relais de communication entre une première et une seconde tête de tunnel même lorsqu'une tête de tunnel intermédiaire dudit chemin par relais de communication n'appartient pas à la communauté de la première tête de tunnel (ou de la seconde tête de tunnel). Ainsi, dans ce mode de réalisation particulier, l'invention repose sur une approche tout à fait nouvelle et inventive de création d'un chemin par relais temporaire de communication entre une première et une seconde tête de tunnel et ce grâce à l'établissement d'un tunnel auxiliaire entre une tête de tunnel intermédiaire n'appartenant pas à la communauté de la première tête de tunnel et ladite première tête de tunnel. De façon avantageuse, ce procédé comprend en outre une étape consistant à émettre un deuxième message de découverte de chemin entre les première et seconde têtes de tunnel, ledit message étant émis sur le ou le(s) tunnel(s), autre(s) que le tunnel auxiliaire, pour lesquels la tête de tunnel intermédiaire est une extrémité et par lesquels ledit premier message de découverte de chemin n'est pas arrivé. Ainsi, une fois le tunnel auxiliaire établi et ainsi résolue l'impasse de progression du message de découverte de chemin, la recherche du chemin peut reprendre à partir de la tête de tunnel intermédiaire avec laquelle le tunnel auxiliaire est établi. De plus, le message est envoyé de manière sélective sur les tunnels que gère la tête de tunnel intermédiaire, afin d'éviter des traitements inutiles et des transmissions sans fin de messages de configuration dans le réseau. Avantageusement, l'étape consistant à activer le chemin de communication est précédée d'une étape consistant à : - émettre un message de détection d'impasse à destination de la première tête de tunnel ; - recevoir, en provenance directe ou indirecte de la première tête de tunnel, un message de poursuite de découverte de chemin de communication entre les première et seconde têtes de tunnel ; - construire ledit deuxième message de découverte de chemin à partir du message de poursuite de découverte reçu. Ainsi, la poursuite de la découverte de chemin s'effectue sur requête de la tête de tunnel ayant initié la découverte de chemin. Cela permet à celle-ci de sélectionner une tête de tunnel intermédiaire parmi plusieurs, dans le cas où plusieurs impasses sont détectées du fait de l'envoi d'un message de découverte sur chacun des tunnels actifs (au moins deux dans ce cas) que gère la tête de tunnel ayant initié la découverte de chemin. Selon une caractéristique avantageuse, la communauté associée à une tête de tunnel donnée correspond à un ensemble de têtes de tunnel avec lesquels la tête de tunnel donnée a précédemment établi un tunnel de communication. Ainsi, la communauté d'une tête de tunnel est administrée automatiquement à l'activation d'un tunnel auxiliaire. Une seule et même table de filtrage peut alors être utilisée de manière à gérer le trafic des trames entre le réseau LAN auquel est connectée la tête de tunnel concernée et les tunnels qu'elle gère et entre ces tunnels entre eux. Selon une autre caractéristique avantageuse, ladite étape consistant à établir le tunnel auxiliaire est suivie d'une étape consistant à inclure la première tête de tunnel dans la communauté de ladite tête de tunnel intermédiaire et à affecter à la première tête de tunnel un niveau de confiance inférieur audit seuil prédéterminé.
Ainsi, la communauté des têtes de tunnel entre lesquelles est établi le tunnel auxiliaire est administrée automatiquement. Le niveau de confiance associé permet alors que les tunnels auxiliaires ne soient pas utiliser pour palier à une autre impasse que celle pour laquelle ils ont été établis. En effet, si le niveau de confiance d'une tête de tunnel A envers une autre tête de tunnel B est inférieur au seuil prédéterminé, alors aucun tunnel auxiliaire n'est établi entre la tête de tunnel A et une tête de tunnel C, dans le cadre de l'établissement d'un chemin par relais entre les têtes de tunnel B et C, la requête de découverte de chemin émanant de la tête de tunnel C.
Avantageusement, ce procédé comprend en outre des étapes consistant à : - recevoir, en provenance directe ou indirecte de l'une parmi les première et seconde têtes de tunnel, d'une requête de désactivation du tunnel auxiliaire ; - retirer la première tête de tunnel de la communauté de ladite tête de tunnel intermédiaire. Ainsi, la communauté d'une tête de tunnel est administrée automatiquement à la désactivation d'un tunnel auxiliaire, et une fois le chemin par relais désactivé, la consommation mémoire liée à la construction et au suivi de la communauté d'une tête de tunnel est maîtrisée.
Dans un autre mode de réalisation particulier de l'invention, l'invention concerne un procédé d'établissement d'un chemin de communication entre une première tête de tunnel connectée à un premier sous-réseau et une seconde tête de tunnel connectée à un second sous-réseau par l'intermédiaire d'au moins une tête de tunnel intermédiaire connectée à un sous-réseau intermédiaire, chaque tête de tunnel permettant l'interconnexion du sous-réseau auquel elle est connectée à au moins un autre sous-réseau au moyen d'au moins un tunnel de communication, à une tête de tunnel donnée étant associée une communauté constituée d'un ensemble de têtes de tunnel, à chaque tête de tunnel d'une communauté étant associé un niveau de confiance de la tête de tunnel donné, De manière remarquable, ce procédé est effectué par ladite première tête de tunnel et comprend les étapes consistant à : - émettre un message de découverte de chemin de communication entre la première et la seconde tête de tunnel, ledit message étant émis sur au moins un tunnel actif dont la première tête de tunnel est une extrémité ; - recevoir un premier message de détection d'impasse provenant d'une première tête de tunnel intermédiaire ; - établir un premier tunnel auxiliaire entre la première tête de tunnel et la première tête de tunnel intermédiaire ; - activer le chemin de communication entre les première et seconde têtes de tunnel par utilisation du tunnel auxiliaire établi.
Avantageusement, ce procédé comprend des étapes consistant à : - recevoir un message de détection d'impasse en provenance de la première tête de tunnel intermédiaire ; - émettre un message de poursuite de découverte de chemin de communication entre les première et seconde têtes de tunnel, ladite poursuite de recherche de chemin devant s'effectuer en prenant en compte le tunnel auxiliaire comme portion dudit chemin et devant reprendre à partir de la première tête de tunnel intermédiaire. De façon avantageuse, ce procédé comprend des étapes consistant à : - désactiver le tunnel auxiliaire, dans le cas où, en réponse audit message de poursuite de recherche de chemin, la première tête de tunnel reçoit un second message de détection d'impasse provenant d'une seconde tête de tunnel intermédiaire ; - établir un second tunnel auxiliaire entre la première tête de tunnel et la seconde 15 tête de tunnel intermédiaire ; - activer le chemin de communication entre les première et seconde têtes de tunnel par utilisation du second tunnel auxiliaire établi. Ainsi, si plusieurs impasses successives sont détectées lors de la recherche d'un chemin par relais entre deux têtes de tunnel, le chemin le plus court est conservé. Le ou 20 les tunnel(s) auxiliaire(s) précédemment établi(s) pour ce chemin ne pouvant être utilisés pour relayer les données entre les deux têtes de tunnel, ceux-ci sont désactivés de manière à maîtriser la consommation de ressources liées à la gestion de la communauté d'une tête de tunnel, ainsi que celles liées à la gestion des tunnels. Avantageusement, la communauté associée à une tête de tunnel donnée 25 correspond à un ensemble de têtes de tunnel avec lesquels la tête de tunnel donnée a précédemment établi un tunnel de communication. En outre, ladite étape consistant à établir le premier tunnel auxiliaire est suivie d'une étape consistant à inclure la première tête de tunnel intermédiaire dans la communauté de la première tête de tunnel et à affecter à la première tête de tunnel 30 intermédiaire un niveau de confiance inférieur audit seuil prédéterminé. 10 De manière intéressante, ce procédé comprend en outre, sur désactivation dudit chemin activé entre la première et la seconde tête de tunnel, une étape consistant à : - désactiver le premier tunnel auxiliaire ; - exclure la première tête de tunnel de la communauté de ladite première tête de tunnel intermédiaire. L'invention concerne également 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é exécuté par la tête de tunnel d'entrée et/ou la tête de tunnel de sortie, lorsque ledit programme est exécuté sur un ordinateur. L'invention concerne également 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é exécuté par la tête de tunnel d'entrée et/ou la tête de tunnel de sortie. Dans un autre mode de réalisation, l'invention concerne une tête de tunnel intermédiaire connectée à un sous-réseau intermédiaire et permettant l'établissement d'un chemin de communication entre une première tête de tunnel connectée à un premier sous-réseau et une seconde tête de tunnel connectée à un second sous-réseau, chaque tête de tunnel permettant l'interconnexion du sous-réseau où elle est connectée à au moins un autre sous-réseau au moyen d'au moins un tunnel de communication, à une tête de tunnel donnée étant associée une communauté constituée d'un ensemble de têtes de tunnel, à chaque tête de tunnel d'une communauté étant associé un niveau de confiance de la tête de tunnel donné, De manière remarquable, ladite tête de tunnel intermédiaire (TEP F) comprend : - des moyens pour recevoir, en provenance directe ou indirecte de la première tête de tunnel, d'un premier message de découverte de chemin de communication entre la première et la seconde tête de tunnel ; - des moyens pour établir un tunnel auxiliaire entre la première tête de tunnel et ladite tête de tunnel intermédiaire ;dans le cas où la seconde tête de tunnel appartient à la communauté de ladite tête de tunnel intermédiaire avec un niveau de confiance supérieur ou égal à un seuil prédéterminé et où la première tête de tunnel n'appartient pas à la communauté de ladite tête de tunnel intermédiaire ; - des moyens pour activer le chemin de communication entre les première et seconde têtes de tunnel par utilisation du tunnel auxiliaire établi.
De manière intéressante, la tête de tunnel intermédiaire comprend des moyens pour émettre un deuxième message de découverte de chemin entre les première et seconde têtes de tunnel, ledit message étant émis sur le ou le(s) tunnel(s), autre(s) que le tunnel auxiliaire, pour lesquels la tête de tunnel intermédiaire est une extrémité et par lesquels ledit premier message de découverte de chemin n'est pas arrivé.
En outre, la tête de tunnel intermédiaire comprend : - des moyens pour émettre un message de détection d'impasse à destination de la première tête de tunnel ; - des moyens pour recevoir, en provenance directe ou indirecte de la première tête de tunnel, un message de poursuite de découverte de chemin de communication entre les première et seconde têtes de tunnel ; - des moyens pour construire ledit deuxième message de découverte de chemin à partir du message de poursuite de découverte reçu. Egalement, la tête de tunnel intermédiaire comprend des moyens d'affectation de la première tête de tunnel dans la communauté de ladite tête de tunnel intermédiaire de façon à affecter à la première tête de tunnel un niveau de confiance inférieur audit seuil prédéterminé. De manière avantageuse, la tête de tunnel intermédiaire comprend : - des moyens pour recevoir, en provenance directe ou indirecte de l'une parmi les première et seconde têtes de tunnel, d'une requête de désactivation du tunnel auxiliaire ; - des moyens pour retirer la première tête de tunnel de la communauté de ladite tête de tunnel intermédiaire. Dans un autre mode de réalisation, l'invention concerne une première tête de tunnel connectée à un premier sous-réseau et située sur un chemin de communication reliant ladite première tête de tunnel et une seconde tête de tunnel connectée à un second sous-réseau, ledit chemin de communication étant établi par l'intermédiaire d'au moins une tête de tunnel intermédiaire connectée à un sous-réseau intermédiaire, chaque tête de tunnel permettant l'interconnexion du sous-réseau auquel elle est connectée à au moins un autre sous-réseau au moyen d'au moins un tunnel de communication, à une tête de tunnel donnée étant associée une communauté constituée d'un ensemble de têtes de tunnel, à chaque tête de tunnel d'une communauté étant associé un niveau de confiance de la tête de tunnel donné, De manière remarquable, ladite première tête de tunnel comprend - des moyens pour émettre un message de découverte de chemin de communication entre la première et la seconde tête de tunnel, ledit message étant émis sur au moins un tunnel actif dont la première tête de tunnel est une extrémité ; - des moyens pour recevoir un premier message de détection d'impasse provenant d'une première tête de tunnel intermédiaire ; - des moyens pour établir un premier tunnel auxiliaire entre la première tête de tunnel et la première tête de tunnel intermédiaire ; - des moyens pour activer le chemin de communication entre les première et seconde têtes de tunnel par utilisation du tunnel auxiliaire établi. De manière intéressante, la première tête de tunnel comprend : - des moyens pour recevoir un message de détection d'impasse en provenance de la première tête de tunnel intermédiaire ; - des moyens pour émettre un message de poursuite de découverte de chemin de communication entre les première et seconde têtes de tunnel, ladite poursuite de recherche de chemin devant s'effectuer en prenant en compte le tunnel auxiliaire comme portion dudit chemin et devant reprendre à partir de la première tête de tunnel intermédiaire. En outre, la première tête de tunnel comprend : - des moyens pour désactiver le tunnel auxiliaire, dans le cas où, en réponse audit message de poursuite de recherche de chemin, la première tête de tunnel reçoit un second message de détection d'impasse provenant d'une seconde tête de tunnel intermédiaire ; 30 - des moyens pour établir un second tunnel auxiliaire entre la première tête de tunnel et la seconde tête de tunnel intermédiaire ; - des moyens pour activer le chemin de communication entre les première et seconde têtes de tunnel par utilisation du second tunnel auxiliaire établi.
De manière avantageuse, la première tête de tunnel comprend des moyens d'affectation de la première tête de tunnel intermédiaire dans la communauté de la première tête de tunnel de façon à affecter à la première tête de tunnel intermédiaire un niveau de confiance inférieur audit seuil prédéterminé. Avantageusement, la première tête de tunnel comprend, sur désactivation dudit chemin activé entre la première et la seconde tête de tunnel : - des moyens pour désactiver le premier tunnel auxiliaire ; - des moyens pour exclure la première tête de tunnel de la communauté de ladite première tête de tunnel intermédiaire. 5. LISTE DES FIGURES D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description suivante, donnée à titre d'exemple indicatif et non limitatif, et des dessins annexés, dans lesquels : - la figure la illustre schématiquement un exemple de configuration sur laquelle l'invention peut s'appliquer ; - la figure lb illustre schématiquement, en relation avec la figure la, le mécanisme d'échanges de messages entre une première tête de tunnel (TEP S), une seconde tête de tunnel (TEP D) et une tête de tunnel intermédiaire (TEP I) ; - la figure 2a illustre une configuration d'un tunnel de niveau 2 ; - la figure 2b illustre un exemple de modèle en couche d'une tête de tunnel dans laquelle peut être mis en oeuvre le procédé selon l'invention ; - la figure 3 illustre un organigramme d'un mode de réalisation particulier du procédé selon l'invention ; - la figure 4 illustre un organigramme d'établissement d'un tunnel direct entre deux têtes de tunnel ; - la figure 5 illustre un organigramme d'établissement d'un tunnel auxiliaire entre deux têtes de tunnel, selon le mode de réalisation particulier de la figure 3 ; 20 25 30 - la figure 6a illustre schématiquement une table des communautés selon l'invention ; - la figure 6b illustre un organigramme de mise à jour de la table de communauté de la figure 6a selon l'invention ; - la figure 6c illustre un organigramme de mise à jour de la table de communauté de la figure 6a après désactivation d'un tunnel ou d'un chemin par relais ; - la figure 6d illustre un organigramme de mise à jour de la table de communauté de la figure 6a après désactivation d'un tunnel auxiliaire ; - la figure 6e illustre un organigramme de mise à jour de la table de communauté de la figure 6a après activation d'un chemin par relais ; - la figure 7 illustre un organigramme de recherche de chemins par relais, mis en oeuvre par la première tête de tunnel (TEP S) ; - la figure 8 illustre un organigramme de recherche de chemins par relais, mis en oeuvre par une tête de tunnel intermédiaire ; - la figure 9 illustre un organigramme de recherche de chemins par relais, mis en oeuvre par la seconde tête de tunnel (TEP D) ; - la figure 10 illustre schématiquement le format des messages utilisés ; - la f i g u r e 1 l a illustre un organigramme d'activation des relais depuis la première tête de tunnel (TEP S); - la figure 1 lb illustre un organigramme d'activation des relais sur une tête de tunnel intermédiaire ; - la figure 12a illustre schématiquement une table de relais ; - la figure 12b illustre schématiquement une table des chemins ; - la figure 13a illustre un organigramme de transmission d'un datagramme depuis la première tête de tunnel (TEPS) ; - la figure 13b illustre un organigramme de transmission d'un datagramme depuis une tête de tunnel intermédiaire ou depuis la seconde tête de tunnel (TEP D) ; - La figure 14 illustre schématiquement une configuration d'une tête de tunnel. 6. DESCRIPTION DÉTAILLÉE La présente invention concerne une technique permettant le transfert de trames de données entre une première tête de tunnel (TEP S) et une seconde tête de tunnel (TEP D).
Plus précisément, dans le cas où l'établissement d'un chemin de communication échoue entre la première tête de tunnel et la seconde tête de tunnel, la présente invention permet la création d'un tunnel, dit tunnel auxiliaire, permettant la circulation de trames entre : - une première tête de tunnel (TEP S) présentant les ressources nécessaires à l'établissement d'un tunnel avec une seconde tête de tunnel (TEP D), et - une tête de tunnel intermédiaire, appartenant à la communauté de la seconde tête de tunnel (TEP D). La figure la illustre un exemple de configuration sur laquelle l'invention peut s'appliquer. Les cercles TEP S, E, F, G et D représentent des têtes de tunnel, chacune étant connectée à son propre réseau LAN (non représenté). Classiquement, les têtes de tunnel sont reliées entre elles par le biais de tunnels représentés par des traits pleins. Dans l'exemple de la figure 1, les têtes de tunnel (TEP S et E) sont reliées par le tunnel SE, les têtes de tunnel (TEP E et F) par le tunnel EF, les têtes de tunnel (TEP F et G) par le tunnel FG, et les têtes de tunnel (TEP G et D) par le tunnel GD. Lors de l'établissement d'un tunnel entre deux têtes de tunnel, chacune de ces deux têtes de tunnel entre dans la communauté de l'autre avec soit un haut niveau de confiance (niveau 1), soit un niveau de confiance plus faible (niveau 2) ou soit avec un niveau de confiance temporaire (niveau 3). Cette notion de niveau de confiance est plus amplement décrite par la suite. La valeur donnée aux niveaux de confiance est illustrative. Il est à noter que ce qui importe est que le niveau de confiance doit être comparé à un seuil prédéterminé, afin de déterminer si un tunnel, et quel type de tunnel (auxiliaire ou pas, tel que décrit par la suite), peut être établi entre les têtes de tunnel, et quelles sont les types de communications (relais,...) autorisées. Un tel niveau de confiance est donné par l'utilisateur ou l'application qui demande l'établissement du tunnel. Ainsi, lorsqu'une tête de tunnel (par exemple la tête de tunnel (TEP S)) a échoué dans l'établissement d'un tunnel direct (c' est-à-dire sans tête de tunnel intermédiaire) vers une autre tête de tunnel (par exemple la tête de tunnel (TEP D)), et qu'il se révèle impossible de trouver un chemin utilisant la fonction relais de tête de tunnel appartenant toutes aux deux communautés des tête de tunnel (TEP S et D), la présente invention propose l'utilisation d'une tête de tunnel intermédiaire (par exemple la tête de tunnel (TEP F)) n'appartenant pas à la communauté de la tête de tunnel (TEP S) mais appartenant à la communauté de la tête de tunnel (TEP D) avec un haut niveau de confiance (niveau 1) afin d'établir un tunnel, dit tunnel auxiliaire, avec la tête de tunnel (TEP S). Ce faisant, la tête de tunnel (TEP F) entre dans la communauté de la tête de tunnel (TEP S) avec un statut particulier selon un niveau de confiance temporaire (niveau 3) plus amplement décrit par la suite. Une nouvelle recherche de chemin utilisant la fonction relais de tête de tunnel se poursuit alors. Selon l'invention, chaque niveau de confiance comprend six attributs prédéfinis.
Quand une tête de tunnel B rejoint la communauté d'une tête de tunnel A suite à l'établissement d'un tunnel, la tête de tunnel A associe à la tête de tunnel B : - un premier attribut d'établissement de tunnel pouvant prendre : - une première valeur indiquant qu'une tête de tunnel A accepte qu'un tunnel soit établi entre la tête de tunnel A et une tête de tunnel C, afin de relayer des données entre la tête de tunnel B et la tête de tunnel C ; - une seconde valeur indiquant que ladite tête de tunnel A n'accepte pas qu'un tunnel soit établi entre la tête de tunnel A et une tête de tunnel C, afin de relayer des données entre la tête de tunnel B et la tête de tunnel C. - un second attribut de relais de message pouvant prendre : - une première valeur indiquant que ladite tête de tunnel A accepte de relayer les messages de découverte qu'elle reçoit vers la tête de tunnel B à travers le tunnel établi ; - une seconde valeur indiquant que ladite tête de tunnel A n'accepte pas de relayer les messages de découverte qu'elle reçoit vers la tête de tunnel B à travers le tunnel établi. - un troisième attribut de relais de message pouvant prendre : - une première valeur indiquant que ladite tête de tunnel A accepte de relayer, vers d'autres têtes de tunnel, les messages de découverte qu'elle reçoit de la tête de tunnel B à travers le tunnel établi; 5 10 15 20 2530 - une seconde valeur indiquant que ladite tête de tunnel A n'accepte pas de relayer, vers d'autres têtes de tunnel, les messages de découverte qu'elle reçoit de la tête de tunnel B à travers le tunnel établi. - un quatrième attribut de relais de message pouvant prendre : - une première valeur indiquant que ladite tête de tunnel A accepte de relayer, vers la tête de tunnel B à travers le tunnel établi, les messages de poursuite de découverte qu'elle reçoit d'autres têtes de tunnel ; - une seconde valeur indiquant que ladite tête de tunnel A n'accepte pas de relayer, vers la tête de tunnel B à travers le tunnel établi, les messages de poursuite de découverte qu'elle reçoit d'autres têtes de tunnel. - un cinquième attribut de relais de message pouvant prendre : - une première valeur indiquant que ladite tête de tunnel A accepte de relayer, vers d'autres têtes de tunnel, les messages de poursuite de découverte qu'elle reçoit de la tête de tunnel B à travers le tunnel établi; - une seconde valeur indiquant que ladite tête de tunnel A n'accepte pas de relayer, vers d'autres têtes de tunnel, les messages de poursuite de découverte qu'elle reçoit de la tête de tunnel B à travers le tunnel établi. - un sixième attribut de gestion de communauté pouvant prendre : - une première valeur indiquant que ladite tête de tunnel B reste dans la communauté de la tête de tunnel A quand le tunnel est désactivé ; - une seconde valeur indiquant que ladite tête de tunnel B ne reste pas dans la communauté de la tête de tunnel A quand le tunnel est désactivé. Ces six attributs permettent de définir les trois niveaux de confiance 1, 2 et 3 précédemment introduits. Pour le niveau de confiance 1, les six attributs prennent leur première valeur respective. Ce niveau 1 correspond à une tête de tunnel B rejoignant la communauté d'une tête de tunnel A suite à l'établissement d'un tunnel direct entre ces deux têtes de tunnel, et la tête de tunnel A n'adjoint pas à la tête de tunnel B de restriction de confiance. Pour le niveau de confiance 2, le premier attribut prend sa seconde valeur tandis que les autres attributs prennent leur première valeur respective. Ce niveau 2 correspond à une tête de tunnel B rejoignant la communauté d'une tête de tunnel A suite à l'établissement d'un tunnel direct entre ces deux têtes de tunnel, mais la tête de tunnel A adjoint à la tête de tunnel B des restrictions de confiance. Pour le niveau de confiance 3, le cinquième attribut prend sa première valeur tandis que les autres attributs prennent leur seconde valeur respective. Ce niveau 3 correspond à une tête de tunnel B rejoignant la communauté d'une tête de tunnel A suite à l'établissement d'un tunnel auxiliaire entre ces deux têtes de tunnel. En prenant l'exemple de la figure la, un tunnel auxiliaire est donc un tunnel établi entre une première tête de tunnel (TEP S) et une tête de tunnel intermédiaire (TEP F), ladite tête de tunnel intermédiaire n'appartenant pas a la communauté de la tête de tunnel (TEP S) mais appartenant à la communauté de la tête de tunnel (TEP D) avec un niveau de confiance égal à 1. Grâce à ce tunnel auxiliaire, un chemin de communication est alors rendu possible entre la première tête de tunnel (TEP S) et une seconde tête de tunnel (TEP D), dans lequel la tête de tunnel intermédiaire (TEP F) a un degré de confiance de niveau 1 avec la seconde tête de tunnel (TEP D). Suite à l'établissement de ce tunnel auxiliaire, la tête de tunnel (TEP S) entre alors dans la communauté de la tête de tunnel (TEP F) avec un niveau de confiance égal à 3, et inversement, la tête de tunnel (TEP F) entre dans la communauté de la tête de tunnel (TEP S) avec un niveau de confiance égal à 3. En relation avec la configuration présentée sur la figure la, nous allons maintenant décrire la notion de communauté pour un ensemble de têtes de tunnel. La tête de tunnel (TEP S) a un tunnel actif avec la tête de tunnel (TEP E) et a précédemment eu des tunnels ouverts avec les têtes de tunnel (TEP G et D), ces tunnels étant à présent désactivés. La communauté Cs de la tête de tunnel (TEP S) contient donc les têtes de tunnel (TEP E, G et D) avec un niveau de confiance égal à 1. La tête de tunnel (TEP E) a un tunnel actif avec les têtes de tunnel (TEP S et F), et a précédemment eu un tunnel actif avec la tête de tunnel (TEP D), ce tunnel étant à présent désactivé. La communauté Ce de la tête de tunnel (TEP E) contient donc les têtes de tunnel (TEP S, F et D) avec un niveau de confiance égal à 1. La tête de tunnel (TEP F) a un tunnel actif avec les têtes de tunnel (TEP E et G), et a précédemment eu un tunnel actif avec la tête de tunnel (TEP D), ce tunnel étant à présent désactivé. La communauté Cf de la tête de tunnel (TEP F) contient donc les têtes de tunnel (TEP E, G et D) avec un niveau de confiance égal à 1. La tête de tunnel (TEP G) a un tunnel actif avec les têtes de tunnel (TEP F et D), et a précédemment eu un tunnel actif avec la tête de tunnel (TEP S), ce tunnel étant à présent désactivé. La communauté Cg de la tête de tunnel (TEP G) contient donc les têtes de tunnel (TEP S, F et D) avec un niveau de confiance égal à 1. Enfin, la tête de tunnel (TEP D) a un tunnel actif avec la tête de tunnel (TEP G) et a eu des tunnels actifs avec les têtes de tunnel (TEP F et S), ces tunnels étant à présent désactivés. La communauté Cd de la tête de tunnel (TEP D) contient donc les têtes de tunnel (TEP S, G et F) avec un niveau de confiance égal à 1. La figure lb illustre, en relation avec la figure la, le mécanisme d'échanges de messages (le type de chaque message est plus amplement décrit par la suite) entre une première tête de tunnel (TEP S), une seconde tête de tunnel (TEP D) et une tête de tunnel intermédiaire (TEP F).
Lorsque qu'une tête de tunnel (par exemple la tête de tunnel (TEP S)) a échoué dans l'établissement d'un tunnel direct avec une autre tête de tunnel (par exemple la tête de tunnel (TEP D)) par manque de ressources de cette dernière, la première tête de tunnel (TEP S) crée et envoie un message de découverte (comprenant les identifiants des têtes de tunnel (TEP S et D)) vers les têtes de tunnel avec lesquelles elle a un tunnel actif. Sur l'exemple de la figure la, la tête de tunnel (TEP S) envoie ce message vers la tête de tunnel (TEP E), ce qui correspond au message msg 1 sur la figure lb. Lorsque la tête de tunnel (TEP E) reçoit ce message msg 1 , la tête de tunnel (TEP E) vérifie, à partir des identifiants contenus dans le message, que les têtes de tunnel (TEP S et D) du message de découverte sont bien listées dans sa propre communauté Ce (ce qui implique que cette tête de tunnel (TEP E) est incluse dans les communautés Cs de la tête de tunnel (TEP S) et Cd de la tête de tunnel (TEP D)). Comme c'est le cas, la tête de tunnel (TEP E) ajoute son identifiant au message de découverte et le transmet vers la tête de tunnel (TEP F) avec laquelle elle a un tunnel actif. Ceci correspond à l'action action 1 et au message msg 2 de la figure lb.
La tête de tunnel (TEP F) reçoit à son tour le message de découverte, mais constate ( action 2 sur la figure lb) que seule la tête de tunnel (TEP D) est dans sa communauté Cf. En théorie, cette impasse devrait bloquer le processus de recherche de chemins passant par cette tête de tunnel (TEP F). Cependant, la tête de tunnel (TEP F) ayant associé un niveau de confiance égal à 1 à la tête de tunnel (TEP D), elle peut, si elle dispose des ressources nécessaires, établir un tunnel auxiliaire avec la tête de tunnel (TEP S), dans le but d'augmenter les chances de succès dans la recherche d'un chemin par relais entre les têtes de tunnel (TEP S et D). Cette tête de tunnel (TEP F) est alors qualifiée de tête de tunnel impasse . Sur détection de cette impasse, la tête de tunnel (TEP F) renvoie alors vers la tête de tunnel (TEP S) un message de détection d'impasse signifiant à la tête de tunnel (TEP S) la possibilité de création d'un tunnel, dit tunnel auxiliaire, entre la tête de tunnel (TEP S) et la tête de tunnel (TEP F) (action 2, messages msg 3 et msg 4 de la figure lb). La tête de tunnel (TEP S), sur réception du message msg 4 , et si aucun autre chemin par relais n'a pu être créé, établit avec la tête de tunnel (TEP F) un tunnel auxiliaire (action 3 et échange de message msg 5 sur la figure lb). Une fois ce tunnel auxiliaire établi (représenté par un trait pointillé reliant la tête de tunnel (TEP S) et la tête de tunnel (TEP F) sur la figure la), la tête de tunnel (TEP S) entre (action 5) dans la communauté Cf de la tête de tunnel (TEP F) avec un niveau de confiance égal à 3 et la tête de tunnel (TEP F) entre (action 4) dans la communauté Cs de la tête de tunnel (TEP S) avec un niveau de confiance égal à 3. La tête de tunnel (TEP S) construit alors un message de poursuite de découverte (message msg 6 ) à destination de la tête de tunnel (TEP D) et transmis vers la tête de tunnel (TEP F) par le tunnel auxiliaire nouvellement créé. Il est à noter que d'autres moyens peuvent être utilisés pour faire parvenir le message de poursuite de découverte à la tête de tunnel (TEP F), et notamment, la tête de tunnel (TEP S) peut utiliser le chemin découvert jusqu'alors entre la tête de tunnel (TEP S) et la tête de tunnel (TEP F). La tête de tunnel (TEP F) ajoute son identifiant à ce message et le transmet (message msg? ) aux autres têtes de tunnel avec lesquelles elle a un tunnel actif. Dans l'exemple de la figure la, la tête de tunnel (TEP F) possède un seul tunnel actif, ce tunnel étant établi avec la tête de tunnel (TEP G). Ce message arrive ensuite sur la tête de tunnel (TEP G). La retransmission du message de poursuite de découverte est identique à celle d'un message de découverte. Ainsi, comme la tête de tunnel (TEP G) appartient aux deux communautés Cs et Cd, aucune impasse n'est détectée. La tête de tunnel (TEP G) retransmet à son tour le message de poursuite de découverte aux autres têtes de tunnel avec lesquelles elle a un tunnel actif (la tête de tunnel (TEP D) dans le cas de la figure la), après y avoir ajouté son propre identifiant (message msg 8 ).
Le message de poursuite de découverte arrive donc jusqu'à la tête de tunnel (TEP D), avec laquelle la tête de tunnel (TEP S) cherche à établir un tunnel. Celle-ci construit et envoie (action 6) alors vers la tête de tunnel (TEP S) un message réponse contenant la liste des identifiant des têtes de tunnel constituant le chemin entre les têtes de tunnel (TEP S et D) (messages msg 9 , msg 10 et msg 11 ). La tête de tunnel (TEP S) peut alors envoyer, vers chaque tête de tunnel constituant le chemin entre les têtes de tunnel (TEP S et D), une requête d'activation de relais pour les trames des LAN auxquels les têtes de tunnel (TEP S et D) sont connectées. Ces requêtes d'activation de relais ne sont pas représentées sur la figure lb). Il est à noter que la requête d'activation de relais peut être envoyée par la tête de tunnel (TEP D) à la place de la tête de tunnel (TEP S), et que la transmission de cette requête peut s'effectuer soit directement entre les têtes de tunnel concernées, soit par l'intermédiaire de tête de tunnel assurant le relais de la requête. L'ensemble des étapes de la figure lb sont plus largement détaillées dans la suite de la description d'un mode de réalisation particulier de l'invention.
La figure 2a illustre l'architecture typique d'un système de communication de type réseau privé virtuel (VPN) permettant l'interconnexion, dans cet exemple, de deux réseaux LAN 103 et 104 à travers un tunnel 100 de niveau 2 supporté par un réseau de communication de type WAN (ou un MAN) 107. Chacun des réseaux LAN 103 et 104 comporte respectivement un équipement d'accès au réseau WAN de type passerelle 105 et 106 ainsi que des équipements de type terminal 108, 109, 110, 111, 112 et 113. Le tunnel 100 est mis en oeuvre par les têtes de tunnel 101 et 102 respectivement connectées au réseau LAN 103 et au réseau LAN 104. La tête de tunnel 101 accède au réseau global 107 via la passerelle 105 qui peut comprendre un pare-feu. La tête de tunnel 102 accède au réseau global 107 via la passerelle 106 qui peut comprendre un pare-feu. Une fois le tunnel 100 établi, les équipements 108, 109 et 110 connectés au réseau LAN A 103 peuvent communiquer avec les équipements 111, 112, et 113 connectés au réseau LAN B 104. Par exemple, le client local 108 connecté au réseau LAN A 103 peut communiquer avec le serveur local 113 connecté au réseau LAN B 104. Il est à noter qu'une tête de tunnel peut être intégrée dans un équipement audiovisuel fixe comme un téléviseur numérique ou un équipement audiovisuel mobile comme un caméscope. 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. La figure 2b représente une pile de protocole pour une tête de tunnel utilisée pour décrire le cheminement d'une trame Ethernet issue d'un des équipements 108, 109 du réseau LAN 103 et qui va entrer dans un tunnel 100. Pour ce faire, un modèle en couche est utilisé pour décrire 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écessaire 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 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 une couche de pont 123 ( bridge en anglais) 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). Sur le pont sont attachées une interface Ethernet 121 et au moins une interface virtuelle 124 simulant un contrôleur Ethernet. Une interface virtuelle 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 extraction d'une trame. C'est encore au sein de l'application 114 que sont implémentés les algorithmes mettant en oeuvre la présente invention. Les trames reçues de l'interface virtuelle 124, après traitement par l'application 114, sont remises sous la forme d'un paquet à travers une interface applicative 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 un paquet tunnel adapté au transport dans le tunnel, celui-ci est passé à la couche réseau 120. Il est à noter que le protocole ICMP fait partie intégrante de cette couche protocolaire qui en outre peut réaliser des opérations de fragmentation et réassemblage. Le paquet IP ainsi formé avec le paquet tunnel peut ensuite être transmit 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 le cheminement inverse à celui présenté ci-dessus.
La figure 3 illustre un algorithme mettant en oeuvre les différentes étapes de la présente invention. Suite à la décision par un utilisateur ou une application d'établir un chemin de communication entre une première tête de tunnel (TEP S) et une seconde tête de tunnel (TEP D) (étape 200), un tunnel direct tente de s'établir de façon directe entre les têtes de tunnel (TEP S et D) (étape 201). Cette étape 201 est détaillée plus en détail par la suite en relation avec la figure 4. En cas de succès pour la création de ce tunnel direct (étape 202), des tables de communautés sont misent à jour au cours d'une étape 203. Cette étape 203 est détaillée plus en détail par la suite en relation avec les figures 6a à 6e.
En cas de non succès pour la création de ce tunnel direct (étape 202), les étapes 204, 205 et 211 permettent de vérifier si l'échec de la création de ce tunnel direct est dû à un manque de ressources au niveau de la tête de tunnel (TEP S) et/ou à un manque de ressources au niveau de la tête de tunnel (TEP D). Si l'échec de la création de ce tunnel direct est dû à un manque de ressources au niveau de la tête de tunnel (TEP S) mais pas au niveau de la tête de tunnel (TEP D), une requête est envoyée vers la tête de tunnel (TEP D) dans une étape 212 pour lui demander de dérouler un algorithme de recherche de chemin par relais selon la présente invention (et plus amplement décrit par la suite). Cette tête de tunnel (TEP D) a en effet les ressources nécessaires à l'établissement d'un tunnel auxiliaire si besoin.
Si l'échec de la création de ce tunnel direct est dû à un manque de ressources au niveau de la tête de tunnel (TEP S) et au niveau de la tête de tunnel (TEP D), c'est l'échec de la demande d'ouverture (ou d'activation) de chemin par relais (étape 209).
Si les ressources nécessaires à l'établissement d'un tunnel sont présentes au niveau de la tête de tunnel (TEP S) et au niveau de la tête de tunnel (TEP D), le tunnel n'a pu être établi pour une raison autre qu'un manque de ressource. Dans ce cas, une recherche de chemin par relais ne saurait résoudre le problème. C'est alors l'échec de la demande d'ouverture (ou d'activation) de chemin par relais (étape 210). Si l'échec de la création de ce tunnel direct est dû à un manque de ressources au niveau de la tête de tunnel (TEP D) mais pas au niveau de la tête de tunnel (TEP S), une requête est envoyée dans une étape 206 vers la tête de tunnel (TEP S) pour lui demander de dérouler (dans une étape 207) un algorithme de recherche de chemin par relais (cet algorithme est plus amplement détaillé en relation avec la figure 7). Cette tête de tunnel (TEP S) a en effet les ressources nécessaires à l'établissement d'un tunnel auxiliaire si besoin. Si aucun chemin par relais n'est détecté lors de l'étape 207, alors c'est l'échec de la demande d'ouverture (ou d'activation) de chemin par relais (étape 209).
Si un chemin par relais est détecté lors de l'étape 207, une étape 208 (détaillée en relation avec la figure 11) permet d'établir une demande d'activation des fonctions relais de chaque tête de tunnel nécessaires à l'établissement du chemin par relais déterminé par l'algorithme. Les tables de communautés sont alors également mises à jour dans l'étape 203.
La figure 4 illustre un chronogramme des différentes étapes lors de l'établissement d'un tunnel direct entre une tête de tunnel et une autre tête de tunnel. Dans le cadre de l'invention, la procédure d'établissement d'un tunnel entre une tête de tunnel (TEP A) et une autre tête de tunnel (TEP B) commence par une demande d'activation de tunnel, faisant suite à une requête de la part d'un utilisateur ou d'une application sur l'une des têtes de tunnel, par exemple la tête de tunnel A (étape 300). Cette demande contient le niveau de confiance accordé à la tête de tunnel B. Cette tête de tunnel A construit alors une requête d'activation de tunnel (étape 301) puis l'envoie à la tête de tunnel B (étape 301). Cette requête est reçue par la tête de tunnel B dans une étape 308. La tête de tunnel B confirme alors dans une étape 309 (avec son utilisateur ou une application) que cette activation de tunnel est bien autorisée. Cette tête de tunnel B reçoit en retour le niveau de confiance accordé à la tête de tunnel A pour ce tunnel.
Dans un autre mode de réalisation, cette autorisation peut être automatisée, par exemple par le biais de variables de configuration dans l'application. De même, le niveau de confiance accordé à l'autre tête de tunnel peut être prédéfini. Ensuite, au cours d'étapes 302 et 310, les deux têtes de tunnel A et B négocient entre elles les paramètres du tunnel: protocole de communication utilisé, type de chiffrement,... Puis, l'établissement proprement dit du tunnel s'effectue de façon classique lors d'étapes 303 et 311. Si cet établissement de tunnel direct échoue (étapes 304 ou 312), le processus se poursuit à l'étape 204 de la figure 3. En cas de succès, la tête de tunnel B envoie à la tête de tunnel A, lors d'une étape 313, son adresse MAC ainsi que l'identifiant le plus élevé des tunnels actifs qu'elle gère. Les adresses MAC des têtes de tunnel sont utilisées comme identifiants de têtes de tunnel.
Lors d'une étape 305, la tête de tunnel A réceptionne des informations en provenance de la tête de tunnel B. La tête de tunnel A détermine alors au cours d'une étape 306 un identifiant tunnel id du tunnel nouvellement créé. Cet identifiant est égal au plus grand des identifiants des tunnels actifs sur la tête de tunnel A et sur la tête de tunnel B incrémenté de 1. Cet identifiant tunnel id est ensuite renvoyé à la tête de tunnel B lors d'une étape 307, avec l'adresse MAC de la tête de tunnel A. Lors d'une étape 314, la tête de tunnel B reçoit ces deux informations. Ces informations seront notamment utilisées pour la mise à jour des tables de communautés décrites en relation avec les figures 6a à 6e.
La figure 5 illustre un chronogramme des différentes étapes lors de l'établissement d'un tunnel auxiliaire entre une tête de tunnel et une autre tête de tunnel. La procédure d'établissement d'un tunnel auxiliaire entre une tête de tunnel (TEP A) et une autre tête de tunnel (TEP B) débute dans une étape 400 par une demande de création d'un tunnel auxiliaire par une tête de tunnel ayant reçue un message de notification d'impasse, par exemple la tête de tunnel A. Ceci déclenche au cours d'étapes 401 et 408 une négociation entre les deux têtes de tunnel A et B pour s'accorder sur les paramètres du tunnel. Par exemple, afin de savoir quelle tête de tunnel sera cliente ou serveur, le type de protocole de communication utilisé, le type de chiffrement,... Puis se déroule l'établissement proprement dit du tunnel auxiliaire au cours des étapes 402 et 409.
Si cet établissement de tunnel échoue lors d'étapes 403 et 410, le processus s'arrête. En cas de succès lors des étapes 403 et 410, les deux têtes de tunnel A et B s'accordent mutuellement un niveau de confiance de 3 au cours d'étapes 404 et 411. Puis la tête de tunnel B envoie à la tête de tunnel A, lors d'une étape 412, son adresse MAC ainsi que l'identifiant le plus élevé des tunnels actifs qu'elle gère. La tête de tunnel A reçoit ces informations lors d'une étape 405. La tête de tunnel A détermine alors, au cours d'une étape 406, un identifiant tunnel id du tunnel nouvellement créé. Cet identifiant est égal au plus grand des identifiants des tunnels ouverts sur la tête de tunnel A et sur la tête de tunnel B incrémenté de 1. Cet identifiant tunnel id est ensuite renvoyé à la tête de tunnel B, avec l'adresse MAC de la tête de tunnel A au cours d'une étape 407. La tête de tunnel B reçoit ces informations au cours d'une étape 413. Ces informations seront notamment utilisées pour la mise à jour des tables de communautés décrites en relation avec les figures 6a à 6e.
La figure 6a illustre une table de communauté propre à chaque tête de tunnel et contenant des informations sur les membres de sa communauté. La table contient notamment une entrée par tête de tunnel membre de la communauté, chaque entrée contenant les champs suivant : - un champ TEP id 500 contenant l'identifiant (l'adresse MAC) de la tête de tunnel correspondante ; - un champ tunnel id 501 contenant l'identifiant du tunnel par lequel est atteignable la tête de tunnel identifiée par le champ TEP id 500. Si la tête de tunnel est atteignable au moyen d'un chemin par relais, ce champ désigne le tunnel menant au prochain relais. Si aucun tunnel direct ni aucun chemin par relais n'est actif vers cette tête de tunnel, ce champ vaut vide ; - un champ chemin direct 502. C'est un booléen, valant vrai Si un tunnel est actif avec la tête de tunnel identifiée par le champ TEP id 500, faux sinon ; - un champ confiance 503, contenant le niveau de confiance accordé à la tête de tunnel identifiée par le champ TEP id 500 ; - un champ tun_id decouv_impasse 504. Dans le cas où un tunnel auxiliaire est établi avec la tête de tunnel identifiée par le champ TEP id 500, ce champ contient l'identifiant du tunnel par lequel est arrivé le message de découverte (ou de poursuite de découverte) qui a conduit à la découverte d'impasse et à l'établissement du tunnel auxiliaire. Ce champ sera utilisé au cours de l'étape 704 de la figure 8 décrite par la suite. La figure 6b illustre un chronogramme des différentes étapes de mise à jour de la table de communauté suite à l'activation (ou l'établissement) d'un tunnel direct entre deux têtes de tunnel. Tout d'abord, une nouvelle entrée est créée au cours d'une étape 505, si la table ne contient aucune entrée correspondant à la tête de tunnel avec laquelle le tunnel a été établi, dénommée tête de tunnel distante ; sinon c'est l'entrée déjà présente dans la table qui sera mise à jour.
Dans une étape 506, cet identifiant est ensuite inséré dans le champ TEP id 500. L'identifiant du tunnel créé est inséré dans le champ tunnel id dans une étape 507. Le champ 502 chemin direct est alors mis à vrai (étape 508) et le niveau de confiance correspondant à la tête de tunnel distante est inséré dans le champ 503 confiance (étape 509). Enfin, dans le cas où le champ confiance prend la valeur 3 (c'est-à-dire lors de l'établissement d'un tunnel auxiliaire), le champ tun_id decouv_impasse reçoit l'identifiant du tunnel par lequel est arrivé le message de découverte (ou de poursuite de découverte) qui a conduit à la découverte d'impasse et à l'établissement du tunnel auxiliaire (étape 512). Sinon ce champ reste vide. La figure 6c illustre un chronogramme des étapes de mise à jour de la table de communauté suite à la désactivation d'un tunnel (autre qu'tunnel auxiliaire) ou d'un chemin par relais avec une tête de tunnel distante. Lors d'une étape 513, la table de communauté est parcourue afin de localiser l'entrée correspondante à la tête de tunnel distante. Le champ 501 tunnel id prend alors la valeur vide lors d'une étape 514, et le booléen chemin direct est mis à la valeur faux lors d'une étape 515.
La figure 6d illustre un chronogramme des étapes de mise à jour de la table de communauté suite à la désactivation d'un tunnel auxiliaire avec une tête de tunnel distante. Lors d'une étape 516, la table de communauté est parcourue afin de localiser l'entrée correspondant à la tête de tunnel distante. Dans une étape 517, cette entrée est effacée de la table de communauté. La figure 6e illustre un chronogramme des étapes de mise à jour de la table de communauté d'une tête de tunnel, suite à l'activation d'un chemin par relais entre cette tête de tunnel et une tête de tunnel distante. La tête de tunnel, lors d'une étape 518, parcourt la table de communauté afin de localiser l'entrée correspondant à la tête de tunnel distante. L'identifiant du tunnel vers le premier relais en direction de la tête de tunnel distante sur le chemin par relais est ensuite inséré dans le champ 501 tunnel id lors d'une étape 519, et le booléen chemin direct est mis à la valeur faux (étape 520). La figure 7 illustre un chronogramme des différentes étapes réalisées par la première tête de tunnel (TEP S) lors de la recherche de chemins par relais entre la première tête de tunnel (TEP S) et la seconde tête de tunnel (TEP D). Ces différentes étapes correspondent à l'étape 206 de la figure 3.
Au cours d'une étape 600, la première tête de tunnel (TEP S) crée et envoie un message de découverte à destination de la seconde tête de tunnel (TEP D). La tête de tunnel (TEP S) émet ce message via l'ensemble des tunnels qui lui sont connectés. Le formatage de ce message est décrit plus en détail en relation avec la figure 10. Dans une étape 601, les réponses sont attendues. Des réponses ne parviennent à la tête de tunnel (TEP S) uniquement si au moins un chemin par relais est découvert ou au moins une tête de tunnel d'impasse est détectée. Sinon aucune réponse ne parvient à la tête de tunnel (TEP S). L'étape 601 doit donc se terminer sur déclenchement d'une temporisation (ou timer en anglais). A échéance de cette temporisation, lors d'une étape 602, si au moins une réponse correspond à un chemin par relais, l'un d'eux est choisi et le processus se poursuit par l'activation des relais décrite plus en détail sur la figure 11. Sinon, et si une ou plusieurs réponses font état de la détection d'une impasse (étape 603), l'identifiant de la tête de tunnel impasse (TEP B) est extrait du message de réponse (étape 604).
Dans une étape 605, un tunnel auxiliaire est ensuite établi entre la tête de tunnel (TEP S) et la tête de tunnel (TEP B) (l'adresse IP publique de la tête de tunnel (TEP B) nécessaire à l'activation du tunnel est connue grâce aux informations comprises dans l'entête IP du message de détection d'impasse). Si l'activation du tunnel auxiliaire échoue (étape 606), et qu'au moins une autre tête de tunnel d'impasse a été détectée (étape 609), l'étape 604 est de nouveau répétée.
Si l'activation du tunnel auxiliaire échoue (étape 606), mais qu'aucune autre tête de tunnel d'impasse n'est détectée (étape 609), alors c'est l'échec (étape 610) du fait qu'aucun chemin ne peut être actif entre la tête de tunnel (TEP S) et la tête de tunnel (TEP D). Si l'activation du tunnel auxiliaire réussit, les communautés de la tête de tunnel (TEP S) et de la tête de tunnel (TEP B) sont alors mises à jour dans une étape 607. La tête de tunnel (TEP S) crée ensuite un message de poursuite de découverte à destination de la tête de tunnel (TEP D). Dans une étape 608, ce message de poursuite de découverte est émis par la tête de tunnel (TEP S) sur le tunnel auxiliaire (et uniquement sur ce dernier). Le formatage de ce message est identique à celui du message de découverte décrit sur la figure 10. La seule différence entre un message de découverte et un message de poursuite de découverte réside en ce que la tête de tunnel (TEP S) émet le message de découverte sur l'ensemble des tunnels qui lui sont connectés sauf les tunnels auxiliaires, alors que le message de poursuite de découverte est émis uniquement sur le tunnel auxiliaire nouvellement créé. Le traitement des réponses reçues est identique à celui décrit ci-dessus. La tête de tunnel (TEP S) se met ensuite en attente de réponses (étape 601). Il est noter que le processus précédemment décrit est itératif. En effet, si une nouvelle tête de tunnel impasse (TEP B2) est découverte par ce message de poursuite de découverte , un nouveau tunnel auxiliaire est alors établi entre la tête de tunnel (TEP S) et la tête de tunnel (TEP B2). Un nouveau message de poursuite de découverte est également émis sur ce nouveau tunnel auxiliaire (et uniquement sur ce dernier). Dans un autre mode de réalisation, le premier tunnel auxiliaire est désactivé (suite à une requête de désactivation), si un autre tunnel auxiliaire est établi entre la tête de tunnel (TEP S) et la nouvelle tête de tunnel intermédiaire d'impasse. La figure 8 illustre un chronogramme des différentes étapes réalisées par une tête de tunnel intermédiaire (TEP I) lors de la recherche de chemins par relais entre la première tête de tunnel (TEP S) et la seconde tête de tunnel (TEP D). Ces différentes étapes correspondent à l'étape 206 de la figure 3. Sur réception (étape 700) par la tête de tunnel (TEP I), comme par exemple la tête de tunnel (TEP F) de la figure la, d'un message de découverte (ou de poursuite de découverte) originaire d'une première tête de tunnel (TEP S) et à destination d'une seconde tête de tunnel (TEP D), la tête de tunnel (TEP I) effectue une première vérification dans une étape 701 : - si la tête de tunnel (TEP S) appartient bien à sa communauté Ci avec un niveau de confiance de 1 ou de 2; ou bien - si la tête de tunnel (TEP S) appartient bien à sa communauté Ci avec un niveau de confiance égal à 3 et si la tête de tunnel (TEP I) est la première tête de tunnel intermédiaire (c'est-à-dire si le message de poursuite de découverte est directement consécutif à l'activation d'un tunnel auxiliaire entre la tête de tunnel (TEP S) et la tête de tunnel (TEP I)).
Si une de ces deux conditions est vérifiée, la tête de tunnel (TEP I) vérifie ensuite dans une étape 702 si la tête de tunnel (TEP D) appartient également à sa communauté Ci. Si ce n'est pas le cas, la tête de tunnel (TEP I) ne peut relayer de trames entre la tête de tunnel (TEP S) et la tête de tunnel (TEP D). Le traitement s'arrête alors (échec de la recherche d'un chemin par relais) dans une étape 705. Si c'est le cas, la tête de tunnel (TEP I) vérifie dans une étape 713 si elle est la première tête de tunnel intermédiaire sur le chemin du message de découverte (ou de poursuite de découverte). Si l'étape 713 est vérifiée, la tête de tunnel (TEP I) insère alors l'adresse IP publique de la tête de tunnel (TEP S) dans le message au cours d'une étape 714. En effet, étant la première tête de tunnel intermédiaire, la tête de tunnel (TEP I) possède un tunnel établi avec la tête de tunnel (TEP S) et connaît donc l'adresse IP publique de la tête de tunnel (TEP S). Puis le processus continue dans une étape 703 avec insertion de l'identifiant de la tête de tunnel (TEP I) dans le message de découverte (ou de poursuite de découverte). Si l'étape 713 n'est pas vérifiée, l'étape 703 est directement exécutée.
Puis dans une étape 704, le message de découverte (ou de poursuite de découverte) est transmis sur les tunnels qui sont connectés à la tête de tunnel (TEP I) (sauf celui par lequel le message est arrivé ainsi que les tunnels auxiliaires éventuels connectés à la tête de tunnel (TEP I)).
Un cas particulier est à noter en ce qui concerne les messages de poursuite de découverte. Un message de poursuite de découverte émis par une tête de tunnel avec laquelle la tête de tunnel recevant le message à un niveau de confiance de 3 (c'est-à-dire un message de poursuite de découverte directement consécutif à l'établissement d'un tunnel auxiliaire entre ces deux têtes de tunnel) ne doit pas être envoyé sur le tunnel par lequel est arrivé le message de découverte (ou de poursuite de découverte) qui a conduit à la découverte d'impasse et à l'activation du tunnel auxiliaire. Ceci afin d'éviter un bouclage du processus de recherche des chemins (retour en arrière dans la progression de la découverte de chemins par relais). Pour réaliser ce filtrage, le champ 504 Tun_id decouv_impasse de l'entrée de la table de communauté correspondant à la tête de tunnel émettrice du message de poursuite de découverte est utilisé pour connaître l'identifiant du tunnel sur lequel le message de poursuite de découverte ne doit pas être envoyé. Dans le cas où la tête de tunnel (TEP S) n'appartient pas à la communauté Ci avec un niveau de confiance 1, 2 ou 3, la table de communauté est parcourue dans une étape 706 afin de trouver le niveau de confiance que la tête de tunnel (TEP I) accorde à la tête de tunnel (TEP D). Si ce niveau de confiance est différent de 1 ou que la tête de tunnel (TEP D) n'appartient pas à la communauté Ci (étape 707), la tête de tunnel (TEP I) ne peut pas relayer de trames entre les têtes de tunnel (TEP S et D). Le traitement s'arrête alors (échec de la recherche d'un chemin par relais) par l'étape 705. Sinon, si le niveau de confiance est égal à 1, un message de détection d'impasse est envoyé vers la tête de tunnel (TEP S) (étape 708). Sur réception de ce message, la tête de tunnel (TEP S) peut ou non décider d'établir un tunnel auxiliaire avec la tête de tunnel (TEP I). Une temporisation est alors démarrée à l'étape 709 dans l'attende d'une requête d'activation de tunnel auxiliaire. Si cette requête n'arrive pas avant l'échéance de la temporisation, l'étape 709 se termine. Le traitement s'arrête alors par l'étape 705.
Sinon, le tunnel auxiliaire est établi entre la tête de tunnel (TEP S) et la tête de tunnel (TEP I) au cours d'une étape 710 (l'adresse IP publique de la tête de tunnel (TEP S) nécessaire à l'activation du tunnel est connue grâce au champ IP source du message de découverte plus amplement détaillé par la suite).
Si l'activation du tunnel auxiliaire échoue (étape 711), le traitement s'arrête alors par l'étape 705. Sinon, la table des communautés est mise à jour au cours de l'étape 712. Un second mode de réalisation (non décrit) peut par exemple proposer des étapes supplémentaires autorisant de nouvelles tentatives en cas d'échec à l'activation du tunnel auxiliaire. La figure 9 illustre les étapes mises en oeuvre par seconde tête de tunnel (TEP D) lors de la recherche de chemins par relais entre la première tête de tunnel (TEP S) et la seconde tête de tunnel (TEP D). Sur réception (étape 800) par la tête de tunnel (TEP D) d'un message de découverte (ou de poursuite de découverte) émis par la tête de tunnel (TEP S), la tête de tunnel (TEP D) construit un message réponse dans une étape 801. La tête de tunnel (TEP D) émet ensuite ce message réponse au travers du réseau et à destination de la tête de tunnel (TEP S). Le formatage de ce message réponse est plus amplement décrit en relation avec la figure 10.
Dans une étape 802, à réception de ce message réponse, la tête de tunnel (TEP S) peut ou non décider d'activer les fonctions relais des têtes de tunnel intermédiaires constituant le chemin par relais de communication précédemment découvert. Une temporisation est donc démarrée à l'étape 802 dans l'attente d'un message de requête d'activation des fonctions relais des têtes de tunnel intermédiaires.
Si cette requête n'arrive pas avant l'échéance de cette temporisation, l'étape 802 se termine et le processus s'arrête. Sinon, la table de communauté de la tête de tunnel (TEP D) est mise à jour au cours d'une étape 803. Une réponse au message de requête d'activation de relais est construite dans une étape 804. Puis ce message est envoyé vers la tête de tunnel (TEP S) émettrice du message de requête d'activation de relais. La figure 10 illustre les différents formats de message utilisés.
Les messages de découverte et de poursuite de découverte circulent entre les têtes de tunnel de la même façon que les messages de contrôle utilisés par les têtes de tunnel pour communiquer entre elles pour l'administration du tunnel. Ces messages sont composés : - d'une entête 900 correspondant au protocole utilisé pour les messages d'administration entre têtes de tunnel (par exemple le protocole TCP, en utilisant un numéro de port dédié aux messages d'administration de tunnel, mais d'autres solutions existent dans l'art antérieur) ; - d'un champ source 901 contenant l'identifiant de la tête de tunnel à l'origine de la recherche de chemin par relais (première tête de tunnel (TEP S)) ; - d'un champ destination 902 contenant l'identifiant de l'autre tête de tunnel (seconde tête de tunnel (TEP D)) ; - d'un champ type de message 903 affecté de la valeur 1 pour les messages de découverte et de la valeur de 2 pour les messages de poursuite de découverte ; - un champ IP source 904 contenant l'adresse IP publique de la tête de tunnel émettrice du message (cette adresse sera notamment utilisée pour l'envoi des messages de détection d'impasse, de réponse au message de découverte et lors de l'établissement des tunnels auxiliaires) ; - un champ nombre de relais 905 contenant le nombre de têtes de tunnel ayant inséré leur identifiant au message ; - un champ 906 contenant les identifiants des têtes de tunnel déjà traversées par le message. Dans un message, la première tête de tunnel (TEP S) est qualifiée de source par le champ 901 car celle-ci est à l'initiative de la recherche de chemin de relais entre la première (TEP S) et la seconde (TEP D) tête de tunnel, par émission du message de découverte. La seconde tête de tunnel (TEP D) est alors qualifiée de destination . I1 est cependant à noter que lorsqu'un chemin, direct ou par relais, est établi entre deux têtes de tunnel, la communication est bidirectionnelle, et il n'y a donc pas de tête de tunnel source et de tête de tunnel destination uniques pour un tunnel donné.
Les messages de détection d'impasse sont transmis sur le réseau internet au niveau protocolaire IP. Ils sont donc composés d'une entête 907 correspondant au protocole IP, d'un champ source 908 contenant l'identifiant de la première tête de tunnel (TEP S), d'un champ destination 909 contenant l'identifiant de la seconde tête de tunnel (TEP D), d'un champ type de message 910 contenant la valeur 3, et d'un champ impasse contenant l'identifiant de la tête de tunnel impasse à l'origine du message.
Les messages de réponse aux messages de découverte sont transmis sur le réseau internet au niveau protocolaire IP. Ils sont donc composés d'une entête 912 correspondant au protocole IP, d'un champ source 913 contenant l'identifiant de la première tête de tunnel (TEP S), d'un champ destination 914 contenant l'identifiant de la seconde tête de tunnel (TEP D), d'un champ type de message 915 contenant la valeur 4, un champ nombre de relais 916 contenant le nombre de têtes de tunnel intermédiaires constituant le chemin par relais entre la première (TEP S) et la seconde (TEP D) tête de tunnel, et un champ 917 contenant les identifiants ces têtes de tunnel intermédiaires. Les messages de requête d'activation de relais circulent entre les têtes de tunnel de la même façon que les messages de contrôle utilisés par les têtes de tunnel pour communiquer entre elles lors de l'établissement et de l'administration du tunnel. Ces messages sont donc composés : d'une entête 918 correspondant au protocole utilisé pour les messages d'administration entre têtes de tunnel (par exemple le protocole TCP, en utilisant un numéro de port dédié aux messages d'administration de tunnel, mais d'autres solutions existent dans l'art antérieur) ; d'un champ source 919 contenant l'identifiant de la tête de tunnel à l'origine de la recherche de chemin par relais (première tête de tunnel (TEP S)) ; d'un champ destination 920 contenant l'identifiant de l'autre tête de tunnel (seconde tête de tunnel (TEP D)) ; d'un champ type de message 921 contenant la valeur 4 ; d'un champ ID du chemin 922 contenant l'identifiant du chemin par relais ; un champ nombre de relais 923 contenant le nombre de têtes de tunnel intermédiaires constituant le chemin par relais entre la première (TEP S) et la seconde (TEP D) tête de tunnel ; un champ 924 contenant les identifiants de ces têtes de tunnel intermédiaires. 25 30 La figure lla illustre un chronogramme des différentes étapes effectuées, par la première tête de tunnel (TEP S), lors de l'activation des relais une fois un chemin par relais déterminé. Lorsqu'un chemin par relais est déterminé, puis sélectionné par la tête de tunnel (TEP S), les têtes de tunnel intermédiaires qui le composent doivent être informées qu'elles doivent rendre le chemin actif et relayer les trames entre les première (TEP S) et seconde (TEP D) têtes de tunnel, situées aux extrémités du chemin par relais. Pour ce faire, la tête de tunnel (TEP S) émet alors à destination de la seconde tête de tunnel (TEP D) une requête d'activation de relais (étapes 1000) à l'aide des informations contenues dans la réponse au message de découverte reçue de la seconde tête de tunnel (TEP D). Cette une requête d'activation de relais est interceptée par chaque tête de tunnel intermédiaire sur le chemin par relais entre la première (TEP S) et la seconde (TEP D) tête de tunnel. La valeur 922 ID du chemin d'un message de requête d'activation de relais (figure 10) est un entier incrémenté à chaque nouveau chemin par relais sélectionné par la première tête de tunnel (TEP S). Il permet d'identifier les différents chemins dont la première tête de tunnel (TEP S) est à l'initiative. Ce message comprend aussi la liste des têtes de tunnel intermédiaires constituant le chemin par relais. Ce message est envoyé par la première tête de tunnel (TEP S) vers la première tête de tunnel intermédiaire (étape 1001) sur le chemin par relais dans la direction de la seconde tête de tunnel (TEP D). Puis une réponse est attendue dans une étape 1002. Sur réception de cette réponse, la table des chemins par relais présente sur la tête de tunnel (TEP S) est mise à jour dans une étape 1003. La figure llb illustre l'activation d'une fonction relais effectuée par une tête de tunnel intermédiaire (TEP I) du chemin de relais déterminé entre la première (TEP S) et la seconde (TEP D) tête de tunnel. Lorsque le message de requête d'activation de relais est reçu, dans une étape 1004, par une tête de tunnel intermédiaire comprise dans le chemin par relais précédemment déterminé, la table de relais locale à cette tête de tunnel intermédiaire (TEP I) est mise à jour dans une étape 1005 à partir des informations contenues dans le message. En effet, le message contient les identifiants des têtes de tunnel qui encadrent la tête de tunnel intermédiaire (TEP I) dans le chemin par relais, et la table de communauté contient les identifiants des tunnels correspondants). Si la tête de tunnel intermédiaire (TEP I) est la dernière tête de tunnel intermédiaire avant la seconde tête de tunnel (TEP D) (c'est-à-dire que la tête de tunnel intermédiaire (TEP I) a un tunnel actif avec la seconde tête de tunnel (TEP D)) alors la requête d'activation de relais est transmise dans une étape 1007 à la seconde tête de tunnel (TEP D), afin de confirmer l'activation des différents relais. Sinon, dans une étape 1008, la requête d'activation de relais est transmise à la tête de tunnel intermédiaire suivante sur le chemin entre la première tête de tunnel (TEP S) et la seconde tête de tunnel (TEP D). La figure 12a illustre une table des relais présente sur chaque tête de tunnel. Cette table des relais permet de savoir si une trame reçue d'une tête de tunnel par le biais d'un tunnel doit être relayée vers une autre tête de tunnel ou non. Chaque entrée contient un champ TEP_src 1100 contenant l'identifiant de la tête de tunnel d'origine de l'établissement du chemin, un champ TEP_dest 1101 contenant l'identifiant de la tête de tunnel située à l'autre extrémité du chemin, un champ tunnel arrivée 1102 contenant l'identifiant du tunnel par lequel les trames originaires de l'une des têtes de tunnel arrivent (et celles originaires de l'autre tête de tunnel repartent), un champ tunnel départ 1103 contenant l'identifiant du tunnel correspondant pour l'autre direction sur le chemin, et un champ chemin ID 1104 contenant un identifiant du chemin concerné (identifiant relatif à la tête de tunnel à l'origine de l'établissement du tunnel). La figure 12b illustre une table des chemins présente sur chaque tête de tunnel. Cette table liste les informations sur les chemins par relais ouverts par la tête de tunnel gérant la table. Chaque entrée contient un champ chemin ID 1105 contenant un identifiant du chemin concerné (identifiant relatif la tête de tunnel gérant la table), un champ destination 1107 contenant l'identifiant de la tête de tunnel à l'autre extrémité du chemin par relais, un champ nombre de relais 1108 contenant le nombre de têtes de tunnel intermédiaires constituant le chemin par relais et un champ 1109 contenant les identifiants de ces têtes de tunnel intermédiaires. Lorsqu'un chemin par relais est établi entre la première tête de tunnel (TEP S) et la seconde tête de tunnel (TEP D), une trame émise par un équipement connecté au réseau LAN S auquel est connectée la première tête de tunnel (TEP S) est alors relayée, via le chemin par relais, jusqu'au réseau LAN D auquel est connectée la seconde tête de tunnel (TEP D). Dans un mode de réalisation particulier, cette trame doit aussi être émise par la tête de tunnel intermédiaire (TEP Il) sur le réseau LAN Il auquel elle est connectée, la tête de tunnel intermédiaire (TEP Il) étant la première tête de tunnel sur le chemin par relais (depuis la première tête de tunnel (TEP S), dans la direction de la seconde tête de tunnel (TEP D)). En effet, un tunnel direct existait entre les réseaux LAN S et Il avant l'activation du chemin par relais entre la première (TEP S) et la seconde (TEP D) tête de tunnel, et les trames émises par des dispositifs de l'un des réseaux LAN directement interconnectés par un tunnel doivent être émises sur l'autre réseau LAN. De même, lorsqu'un chemin par relais est établi entre la première tête de tunnel (TEP S) et la seconde tête de tunnel (TEP D), une trame émise par un équipement connecté au réseau LAN D auquel est connectée la seconde tête de tunnel (TEP D) est alors relayée, via le chemin par relais, jusqu'au réseau LAN S auquel est connectée la première tête de tunnel (TEP S). Dans le mode de réalisation particulier mentionné ci-dessus, cette trame doit aussi être émise par la tête de tunnel intermédiaire (TEP I2) sur le réseau LAN I2 auquel elle est connectée, la tête de tunnel intermédiaire (TEP I2) étant la première tête de tunnel sur le chemin par relais (depuis la seconde tête de tunnel (TEP D), dans la direction de la première tête de tunnel (TEP S)). En effet, un tunnel direct existait entre les réseaux LAN D et I2 avant l'activation du chemin par relais entre la première (TEP S) et la seconde (TEP D) tête de tunnel, et les trames émises par des dispositifs de l'un des réseaux LAN directement interconnectés par un tunnel doivent être émises sur l'autre réseau LAN. Les figures 13a et 13b présentent une méthode répondant à ces exigences en émettant les trames sur les réseaux LAN auxquels sont reliées, via un tunnel actif, les première (TEP S) et seconde (TEP D) têtes de tunnel, et qui ont, comme tête de tunnel, une tête de tunnel intermédiaire du chemin par relais entre les première (TEP S) et seconde (TEP D) têtes de tunnel. Ces têtes de tunnel intermédiaires étant des têtes de tunnel avec un niveau de confiance suffisant (supérieur à un seuil déterminé), ceci ne pose pas de problèmes.
La figure 13a illustre la transmission d'un datagramme (ou trame) depuis une tête de tunnel (TEP S ou TEP D) située à une extrémité du chemin par relais activé. Lorsqu'une tête de tunnel reçoit une trame en provenance du réseau LAN sur lequel elle est connectée (étape 1200), cette tête de tunnel encapsule (étape 1201) la trame suivant le protocole en service sur le tunnel. En plus des informations classiques du protocole est ajouté un champ dans lequel est inséré l'identifiant de la tête de tunnel. Cette trame encapsulée est ensuite émise (étape 1202) sur l'ensemble des tunnels connectés à la tête de tunnel. La figure 13b illustre la réception (étape 1203), par une tête de tunnel du chemin par relais activé, d'une trame encapsulée depuis l'un des tunnels qui lui sont connectés. Cette trame est ensuite émise sur le réseau LAN connecté à la tête de tunnel après avoir été dés-encapsulée (étape 1204), si le réseau LAN est destinataire de la trame (cas d'une tête de tunnel située à une extrémité du chemin par relais activé) ou s'il existe un tunnel actif entre la tête de tunnel et une des têtes de tunnel situées aux extrémités du chemin par relais activé (cas d'une tête de tunnel) intermédiaire. La table des relais est ensuite parcourue dans une étape 1205 afin de vérifier si l'identifiant de la tête de tunnel émettrice (TEP S dans ce cas) de la trame est présent dans le champ TEP_src 1100 contenant l'identifiant de la tête de tunnel à l'origine de l'établissement du chemin par relais ou dans le champ TEP_dest 1101 contenant l'identifiant de la tête de tunnel située à l'autre extrémité du chemin. Si tel est le cas, la trame encapsulée est relayée sur les tunnels correspondants (étape 1206). La figure 14 illustre une implémentation d'une tête de tunnel générique 1000 du même type que les têtes de tunnel 101 ou 102 décrites sur la figure 2a. Chaque tête de tunnel étant adaptée à mettre en oeuvre le procédé selon un mode de réalisation particulier de l'invention. Cette tête de tunnel générique 1300 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 1300 des données multimédia. Ainsi, la tête de tunnel générique 1300 comporte un bus de communication 1302 auquel sont reliés : - une unité centrale de traitement 1303 (qui est par exemple un microprocesseur référencé CPU) ; - une mémoire morte 1304 référencée ROM (pour Read Only Memory en anglais) ; - une mémoire vive 1306 (mémoire cache référencée RAM pour Random Access memory en anglais), fonctionnant comme une mémoire principale, une zone de travail, etc., de l'unité centrale 1303. La capacité de la RAM 1306 peut être étendue par une RAM optionnelle reliée à un port d'extension (non illustré) ; - un clavier 1310, une souris 1311 et un écran 1308 permettant à un utilisateur d'interagir avec cette implémentation 1300 ; - une interface de communication 1318 reliée à un réseau de communication distribué 1320, par exemple un réseau tel que le réseau LAN 103 de la figure 2a, l'interface étant apte à transmettre et à recevoir des données. La tête de tunnel 1300 comporte également un disque dur 1312 et un lecteur de disquette 1314. Le bus de communication 1302 permet la communication et l'interopérabilité entre les différents dispositifs inclus dans la tête de tunnel générique 1300 ou reliés à cet équipement. De manière plus générale, grâce au bus de communication 1302, l'unité centrale 1303 est susceptible de communiquer des instructions à tout dispositif inclus dans la tête de tunnel générique 1300 directement ou par l'intermédiaire d'un autre dispositif de la tête de tunnel générique 1300. L'unité centrale 1303 est capable, à la mise sous tension de l'appareil de communication, d'exécuter des instructions à partir de la ROM de programme 1304.
Après la mise sous tension, l'unité centrale 1303 est capable d'exécuter des instructions provenant de la mémoire principale 1306 en relation avec une application logicielle après que ces instructions ont été chargées à partir par exemple, de la ROM de programme 1304, du disque dur 1312 ou du lecteur de disquette 1314 associé a une disquette 1316.
Une telle application logicielle, lorsqu'elle est exécutée par l'unité centrale 1303 provoque la réalisation de tout ou partie des étapes des organigrammes illustrés précédemment sur les figures 3, 4, 5, 6b à 6e, 7, 8, 9, lla, llb, 13a et 13b. On notera que l'invention ne se limite pas à une implantation purement matérielle mais qu'elle peut aussi être mise en oeuvre sous la forme d'une séquence d'instructions d'un programme informatique ou toute forme mixant une partie matérielle et une partie logicielle. Dans le cas où l'invention est implantée partiellement ou totalement sous forme logicielle, la séquence d'instructions correspondante pourra être stockée dans un moyen de stockage amovible (tel que par exemple une disquette, un CD-ROM ou un DVD-ROM) ou non, ce moyen de stockage étant lisible partiellement ou totalement par un ordinateur ou un microprocesseur.

Claims (24)

  1. REVENDICATIONS1. Procédé d'établissement d'un chemin de communication entre une première tête de tunnel (TEP S) connectée à un premier sous-réseau et une seconde tête de tunnel (TEP D) connectée à un second sous-réseau par l'intermédiaire d'au moins une tête de tunnel intermédiaire (TEP F) connectée à un sous-réseau intermédiaire, chaque tête de tunnel permettant l'interconnexion du sous-réseau où elle est connectée à au moins un autre sous-réseau au moyen d'au moins un tunnel de communication, à une tête de tunnel donnée étant associée une communauté constituée d'un ensemble de têtes de tunnel, à chaque tête de tunnel d'une communauté étant associé un niveau de confiance de la tête de tunnel donné, ledit procédé étant effectué par une tête de tunnel intermédiaire et étant caractérisé en ce qu'il comprend des étapes consistant à : recevoir (700), en provenance directe ou indirecte de la première tête de tunnel, d'un premier message de découverte de chemin de communication entre la première et la seconde tête de tunnel ; dans le cas où la seconde tête de tunnel appartient à la communauté de ladite tête de tunnel intermédiaire avec un niveau de confiance supérieur ou égal à un seuil prédéterminé et où la première tête de tunnel n'appartient pas à la communauté de ladite tête de tunnel intermédiaire, établir un tunnel auxiliaire (710) entre la première tête de tunnel et ladite tête de tunnel intermédiaire ; - activer le chemin de communication entre les première et seconde têtes de tunnel par utilisation du tunnel auxiliaire établi.
  2. 2. Procédé selon la revendication 1, caractérisé en ce qu'il comprend en outre une étape consistant à : - émettre un deuxième message de découverte de chemin entre les première et seconde têtes de tunnel, ledit message étant émis sur le ou le(s) tunnel(s), autre(s) que le tunnel auxiliaire, pour lesquels la tête de tunnel intermédiaire est une extrémité et par lesquels ledit premier message de découverte de chemin n'est pas arrivé.
  3. 3. Procédé selon la revendication 2, caractérisé en ce que l'étape consistant à activer le chemin de communication est précédée d'une étape consistant à :- émettre (708) un message de détection d'impasse à destination de la première tête de tunnel ; - recevoir, en provenance directe ou indirecte de la première tête de tunnel, un message de poursuite de découverte de chemin de communication entre les première et seconde têtes de tunnel ; - construire ledit deuxième message de découverte de chemin à partir du message de poursuite de découverte reçu.
  4. 4. Procédé selon l'une quelconque des revendications 1 à 3, caractérisé en ce que la communauté associée à une tête de tunnel donnée correspond à un ensemble de têtes de tunnel avec lesquels la tête de tunnel donnée a précédemment établi un tunnel de communication.
  5. 5. Procédé selon l'une quelconque des revendications 1 à 4, caractérisé en ce que ladite étape consistant à établir le tunnel auxiliaire est suivie d'une étape consistant à inclure la première tête de tunnel dans la communauté de ladite tête de tunnel intermédiaire et à affecter à la première tête de tunnel un niveau de confiance inférieur audit seuil prédéterminé.
  6. 6. Procédé selon la revendication 5, caractérisé en ce qu'il comprend en outre des étapes consistant à : - recevoir, en provenance directe ou indirecte de l'une parmi les première et seconde têtes de tunnel, d'une requête de désactivation du tunnel auxiliaire ; - retirer la première tête de tunnel de la communauté de ladite tête de tunnel intermédiaire.
  7. 7. Procédé d'établissement d'un chemin de communication entre une première tête de tunnel (TEP S) connectée à un premier sous-réseau et une seconde tête de tunnel (TEP D) connectée à un second sous-réseau par l'intermédiaire d'au moins une tête de tunnel intermédiaire (TEP F) connectée à un sous-réseau intermédiaire, chaque tête de tunnel permettant l'interconnexion du sous-réseau auquel elle est connectée à au moins un autre sous-réseau au moyen d'au moins un tunnel de communication, à une tête de tunnel donnée étant associée une communauté constituée d'un ensemble de têtes de tunnel, à chaque tête de tunnel d'une communauté étant associé un niveau de confiance de la tête de tunnel donné,ledit procédé étant effectué par ladite première tête de tunnel et étant caractérisé en ce qu'il comprend des étapes consistant à : - émettre un message de découverte de chemin de communication entre la première et la seconde tête de tunnel, ledit message étant émis sur au moins un tunnel actif dont la première tête de tunnel est une extrémité ; - recevoir un premier message de détection d'impasse provenant d'une première tête de tunnel intermédiaire ; - établir un premier tunnel auxiliaire entre la première tête de tunnel et la première tête de tunnel intermédiaire ; - activer le chemin de communication entre les première et seconde têtes de tunnel par utilisation du tunnel auxiliaire établi.
  8. 8. Procédé selon la revendication 7, caractérisé en ce qu'il comprend des étapes consistant à : - recevoir un message de détection d'impasse en provenance de la première tête de tunnel intermédiaire ; - émettre un message de poursuite de découverte de chemin de communication entre les première et seconde têtes de tunnel, ladite poursuite de recherche de chemin devant s'effectuer en prenant en compte le tunnel auxiliaire comme portion dudit chemin et devant reprendre à partir de la première tête de tunnel intermédiaire.
  9. 9. Procédé selon la revendication 8, caractérisé en ce qu'il comprend des étapes consistant à : - désactiver le tunnel auxiliaire, dans le cas où, en réponse audit message de poursuite de recherche de chemin, la première tête de tunnel reçoit un second message de détection d'impasse provenant d'une seconde tête de tunnel intermédiaire ; - établir un second tunnel auxiliaire entre la première tête de tunnel et la seconde tête de tunnel intermédiaire ; - activer le chemin de communication entre les première et seconde têtes de tunnel par utilisation du second tunnel auxiliaire établi. 30
  10. 10. Procédé selon l'une quelconque des revendications 7 à 9, caractérisé en ce que la communauté associée à une tête de tunnel donnée correspond à un ensemble de têtes de tunnel avec lesquels la tête de tunnel donnée a précédemment établi un tunnel de communication.
  11. 11. Procédé selon l'une quelconque des revendications 7 à 10, caractérisé en ce que ladite étape consistant à établir le premier tunnel auxiliaire est suivie d'une étape consistant à inclure la première tête de tunnel intermédiaire dans la communauté de la première tête de tunnel et à affecter à la première tête de tunnel intermédiaire un niveau de confiance inférieur audit seuil prédéterminé.
  12. 12. Procédé selon la revendication 1l, caractérisé en ce qu'il comprend en outre, sur désactivation dudit chemin activé entre la première et la seconde tête de tunnel, une étape consistant à : - désactiver le premier tunnel auxiliaire ; - exclure la première tête de tunnel de la communauté de ladite première tête de tunnel intermédiaire.
  13. 13. 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 à 6 et/ou au moins une des revendications 7 à 12, lorsque ledit programme est exécuté sur un ordinateur.
  14. 14. Moyen de stockage lisible par ordinateur, éventuellement totalement ou partiellement amovible, stockant un programme d'ordinateur comprenant un jeu d'instructions exécutables par un ordinateur pour mettre en oeuvre le procédé de selon au moins une des revendications 1 à 6 et/ou au moins une des revendications 7 à 12, lorsque ledit programme est exécuté sur un ordinateur.
  15. 15. Tête de tunnel intermédiaire (TEP F) connectée à un sous-réseau intermédiaire et permettant l'établissement d'un chemin de communication entre une première tête de tunnel (TEP S) connectée à un premier sous-réseau et une seconde tête de tunnel (TEP D) connectée à un second sous-réseau, chaque tête de tunnel permettant l'interconnexion du sous-réseau où elle est connectée à au moins un autre sous-réseau au moyen d'aumoins un tunnel de communication, à une tête de tunnel donnée étant associée une communauté constituée d'un ensemble de têtes de tunnel, à chaque tête de tunnel d'une communauté étant associé un niveau de confiance de la tête de tunnel donné, ladite tête de tunnel intermédiaire (TEP F) étant caractérisée en ce qu'elle comprend : - des moyens pour recevoir, en provenance directe ou indirecte de la première tête de tunnel, d'un premier message de découverte de chemin de communication entre la première et la seconde tête de tunnel ; - des moyens pour établir un tunnel auxiliaire entre la première tête de tunnel et ladite tête de tunnel intermédiaire ;dans le cas où la seconde tête de tunnel appartient à la communauté de ladite tête de tunnel intermédiaire avec un niveau de confiance supérieur ou égal à un seuil prédéterminé et où la première tête de tunnel n'appartient pas à la communauté de ladite tête de tunnel intermédiaire ; - des moyens pour activer le chemin de communication entre les première et seconde têtes de tunnel par utilisation du tunnel auxiliaire établi.
  16. 16. Tête de tunnel intermédiaire (TEP F) selon la revendication 15, caractérisée en ce qu'elle comprend en outre : - des moyens pour émettre un deuxième message de découverte de chemin entre les première et seconde têtes de tunnel, ledit message étant émis sur le ou le(s) tunnel(s), autre(s) que le tunnel auxiliaire, pour lesquels la tête de tunnel intermédiaire est une extrémité et par lesquels ledit premier message de découverte de chemin n'est pas arrivé.
  17. 17. Tête de tunnel intermédiaire (TEP F) selon la revendication 16, caractérisée en ce qu'elle comprend également : - des moyens pour émettre un message de détection d'impasse à destination de la première tête de tunnel ; - des moyens pour recevoir, en provenance directe ou indirecte de la première tête de tunnel, un message de poursuite de découverte de chemin de communication entre les première et seconde têtes de tunnel ; - des moyens pour construire ledit deuxième message de découverte de chemin à partir du message de poursuite de découverte reçu.
  18. 18. Tête de tunnel intermédiaire (TEP F) selon l'une quelconque des revendications 15 à 17, caractérisée en ce qu'elle comprend des moyens d'affectation de la première tête de tunnel dans la communauté de ladite tête de tunnel intermédiaire de façon à affecter à la première tête de tunnel un niveau de confiance inférieur audit seuil prédéterminé.
  19. 19. Tête de tunnel intermédiaire (TEP F) selon la revendication 18, caractérisée en ce qu'elle comprend : - des moyens pour recevoir, en provenance directe ou indirecte de l'une parmi les première et seconde têtes de tunnel, d'une requête de désactivation du tunnel auxiliaire ; - des moyens pour retirer la première tête de tunnel de la communauté de ladite tête de tunnel intermédiaire.
  20. 20. Première tête de tunnel (TEP S) connectée à un premier sous-réseau et située sur un chemin de communication reliant ladite première tête de tunnel (TEP S) et une seconde tête de tunnel (TEP D) connectée à un second sous-réseau, ledit chemin de communication étant établi par l'intermédiaire d'au moins une tête de tunnel intermédiaire (TEP F) connectée à un sous-réseau intermédiaire, chaque tête de tunnel permettant l'interconnexion du sous-réseau auquel elle est connectée à au moins un autre sous-réseau au moyen d'au moins un tunnel de communication, à une tête de tunnel donnée étant associée une communauté constituée d'un ensemble de têtes de tunnel, à chaque tête de tunnel d'une communauté étant associé un niveau de confiance de la tête de tunnel donné, ladite première tête de tunnel (TEP S) étant caractérisée en ce qu'elle comprend : - des moyens pour émettre un message de découverte de chemin de communication entre la première et la seconde tête de tunnel, ledit message étant émis sur au moins un tunnel actif dont la première tête de tunnel est une extrémité ; - des moyens pour recevoir un premier message de détection d'impasse provenant d'une première tête de tunnel intermédiaire ; - des moyens pour établir un premier tunnel auxiliaire entre la première tête de tunnel et la première tête de tunnel intermédiaire ;- des moyens pour activer le chemin de communication entre les première et seconde têtes de tunnel par utilisation du tunnel auxiliaire établi.
  21. 21. Première tête de tunnel (TEP S) selon la revendication 20, caractérisée en ce qu'elle comprend : - des moyens pour recevoir un message de détection d'impasse en provenance de la première tête de tunnel intermédiaire ; - des moyens pour émettre un message de poursuite de découverte de chemin de communication entre les première et seconde têtes de tunnel, ladite poursuite de recherche de chemin devant s'effectuer en prenant en compte le tunnel auxiliaire comme portion dudit chemin et devant reprendre à partir de la première tête de tunnel intermédiaire.
  22. 22. Première tête de tunnel (TEP S) selon la revendication 21, caractérisée en ce qu'elle comprend : - des moyens pour désactiver le tunnel auxiliaire, dans le cas où, en réponse audit message de poursuite de recherche de chemin, la première tête de tunnel reçoit un second message de détection d'impasse provenant d'une seconde tête de tunnel intermédiaire ; - des moyens pour établir un second tunnel auxiliaire entre la première tête de tunnel et la seconde tête de tunnel intermédiaire ; - des moyens pour activer le chemin de communication entre les première et seconde têtes de tunnel par utilisation du second tunnel auxiliaire établi.
  23. 23. Première tête de tunnel (TEP S) selon l'une quelconque des revendications 20 à 22, caractérisée en ce qu'elle comprend des moyens d'affectation de la première tête de tunnel intermédiaire dans la communauté de la première tête de tunnel de façon à affecter à la première tête de tunnel intermédiaire un niveau de confiance inférieur audit seuil prédéterminé.
  24. 24. Première tête de tunnel (TEP S) selon la revendication 23, caractérisée en ce qu'elle comprend, sur désactivation dudit chemin activé entre la première et la seconde tête de tunnel : des moyens pour désactiver le premier tunnel auxiliaire ;- des moyens pour exclure la première tête de tunnel de la communauté de ladite première tête de tunnel intermédiaire.
FR0855306A 2008-07-31 2008-07-31 Procede d'etablissement d'un chemin de communication entre une premiere tete de tunnel et une seconde tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes. Expired - Fee Related FR2934735B1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
FR0855306A FR2934735B1 (fr) 2008-07-31 2008-07-31 Procede d'etablissement d'un chemin de communication entre une premiere tete de tunnel et une seconde tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes.

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0855306A FR2934735B1 (fr) 2008-07-31 2008-07-31 Procede d'etablissement d'un chemin de communication entre une premiere tete de tunnel et une seconde tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes.

Publications (2)

Publication Number Publication Date
FR2934735A1 true FR2934735A1 (fr) 2010-02-05
FR2934735B1 FR2934735B1 (fr) 2010-08-27

Family

ID=40535636

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0855306A Expired - Fee Related FR2934735B1 (fr) 2008-07-31 2008-07-31 Procede d'etablissement d'un chemin de communication entre une premiere tete de tunnel et une seconde tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes.

Country Status (1)

Country Link
FR (1) FR2934735B1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020147771A1 (en) * 2001-01-22 2002-10-10 Traversat Bernard A. Peer-to-peer computing architecture
US20040225895A1 (en) * 2003-05-05 2004-11-11 Lucent Technologies Inc. Method and apparatus for providing adaptive VPN to enable different security levels in virtual private networks (VPNs)
US20050265308A1 (en) * 2004-05-07 2005-12-01 Abdulkadev Barbir Selection techniques for logical grouping of VPN tunnels
US20070091795A1 (en) * 2005-10-20 2007-04-26 Olivier Bonaventure Method of constructing a backup path in an autonomous system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020147771A1 (en) * 2001-01-22 2002-10-10 Traversat Bernard A. Peer-to-peer computing architecture
US20040225895A1 (en) * 2003-05-05 2004-11-11 Lucent Technologies Inc. Method and apparatus for providing adaptive VPN to enable different security levels in virtual private networks (VPNs)
US20050265308A1 (en) * 2004-05-07 2005-12-01 Abdulkadev Barbir Selection techniques for logical grouping of VPN tunnels
US20070091795A1 (en) * 2005-10-20 2007-04-26 Olivier Bonaventure Method of constructing a backup path in an autonomous system

Also Published As

Publication number Publication date
FR2934735B1 (fr) 2010-08-27

Similar Documents

Publication Publication Date Title
EP3476095B1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
EP3044913B1 (fr) Procede et systeme d'etablissement de reseaux prives virtuels entre reseaux locaux
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
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
US7730200B2 (en) Synthetic bridging for networks
FR2919778A1 (fr) Procede de transmission de paquets de donnees dans un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
FR2939993A1 (fr) Procede de transmission d'un flux de donnees multi-canal sur un tunnel multi-transport, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes
FR2873524A1 (fr) Reseau local a groupe(s) virtuel(s) d'equipements de coeur propres a la commutation de niveau deux
EP1864466A1 (fr) Dispositif et procede de communication dans un reseau
FR2853187A1 (fr) Systeme permettant a toute application reseau de fonctionner de facon transparente a travers un dispositif de traduction d'adresse de reseau
FR2824930A1 (fr) Procede de communication et/ou de partage de ressources machines, au sein d'un reseau de communication, entre une pluralite de membres d'une communaute
FR2909241A1 (fr) Procedes et dispositifs de gestion dynamique des erreurs de transmission par des points d'interconnexion de reseaux.
FR2929789A1 (fr) Procede de gestion de mecanismes d'amelioration de transmission de flux de donnees sur un tunnel, produit programme d'ordinateur, moyen de stockage et tete de tunnel correspondants
EP3695571B1 (fr) Dispositif et procédé de transmission de données
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é
FR2737372A1 (fr) Dispositif et procede d'interconnexion de reseaux, routeur ip comprenant un tel dispositif
FR2922398A1 (fr) Systeme d'interconnexion entre au moins un appareil de communication et au moins un systeme d'information distant et methode d'interconnexion
EP3373558B1 (fr) Procédé de communication pour assurer le maintien d'une session applicative entre un terminal et un serveur d'application
FR2934735A1 (fr) Procede d'etablissement d'un chemin de communication entre une premiere tete de tunnel et une seconde tete de tunnel, produit programme d'ordinateur, moyen de stockage et tetes de tunnel correspondantes.
EP3235217B1 (fr) Procédé d'échanges de données entre deux navigateurs internet, équipement de routage, terminal, programme d'ordinateur et support d'informations corespondants
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
EP2579545B1 (fr) Méthode d'attribution d'une adresse réseau publique à un équipement disposant d'une adresse réseau privée
EP1432210B1 (fr) Dispositif de contrôle de traitements associés a des flux au sein d'un reseau de communications
EP4046457A1 (fr) Procede de connexion d'un noeud de communication, et noeud de communication correspondant
FR2938144A1 (fr) Procede de gestion d'espaces d'adressage a la fermeture d'un tunnel de communication entre une premiere et une seconde tete de tunnel, produit programme d'ordinateur, moyen de stockage et dispositif correspondants.

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20140331