Résumé
- L'ensemble des doublons d'OLSR atteste qu'un nœud a déjà enregistré une identité de message de contrôle pendant une durée donnée. Il ne constitue pas un accusé de réception collectif des branches qui devaient être atteintes.
- Pour expliquer un résultat, il faut conserver séparément l'observation HELLO, la sélection des relais, la réception et la retransmission des TC, l'état topologique accepté, l'installation de route, le passage des paquets et la réponse de l'application.
« Déjà vu » répond à une seule question
Un message de contrôle arrive avec une adresse d'origine et un numéro de séquence. Le nœud consulte son ensemble des doublons. Une entrée correspondante existe déjà. Selon les règles de RFC 3626, il peut éviter un nouveau traitement ou une nouvelle retransmission.
Le protocole vient de répondre à une question locale : ai-je déjà enregistré cette identité de message pendant sa période de validité ? Il n'a pas répondu à la question que l'exploitation voudrait souvent lui faire porter : le message a-t-il été diffusé partout où il devait l'être ?
RFC 3626, publié en octobre 2003, décrit l'Optimized Link State Routing Protocol comme protocole expérimental pour les réseaux mobiles ad hoc. Ce n'est pas une norme Internet. Son économie repose sur une idée raisonnable : au lieu de demander à chaque voisin de répéter chaque diffusion, chaque nœud choisit un sous-ensemble de voisins symétriques, les relais multipoints ou MPR, capable de couvrir le voisinage strict à deux sauts.
Cette couverture offre une possibilité de propagation. L'ensemble des doublons évite qu'elle ne devienne une tempête. Entre les deux reste l'événement réel : qui a reçu, qui a retransmis, qui a perdu et qui a accepté ? Une architecture de preuve doit garder cette question ouverte jusqu'aux observations suivantes.
HELLO fabrique une vue, pas le terrain
Les messages HELLO sont diffusés sur l'interface locale et ne sont jamais relayés. Ils servent à détecter les liens, à maintenir le voisinage à un et deux sauts, à annoncer la volonté de relayer et à signaler les sélections MPR.
Un lien dit symétrique est donc une conclusion du mécanisme à partir de messages reçus. Le tuple correspondant dispose d'une durée de validité. Il peut rester exploitable entre deux observations, justement pour tolérer des pertes ordinaires et éviter une topologie qui clignote à chaque silence radio.
Il faut respecter la portée de ce registre. « Symétrique » signifie que les conditions de l'état OLSR sont satisfaites, pas que le support est mesuré en continu. « Voisin à deux sauts » signifie qu'une relation a été annoncée par un voisin symétrique, pas que de la capacité a été réservée. « Valide » signifie que l'échéance du tuple n'est pas atteinte, pas que le monde physique vient d'être relu.
Une trace utile associe donc chaque tuple à l'interface, à l'origine du HELLO, à l'heure de réception, à la durée annoncée et à la version du voisinage qui a servi au calcul. Sans cette provenance, l'écran montre une carte dont personne ne peut expliquer l'âge.
La sélection MPR délègue une fonction limitée
Le calcul MPR doit couvrir chaque voisin strict et symétrique à deux sauts par au moins un voisin sélectionné. La petitesse de l'ensemble réduit la surcharge, mais la minimalité n'est pas une condition absolue. Le paramètre local MPR_COVERAGE peut même rechercher plusieurs couvertures lorsque la redondance est souhaitée.
Cette règle ne promet pas plusieurs livraisons indépendantes. Une couverture de deux peut reposer sur deux relais exposés à la même interférence, à la même alimentation ou au même défaut logiciel. Elle compte des options dans la vue locale ; elle ne mesure ni leur indépendance ni leur résultat.
La volonté annoncée ajoute une autre dimension. WILL_NEVER interdit la sélection ; WILL_ALWAYS l'impose au départ de l'heuristique. Cette valeur peut exprimer une politique énergétique ou une préférence d'exploitation. Ce n'est ni un test de capacité, ni une garantie de disponibilité. Le paramètre produit pourtant une conséquence concrète sur les nœuds choisis et sur les liens qui seront ensuite annoncés.
Le propriétaire de cette politique doit être identifiable. Il faut conserver la valeur, sa justification, sa durée et les sélections qu'elle a modifiées. Une déclaration de volonté crée une attente de fonction ; seule l'observation du comportement peut produire une preuve de performance.
La branche silencieuse disparaît du récit
Imaginons qu'un TC atteigne un relais, soit enregistré dans l'ensemble des doublons, puis ne reparte pas vers une branche. La cause peut être un critère de sélection, une interface, une expiration, une perte ou un défaut. Le nœud possède un reçu local parfaitement cohérent : message vu. Les nœuds en aval ne possèdent rien.
Si le tableau de bord ne collecte que le compteur des doublons, il peut même interpréter l'activité comme une bonne redondance. Pourtant la seule information certaine est que des copies ont atteint certains points. La frontière de diffusion demeure inconnue.
Il faut donc échantillonner la chaîne réception–décision–retransmission sur des branches représentatives. Pour chaque message important : origine, séquence, interface d'arrivée, relation de sélecteur MPR, état du doublon, décision de transmettre, interface de sortie et réception en aval. L'absence d'un doublon est elle aussi ambiguë : message nouveau, perdu ou entrée expirée.
L'optimisation autorise la suppression d'un travail prédit inutile. Elle ne doit pas supprimer les éléments qui permettraient de vérifier la prédiction.
TC compresse la topologie une seconde fois
Les nœuds choisis comme MPR émettent des messages Topology Control. Un TC doit annoncer au moins les liens vers les voisins qui ont sélectionné son émetteur comme relais. Ces messages sont à leur tour diffusés par les MPR. Les récepteurs construisent des tuples topologiques temporaires et calculent leurs routes.
Le numéro ANSN ordonne les versions de l'ensemble de voisins annoncés, y compris après bouclage du compteur. Il permet de dire qu'une annonce acceptée est plus récente qu'une autre. Il ne transforme pas la nouvelle annonce en observation instantanée du support radio.
De plus, un ensemble annoncé peut être réparti sur plusieurs TC si la taille des messages l'exige. Lire un seul fragment comme inventaire complet est une erreur de mesure. Le reçu doit regrouper les fragments attendus dans la période de rafraîchissement et lier leur origine, leur numéro, leur durée de validité et la version topologique résultante.
La chaîne a donc deux compressions. Le choix MPR réduit les relais de diffusion ; l'annonce TC réduit l'information de liens nécessaire au calcul. Ces gains sont le but du protocole. Mais plus un système compresse, plus il doit expliquer précisément ce qui a été retenu et ce qui ne l'a pas été.
Une route calculée ne transporte aucun paquet
RFC 3626 indique explicitement qu'OLSR ne transfère pas lui-même les paquets de données. Il maintient la table de routage du système d'exploitation sous-jacent, supposé assurer le transfert.
La frontière est décisive. Le calcul peut être correct au regard des tuples disponibles, tandis que l'installation dans le noyau échoue. La route peut être installée tandis que la résolution du prochain saut échoue. Le prochain saut peut traiter les contrôles et abandonner les données. Le paquet peut atteindre la machine sans que le service réponde.
RFC 3626 mentionne précisément le cas d'un nœud qui relaie correctement les messages de contrôle diffusés mais ne transfère pas le trafic unicast. Un ensemble des doublons actif et des TC réguliers peuvent donc coexister avec un trou noir applicatif.
Il faut attribuer un reçu à chaque passage : version topologique, résultat du calcul, transaction de table, entrée effectivement active, résolution du voisin, compteurs d'interface, observation du paquet à l'entrée et à la sortie, puis acceptation par l'application. Aucun propriétaire ne devrait clôturer les étapes qu'il n'observe pas.
Le temps protège la stabilité et crée une dette
Les durées de conservation doivent dépasser les intervalles d'émission afin de tolérer des pertes. Cette marge évite de retirer immédiatement un voisin ou une topologie après un HELLO ou un TC manqué. Elle crée aussi une dette de fraîcheur : pendant un intervalle, un tuple encore valide peut décrire une liaison déjà changée.
Les numéros de séquence répondent à l'ordre, pas à la réalité présente. Ils empêchent qu'une ancienne annonce remplace une nouvelle, même autour du bouclage. Ils ne peuvent pas créer une observation qui n'a pas eu lieu.
Un écran sérieux montre donc l'âge du dernier témoin, la durée restante, les rafraîchissements manqués et les routes dépendantes. Sinon, rallonger les durées peut améliorer artificiellement la stabilité visuelle tout en laissant plus longtemps des décisions s'appuyer sur une information vieillie.
HNA franchit une frontière d'autorité
Les messages HNA permettent à une passerelle d'annoncer un réseau rattaché par une interface hors OLSR. Les autres nœuds enregistrent le préfixe, le masque, la passerelle et l'expiration, puis peuvent installer une route. Contrairement au TC, l'information HNA disparaît par expiration plutôt que par annulation ANSN.
La propagation réussie ne prouve ni que la passerelle est autorisée à annoncer le préfixe, ni que le réseau externe reste atteignable. L'identité de l'émetteur, le droit d'origine, la fraîcheur et le résultat du chemin sont quatre questions distinctes.
La distinction de Heng Lu entre registre et réalité devient ici une règle d'exploitation. OLSR peut enregistrer fidèlement « telle passerelle a affirmé telle association jusqu'à telle heure ». Il ne peut pas fabriquer le mandat qui donne légitimité à cette affirmation.
Authentifier n'est pas confirmer chaque lien
RFC 3626 ne prescrit pas de sécurité spéciale. Il avertit que la diffusion proactive révèle la topologie et que des nœuds malveillants ou défaillants peuvent inventer des voisins, usurper une origine, altérer, retenir ou rejouer des contrôles. L'authentification des messages est recommandée.
Le texte distingue l'authenticité du message entier de celle des liens individuels annoncés. Une signature valide identifie un détenteur de clé et protège des octets. Elle ne prouve pas que chaque voisin existe, que l'annonce HNA est autorisée, ni que l'état n'est pas un rejeu encore correctement signé.
Les RFC ultérieures ont séparé découverte de voisinage, format de message, intégrité et analyse de menace. OLSRv2 distingue aussi les MPR de diffusion des MPR de routage. Cette évolution confirme surtout une discipline : transporter l'information et construire une route sont deux fonctions, et aucune ne vaut constat applicatif.
Fermer la bonne question
L'ensemble des doublons est une excellente réponse à « ce nœud a-t-il déjà vu ce message ? ». Il devient dangereux seulement lorsqu'on lui demande de répondre à « le réseau a-t-il reçu l'information ? » ou « le client a-t-il été servi ? ».
La gouvernance technique commence par des conclusions plus petites. Le HELLO établit une observation locale. Le MPR établit une sélection. Le doublon établit une mémoire. Le TC établit une annonce reçue. La table établit une instruction active. Le paquet et l'application établissent le résultat.
Chaque reçu ferme sa propre question. Aucun ne doit fermer celle du suivant.
Sources
- https://www.rfc-editor.org/rfc/rfc3626.html
- https://www.rfc-editor.org/rfc/rfc3626.txt
- https://www.rfc-editor.org/info/rfc3626/
- https://datatracker.ietf.org/doc/rfc3626/
- https://www.rfc-editor.org/errata_search.php?rec_status=0&rfc=3626
- https://www.rfc-editor.org/rfc/rfc2501.html
- https://www.rfc-editor.org/rfc/rfc5148.html
- https://www.rfc-editor.org/rfc/rfc5444.html
- https://www.rfc-editor.org/rfc/rfc5497.html
- https://www.rfc-editor.org/rfc/rfc6130.html
- https://www.rfc-editor.org/rfc/rfc6621.html
- https://www.rfc-editor.org/rfc/rfc7181.html
- https://www.rfc-editor.org/rfc/rfc7183.html
- https://www.rfc-editor.org/rfc/rfc7185.html
- https://www.rfc-editor.org/rfc/rfc7186.html
- https://www.rfc-editor.org/rfc/rfc8116.html
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/on-authority-belief-and-the-internets-addressing-system/
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
