Se connecter
Pas encore inscrit?
RSS facebook

JhACKeur

Controle coopératif chez Aerohive

Grâce à l’utilisation du contrôle coopératif – une technologie clé de l’architecture Aerohive – les HiveAP sont capable de fournir, en coopérant avec leurs voisins, des fonctions avancées de contrôle telles que la gestion dynamique des radios fréquences, la mobilité niveau 2/niveau 3, le partage de la charge des clients, le maillage par la radio,… éliminant ainsi tout besoin d’équipement central prenant l’ensemble des décisions et contrôlant l’infrastructure.

Les protocoles de contrôle coopératif

Le contrôle coopératif, auto-organisé, repose sur les protocoles suivants :

Ces protocoles de contrôle coopératif permettent aux points d’accès HiveAP de travailler ensembles tel un seul système fournissant mobilité, sécurité, contrôle de l’espace radio et des fréquences, évolutivité et résilience : des fonctions essentielles pour les réseaux sans fil d’entreprises.

Auto-découverte et auto-organisation des HiveAP

L’architecture à contrôle coopératif simplifie les déploiements en série de HiveAP en permettant aux points d’accès de se découvrir mutuellement et automatiquement et en synchronisant pro-activement leur état réseau.
Les HiveAP peuvent ainsi se découvrir mutuellement selon qu’ils sont connectés entre eux via le réseau câblé (en filaire) ou via le réseau sans fil (en radio). Lorsque l’on allume un HiveAP, il commence à sonder son voisinage réseau (filaire et radio) à la recherche de voisins. Si ces voisins partagent la même ruche (hive) et le même secret, alors une connexion sécurisée est établie entre ce HiveAP et chacun de ses voisins en utilisant l’algorithme de chiffrement AES si la communication est effectuée via le lien montant filaire, ou WPA2 et AES-CCMP si la communication est réalisée via le lien montant radio.
Une fois les connexions établies entre voisins membres d’une même ruche, les messages des protocoles de contrôle coopératif sont échangés permettant la mise en œuvre des différentes fonctions avancées évoquées précédemment.
Si un HiveAP découvre dans son voisinage un autre HiveAP, membre de la même ruche et partageant le même secret, mais dans un sous-réseau différent, alors ils échangeront mutuellement leurs informations et établiront des communications IP via le réseau routé (niveau 3) de manière dynamique et uniquement lorsque nécessaire. Les fonctions de contrôle coopératif sont ainsi implémentées même au niveau de la couche 3.
L’intérêt majeur des protocoles de contrôle coopératif réside dans le fait qu’ils n’ont pas besoin d’être configurés au préalable mais s’exécutent automatiquement et sans intervention d’un administrateur réseau, permettant ainsi une diminution importante des coûts opérationnels et des efforts nécessaires au déploiement d’une solution de réseau sans fil moderne et évolutive.

Contrôle coopératif des radios fréquences

Dans le but d’éliminer les interférences provenant d’un même canal radio ou de canaux adjacents, et afin de pouvoir réagir aux changements dans l’environnement radio, les points d’accès HiveAP utilisent le protocole ACSP (Automatic Channel Selection Protocol) pour coopérer entre eux et sélectionner automatiquement les meilleurs canaux radios que chacun utilisera. ACSP assure une utilisation optimale de l’espace radio et des canaux pour une plus grande performance du réseau sans fil.

controle_cooperatif_aerohive.jpg

Les HiveAP utilisent ACSP afin de scanner les canaux radios et construire des tables listant les équipements sans fil découverts dans l’espace radio. Ces tables sont ensuite utilisées pour identifier et classifier les interférences. Les HiveAP s’échangent alors mutuellement les informations relatives à ACSP et utilisent les données collectées pour s’assigner un canal et un niveau de puissance d’émission fonction de la topologie et de la configuration du réseau sans fil.
Si les 2 radios (a et b/g) d’un même point d’accès HiveAP sont utilisées pour l’accès des clients sans fil, alors ACSP détermine les canaux optimaux utilisés par les radios du HiveAP afin de minimiser les interférences avec ses voisins. Ceci s’effectue en garantissant que chaque HiveAP utilise un canal différent de ses voisins immédiats et en ajustant la puissance d’émission pour minimiser les interférences avec les HiveAP plus distants mais utilisant le même canal.
Si un point d’accès HiveAP utilise l’une de ses deux radios comme lien montant vers le réseau (connexion maillée backhaul), alors ACSP va déterminer le canal utilisé par les HiveAP pour pouvoir communiquer ensemble via ce lien montant radio, tout en continuant de minimiser les interférences pour l’accès des clients sans fil sur l’autre radio.
Afin d’obtenir des performances optimales sur le réseau sans fil, ACSP peut être programmé pour redéfinir quotidiennement, à une heure configurable et quand les clients ne sont pas connectés, la répartition des canaux radios. Ceci permet de s’assurer que les canaux radios ne sont pas modifiés lorsqu’ils sont utilisés par des clients sans fil, évitant ainsi toute interruption de service.

