FR2883437A1 - Dispositif et procede de communication dans un reseau - Google Patents

Abstract

Réseau de communication comprenant une pluralité d'équipements (30) interconnectés, les équipements (30) assurant l'administration du réseau, par exemple la gestion des données dans les équipements du réseau, la surveillance du réseau, le contrôle du réseau, la gestion du contrôle d'accès au réseau. Les équipements (30) constituant le réseau étant des routeurs, des contrôleurs d'accès ou des commutateurs.

Description

La présente invention concerne le domaine de la communication dans un

réseau, et plus particulièrement le domaine de l'administration réseau, notamment la gestion du

contrôle d'accès et la gestion des équipements installés dans un réseau de communication.

Aujourd'hui, pour permettre l'administration réseau, plusieurs technologies et standards industriels sont utilisés, telles que par exemple les architectures SNMP (Simple Network Management Protocol) ou AAA (Authentication / Authorization / Accounting) bien connues de l'homme du métier.

La figure la présente une architecture d'un réseau conforme au standard SNMP. Ce standard définit une infrastructure de gestion de réseau suivant le modèle de communication agent-manager, connu de l'homme du métier. Dans un tel modèle les agents (110) installés sur les équipements renvoient des rapports à une instance centrale nommée manager. Le manager utilise ces rapports pour construire une image de la situation globale du réseau. SNMP permet également le changement de certains variables définies dans les bases d'information de la gestion, communément appelé MIB (Management Information Base).

Dans le domaine de l'administration réseau, on peut distinguer trois parties dans un réseau: le plan d'activité (business plane), le plan de contrôle (10) (control plane / management plane) et le plan de réseau (I1) (network plane). Le plan d'activité est parfois inexistant ou confondu avec le plan de contrôle (10).

Le plan d'activité est utilisé par l'administration réseau pour configurer, contrôler et observer le comportement du réseau. Il permet également à l'administrateur du réseau de définir des comportements standard de base du réseau.

Le plan réseau (1l) contient des équipements, par exemple des routeurs, qui assurent les services de base dans un réseau, par exemple le transport de données provenant d'un utilisateur vers le destinataire de ces données par un routeur. Le routeur étant chargé de choisir l'itinéraire à suivre.

Le plan de contrôle (10) également appelé plan de gestion, est le plan intermédiaire entre le plan d'activité et le plan réseau. Il permet de simplifier l'administration du réseau en automatisant les tâches standard par exemple de prises de décision dans les situations standard définis préalablement par l'administration du réseau en terme de règles et de stratégies. Le plan de contrôle centralise le contrôle des équipements dans le plan réseau. Cependant il arrive dans la pratique que le plan de contrôle se confonde avec le plan d'activité.

Dans le plan de contrôle d'un réseau de type SNMP, un équipement central nommé poste de gestion réseau, appelé communément NMS (101) (Network Management Station), collecte des données des agents (110) SNMP installés dans les équipements du plan réseau. Le NMS (101) sert alors de point de contrôle central pour l'administration accessible à partir du plan d'activité. Dans ce modèle, il existe donc une administration mais une variété d'équipements à gérer: l'administration du réseau est donc centralisée.

La figure lb illustre une architecture réseau conforme au standard AAA présentant également une administration centralisée. Le standard AAA définit une interface vers, par exemple, une base de données, et permet l'autorisation et l'authentification à l'utilisation d'un service, ainsi qu'aux échanges de statistiques sur l'utilisation du service. Le standard AAA définit également une architecture et des protocoles permettant les échanges de preuves d'identité, de droits attribués, ainsi que les statistiques d'utilisation de ressources. Le protocole AAA le plus répandu est le standard nommé IETF RADIUS. Ce protocole présume une infrastructure centralisée basée sur le modèle client-serveur connu de l'homme du métier. Dans ce modèle, un équipement central faisant partie du plan de contrôle (11), nommée serveur d'authentification et noté AS (Authentication Server) (102), est utilisé pour vérifier les demandes d'accès aux services provenant des autres équipements du plan de réseau (11) communément appelés serveur d'accès réseau et notés NAS (Network Access Server) (111) par l'homme du métier. En fonction de cette vérification et des stratégies locales, l'AS (102) répond avec un message d'autorisation ou de refus d'accès. Les NAS (111) typiques sont par exemple des serveurs entrants, des points d'accès IEEE 802.11, divers périphériques réseau et également des services réalisant une vérification de l'autorisation d'accès utilisateur.

