Résumé

  • Dans MSDP, un RP annonce un couple source-groupe, les pairs appliquent le peer-RPF et conservent l’annonce. La date du cache atteste cette conservation, pas une surveillance permanente du trafic d’origine.
  • Une reconnexion, un nouveau chemin de routage, un filtre ou une expiration peuvent modifier ce que chaque RP sait sans que la source change. Le service doit donc être prouvé au-delà du message Source-Active.

Trois horloges se cachaient derrière une seule date

Un opérateur voit une entrée (S,G) âgée de douze secondes. Il sait que le cache MSDP a été touché récemment. Il ne sait pas encore quand le RP d’origine a vu le premier paquet, quand l’annonce a été créée, ni si des données circulent maintenant. L’interface a comprimé plusieurs événements en une seule notion de fraîcheur.

RFC 3618, publié en octobre 2003 dans la catégorie Experimental, décrit un protocole IPv4 reliant des domaines PIM-SM autonomes. Lorsqu’un RP apprend l’existence d’un nouvel émetteur, par exemple grâce à un Register PIM, il produit un message Source-Active. Ce message contient l’adresse de la source, le groupe et l’adresse du RP. Les pairs le diffusent ; un domaine intéressé peut ensuite rejoindre l’arbre vers la source.

La preuve initiale est donc locale et datée. Le RP a observé suffisamment d’éléments pour déclarer la source active. Les autres routeurs ne voient pas cette observation d’origine : ils voient une annonce reçue, acceptée, relayée et mémorisée. Chacune de ces opérations possède sa propre heure et sa propre autorité.

Lorsque l’écran n’affiche que « dernière mise à jour », il invite à confondre la vie du message avec celle de la source.

Le cache devait survivre assez longtemps pour être utile

RFC 3618 impose la mise en cache des messages SA. Cette mémoire réduit la latence lorsqu’un nouveau récepteur apparaît, cadence la diffusion et facilite le diagnostic. Le RP d’origine réannonce périodiquement ses sources, avec une période de 60 secondes. Après l’établissement d’une connexion, une implémentation devrait envoyer tous les messages conservés en cache.

Cette dernière règle est essentielle. Un SA reçu juste après la reconnexion peut être une reproduction d’un état déjà connu, pas la conséquence d’un nouveau paquet observé chez la source. La réception est neuve ; la connaissance qu’elle transporte peut être plus ancienne.

Chaque entrée possède aussi un temporisateur SA-State. Un autre SA le réinitialise. À l’expiration, le comportement est laissé à l’implémentation, le cas habituel étant de marquer l’entrée pour suppression. Ainsi, même la disparition d’une entrée a plusieurs causes possibles : arrêt de la source, perte de session, changement de chemin, filtrage, limitation, erreur de configuration ou politique d’expiration.

Le bon modèle de données conserve au moins quatre instants : observation d’origine, émission du SA, réception locale et modification du cache. Il ajoute l’événement qui a provoqué chaque transition. Sans cette chaîne, « récent » décrit seulement l’écriture la plus proche.

Le peer-RPF validait la direction du messager

Le peer-RPF de MSDP ne reproduit pas exactement le RPF appliqué aux paquets de données. Il examine l’adresse du RP inscrite dans le SA et choisit, à partir de la MRIB et de règles déterministes, le pair depuis lequel l’annonce est admissible. Une copie venant d’un autre pair est rejetée.

Ce mécanisme maîtrise les boucles de diffusion. Il ne vérifie pas si la source envoie encore. Il ne prouve pas non plus que le RP a le droit d’annoncer ce groupe, que l’adresse source n’a pas été usurpée en amont, ni que le domaine récepteur installera un chemin de données.

RFC 4611 montre combien le résultat dépend de la topologie de contrôle. L’AS suivant du chemin BGP, l’adresse utilisée pour la session, la portée de l’IGP et les exceptions configurées peuvent faire passer ou échouer le même SA. Un pair par défaut peut accepter les annonces lorsque le test ordinaire échouerait. Un groupe maillé suit d’autres règles de propagation.

Il faut donc archiver la décision, pas seulement son résultat : table consultée, route vers le RP, pair sélectionné, règle correspondante, exception statique, version de configuration et propriétaire. Un compteur nul d’échecs peer-RPF prouve seulement qu’aucune copie reçue n’a contredit cette politique pendant la période observée.

Diffuser la source ne signifiait pas annoncer les récepteurs

MSDP fut conçu pour permettre à un domaine ne contenant que des récepteurs d’obtenir les données sans publier mondialement ses adhésions. Le modèle « flood-and-join » diffuse la connaissance des sources. Chaque RP décide ensuite si son propre domaine contient un intérêt pour le groupe et, le cas échéant, déclenche un join (S,G).

