Résumé

  • La RFC 2443 permettait à plusieurs serveurs de résolution multicast sur ATM de partager l’état des clients et des groupes, sans rattacher chaque client à tous les serveurs.
  • Après deux mises à jour de présence manquées, les pairs devaient supprimer les appartenances apprises auprès du serveur défaillant. Le client devait ensuite s’inscrire auprès d’un serveur de secours et rejoindre à nouveau ses groupes.

Trois copies cohérentes, une source silencieuse

Imaginons trois serveurs MARS affichant la même ligne : un client appartient à un groupe multicast. La cohérence paraît rassurante. Puis le serveur qui a enregistré ce client cesse d’émettre son entrée de redirection périodique. Les deux autres possèdent toujours la même ligne, mais la RFC 2443 ne confond pas cette concordance avec la preuve que la source — ou le client qui lui était rattaché — fonctionne encore. Après deux mises à jour consécutives manquantes, ils doivent supprimer les appartenances apprises de ce serveur.

Cette distinction était au cœur du dispositif. La RFC 2022 avait décrit MARS, le serveur de résolution d’adresses multicast, comme un moyen de diffuser sur ATM les informations de connexion et d’appartenance multicast de couche 3. Dans un modèle distribué, chaque serveur d’un sous-réseau logique IP (LIS) devait pouvoir répondre pour tous les groupes du LIS. Publiée en novembre 1998 à titre expérimental, la RFC 2443 adapta le Server Cache Synchronization Protocol (SCSP) afin de répliquer ces enregistrements entre serveurs MARS.

Les enregistrements circulaient, pas la relation d’origine

SCSP apportait un cadre de synchronisation : établir une relation entre serveurs, aligner leurs caches, puis diffuser les changements. La RFC 2443 attribua l’identifiant de protocole 0x0003 au service MARS et limita le groupe de serveurs au LIS. Lorsqu’un client s’inscrivait auprès d’un serveur, celui-ci propageait son inscription puis les changements de groupe à ses pairs. Pourtant, chaque client ne s’inscrivait qu’auprès d’un serveur MARS. Son rattachement passait par le circuit virtuel de contrôle de cluster ou le circuit virtuel de contrôle de serveur de ce serveur. Les copies élargissaient la vue du groupe ; elles ne transféraient pas la relation de contrôle du client à tous les pairs.

La réplication ne résolvait pas non plus la question de l’attribution. Chaque client MARS devait recevoir un identifiant de membre du cluster unique dans tout le LIS. La RFC supposait que chaque serveur disposait d’une plage distincte ; un mécanisme externe était possible, mais restait hors du périmètre du document. Synchroniser les bases peut rendre identique une attribution erronée. Cela ne crée pas à lui seul une autorité d’allocation sans collisions.

Le battement de cœur servait à invalider un savoir périmé

Chaque serveur devait actualiser son entrée MARS Server Redirect au moins toutes les deux minutes ; une minute était recommandée. Si un pair manquait deux mises à jour consécutives d’une source, il devait purger les informations de clients et de groupes apprises auprès de celle-ci. Cette règle ne rafraîchissait pas seulement une liste de secours : elle attachait une preuve de fraîcheur à une origine précise et limitait la suppression aux données qui en dépendaient.

La reprise revenait ensuite au client. Après avoir détecté la panne de son MARS, il choisissait un serveur de secours et tentait de s’y inscrire. Ce n’est qu’après une inscription réussie qu’il rejoignait de nouveau ses groupes antérieurs. En cas d’échec, il essayait un autre serveur. La carte de redirection indiquait où tenter la connexion ; elle ne certifiait ni le déplacement de ce client précis, ni sa réinscription, ni le rétablissement de ses appartenances, ni la reprise du multicast.

Et une ligne d’appartenance rétablie ne prouvait pas qu’un circuit ATM multipoint avait été construit ou que des paquets atteignaient une application. Ce sont des transitions opérationnelles distinctes. Dans un réseau en production, une ligne répliquée du plan de contrôle est un préalable à l’action, pas le reçu de son exécution.

L’authentification bornait la confiance et son rayon d’impact

La RFC 2443 ne chiffrait pas sa partie spécifique MARS des enregistrements d’état. Elle renvoyait aux mécanismes de sécurité du socle générique SCSP. L’authentification pouvait faire rejeter des paquets non authentifiés, mais la RFC indiquait aussi la contrepartie : l’information reçue d’un serveur correctement authentifié était réputée fiable et propagée dans le groupe. La compromission d’un tel serveur pouvait donc corrompre la base partagée. L’authentification limitait les interlocuteurs ; elle ne garantissait pas que leurs données étaient vraies et ne confinait pas une source compromise.

En 2004, la RFC 3790 observa que la RFC 2443 définissait des valeurs par défaut pour IPv4 et prévoyait une extension à IPv6 avec des définitions IANA appropriées. C’est une observation sur la conception publiée, pas une preuve d’implémentation ou de déploiement. Les RFC documentent des exigences et des avertissements ; elles ne disent pas à quelle fréquence le service a réellement fonctionné ni si toutes les implémentations respectaient ces règles.

La leçon durable dépasse donc « la réplication améliore la disponibilité ». Il faut savoir qui a produit chaque enregistrement, à quel moment sa preuve de vie a été observée, ce qu’il faut invalider quand cette preuve expire, et quel acteur doit intervenir ensuite. Puis mesurer séparément l’inscription, le retour dans les groupes, la construction du circuit, l’acheminement des paquets et leur réception par l’application. Trois caches peuvent s’accorder sur le passé. Seul un client actif et un chemin de données fonctionnel montrent que le service multicast est revenu.

Sources