Ainsi, comme illustré sur la figure 2a, si l'AS (102) ne répond pas à cause d'une panne, aucun NAS (111) soumis administrativement à ce serveur ne peut accepter de nouvelles sessions. Les sessions existantes sur de tels points d'accès seront interrompues à la ré-authentification suivante. Généralement, une panne peut être par exemple une surcharge du serveur AAA. En outre la surcharge du réseau dépend de plusieurs paramètres, par exemple le nombre total d'utilisateurs, la durée de session définie par l'utilisateur, la méthode d'authentification utilisateur, la mobilité utilisateur. Cette éventuelle situation de surcharge souligne en outre un autre problème clé d'une telle solution centralisée: l'extensibilité ou le passage à l'échelle c'est-à-dire la capacité à administrer un réseau croissant en terme de taille. Le point de contrôle centralisé d'une telle architecture est quasiment toujours sur- ou sous-dimensionné, représentant ainsi une perte de ressource ou un goulot d'étranglement respectivement. Dans cette configuration, la fiabilité de l'ensemble du plan de contrôle dépend ainsi directement de la fiabilité de l'infrastructure AAA. L'infrastructure AAA devient alors critique pour le service réseau global.

Une solution possible au problème de passage à l'échelle d'un réseau serait d'installer des serveurs AAA supplémentaires et de réaliser une division du réseau en sous-ensembles gérés par AAA de taille appropriée. Ceci est illustré sur la figure 2b dans laquelle le point d'accès à gauche authentifie sur le Serveur AAA 1 (1021), alors que les autres points d'accès authentifient sur le serveur AAA N (102N). Les protocoles AAA modernes, tel que le protocole standardisé RADIUS, proposent des mesures de l'interconnexion serveur AAA, appelée proxy, permettant d'obtenir une telle division sans limitations de la mobilité de l'utilisateur: un utilisateur (2) dont le profil est géré par le Serveur AAA 1 (1021) peut toujours accéder au service sur tous les points d'accès (111) connectés. Cependant, une telle solution consistant à installer des serveurs supplémentaires devient très coûteuse en ce qui concerne la maintenance et présente une infrastructure de contrôle considérablement plus complexe.

Ainsi, toutes ces solutions d'administration réseaux, notamment de gestion et de contrôle d'accès, se basent exclusivement sur des architectures centralisées, c'est-à- dire que la gestion ne se fait que par un seul et même équipement central dédié, et cela présente plusieurs inconvénients majeurs, notamment en terme de robustesse, de coût et de passage à l'échelle.

En effet, si l'équipement central introduit par les architectures SNMP ou AAA tombe en panne, par exemple panne de matériel, de réseau, ou de courant, le service rendu par le réseau devient immédiatement et complètement inaccessible pour tout nouvel utilisateur; les sessions ouvertes ne peuvent plus être prolongées après leur expiration pour les utilisateurs connectés, la durée de session étant de l'ordre de 5 à 10 minutes par exemple dans le cadre d'un réseau sans fil.

En outre, comme avec toutes les solutions centralisées, une situation de surcharge peut être provoquée par une activité élevée du réseau, par exemple par un nombre trop élevé d'équipements (par exemple clients, agents) déployés dans le réseau et soumis à ce même équipement central. Celui-ci se présente alors comme un goulot d'étranglement et limite le passage à l'échelle du réseau. Dans le cas concret d'une architecture AAA, la surcharge peut être due par exemple au nombre d'utilisateurs, à la durée de session définie, à la mobilité des utilisateurs, ou encore aux méthodes utilisées pour l'authentification des utilisateurs. La nécessité d'un équipement centralisé ne permet pas de suivre la croissance naturelle du réseau. Par exemple, si une entreprise veut déployer un petit réseau pour couvrir des besoins spécifiques identifiés, le coût d'un tel réseau sera disproportionné par rapport à sa En fait, le passage de tout. système centralisé à une autre échelle est difficile: il est naturellement soit sur- soit sous-dimensionné à un certain moment.