La mobilité dans un réseau sans fil

Les problèmes de mobilité avec les points d’accès autonomes

La mobilité rapide (le passage d’un point d’accès Wi-Fi à un autre que l’on appelle souvent roaming ou handover) est généralement définie comme intervenant en quelques dizaines de millisecondes afin de ne pas être perceptible par l’utilisateur humain.
Ceci est particulièrement important lorsque l’on exécute des applications temps-réel telles que la voix où une interruption dans la connexion peut engendrer des blancs dans la conversation, du bruit de fond, voire même des pertes d’appel.
Avec les points d’accès autonomes traditionnels, indépendants les uns des autres, la mobilité rapide et transparente sur le réseau sans fil sécurisé, utilisant la norme IEEE 802.1X et EAP pour l’authentification, n’est tout simplement pas possible.

controle_cooperatif_aerohive2.jpg

Ceci s’explique par le fait que, durant l’authentification, la serveur Radius, le client sans fil et le point d’accès échangent des informations et génèrent des clés de chiffrement utilisées ensuite pour communiquer de manière sécurisée entre eux.
Si le client sans fil erre et se connecte sur un autre point d’accès, celui-ci ne disposant pas des clés créées lors de la connexion initiale avec le précédent point d’accès, le client sans fil doit alors répéter complètement le processus d’authentification et de génération des clés avec le nouveau point d’accès.
Au cours de ce processus, les sessions existantes, particulièrement sensibles au temps d’inactivé, sont alors perdues. C’est notamment valable pour les communications voix et même les simples transferts de fichiers qui sont alors interrompus et doivent être réinitialisés.

La solution de mobilité Aerohive rapide et transparente (layer 2 roaming)

Aerohive a résolu ce problème critique des points d’accès autonomes par l’utilisation du protocole de routage AMRP présenté précédemment.
Grâce à AMRP, et qu’ils soient connectés en filaire ou en radio les uns aux autres, les points d’accès HiveAP voisins coopèrent entre eux afin de s’échanger de manière prédictive l’état d’authentification des clients, les informations d’identité et les clés de chiffrement.
Ceci permet aux clients d’errer entre différents points d’accès HiveAP d’un même voisinage de manière rapide, transparente et sécurisée.

Le diagramme ci-après liste les différentes étapes du processus d’itinérance rapide entre plusieurs HiveAP.

controle_cooperatif_aerohive3.jpg

Parallèlement à la distribution des clés entre les HiveAP voisins, AMRP distribue également les informations d’identité des utilisateurs afin de permettre l’application continue des règles de firewall et des paramètres de qualité de service (QoS) qui sont propres à chaque profil d’utilisateurs. Ainsi, tout au long de l’itinéraire de l’utilisateur mobile, la sécurité et la qualité de service sont maintenues.

La solution de mobilité Aerohive rapide et sécurisée de niveau 3 (layer 3 roaming)

La mobilité dans les réseaux IP traditionnels est un véritable challenge du fait que lorsque les utilisateurs errent d’un sous-réseau à un autre sous-réseau, leurs paramètres IP changent, entrainant des coupures et des terminaisons pour les applications qui reposent sur des sessions IP.
Pour permettre aux utilisateurs de maintenir leurs paramètres IP et leurs connections réseaux au cours de leur processus d’itinérance sur le réseau sans fil, Aerohive a développé le protocole DNXP (Dynamic Network Extension Protocol).
Au moment où un utilisateur mobile erre d’un HiveAP à un autre HiveAP connecté à un sous-réseau IP différent, DNXP est utilisé pour établir dynamiquement un tunnel (Ce tunnel est un tunnel GRE (Generic Routine Encapsulation), de niveau 2, normalisé par l’IETF (RFC 2784)) initié depuis le nouveau HiveAP vers l’ancien HiveAP d’où est originaire l’utilisateur. Le trafic de l’utilisateur est alors totalement envoyé dans ce tunnel directement vers son sous-réseau IP initial, permettant ainsi au client de conserver ses paramètres IP d’origine (en particulier son adresse IP), ses informations d’authentification et d’identité, ses clés de chiffrement, ses paramètres de sécurité réseau (firewall) et de qualité de service (QoS),… et ce bien que l’utilisateur soit maintenant connecté à un HiveAP d’un sous-réseau totalement distinct.
Cette technique est particulièrement appréciable lorsque les clients mobiles utilisent des applications de voix sur le réseau sans fil (VoWLAN).
Lorsque l’itinérance de niveau 3 est active, les HiveAP prennent connaissance de leurs voisins de niveau 3 (dans un sous-réseau distinct) soit par configuration de l’administrateur réseau (sur le HiveManager), soit par découverte automatique en sondant les canaux radios. Alors, les points d’accès HiveAP construisent des relations de voisinage entre eux.