Cette séparation protège une partie de la topologie des récepteurs, mais elle crée deux dossiers indépendants. Le dossier source contient l’annonce et son chemin de diffusion. Le dossier demande contient l’état (*,G), le join, la construction de branche et la livraison. Aucun ne peut être reconstitué entièrement à partir de l’autre.

Un SA exact peut être ignoré faute de récepteur. Un récepteur peut attendre alors qu’un filtre empêche le SA de parvenir. Un join peut partir puis suivre une interface RPF inattendue. L’état peut être installé sans que le premier paquet utile arrive. Enfin, un paquet peut atteindre le réseau local tandis que l’application rejette son contenu ou sa fraîcheur.

L’encapsulation optionnelle d’un paquet dans le SA ne supprime pas ces étapes. Elle permet notamment à une petite rafale d’être transmise avant la construction complète de l’arbre. Elle prouve qu’un paquet particulier a été transporté dans le contrôle ; elle ne prouve pas la durabilité de l’arbre suivant.

La réduction des tempêtes pouvait fabriquer du silence

Le cache et les groupes maillés réduisent les répétitions. Dans un mesh-group, un membre ne renvoie pas un SA aux autres membres parce que l’émetteur est supposé l’avoir envoyé directement à chacun. Cette optimisation exige un maillage complet.

Si une session manque, le protocole peut produire une connaissance asymétrique sans boucle visible. Un RP conserve le couple (S,G), un autre ne le voit jamais, et les règles de suppression empêchent un voisin de compenser. Le mot « mesh » dans la configuration ne prouve ni la complétude des connexions ni l’égalité des caches.

L’Anycast-RP emploie également MSDP pour partager l’état des sources. Les RPs rendent un même service sous une adresse anycast, mais leurs messages SA doivent porter une adresse individuelle adaptée au peer-RPF. La façade est commune ; la provenance de l’annonce reste attachée à une machine réelle.

La reprise doit donc être testée en retirant une session, en modifiant la route vers un RP et en comparant les caches avant et après reconnexion. Une adresse anycast toujours joignable ne constitue pas une preuve de synchronisation.

Authentifier le pair ne suffisait pas à authentifier le monde

RFC 3618 demande aux implémentations de prendre en charge l’option TCP MD5 pour protéger les messages de contrôle. Cette protection peut attester qu’une connexion utilise le secret attendu et réduire certaines modifications en transit. Elle ne garantit pas que le pair distant a correctement observé la source ou appliqué une politique légitime.

Le protocole recommande aussi filtres et limites : listes de sources ou groupes, plafond absolu d’entrées SA et limitation du rythme de création. Ce sont des outils contre l’explosion d’état et le déni de service. Ils matérialisent un arbitrage local. Accepter une annonce signifie qu’elle satisfait la règle locale ; la règle n’atteste pas sa vérité. Refuser une annonce peut protéger le routeur tout en supprimant un service réel.

RFC 4624 rend visibles des compteurs, les pairs et la table de cache. RFC 8916 ajoute une surface de configuration et d’état plus moderne. Ces interfaces sont précieuses si elles conservent les distinctions du protocole. Elles deviennent trompeuses si un agrégat « healthy » mélange session authentifiée, SA admis, cache présent, arbre installé et service reçu.

Le retrait est une preuve aussi importante que l’annonce

Une organisation responsable ne s’arrête pas à l’admission. Elle doit savoir retirer une connaissance devenue fausse. Cela exige de relier le SA à l’époque de routage, à la politique de filtre, au cache précis, aux joins dérivés et aux branches installées. Une expiration doit produire un constat explicable, pas seulement l’absence d’une ligne.

Le risque de second ordre est la propagation corrélée d’un état périmé : une annonce peut être répliquée, mise en cache et rejouée à plusieurs RPs. Le risque de troisième ordre est l’impossibilité d’enquêter si tous les témoins enregistrent uniquement la dernière réception.

La discipline proposée par Heng Lu consiste à laisser l’autorité au niveau qui supporte la perte. Le standard fournit un mécanisme minimal de coordination. Le domaine décide quels pairs et quels couples (S,G) peuvent consommer ses ressources. L’application décide si les données reçues sont utilisables. Chaque décision mérite son propre reçu.

RFC 3618 a rendu la découverte inter-domaines possible sans prétendre que le message était la réalité entière. Le cache pouvait être parfaitement à jour selon ses règles et raconter malgré tout une histoire déjà terminée.

Sources