De plus, en terme de coût d'équipement, une installation nécessitant un minimum en sécurité et gestion de réseau implique une installation d'un système de contrôle centralisé. La fiabilisation de ce système, la complexité de sa gestion et de sa maintenance, impliquent le déploiement de forces et de compétences humaines nécessaires pour le bon fonctionnement du réseau, et représentent donc un coût non négligeable.

Pour résumer les propriétés et inconvénients techniques de l'architecture de contrôle 5 centralisée, il est possible d'affirmer qu'elle n'est pas bien adaptée à différents cas.

Dans le cas d'une installation de réseaux d'envergure, le point de contrôle central ou l'AS (102) dans le cas d'une architecture AAA, peut devenir un goulot d'étranglement et représente également un point de faiblesse indésirable.

L'installation de plusieurs serveurs AAA authentifiant en direction d'une base de données utilisateur commune n'atténue pas le problème de mise à l'échelle et de coût.

Dans le cas de petits réseaux: les concepts d'administration centralisées ne sont pas bien adaptés aux petites installations de moins de 50 points d'accès. Le principal problème est le coût et le fonctionnement d'une installation centrale fiable. En raison de sa souplesse d'utilisation, la gestion requiert généralement une connaissance approfondie du réseau et une administration compétente. L'effort d'administration et le coût supplémentaire en équipement, logiciel et maintenance sont difficiles à amortir dans de petites installations. Par exemple, ce qui est difficile, tout particulièrement pour les petites entreprises, c'est d'utiliser les solutions de contrôle d'accès actuellement disponibles pour les réseaux locaux sans fil: ils ne sont pas assez sûrs ou leur sécurité est inabordable. Pour cette raison, la norme IEEE 802.11 i propose un mode de clé pré-partagée (PSK) pour les points d'accès indépendants.

Cependant, dans ce mode, il est quasiment impossible de proposer un accès à des visiteurs occasionnels et à différents groupes d'utilisateurs. En outre, si une installation de réseau local sans fil basée sur le mode de clé pré-partagée doit être étendue à plusieurs points d'accès, l'extension revient principalement au coût d'une sécurité réduite ou entraîne une affectation utilisateur/point d'accès prédéfinie limitant la mobilité. Ainsi, la seule alternative existante dans les concepts centralisés actuels consiste en ce que tous les nouveaux points d'accès authentifient en direction du premier point d'accès agissant comme un serveur AAA local et contenant les profils utilisateurs. Cependant, bien que pratiquement plus simple à obtenir dans un petit réseau, cette solution suppose l'installation d'un serveur AAA central, avec des ressources particulièrement limitées. Cette solution ne peut pas être facilement étendue. En outre, les serveurs AAA intégrés existants sont volontairement relativement simples et ne proposent typiquement pas l'entière fonctionnalité d'un serveur AAA dédié.

Dans le cas de la croissance du réseau, il existe des problèmes d'extensibilité et de coût. En effet, avec les architectures centralisées disponibles, une croissance continue du réseau (due au développement de l'entreprise par exemple) est difficile à suivre.

L'installation d'un serveur AAA représente un coût considérable. En outre, un nouveau serveur AAA est difficile à ajouter à une infrastructure existante en raison de la nouvelle répartition de la base de données et de la relation de confiance nécessaire. Par exemple, si les bases de données utilisateur sont totalement répliquées, des mécanismes de cohérence doivent être utilisés pour obtenir le même contenu dans toutes les bases de données. Ceci est difficile car des modifications peuvent être apportées dans différentes bases de données simultanément. Si la base de données n'est pas répliquée pour chaque serveur AAA, chaque serveur AAA devient alors un point de faiblesse pour tous les utilisateurs gérés dans sa base de données. Il existe bien évidemment un compromis indésirable entre la performance du plan de contrôle d'une part et sa complexité d'autre part.

