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

Dispositif et procede de communication dans un reseau Download PDF

Info

Publication number
WO2006097615A1
WO2006097615A1 PCT/FR2006/000552 FR2006000552W WO2006097615A1 WO 2006097615 A1 WO2006097615 A1 WO 2006097615A1 FR 2006000552 W FR2006000552 W FR 2006000552W WO 2006097615 A1 WO2006097615 A1 WO 2006097615A1
Authority
WO
WIPO (PCT)
Prior art keywords
network
equipment
data
node
access
Prior art date
Application number
PCT/FR2006/000552
Other languages
English (en)
Inventor
Artur Hecker
Erik-Oliver Blass
Houda Labiod
Original Assignee
Wavestorm
Groupes Des Ecoles Des Telecommunications
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 Wavestorm, Groupes Des Ecoles Des Telecommunications filed Critical Wavestorm
Priority to EP06726081A priority Critical patent/EP1864466A1/fr
Publication of WO2006097615A1 publication Critical patent/WO2006097615A1/fr
Priority to US11/898,859 priority patent/US20080071900A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0893—Assignment of logical groups to network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823—Network architectures or network communication protocols for network security for authentication of entities using certificates

Definitions

  • the present invention relates to the field of communication in a network, and more particularly the field of network administration, in particular the management of access control and the management of equipment installed in a communication network.
  • SNMP Simple Network Management Protocol
  • AAA Authentication / Authorization / Accounting
  • Figure la presents an architecture of a network compliant with the SNMP standard.
  • This standard defines a network management infrastructure according to the agent-manager communication model, known to those skilled in the art.
  • the agents (110) installed on the devices send reports to a central instance named manager.
  • the manager uses these reports to build an image of the overall network situation.
  • SNMP also allows the change of certain variables defined in the management information bases, commonly called MIB (Management Information Base).
  • the business plan is used by network administration to configure, monitor, and observe network behavior. It also allows the network administrator to define basic network behaviors.
  • the network plane (11) contains equipment, for example routers, which provide the basic services in a network, for example the transport of data from a user to the recipient of this data by a router.
  • the router being responsible for choosing the route to follow.
  • the control plan (10), also known as the management plan, is the intermediate plan between the business plan and the network plan. It simplifies the administration of the network by automating standard tasks, for example decision-making in the standard situations previously defined by the network administration in terms of rules and strategies.
  • the control plan centralizes the control of the equipment in the network plan. However, it happens in practice that the control plan is merged with the activity plan.
  • NMS (101) Network Management Station
  • Figure Ib shows an AAA-standard network architecture also showing centralized administration.
  • the AAA standard defines an interface to, for example, a database, and allows the authorization and authentication to the use of a service, as well as the exchange of statistics on the use of the service.
  • the AAA standard also defines an architecture and protocols for the exchange of proof of identity, assigned rights, as well as resource usage statistics.
  • the most common AAA protocol is the standard named IETF RADIUS. This protocol assumes a centralized infrastructure based on the client-server model known to those skilled in the art.
  • NAS Network Access Server
  • AS Authentication Server
  • NAS Network Access Server
  • AS Authentication Server
  • NAS Network Access Server
  • AS Authentication Server
  • Typical NAS (111) are, for example, incoming servers, IEEE 802.11 access points, various network devices, and also services performing a user access authorization check.
  • a failure can be for example an overload of the AAA server.
  • network overhead depends on several parameters, for example the total number of users, user defined session time, user authentication method, user mobility.
  • This possible overload situation also highlights another key problem of such a centralized solution: scalability or scalability, that is to say the ability to administer a growing network in terms of size.
  • the centralized control point of such an architecture is almost always over- or undersized, representing a resource loss or a bottleneck respectively. In this configuration, the reliability of the entire control plan thus directly depends on the reliability of the AAA infrastructure. The AAA infrastructure then becomes critical for the global network service.
  • a possible solution to the problem of scaling a network would be to install additional AAA servers and to partition the network into AAA managed subsets of appropriate size.
  • This is illustrated in Figure 2b in which the access port on the left authenticates on the AAA Server 1 (1021), while the other access points authenticate on the AAA server N (102N).
  • Modern AAA protocols such as the standardized RADIUS protocol, provide measurements of AAA server interconnection, called proxy, to achieve such a division without limitations of user mobility: a user (2) whose profile is managed by the AAA Server 1 (1021) can still access the service on all connected access points (111).
  • a solution of installing additional servers becomes very expensive in maintenance and presents a considerably more complex control infrastructure.
  • the central equipment introduced by the SNMP or AAA architectures fails, for example hardware, network, or power failure, the service rendered by the network becomes immediately and completely inaccessible to any new user; open sessions can not be extended after their expiration for logged in users, the session duration being of the order of 5 to 10 minutes for example in the context of a wireless network.
  • an overload situation can be caused by high network activity, for example by too many devices (eg clients, agents) deployed in the network and subjected to the same network. central equipment. This then presents itself as a bottleneck and limits the scaling up of the network.
  • the overhead can be due for example to the number of users, to the defined session duration, to the mobility of the users, or to the methods used for the authentication of the users. The need for centralized equipment does not make it possible to follow the natural growth of the network.
  • the central control point or PAS (102) in the case of an AAA architecture can become a bottleneck and also represents an undesirable weak point. Installing multiple AAA servers that authenticate to a common user database does not alleviate the problem of scaling and cost.
  • the extension primarily returns the cost of reduced security or results in a user / point assignment.
  • predefined access limiting mobility the only alternative existing in the current centralized concepts is that all new access points authenticate towards the first access point acting as a local AAA server and containing the user profiles.
  • this solution requires the installation of a central AAA server, with particularly limited resources. This solution can not be easily extended.
  • existing integrated AAA servers are deliberately relatively simple and typically do not offer the full functionality of a dedicated AAA server.
  • the object of the present invention is to remedy these drawbacks, and in particular, but not exclusively, to provide a network capable of following the growth of the network administration capacity, that is to say, to optimize the passage scale, easily accepting the addition of a new transparent access point for users, supporting the management of users, not imposing new constraints on the mobility of users, that is to say that is, each authorized user must be able to connect to each access point of the network, supporting simplified management, not introducing constraints on data transfer rates and delays at the data transport level, not imposing constraints at the network plan service level.
  • Another objective of the invention is to propose a solution that does not reduce network performance and allows no point of weakness, and whose impact partial failure must be limited to faulty equipment.
  • Another objective of the invention is to propose a solution offering user profile support of the AAA type, for example, with identical or equivalent user management possibilities, with for each user the possibility of being able to access each part of the network.
  • this communication network comprises, according to a first aspect, at least equipment integrating means ensuring the administration of the network, the administration of the network including in particular, but not exclusively, the management of data in the network equipment. , network monitoring, network control, including but not limited to network access control management, and network equipment comprising routers, access controllers and / or switches.
  • the means for administering the network comprise data enabling the identification of the users, the configuration parameters of the network equipment, and / or the addresses to which the equipment must connect to send or receive information.
  • At least one equipment of the network is provided with means to act as an access point.
  • the invention provides a communication method in a network comprising a plurality of interconnected equipment, the method comprising the steps of: - configuring at least one network device, comprising at least the data storage enabling communication between the network equipment, these data include at least data allowing the identification of the equipment in the network and data ensuring the security of the exchanges;
  • network construction comprising at least the addition of a node in the network, and at least a division of tasks among at least some of the network equipment concerning the administration of the network; and processing data stored in the equipment, said processing comprising at least the operations of allowing each equipment to retrieve distributed data between the network equipment, erasing data if necessary, and / or recording or modifying data already stored.
  • the construction of the network comprises the automatic addition of a node when the node is operational.
  • FIG. 1a presents a network using the SNMP architecture
  • Figure Ib shows a network using the AAA architecture
  • FIG. 2a shows a possible configuration of a network using the AAA architecture
  • FIG. 2b shows another possible configuration of a network using the AAA architecture
  • FIG. 3 shows a configuration of the control plane according to the invention
  • - Figure 4 shows an example of a CAN table with 2 dimensions with 5 nodes
  • Figure 5 shows a preferred embodiment of a network according to the invention
  • FIG. 6 shows a distribution of management zones according to the invention
  • network plan devices are organized directly and deployed to create a peer-to-peer network, also known as P2P (peer-to-peer), for example for the storage of data relating to access control, network management or the entity configuration, as shown in Figure 3.
  • P2P peer-to-peer
  • the part of the control plane of the network equipment for example the AAA client or the SNMP agent
  • P2P module (3) thus contains the necessary data of the control plane.
  • the administrative load is distributed among all the network plan equipment (30) (eg routers or access points). ). Thus, each equipment in the control plan is only concerned with part of the total administrative burden.
  • a network access control is integrated in the equipment making the link with the user.
  • This network access control has an internal network architecture developing recent advances in P2P networking.
  • the P2P network thus formed can be used for any standard task of the control plane such as the management of deployed equipment, mobility support or automatic configuration. For this, other equipment or additional P2P nodes can be added to this P2P network.
  • IEEE 802.11 access points could form an independent P2P dedicated network, storing the distributed user database used for IEEE 802 IX network access control.
  • DHT Distributed Hash Tables
  • a DHT is a hash table divided into several parts. These parts are distributed between certain customers now typically forming a dedicated network. Such a network allows the user to store and retrieve information in pairs (key, data) as illustrated by traditional hash tables known to those skilled in the art. They require specific rules and algorithms.
  • Famous examples of distributed hash tables are file sharing / P2P networks. Each node that is part of such a P2P network is responsible for a part of the hash table called zone. Thanks to this, a central network device managing the complete hash table or its index is no longer necessary.
  • Each node participating in such a P2P network manages its part of the hash table and implements the primitives: lookup (k), store (k, d) and delete (k).
  • a node searches the P2P network for a given hash key k and obtains the data d associated with the key k. Since each node has only a fraction of the complete hash table, it is possible that k is not part of the node's fraction.
  • Each distributed hash table therefore defines an algorithm for finding the particular node n responsible for k, since this is done on a hop per hop basis with each "closer" hop of n, this is the algorithm distributed hash table routing, known to those skilled in the art.
  • the store primitive (k, d) stores a tuple comprising a key k and the associated data value d in the network, i.e. (k, d) is transmitted to a node responsible for k using the Same routing technique as with lookup.
  • delete (k) an entry is removed from the hash table, that is, the node responsible for k deletes (k, d).
  • Dedicated P2P-based networks use their own routing or data transfer mechanisms. They are optimized so that each node has only a very local view of its network neighborhood. This property is necessary for good scaling since node state does not necessarily increase with network growth.
  • the routing is deterministic and there are upper limits to the number of hops a request must make.
  • Most P2P networks exhibit logarithmic behavior with a total number of nodes.
  • CAN Content Adressable Network
  • CAN defines a standard hash-table user interface as described above.
  • the CAN network offers dedicated construction mechanisms (node node / node bootstrap), node output, routing algorithm.
  • the index of the hash table of the CAN network is a Cartesian coordinate space with dimension d on a torus d. Each node is responsible for part of the entire coordinate space.
  • Figure 4 illustrates an example of a two-dimensional CAN network with five nodes (A, B, C, D and E).
  • each node contains the area database corresponding to the assigned coordinate space and a dedicated neighbor table. The size of the latter depends solely on the dimension d.
  • the CAN network uses a dedicated build procedure (called bootstrapping) based on a well-known Domain Name System (DNS) address. This allows each node joining the network to obtain an address of one or more initiating nodes of the CAN network.
  • DNS Domain Name System
  • a bootstrap node Upon receiving a request from a new node, a bootstrap node simply responds with the Internet Protocol (IP) addresses of several randomly selected nodes that are in the recovery.
  • IP Internet Protocol
  • the join request is then sent to one of these nodes.
  • the new node then randomly chooses an index address and sends a join request for that address to one of the received IPs.
  • the CAN network uses its Routing algorithm to route this request to the node responsible for the area on which this address depends.
  • the solicited node now divides its area into two halves and retains one of the halves, the linked area database, and the list of neighbors derived from the node joining the network.
  • A is the first node and contains the entire database
  • D joins the network and randomly obtains half of the area of B on the y axis (41)
  • E joins the network and randomly gets one half of the area of D on the x-axis (40)
  • Each query contains the destination point in the index space.
  • Each receiving node not responsible for the destination point transfers this request to one of its neighbors whose coordinates are closer to the point than hers.
  • the CAN network presents various parameters:
  • Number of independent realities r by using several independent CAN indexes r within a CAN network, nodes r are responsible for the same zone. The length of the global path decreases with r (since the routing can take place in all realities in parallel and be abandoned if successful). The number of paths actually available increases. The availability of data increases as the database is replicated r times.
  • the CAN network can use a different routing measure.
  • the underlying topology can be reproduced in the overlay.
  • Node traffic exchange The same zone can be assigned to a group of nodes, reducing the number of global zones and path length.
  • FIG. 5 presents another exemplary implementation of an 802.11 wireless distributed local area network management architecture, illustrating how decentralized access control and management can be integrated with an existing population access technology.
  • This example is based on standard Transmission Control Protocol / Internet Protocol (TCP / IP) networking, known to those skilled in the art, in the core network.
  • the P2P management network consists of access points (5) according to the 802.11 standard. Each access point (5) acts as a node (6) P2P forming a logical dedicated network (8) on the physical core network.
  • This recovery stores various logical databases, mainly the user and management databases (7).
  • the user database stores user profiles of type AAA.
  • the management database assists the administrator in managing all connected access points and stores the access point parameters expressed in the respective syntax (eg, 802.11 MIB variables, proprietary manufacturer settings).
  • the requested node retrieves the corresponding profile.
  • the serving access point (5) follows the usual 802X standard procedure as an authentication with a local authentication server.
  • assistant auxiliary nodes 60
  • All nodes (5, 6) participating in the P2P network interact with one another to route requests and retrieve, store and delete data.
  • the P2P network is accessible on any connected access point.
  • n access points and no central equipment With n access points and no central equipment, it is convenient to express this relationship of trust by means of public key cryptography using signed certificates for example, to protect the establishment of a communication between two participants at any time with n secrets for n nodes.
  • the defined identity of an access point is the MAC address of its wired interface connected to the ADC.
  • Each access point requires a minimum configuration before it is deployed in the network. This is primarily necessary for secure management access to this access point.
  • the trust relationship with the access point is represented by the installation of a signed certificate on each access point.
  • the administrator sets a local administrative login (user pair / password) and sets the usual 802.11 settings (SSID, authentication node, channels and outputs used).
  • the administrator provides the starting address of the dedicated network and deploys the access point in the installation to the desired location and connecting it to the network.
  • the network is configured to balance the task load: If an access point has a heavy load, the administrator can install an additional access point nearby. If the affected access points are not CAN neighbors, they share only the 802.11 traffic load. If the access points are neighbors of the CAN, they also share the administrative burden. This is shown in Figure 6 illustrating three access points (5) installed in a large room. At the beginning, the originally installed Access Point (APl) has the entire index. At the arrival of Access Point 2, AP1 gives half of its area to Access Point 2 (AP2), thus becoming its dedicated neighbor (but not necessarily its neighbor physical). If the user data traffic is particularly high.
  • the administrator could add Access Point 3 (AP3) in the topological neighborhood of Access Point 2 to process the load of high wireless traffic.
  • AP3 Access Point 3
  • the new AP3 automatically becomes a dedicated AP2 neighbor.
  • AP2 Zone 3
  • the access point area sizes decrease in the high traffic load areas, thereby freeing up system capabilities for processing the traffic. traffic.
  • the area of APl remains relatively important, but this is justified by the lower traffic load. There is of course a trade-off between the zone management overhead and the WLAN traffic load.
  • the different data are distributed among the different devices of the network.
  • a piece of equipment serving as an access point searches for the missing data in the various equipment of the network.
  • the control plane can also be scaled. For example, increasing the number of 802.11 access points to meet traffic requirements could automatically enable the management of more users. Since there is no central element that could gradually increase the overall cost, this solution can also be used in very small networks. A larger network can be built simply by adding additional elements of the network map, such as 802.11 access points. This solution automatically follows the natural growth of the network and can perfectly be adapted to very large networks. It is also conceivable to store the data several times in the network equipment. Each equipment thus contains two databases. The data contained in the first database being different from the data contained in the second database. In this way, if a device breaks down, its data can be found in other equipment.