controle_cooperatif_aerohive4.jpg

Lorsque des voisins de niveau 3 sont découverts, les HiveAP de sous-réseaux différents échangent leurs listes de portails HiveAP disponibles ainsi que la liste des clients connectés et le contenu de leur cache d’itinérance (roaming cache contenant la clé PMK, l’identifiant PMKID, les adresses MAC du client et du HiveAP initial, la durée de vie de la clé,…). Ceci s’effectue uniquement entre voisins. De cette manière, si un client erre vers un nouveau sous-réseau, le HiveAP de ce nouveau réseau connait de manière proactive le client et peut dynamiquement construire le tunnel qui lui permet de renvoyer le trafic du client vers son HiveAP initial dans son sous-réseau d’origine, permettant ainsi un processus de mobilité rapide, sécurisée, transparente pour l’utilisateur et ses applications.
Le diagramme ci-après présente les différentes étapes réalisées par les HiveAP au cours du processus d’errance d’un client mobile entre différent sous-réseaux IP.

controle_cooperatif_aerohive5.jpg

Les tunnels sont établis et maintenus uniquement en fonction du besoin et sont automatiquement terminés s’ils ne sont pas utilisés par le client (par exemple, lorsque le client n’a plus aucune session ouverte). De plus, un même tunnel peut être utilisé par de multiples clients, ce qui permet d’optimiser les échanges entre HiveAP et d’augmenter les performances du réseau.
En résumé, grâce aux HiveAP et au contrôle coopératif, les clients sans fil ont la possibilité d’errer de manière rapide et sécurisée au sein de l’infrastructure réseau sans fil reposant sur les points d’accès HiveAP, au sein d’un même sous-réseau IP ou entre différents sous-réseaux, et ce sans impacter les applications du client et les connexions voix.

Équilibrage de la charge du tunnel dans des environnements à forte mobilité de niveau 3

Le procédé de mobilité transparente de niveau 3 proposé par Aerohive permet une facilité dans la gestion du chemin parcouru par des clients sans fil au sein du réseau et une importante évolutivité grâce à l’utilisation de l’équilibrage de la charge des tunnels, permettant ainsi de distribuer lesdits tunnels entre différents portails HiveAP d’un même sous-réseau.
Ce procédé étend le principe plus général de distribution de la capacité de traitement entre différents HiveAP afin de supporter plusieurs milliers de tunnels pour l’itinérance de niveau 3 et un débit cumulé de plusieurs gigabits entre différents sous-réseaux.
Lorsqu’un HiveAP d’un sous-réseau distant tente d’établir un tunnel avec un autre HiveAP du sous-réseau d’origine, si ledit HiveAP connecté au sous-réseau initial a un niveau de charge élevé, alors il en informe le HiveAP du sous-réseau distant et lui demande d’établir le tunnel avec un autre portail HiveAP de son sous-réseau. Ceci évite d’utiliser à outrance un unique HiveAP pour terminer les tunnels GRE.

Equilibrage de la charge des clients sans fil

Très souvent dans un réseau sans fil, les utilisateurs d’une même zone géographique sont, à leur insu, tous connectés au même point d’accès qui est alors surchargé, quand bien même d’autres points d’accès aux alentours sont sous-utilisés. Ceci peut avoir un impact significatif sur les performances des connexions des clients et peut entrainer des désagréments d’utilisation.
En conséquence, il est logique d’encourager les clients à se connecter sur les points d’accès les moins sollicités. Afin de distribuer les clients entre plusieurs HiveAP d’une même infrastructure de contrôle coopératif, Aerohive a implémenté un procédé d’équilibrage de la charge sur ses HiveAP.
Dans le cas où un HiveAP devient démesurément utilisé, et en fonction de la charge totale du système, de la quantité de connexions voix, du nombre total de clients attachés au HiveAP et de la qualité du signal desdits clients, le HiveAP peut décider de transférer une partie de sa charge provenant des clients vers un autre HiveAP plus approprié car moins sollicité, tout en contrôlant l’admission des clients afin de prévenir toute surexploitation du procédé.
Ce dernier point est très important puisqu’il permet de s’assurer que la charge sur un HiveAP est suffisamment contrôlée et capée afin de permettre à des clients potentiellement itinérants de se connecter en cas de mobilité. Ce procédé est particulièrement utile pour la voix sur le réseau sans fil car il permet de s’assurer que le HiveAP dispose d’assez de capacité libre pour accueillir des clients voix mobiles et qu’il y a suffisamment de temps d’antenne disponible pour garantir la qualité de la communication voix.