La présente invention a pour but de remédier à ces inconvénients, et notamment, mais non exclusivement, à pour but de proposer un réseau capable de suivre la croissance de la capacité d'administration du réseau, c'est-à-dire optimiser le passage à l'échelle, acceptant facilement l'ajout d'un nouveau point d'accès transparent pour les utilisateurs, supportant la gestion d'utilisateurs, n'imposant pas de nouvelles contraintes au niveau de la mobilité des utilisateurs, c'est-à-dire que chaque utilisateur autorisé doit pouvoir se connecter à chaque point d'accès du réseau, supportant une gestion simplifiée, n'introduisant pas de contrainte au niveau des débits et de délais au niveau de transport de données, n'imposant pas de contraintes au niveau du service plan réseau.

Un autre objectif de l'invention est de proposer une solution ne diminuant pas la performance du réseau et n'autorisant aucun point de faiblesse, et dont l'impact d'une panne partielle doit être limité aux équipements défaillants.

Un autre objectif de l'invention est de proposer une solution offrant un support de profil utilisateur du type AAA par exemple, avec des possibilités identiques ou équivalentes de gestion utilisateur, avec pour chaque utilisateur la possibilité de pouvoir accéder à chaque partie du réseau.

Ces objectifs sont atteints par la prévision d'un (ici seront insérées les revendications pour des questions juridiques) Ces objets, caractéristiques et avantages ainsi que d'autres de la présente invention seront exposés plus en détail dans la description suivante d'un mode de réalisation préféré de l'invention, à titre non limitatif, en référence aux figures parmi lesquelles: - La figure la présente un réseau utilisant l'architecture SNMP; La figure lb présente un réseau utilisant l'architecture AAA; La figure 2a présente une configuration possible d'un réseau utilisant l'architecture AAA; La figure 2b présente une autre configuration possible d'un réseau utilisant l'architecture AAA; La figure 3 présente une configuration du plan contrôle selon l'invention; La figure 4 présente un exemple d'une table CAN à 2 dimensions avec 5 noeuds; La figure 5 présente une réalisation préférée d'un réseau selon l'invention; La figure 6 présente une répartition de zones de gestion selon l'invention; Pour réduire les coûts et obtenir une mise à l'échelle naturelle, les équipements du plan du réseau sont organisés directement et déployés afin de créer un réseau comparable au réseau égal à égal, également noté P2P (peer-to-peer), par exemple pour le stockage de données relatives au contrôle d'accès, à la gestion du réseau ou à la configuration d'entité, tel qu'illustré sur la figure 3. Pour cela, la partie du plan de contrôle de l'équipement réseau (par exemple le client AAA ou l'agent SNMP) est étendue ou remplacée par un module P2P (3). Ce module P2P (3) contient ainsi les données nécessaires du plan de contrôle.

Etant donné que les ressources disponibles au niveau des équipements (30) du plan de contrôle pour des tâches supplémentaires sont typiquement limitées, la charge administrative est distribuée entre tous les équipements (30) du plan du réseau (par exemple routeurs ou points d'accès). Ainsi, chaque équipement du plan de contrôle n'est concerné que par une partie de l'ensemble de la charge administrative.

Pour répondre aux objectifs de l'invention définis précédemment, un contrôle d'accès réseau est intégré dans l'équipement faisant le lien avec l'utilisateur. Ce contrôle d'accès réseau possède une architecture interne réseau développant les récentes avancées dans la mise en réseau P2P. De plus, le réseau P2P ainsi formé peut être utilisé pour toute tâche classique du plan de contrôle comme la gestion de l'équipement déployé, le support de la mobilité ou la configuration automatique.

Pour cela, d'autres équipements ou des noeuds P2P supplémentaires peuvent être ajoutés à ce réseau P2P.

En guise d'exemple de réalisation, des points d'accès IEEE 802.11 pourraient former un réseau dédié P2P indépendant, stockant la base de données utilisateur distribué, utilisée pour le contrôle d'accès réseau IEEE 802.1X.

Des exemples de mise en oeuvre de l'invention sont exposés ci-après.

Afin de répondre aux exigences d'extensibilité et de tolérance aux fautes, aucune entité ne peut disposer de connaissances sur le réseau global. Le problème de base ici n'étant alors pas le transfert de données, mais plutôt la localisation de données à transférer.

Par exemple, aucun point d'accès n'est autorisé à disposer d'un index de tous les enregistrements de données dans le recouvrement. De plus la diffusion de données dans le réseau (par exemple " qui tient la structure de données X ? ") par un équipement n'est pas autorisée pour des raisons d'efficacité et d'extensibilité. Enfin, dans l'environnement donné, une diffusion basée sur un seuil ne peut être acceptée, l'itération de la requête pouvant entraîner des retards de recherche accrus de manière aléatoire, des délais d'attente et, généralement, une qualité de service inférieure. Dans ce contexte, des tables de hachage distribuées (DHT Distributed Hash Table) peuvent par exemple être utilisées. Elles sont utilisées pour stocker et récupérer une base de données AAA distribuée entre les points d'accès.

Une DHT est une table de hachage divisée en plusieurs parties. Ces parties sont distribuées entre certains clients formant désormais typiquement un réseau dédié. Un tel réseau permet à l'utilisateur de stocker et de récupérer des informations dans des paires (clé, données) tel qu'illustré par les tables de hachage traditionnelles connu de l'homme du métier. Elles requièrent des règles et algorithmes spécifiques. Des exemples célèbres de tables de hachage distribuées sont les réseaux de partage de fichier/P2P. Chaque noeud faisant partie d'un tel réseau P2P est responsable d'une partie de la table de hachage appelée zone. Grâce à cela, un équipement réseau centrale gérant la table de hachage complète ou son index n'est plus nécessaire.

Chaque noeud participant à un tel réseau P2P gère sa partie de la table de hachage et met en oeuvre les primitives: lookup(k), store(k, d) et delete(k).

Avec lookup(k), un noeud recherche sur le réseau P2P une clé de hachage k donnée et obtient les données d associées à la clé k. Etant donné que chaque noeud ne dispose que d'une fraction de la table de hachage complète, il est possible que k ne fasse pas partie de la fraction du noeud. Chaque table de hachage distribuée définit donc un algorithme pour rechercher le noeud n particulier responsable de k, étant donné que ceci est réalisé sur une base de bond par bond avec chaque bond " plus proche " de n, il s'agit de l'algorithme d'acheminement de table de hachage distribuée, connu de l'homme du métier.

La primitive store (k, d) stocke un uplet comprenant une clé k et la valeur de données associée d dans le réseau, c'est-à-dire que (k, d) sont transmis à un noeud responsable de k en utilisant la même technique d'acheminement qu'avec lookup.

Avec delete(k), une entrée est supprimée de la table de hachage, c'est-àdire que le noeud responsable de k supprime (k, d).

Les réseaux dédiés basés sur le P2P utilisent leurs propres mécanismes d'acheminement ou de transfert de données. Ils sont donc optimisés de telle sorte que chaque noeud ne dispose que d'une vue très locale de son voisinage réseau. Cette propriété est nécessaire pour une bonne mise à l'échelle puisque l'état par noeud n'augmente pas nécessairement avec la croissance du réseau. L'acheminement est déterministe et il existe des limites supérieures au nombre de bonds qu'une requête doit réaliser. La plupart des réseaux P2P présentent un comportement logarithmique avec un nombre total de noeuds.

Un exemple de DHT à utilisée est par exemple le type CAN (Content Adressable Network). CAN définit une interface utilisateur de table de hachage standard tel que décrit ci-dessus. Le réseau CAN propose les mécanismes de construction dédiée (jonction de noeud/amorçage de noeud), de sortie de noeud, d'algorithme d'acheminement. L'index de la table de hachage du réseau CAN est un espace de coordonnées cartésiennes à dimension d sur un tore d. Chaque noeud est responsable d'une partie de l'ensemble de l'espace de coordonnées. La figure 4 illustre un exemple de réseau CAN en deux dimensions avec cinq noeuds (A, B, C, D et E). Dans le réseau CAN, chaque noeud contient la base de données de zone correspondant à l'espace de coordonnées affecté et une table voisine dédiée. La taille de cette dernière dépend uniquement de la dimension d. Le mécanisme standard pour l'affectation de zone entraîne une distribution uniforme de l'index entre les noeuds. Par défaut, le réseau CAN utilise une procédure de construction dédiée (appelée amorçage) basée sur une adresse DNS (Domain Name System) bien connue. Ceci permet à chaque noeud rejoignant le réseau d'obtenir une adresse d'un ou plusieurs noeuds d'amorce du réseau CAN. A la réception d'une requête d'un nouveau noeud, un noeud d'amorce répond simplement avec les adresses IP (Internet Protocol) de plusieurs noeuds choisis de manière aléatoire qui se trouvent dans le recouvrement. La requête de jonction est ensuite envoyée à l'un de ces noeuds. Le nouveau noeud choisit ensuite de manière aléatoire une adresse index et envoie une requête de jonction pour cette adresse à l'une des IP reçues. Le réseau CAN utilise son algorithme d'acheminement pour acheminer cette requête au noeud responsable de la zone dont cette adresse dépend. Le noeud sollicité répartit désormais sa zone en deux moitiés et conserve une des moitiés, la base de données de zone liée et la liste des 11 voisins dérivés du noeud rejoignant le réseau.

Par exemple, le réseau CAN sur la figure 4 est un résultat possible du scénario suivant: A est le premier noeud et contient la base de données entière B rejoint le réseau et obtient une moitié de la zone de A sur l'axe x (40) C rejoint le réseau et obtient de manière aléatoire une moitié de la zone de A sur l'axe y (41) D rejoint le réseau et obtient de manière aléatoire une moitié de la zone de B sur l'axe y (41) E rejoint le réseau et obtient de manière aléatoire une moitié de la zone de D sur l'axe x (40) L' acheminement dans le réseau CAN est basé sur un transfert considérable. Chaque requête contient le point de destination dans l'espace d'index. Chaque noeud récepteur non responsable du point de destination transfère cette requête à l'un de ses voisins dont les coordonnées sont plus proches du point que les siennes.

Pour améliorer la performance (supprimer les latences, obtenir une meilleure fiabilité), le réseau CAN présente différents paramètres: Ajuster la dimension d: le nombre d'éventuels chemins augmente avec la dimension, entraînant ainsi une meilleure protection contre les défaillances de noeud. La longueur du chemin globale diminue avec d.

Nombre de réalités indépendantes r: en utilisant plusieurs index CAN indépendants r au sein d'un réseau CAN, des noeuds r sont responsables de la même zone. La longueur du chemin globale diminue avec r (puisque l'acheminement peut prendre place dans toutes les réalités en parallèle et être abandonné en cas de succès). Le nombre de chemins réellement disponibles augmente. La disponibilité des données augmente puisque la base de données est répliquée r fois.

Utilisation de différentes mesures, reproduction de la topologie dans le réseau CAN: le réseau CAN peut utiliser une mesure d'acheminement différente. La topologie sous-jacente peut être reproduite dans le recouvrement.

Echange de trafic de noeud: la même zone peut être affectée à un groupe de noeuds, réduisant ainsi le nombre de zones et la longueur du chemin globaux.

Utilisation de plusieurs fonctions de hachage. ceci est comparable à plusieurs réalités étant donné que chaque fonction de hachage construit une entrée d'index parallèle.

Cache et réplication de paires de données: des paires " populaires " peuvent être mises en cache par les noeuds et ainsi répliquées dans la base de données.

La figure 5 présente un autre exemple de réalisation d'une architecture de gestion décentralisée pour réseaux locaux sans fil conforme au standard 802.11, illustrant comment un contrôle d'accès et une gestion décentralisés peuvent être intégrés à une technologie d'accès population existante. Cet exemple est basé sur une mise en réseau TCP/IP (Transmission Control Protocol/Internet Protocol) standard connue de l'homme du métier, dans le réseau central. Le réseau de gestion P2P est formé de points d'accès (5) conforme au standard 802.11. Chaque point d'accès (5) agit en tant que noeud (6) P2P formant un réseau dédié (8) logique sur le réseau central physique. Ce recouvrement stocke différentes bases de données logiques, principalement les bases de données utilisateur et de gestion (7). La base de données utilisateur stocke des profils utilisateurs du type AAA. La base de données de gestion aide l'administrateur à gérer tous les points d'accès connectés et stocke les paramètres de point d'accès exprimés dans la syntaxe respective (par exemple variables MIB 802.11, paramètres du fabricant propriétaire). A la demande de l'utilisateur, le noeud sollicité récupère le profil correspondant. Grâce au profil récupéré, le point d'accès (5) desservant suit la procédure selon le standard 802.1X habituelle en tant qu'authentificateur avec un serveur d'authentification local. De plus, il est possible d'inclure un quelconque nombre de noeuds (60) auxiliaires assistant, par exemple la console de l'administrateur réseau, dans ce réseau P2P. Tous les noeuds (5, 6) participant au réseau P2P interagissent entre-eux afin d'acheminer les requêtes et de récupérer, stocker et supprimer des données. Le réseau P2P est accessible sur un quelconque point d'accès connecté.

Avec n points d'accès et aucun équipement central, il est pratique d'exprimer cette relation de confiance au moyen d'une cryptographie de clé publique utilisant des certificats signés par exemple, permettant de protéger l'établissement d'une communication entre deux participants à un quelconque moment avec n secrets pour n noeuds. L'identité définie d'un point d'accès est l'adresse MAC de son interface filaire connectée au CAN.

Chaque point d'accès requiert une configuration minimum avant son déploiement dans le réseau. Ceci est principalement nécessaire pour un accès de gestion sécurisé à ce point d'accès.

La relation de confiance avec le point d'accès est représentée parl'installation d'un certificat signé sur chaque point d'accès. En outre, l'administrateur définit une connexion administrative locale (paire utilisateur/mot de passe) et règle les paramètres 802.11 habituels (SSID, noeud d'authentification, canaux et sorties utilisés). Enfin, l'administrateur fournit l'adresse amorce du réseau dédié et déploie le point d'accès en l'installation à l'emplacement souhaité et en le connectant au réseau.