Landscapes

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

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

DISPOSITIF ET PROCEDE DE COMMUNICATION DANS UN RESEAU
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 (11) (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 (11) 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 Ib 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'authentifi cation 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 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 PAS (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. Hi 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 réseau de communication comprenant une pluralité d'équipements interconnectés.
Selon l'invention ce réseau de communication comprend, selon un premier aspect, au moins des équipements intégrant des moyens 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 constituant le réseau comprenant des routeurs, des contrôleurs d'accès et/ou des commutateurs.
De préférence, les moyens pour l'administration du réseau comprennent des données permettant l'identification des utilisateurs, des paramètres de configuration des équipements du réseau, et/ou des adresses vers lesquelles les équipements doivent se connecter pour envoyer ou recevoir des informations.
Avantageusement, au moins un équipement du réseau est doté de moyens pour assurer le rôle de point d' accès.
L'invention prévoit selon un deuxième aspect, un procédé de communication dans un réseau comprenant une pluralité d'équipements interconnectés, le procédé comprenant les étapes de : - configuration d'au moins un équipement du réseau, comprenant au moins le stockage de données permettant la communication entre les équipements 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 nœud dans le réseau, et au moins une répartition des tâches parmi au moins certains des équipements 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 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.
Avantageusement la construction du réseau comprend l'ajout automatique d'un nœud lorsque le nœud est opérationnel.
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 1 a présente un réseau utilisant l'architecture SNMP ; La figure Ib 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 nœuds ; 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 nœuds 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. IX.
Des exemples de mise en œuvre 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 nœud 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 nœud participant à un tel réseau P2P gère sa partie de la table de hachage et met en œuvre les primitives : lookup(k), store(k, d) et delete(k).
Avec lookup(k), un nœud 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 nœud 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 nœud. Chaque table de hachage distribuée définit donc un algorithme pour rechercher le nœud 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 nœud 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 nœud 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 nœud 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 nœud 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 nœuds.
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 nœud/amorçage de nœud), de sortie de nœud, 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 nœud 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 nœuds (A, B, C, D et E). Dans le réseau CAN, chaque nœud 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 nœuds. 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 nœud rejoignant le réseau d'obtenir une adresse d'un ou plusieurs nœuds d'amorce du réseau CAN. A la réception d'une requête d'un nouveau nœud, un nœud d'amorce répond simplement avec les adresses IP (Internet Protocol) de plusieurs nœuds 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 nœuds. Le nouveau nœud 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 nœud responsable de la zone dont cette adresse dépend. Le nœud 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 voisins dérivés du nœud 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 nœud 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 nœud 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 à : le nombre d'éventuels chemins augmente avec la dimension, entraînant ainsi une meilleure protection contre les défaillances de nœud. 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 nœuds 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 nœud : la même zone peut être affectée à un groupe de nœuds, 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 nœuds 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 nœud (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 nœud 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. IX habituelle en tant qu'authentificateur avec un serveur d'authentification local. De plus, il est possible d'inclure un quelconque nombre de nœuds (60) auxiliaires assistant, par exemple la console de l'administrateur réseau, dans ce réseau P2P. Tous les nœuds (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 nœuds. 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 par l'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, nœud 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 (APl) initialement installé dispose de l'index entier. A l'arrivée du Point d'accès 2, APl 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 APl 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. II 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

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 nœud (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 nœud (6) lorsque le nœud (6) est opérationnel.
PCT/FR2006/000552 2005-03-16 2006-03-13 Dispositif et procede de communication dans un reseau WO2006097615A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP06726081A EP1864466A1 (fr) 2005-03-16 2006-03-13 Dispositif et procede de communication dans un reseau
US11/898,859 US20080071900A1 (en) 2005-03-16 2007-09-17 Device and a method for communicating in a network

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0502584 2005-03-16
FR0502584A FR2883437B1 (fr) 2005-03-16 2005-03-16 Dispositif et procede de communication dans un reseau

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US11/898,859 Continuation-In-Part US20080071900A1 (en) 2005-03-16 2007-09-17 Device and a method for communicating in a network

Publications (1)

Publication Number Publication Date
WO2006097615A1 true WO2006097615A1 (fr) 2006-09-21

Family

ID=35219659

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2006/000552 WO2006097615A1 (fr) 2005-03-16 2006-03-13 Dispositif et procede de communication dans un reseau

Country Status (4)

Country Link
US (1) US20080071900A1 (fr)
EP (1) EP1864466A1 (fr)
FR (1) FR2883437B1 (fr)
WO (1) WO2006097615A1 (fr)

Families Citing this family (124)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8892706B1 (en) 2010-06-21 2014-11-18 Vmware, Inc. Private ethernet overlay networks over a shared ethernet in a virtual environment
US8924524B2 (en) 2009-07-27 2014-12-30 Vmware, Inc. Automated network configuration of virtual machines in a virtual lab data environment
US8619771B2 (en) 2009-09-30 2013-12-31 Vmware, Inc. Private allocated networks over shared communications infrastructure
EP2193630B1 (fr) * 2007-09-26 2015-08-26 Nicira, Inc. Système d'exploitation de réseau pour la gestion et la sécurisation des réseaux
US9092380B1 (en) * 2007-10-11 2015-07-28 Norberto Menendez System and method of communications with supervised interaction
US8195774B2 (en) 2008-05-23 2012-06-05 Vmware, Inc. Distributed virtual switch for virtualized computer systems
US8966035B2 (en) 2009-04-01 2015-02-24 Nicira, Inc. Method and apparatus for implementing and managing distributed virtual switches in several hosts and physical forwarding elements
US8964528B2 (en) 2010-07-06 2015-02-24 Nicira, Inc. Method and apparatus for robust packet distribution among hierarchical managed switching elements
US9680750B2 (en) 2010-07-06 2017-06-13 Nicira, Inc. Use of tunnels to hide network addresses
US8817621B2 (en) 2010-07-06 2014-08-26 Nicira, Inc. Network virtualization apparatus
US10103939B2 (en) 2010-07-06 2018-10-16 Nicira, Inc. Network control apparatus and method for populating logical datapath sets
US9525647B2 (en) 2010-07-06 2016-12-20 Nicira, Inc. Network control apparatus and method for creating and modifying logical switching elements
US8825900B1 (en) 2011-04-05 2014-09-02 Nicira, Inc. Method and apparatus for stateless transport layer tunneling
US9043452B2 (en) 2011-05-04 2015-05-26 Nicira, Inc. Network control apparatus and method for port isolation
US10091028B2 (en) 2011-08-17 2018-10-02 Nicira, Inc. Hierarchical controller clusters for interconnecting two or more logical datapath sets
US9369426B2 (en) 2011-08-17 2016-06-14 Nicira, Inc. Distributed logical L3 routing
US9288104B2 (en) 2011-10-25 2016-03-15 Nicira, Inc. Chassis controllers for converting universal flows
US9154433B2 (en) 2011-10-25 2015-10-06 Nicira, Inc. Physical controller
US9137107B2 (en) 2011-10-25 2015-09-15 Nicira, Inc. Physical controllers for converting universal flows
US9203701B2 (en) 2011-10-25 2015-12-01 Nicira, Inc. Network virtualization apparatus and method with scheduling capabilities
US10089127B2 (en) 2011-11-15 2018-10-02 Nicira, Inc. Control plane interface for logical middlebox services
WO2013158918A1 (fr) 2012-04-18 2013-10-24 Nicira, Inc. Utilisation de transactions pour réduire à un minimum le taux de désabonnement dans un système de commande de réseau distribué
US9047442B2 (en) 2012-06-18 2015-06-02 Microsoft Technology Licensing, Llc Provisioning managed devices with states of arbitrary type
US9231892B2 (en) 2012-07-09 2016-01-05 Vmware, Inc. Distributed virtual switch configuration and state management
US9432215B2 (en) 2013-05-21 2016-08-30 Nicira, Inc. Hierarchical network managers
US9571386B2 (en) 2013-07-08 2017-02-14 Nicira, Inc. Hybrid packet processing
US10218564B2 (en) 2013-07-08 2019-02-26 Nicira, Inc. Unified replication mechanism for fault-tolerance of state
US9602312B2 (en) 2013-07-08 2017-03-21 Nicira, Inc. Storing network state at a network controller
US9407580B2 (en) 2013-07-12 2016-08-02 Nicira, Inc. Maintaining data stored with a packet
US9197529B2 (en) 2013-07-12 2015-11-24 Nicira, Inc. Tracing network packets through logical and physical networks
US9282019B2 (en) 2013-07-12 2016-03-08 Nicira, Inc. Tracing logical network packets through physical network
US9952885B2 (en) 2013-08-14 2018-04-24 Nicira, Inc. Generation of configuration files for a DHCP module executing within a virtualized container
US9887960B2 (en) 2013-08-14 2018-02-06 Nicira, Inc. Providing services for logical networks
US9973382B2 (en) 2013-08-15 2018-05-15 Nicira, Inc. Hitless upgrade for network control applications
US9432204B2 (en) 2013-08-24 2016-08-30 Nicira, Inc. Distributed multicast by endpoints
US9503371B2 (en) 2013-09-04 2016-11-22 Nicira, Inc. High availability L3 gateways for logical networks
US9577845B2 (en) 2013-09-04 2017-02-21 Nicira, Inc. Multiple active L3 gateways for logical networks
US9674087B2 (en) 2013-09-15 2017-06-06 Nicira, Inc. Performing a multi-stage lookup to classify packets
US9602398B2 (en) 2013-09-15 2017-03-21 Nicira, Inc. Dynamically generating flows with wildcard fields
US10148484B2 (en) 2013-10-10 2018-12-04 Nicira, Inc. Host side method of using a controller assignment list
US9785455B2 (en) 2013-10-13 2017-10-10 Nicira, Inc. Logical router
US10063458B2 (en) 2013-10-13 2018-08-28 Nicira, Inc. Asymmetric connection with external networks
US10158538B2 (en) 2013-12-09 2018-12-18 Nicira, Inc. Reporting elephant flows to a network controller
US9967199B2 (en) 2013-12-09 2018-05-08 Nicira, Inc. Inspecting operations of a machine to detect elephant flows
US9569368B2 (en) 2013-12-13 2017-02-14 Nicira, Inc. Installing and managing flows in a flow table cache
US9996467B2 (en) 2013-12-13 2018-06-12 Nicira, Inc. Dynamically adjusting the number of flows allowed in a flow table cache
US9438705B2 (en) * 2013-12-16 2016-09-06 International Business Machines Corporation Communication and message-efficient protocol for computing the intersection between different sets of data
US9602392B2 (en) 2013-12-18 2017-03-21 Nicira, Inc. Connectivity segment coloring
US9602385B2 (en) 2013-12-18 2017-03-21 Nicira, Inc. Connectivity segment selection
CN104811306B (zh) * 2014-01-28 2019-07-19 西安西电捷通无线网络通信股份有限公司 实体鉴别方法、装置及系统
US9225597B2 (en) 2014-03-14 2015-12-29 Nicira, Inc. Managed gateways peering with external router to attract ingress packets
US9590901B2 (en) 2014-03-14 2017-03-07 Nicira, Inc. Route advertisement by managed gateways
US9419855B2 (en) 2014-03-14 2016-08-16 Nicira, Inc. Static routes for logical routers
US9313129B2 (en) 2014-03-14 2016-04-12 Nicira, Inc. Logical router processing by network controller
US9647883B2 (en) 2014-03-21 2017-05-09 Nicria, Inc. Multiple levels of logical routers
US9503321B2 (en) 2014-03-21 2016-11-22 Nicira, Inc. Dynamic routing for logical routers
US9413644B2 (en) 2014-03-27 2016-08-09 Nicira, Inc. Ingress ECMP in virtual distributed routing environment
US9893988B2 (en) 2014-03-27 2018-02-13 Nicira, Inc. Address resolution using multiple designated instances of a logical router
US9985896B2 (en) 2014-03-31 2018-05-29 Nicira, Inc. Caching of service decisions
US9794079B2 (en) 2014-03-31 2017-10-17 Nicira, Inc. Replicating broadcast, unknown-unicast, and multicast traffic in overlay logical networks bridged with physical networks
US9385954B2 (en) 2014-03-31 2016-07-05 Nicira, Inc. Hashing techniques for use in a network environment
US10193806B2 (en) 2014-03-31 2019-01-29 Nicira, Inc. Performing a finishing operation to improve the quality of a resulting hash
US10404613B1 (en) * 2014-03-31 2019-09-03 Amazon Technologies, Inc. Placement of control and data plane resources
US9602422B2 (en) 2014-05-05 2017-03-21 Nicira, Inc. Implementing fixed points in network state updates using generation numbers
US9742881B2 (en) 2014-06-30 2017-08-22 Nicira, Inc. Network virtualization using just-in-time distributed capability for classification encoding
US10481933B2 (en) 2014-08-22 2019-11-19 Nicira, Inc. Enabling virtual machines access to switches configured by different management entities
US10020960B2 (en) 2014-09-30 2018-07-10 Nicira, Inc. Virtual distributed bridging
US10511458B2 (en) 2014-09-30 2019-12-17 Nicira, Inc. Virtual distributed bridging
US10250443B2 (en) 2014-09-30 2019-04-02 Nicira, Inc. Using physical location to modify behavior of a distributed virtual network element
US11178051B2 (en) 2014-09-30 2021-11-16 Vmware, Inc. Packet key parser for flow-based forwarding elements
US9768980B2 (en) 2014-09-30 2017-09-19 Nicira, Inc. Virtual distributed bridging
US10469342B2 (en) 2014-10-10 2019-11-05 Nicira, Inc. Logical network traffic analysis
US9787605B2 (en) 2015-01-30 2017-10-10 Nicira, Inc. Logical router with multiple routing components
US10038628B2 (en) 2015-04-04 2018-07-31 Nicira, Inc. Route server mode for dynamic routing between logical and physical networks
US9923760B2 (en) 2015-04-06 2018-03-20 Nicira, Inc. Reduction of churn in a network control system
US10225184B2 (en) 2015-06-30 2019-03-05 Nicira, Inc. Redirecting traffic in a virtual distributed router environment
US10230629B2 (en) 2015-08-11 2019-03-12 Nicira, Inc. Static route configuration for logical router
US10057157B2 (en) 2015-08-31 2018-08-21 Nicira, Inc. Automatically advertising NAT routes between logical routers
US10204122B2 (en) 2015-09-30 2019-02-12 Nicira, Inc. Implementing an interface between tuple and message-driven control entities
US10095535B2 (en) 2015-10-31 2018-10-09 Nicira, Inc. Static route types for logical routers
US10333849B2 (en) 2016-04-28 2019-06-25 Nicira, Inc. Automatic configuration of logical routers on edge nodes
US11019167B2 (en) 2016-04-29 2021-05-25 Nicira, Inc. Management of update queues for network controller
US10484515B2 (en) 2016-04-29 2019-11-19 Nicira, Inc. Implementing logical metadata proxy servers in logical networks
US10841273B2 (en) 2016-04-29 2020-11-17 Nicira, Inc. Implementing logical DHCP servers in logical networks
US10091161B2 (en) 2016-04-30 2018-10-02 Nicira, Inc. Assignment of router ID for logical routers
US10153973B2 (en) 2016-06-29 2018-12-11 Nicira, Inc. Installation of routing tables for logical router in route server mode
US10560320B2 (en) 2016-06-29 2020-02-11 Nicira, Inc. Ranking of gateways in cluster
US10454758B2 (en) 2016-08-31 2019-10-22 Nicira, Inc. Edge node cluster network redundancy and fast convergence using an underlay anycast VTEP IP
US10341236B2 (en) 2016-09-30 2019-07-02 Nicira, Inc. Anycast edge service gateways
US10742746B2 (en) 2016-12-21 2020-08-11 Nicira, Inc. Bypassing a load balancer in a return path of network traffic
US10212071B2 (en) 2016-12-21 2019-02-19 Nicira, Inc. Bypassing a load balancer in a return path of network traffic
US10237123B2 (en) 2016-12-21 2019-03-19 Nicira, Inc. Dynamic recovery from a split-brain failure in edge nodes
US10616045B2 (en) 2016-12-22 2020-04-07 Nicira, Inc. Migration of centralized routing components of logical router
US10200306B2 (en) 2017-03-07 2019-02-05 Nicira, Inc. Visualization of packet tracing operation results
US10637800B2 (en) 2017-06-30 2020-04-28 Nicira, Inc Replacement of logical network addresses with physical network addresses
US10681000B2 (en) 2017-06-30 2020-06-09 Nicira, Inc. Assignment of unique physical network addresses for logical network addresses
US10608887B2 (en) 2017-10-06 2020-03-31 Nicira, Inc. Using packet tracing tool to automatically execute packet capture operations
US10511459B2 (en) 2017-11-14 2019-12-17 Nicira, Inc. Selection of managed forwarding element for bridge spanning multiple datacenters
US10374827B2 (en) 2017-11-14 2019-08-06 Nicira, Inc. Identifier that maps to different networks at different datacenters
US10999220B2 (en) 2018-07-05 2021-05-04 Vmware, Inc. Context aware middlebox services at datacenter edge
US11184327B2 (en) 2018-07-05 2021-11-23 Vmware, Inc. Context aware middlebox services at datacenter edges
US10931560B2 (en) 2018-11-23 2021-02-23 Vmware, Inc. Using route type to determine routing protocol behavior
US10735541B2 (en) 2018-11-30 2020-08-04 Vmware, Inc. Distributed inline proxy
US10797998B2 (en) 2018-12-05 2020-10-06 Vmware, Inc. Route server for distributed routers using hierarchical routing protocol
US10938788B2 (en) 2018-12-12 2021-03-02 Vmware, Inc. Static routes for policy-based VPN
US11394693B2 (en) * 2019-03-04 2022-07-19 Cyxtera Cybersecurity, Inc. Establishing network tunnel in response to access request
US10778457B1 (en) 2019-06-18 2020-09-15 Vmware, Inc. Traffic replication in overlay networks spanning multiple sites
US11159343B2 (en) 2019-08-30 2021-10-26 Vmware, Inc. Configuring traffic optimization using distributed edge services
US11641305B2 (en) 2019-12-16 2023-05-02 Vmware, Inc. Network diagnosis in software-defined networking (SDN) environments
US11283699B2 (en) 2020-01-17 2022-03-22 Vmware, Inc. Practical overlay network latency measurement in datacenter
US11606294B2 (en) 2020-07-16 2023-03-14 Vmware, Inc. Host computer configured to facilitate distributed SNAT service
US11616755B2 (en) 2020-07-16 2023-03-28 Vmware, Inc. Facilitating distributed SNAT service
US11611613B2 (en) 2020-07-24 2023-03-21 Vmware, Inc. Policy-based forwarding to a load balancer of a load balancing cluster
US11902050B2 (en) 2020-07-28 2024-02-13 VMware LLC Method for providing distributed gateway service at host computer
US11451413B2 (en) 2020-07-28 2022-09-20 Vmware, Inc. Method for advertising availability of distributed gateway service and machines at host computer
US11558426B2 (en) 2020-07-29 2023-01-17 Vmware, Inc. Connection tracking for container cluster
US11570090B2 (en) 2020-07-29 2023-01-31 Vmware, Inc. Flow tracing operation in container cluster
US11196628B1 (en) 2020-07-29 2021-12-07 Vmware, Inc. Monitoring container clusters
US11736436B2 (en) 2020-12-31 2023-08-22 Vmware, Inc. Identifying routes with indirect addressing in a datacenter
US11336533B1 (en) 2021-01-08 2022-05-17 Vmware, Inc. Network visualization of correlations between logical elements and associated physical elements
US11784922B2 (en) 2021-07-03 2023-10-10 Vmware, Inc. Scalable overlay multicast routing in multi-tier edge gateways
US11687210B2 (en) 2021-07-05 2023-06-27 Vmware, Inc. Criteria-based expansion of group nodes in a network topology visualization
US11711278B2 (en) 2021-07-24 2023-07-25 Vmware, Inc. Visualization of flow trace operation across multiple sites
US11706109B2 (en) 2021-09-17 2023-07-18 Vmware, Inc. Performance of traffic monitoring actions

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2359691A (en) * 2000-02-23 2001-08-29 Motorola Israel Ltd Distributed network monitoring with static/dynamic data discrimination
US20030135611A1 (en) * 2002-01-14 2003-07-17 Dean Kemp Self-monitoring service system with improved user administration and user access control

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7555553B2 (en) * 2002-10-01 2009-06-30 Hewlett-Packard Development Company, L.P. Placing an object at a node in a peer-to-peer system based on storage utilization
US7870218B2 (en) * 2003-04-09 2011-01-11 Nec Laboratories America, Inc. Peer-to-peer system and method with improved utilization
US7483391B2 (en) * 2003-09-19 2009-01-27 Hewlett-Packard Development Company, L.P. Providing a notification including location information for nodes in an overlay network
US7644167B2 (en) * 2004-01-30 2010-01-05 Hewlett-Packard Development Company, L.P. Identifying a service node in a network
US7590589B2 (en) * 2004-09-10 2009-09-15 Hoffberg Steven M Game theoretic prioritization scheme for mobile ad hoc networks permitting hierarchal deference
US7826396B2 (en) * 2005-03-07 2010-11-02 Miller John L System and method for implementing PNRP locality

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2359691A (en) * 2000-02-23 2001-08-29 Motorola Israel Ltd Distributed network monitoring with static/dynamic data discrimination
US20030135611A1 (en) * 2002-01-14 2003-07-17 Dean Kemp Self-monitoring service system with improved user administration and user access control

Also Published As

Publication number Publication date
FR2883437A1 (fr) 2006-09-22
US20080071900A1 (en) 2008-03-20
EP1864466A1 (fr) 2007-12-12
FR2883437B1 (fr) 2007-08-03

Similar Documents

Publication Publication Date Title
WO2006097615A1 (fr) Dispositif et procede de communication dans un reseau
FR2801754A1 (fr) Methode pour assigner une double adresse ip a un poste de travail relie a un reseau de transmission de donnees ip
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
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
EP3787344A1 (fr) Procédé de configuration d'un système d'extension de couverture de communication sans-fil et un système d'extension de couverture de communication sans-fil mettant en oeuvre ledit procédé
US20230119540A1 (en) Content delivery system special network device and special local area network connection, content discovery, data transfer, and control methods
EP3682600B1 (fr) Gestion de la connexion avec d'autres passerelles residentielles d'une passerelle residentielle mettant en oeuvre l'agregation de liens
Ford UIA: A global connectivity architecture for mobile personal devices
EP2979435B1 (fr) Procédé de traitement de donnés d'utilisateur d'un réseau social
EP2446360B1 (fr) Technique de determination d'une chaine de fonctions elementaires associee a un service
EP3829101B1 (fr) Procede de securisation de flux de donnees entre un equipement de communication et un terminal distant, equipement mettant en oeuvre le procede
CA3153796A1 (fr) Procede de connexion d'un noeud de communication, et noeud de communication correspondant
WO2021191535A1 (fr) Procede de delegation entre reseaux informatiques de peripherie a acces multiples
WO2012004492A1 (fr) Accès confidentiel ou protégé à un réseau de nœuds répartis sur une architecture de communication à l'aide d'un serveur de topoloqie
EP4145798B1 (fr) Procédé de configuration d'une jonction pour un routage conforme au protocole de passerelle de bordure _ bgp et routeur de bordure associé
EP2446608B1 (fr) Technique de contrôle d'accès par une entité cliente à un service
WO2023111432A1 (fr) Mécanismes de communication avec un service accessible via un réseau de télécommunication prenant en compte la mobilité des services, des utilisateurs et des équipements
FR3138254A1 (fr) Procédé de fédération dynamique d'une plurialité de réseaux de radiocommunication, programme d'ordinateur et réseau associés
Kim et al. Marconi Protocol
FR3118561A1 (fr) Procede de configuration d'une interface securisee entre un reseau de transport et un reseau elementaire d'une pluralite de reseaux elementaires federes a travers le reseau de transport ; interface associee
FR2856540A1 (fr) Architecture de reseau local sans fil
Pathak Developing Peer-to-Peer Applications with WCF
Kokkinen et al. Towards distributed service provisioning
Peiris et al. Developing Peer-to-Peer Applications with WCF
Innovate et al. Ali Sajjad1, Andrea Zisman1, Muttukrishnan Rajarajan1, Srijith K. Nair2 and Theo Dimitrakos2

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 11898859

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

NENP Non-entry into the national phase

Ref country code: RU

WWE Wipo information: entry into national phase

Ref document number: 2006726081

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Country of ref document: RU

WWP Wipo information: published in national office

Ref document number: 2006726081

Country of ref document: EP

WWP Wipo information: published in national office

Ref document number: 11898859

Country of ref document: US