Gluon: Demande de fonctionnalité : utilisez les fonctionnalités 802.11s pour un meilleur contrôle des maillages

Créé le 7 juil. 2017  ·  4Commentaires  ·  Source: freifunk-gluon/gluon

Pour de meilleures performances, il pourrait être agréable de contrôler certains Mesh-Links
Le 802.11s propose certaines options que nous pourrions utiliser pour contrôler les maillages d'un nœud.

Par exemple, nous pourrions fournir une liste blanche ou noire des nœuds avec lesquels le nœud est maillé :
https://github.com/o11s/open80211s/wiki/HOWTO#advanced -bricolage

les autres paramètres 802.11s possibles sont :
Les paramètres de maillage possibles sont :

  • mesh_retry_timeout
  • mesh_confirm_timeout
  • mesh_holding_timeout
  • mesh_max_peer_links
  • mesh_max_retries
  • mesh_ttl
  • mesh_element_ttl
  • mesh_auto_open_plinks
  • mesh_hwmp_max_preq_retries
  • mesh_path_refresh_time
  • mesh_min_discovery_timeout
  • mesh_hwmp_active_path_timeout
  • mesh_hwmp_preq_min_interval
  • mesh_hwmp_net_diameter_traversal_time
  • mesh_hwmp_rootmode
  • mesh_hwmp_rann_interval
  • mesh_gate_announcements
  • mesh_fwding
  • mesh_sync_offset_max_neighor
  • mesh_rssi_threshold
  • mesh_hwmp_active_path_to_root_timeout
  • mesh_hwmp_root_interval
  • mesh_hwmp_confirmation_interval
  • mesh_power_mode
  • mesh_awake_window
  • mesh_plink_timeout

Ce serait également bien si les paramètres de vidage de la station iw dev mesh0, tels que les débits binaires et le débit attendu, pouvaient être affichés sur la page d'état. (à propos : je pense que l'intervalle de balise de 100 pourrait être plus long.)

enhancement rfc

Commentaire le plus utile

Je pense que la plupart des options 11s ne sont pas très intéressantes pour nous, car nous prenons toutes les décisions de routage dans un protocole de routage de couche supérieure et n'utilisons que 11s en remplacement du mode adhoc.

Certains travaux sur l'autorisation de mettre les liens sur liste noire ont été effectués dans freifunk-gluon/packages#118, mais ils ne sont pas terminés.

Augmenter l'intervalle de balise est probablement une bonne idée, nous devons simplement choisir une bonne valeur (de plus, tous les VIF utilisent le même intervalle de balise, donc les changements affecteront également les interfaces AP).

Tous les 4 commentaires

Je pense que la plupart des options 11s ne sont pas très intéressantes pour nous, car nous prenons toutes les décisions de routage dans un protocole de routage de couche supérieure et n'utilisons que 11s en remplacement du mode adhoc.

Certains travaux sur l'autorisation de mettre les liens sur liste noire ont été effectués dans freifunk-gluon/packages#118, mais ils ne sont pas terminés.

Augmenter l'intervalle de balise est probablement une bonne idée, nous devons simplement choisir une bonne valeur (de plus, tous les VIF utilisent le même intervalle de balise, donc les changements affecteront également les interfaces AP).

L'augmentation de l'intervalle de balise ne résoudra pas le problème d'encombrement d'une fréquence. Ne vous attendez pas à une augmentation importante de la bande passante à partir de cela (maximum 10%). Ce que vous voulez vraiment, c'est du TDMA ou au moins du RTS/CTS en cas de chevauchement des BSS. Par exemple, http://netshe.ru/ a construit une implémentation TDMA basée sur batadv14 qui n'utilise pas la perte de paquets mais les informations wifi nl80211 pour les calculs métriques (mais c'est une source fermée et pas assez bien entretenue).
ATH9K HMAC https://github.com/szehl/ath9k-hmac est une implémentation de preuve de concept consistant à utiliser un petit hack pour faire fonctionner TDMA sans casser CSMA/CA. Avec celui-ci, on pourrait s'assurer que les réseaux AP n'interfèrent pas avec les réseaux Mesh, mais il faudrait quelqu'un comme NeoRaider pour nettoyer cela pour la prise en charge du noyau en amont. L'interface de communication netlink de l'espace utilisateur est écrite en C++ et doit d'abord être réécrite en C. Il n'y a pas non plus de gestionnaire pour le paramétrage dynamique des règles TDMA.

J'ai peut-être trouvé un problème qui aggrave les performances du 802.11.
Les 802.11s ont une fonctionnalité appelée MCCA qui est un mécanisme d'évitement des collisions fonctionnant de manière similaire à TDMA. Tous les voisins 802.11s sont synchronisés (voir Synchronisation du maillage 802.11s ) par défaut. C'est étonnamment précis (moyenne <10 microsecondes). Contrairement à TDMA, MCCA n'utilise pas de tranches de temps mais des intervalles DTIM. Un nœud 802.11s peut demander via monodiffusion ou multidiffusion un tel intervalle DTIM pour son utilisation. Tous les nœuds voisins refuseront ou accepteront cela via une réponse en fonction de tout chevauchement avec leurs propres intervalles. Ainsi, MCCA est une sorte de fonctionnalité TDMA auto-organisée pour les 802.11, ce qui est vraiment cool et j'aurais aimé le savoir avant.

Autant que je sache, les intervalles DTIM de l'interface de maillage n'ont aucun effet sur les autres VIF.

Edit: Je pense que ce n'est pas le gros problème car il semble que MCCA ne soit pas du tout implémenté dans ath9k. EDCA pourrait-il avoir des problèmes avec plusieurs VIF (utilise-t-il la planification des files d'attente) ? Qu'en est-il des pilotes broadcom/ralink ? Je pense que l'on pourrait vérifier les IE si le code est source fermée ou tout simplement trop confus. Malheureusement, je ne connais pas le format correct pour cela et je n'ai trouvé que ceci :

Chaque station peut
activer sa prise en charge de MCCA et afficher cette prise en charge en définissant sur 1 le bit MCCA Enabled,
qui se trouve dans le sous-champ Capacité de maillage de l'élément de configuration de maillage présent dans
les balises et les réponses des sondes. Une autre station peut prendre en charge MCCA mais ne pas l'implémenter (la
Le sous-champ Capacité de maillage comprend également un bit pris en charge par MCCA). Dans ce cas, la station peut
participer au mécanisme MCCA, mais ne peut initier aucune réservation MCCA.
voir https://www.cwnp.com/uploads/802-11s_mesh_networking_v1-0.pdf

Clôture : La plupart des options 11s ne sont pas pertinentes pour Gluon. Si nous trouvons une option spécifique intéressante à soutenir, une question distincte devrait être ouverte.

Voir également:

  • #421 (blocage des liens de maillage individuels)
  • #2028 (configuration d'intervalle de balise)
Cette page vous a été utile?
0 / 5 - 0 notes