Le réseau est ainsi configuré de sorte à équilibré la charge des tâches: si un point d'accès connaît une lourde charge, l'administrateur peut installer un point d'accès supplémentaire à proximité. Si les points d'accès concernés ne sont pas des voisins du CAN, ils ne partagent que la charge du trafic 802.11. Si les points d'accès sont des voisins du CAN, ils partagent également la charge administrative. Ceci est représenté sur la figure 6 illustrant trois points d'accès (5) installés dans une grande salle. Au début, le Point d'accès (API) initialement installé dispose de l'index entier.

A l'arrivée du Point d'accès 2, API donne la moitié de sa zone au Point d'accès 2 (AP2), devenant ainsi son voisin dédié (mais pas nécessairement son voisin physique). Si le trafic de données utilisateur est particulièrement élevé dans l'angle inférieur droit de la carte et relativement faible dans l'angle supérieur gauche, l'administrateur pourrait ainsi ajouter le Point d'accès 3 (AP3) dans le voisinage topologique du Point d'accès 2 afin de traiter la charge de trafic sans fil élevée. Si nous associons le recouvrement à la topologie du réseau, le nouveau AP3 devient automatiquement un voisin dédié de AP2. Ainsi, il obtient la moitié de la base de données de zone gérée par AP2 (Zone 3). En conséquence, en supposant que l'administrateur tente d'équilibrer la charge du trafic, avec cette approche, les tailles de zone des points d'accès diminuent dans les zones de charge de trafic élevée, libérant ainsi des capacités système pour le traitement du trafic. Au contraire, la zone de AP 1 reste relativement importante, ceci est cependant justifié par la charge de trafic inférieure. Il existe bien évidemment un compromis entre le surdébit de gestion de zone et la charge de trafic du réseau local sans fil.

Ainsi, au lieu d'avoir toutes les données nécessaires à l'administration du réseau stockées dans une seule base de données d'un serveur central, les différentes données sont réparties entre les différents équipements du réseau. Ainsi, un équipement servant de point d'accès rechercher les donnés qui lui manquent dans les différents équipements du réseau.

Etant donné que le nombre d'éléments du plan du réseau est choisi en fonction de la charge du trafic et si la charge administrative est bien distribuée entre les éléments du plan du réseau, le plan de contrôle peut également se mettre à l'échelle. Par exemple, l'augmentation du nombre de points d'accès 802.11 pour répondre aux exigences en termes de trafic pourrait activer automatiquement la gestion d'un plus grand nombre d'utilisateurs. Etant donné qu'il n'existe pas d'élément central qui pourrait augmenter progressivement le coût global, cette solution peut également être utilisée dans de très petits réseaux. Un réseau plus important peut être construit en ajoutant simplement des éléments supplémentaires du plan du réseau, des points d'accès 802.11 par exemple. Cette solution suit ainsi automatiquement la croissance naturelle du réseau et peut parfaitement être adaptée aux très grands réseaux.

Il est également envisageable de stocker les données plusieurs fois dans les équipements du réseau. Chaque équipement contient ainsi deux bases de données.

Les données contenues dans la première base de données étant différentes des données contenues dans la deuxième base de données. De cette manière si un équipement tombe en panne, ses données peuvent être retrouvées dans les autres équipements.

Claims (5)

REVENDICATIONS

1. Réseau de communication comprenant une pluralité d'équipements (30) interconnectés caractérisé en ce que certains au moins des équipements (30) intègrent des moyens (3) assurant l'administration du réseau, l'administration du réseau comprenant notamment, mais non exclusivement, la gestion des données dans les équipements du réseau, la surveillance du réseau, le contrôle du réseau, notamment mais non exclusivement la gestion du contrôle d'accès au réseau, et les équipements (30) constituant le réseau comprenant des routeurs, des contrôleurs d'accès et/ou des commutateurs.

2. Réseau de communication selon la revendication 1, caractérisé en ce que lesdits moyens (3) pour l'administration du réseau comprennent des données permettant l'identification des utilisateurs (2), des paramètres de configuration des équipements (30) du réseau, et/ou des adresses vers lesquelles les équipements (30) doivent se connecter pour envoyer ou recevoir des informations.

3. Réseau selon l'une quelconque des revendications 1 et 2, caractérisé en ce qu'au moins un équipement (30) du réseau est doté de moyens pour assurer le rôle de point d'accès.

4. Procédé de communication dans un réseau comprenant une pluralité d'équipements (30) interconnectés, le procédé comprenant les étapes de: configuration d'au moins un équipement (30) du réseau, comprenant au moins le stockage de données permettant la communication entre les équipements (30) du réseau, ces données comprennent au moins des données permettant l'identification de l'équipement dans le réseau et des données assurant la sécurité des échanges; construction du réseau comprenant au moins l'ajout d'un noeud (6) dans le réseau, et au moins une répartition des tâches parmi au moins certains des équipements (30) du réseaux concernant l'administration du réseau; et traitement de données stockées dans les équipements, ces traitements comprenant au moins les opérations consistant à permettre à chaque équipement (30) de retrouver des données réparties entre les équipements du réseau, à effacer des données si nécessaire, et/ou à enregistrer ou modifier des données déjà stockées.

5. Procédé de communication selon la revendication 4 caractérisé en ce que la construction du réseau comprend l'ajout automatique d'un noeud (6) lorsque le noeud (6) est opérationnel.