RFC 2174 : la route existait, mais le commutateur devait encore attendre

Résumé

• RFC 2174 réunissait un routage unicast à vecteur de distance et un arbre unique, enraciné sur un commutateur source virtuel, pour le broadcast et le multicast.
• Les trames MAPOS n’avaient ni adresse source ni TTL ; une boucle transitoire ne pouvait donc ni retrouver son origine réelle ni s’éteindre d’elle-même.
• Une route valide, une racine VSS choisie ou un bit de port marqué décrivait un état de contrôle local, pas l’autorisation immédiate de diffuser ni la preuve d’une livraison.

Le délai qui transformait l’attente en état

Le geste décisif de SSP n’était pas toujours l’envoi d’une mise à jour. C’était parfois son refus de transmettre une trame alors même qu’un chemin venait d’être appris.

La valeur par défaut du FORWARD_DELAY_TIMER était de trente secondes, soit trois périodes de mise à jour complète. Lorsqu’un port aval apparaissait dans les annonces empoisonnées, le commutateur pouvait reconnaître la relation et commencer à la suivre. Il lui était toutefois interdit d’y envoyer du broadcast ou du multicast avant l’expiration du délai.

Cette temporisation ne corrigeait pas une propriété abstraite de la table. Elle compensait deux absences dans la trame. MAPOS ne portait pas d’adresse source. Un commutateur ne pouvait donc pas traiter chaque émetteur réel comme racine d’un test de chemin inverse. La trame ne portait pas non plus de TTL. Si deux équipements construisaient momentanément des arbres incompatibles, aucun compteur dans la trame ne garantissait la fin de sa circulation.

RFC 2174 a choisi une réponse conservatrice : laisser circuler l’information de routage avant de laisser circuler le trafic diffusé.

Une racine virtuelle plutôt que mille origines

Le protocole créait une origine de calcul commune. Son algorithme VRPB supposait que toutes les trames de broadcast et multicast provenaient d’un nœud situé sous un même Virtual Source Switch. Ce VSS était le commutateur joignable portant le plus petit numéro.

Chaque commutateur le déterminait dans sa propre table unicast. Il calculait ensuite le plus court chemin inverse vers cette racine. Hors de la racine, un port était classé en amont et d’autres pouvaient être classés en aval. Le réseau MAPOS ne maintenait qu’un arbre à un instant donné.

Cette construction simplifiait le plan de contrôle. Elle ne créait pas un scrutin global. Deux commutateurs pouvaient sélectionner des racines différentes pendant la propagation d’un changement, chacun à partir d’informations localement cohérentes mais datées différemment. Le plus petit numéro n’était pas un certificat de consensus ; c’était une règle de sélection appliquée à une vue locale.

La découverte d’un nouveau VSS ou la perte de l’ancien invalidait toute la table broadcast/multicast. Une modification seulement aval avait une portée plus étroite. Cette asymétrie montrait déjà que tous les changements de bits n’avaient pas la même signification opérationnelle.

Ce que disait réellement la carte de bits

La table de diffusion prenait la forme d’un bitmap. Chaque bit correspondait à un port. Un bit à un indiquait qu’une trame devait être envoyée vers un nœud, un commutateur amont ou un commutateur aval. Aucun bit marqué signifiait que la trame devait être rejetée silencieusement.

Le bitmap était une consigne, pas un journal de livraison. Il n’indiquait pas si le signal était sorti, si le voisin avait reçu la trame, si ce voisin partageait le même VSS, ni si une application avait accepté le contenu. Même la présence du bit ne suffisait pas : pendant le forward delay, la relation était connue mais encore interdite au trafic diffusé.

Les bits naissaient de preuves différentes. Une requête NSP indiquait la présence d’un nœud local. Le prochain saut vers le VSS désignait l’amont. Une annonce avec poisoned reverse signalait qu’un voisin utilisait le commutateur local comme chemin vers la racine et pouvait donc être classé en aval.

Une nouvelle annonce aval démarrait deux histoires temporelles. Le forward delay retardait l’activation. Un PORT_EXPIRATION_TIMER, lui aussi de trente secondes par défaut, surveillait ensuite la continuité des annonces empoisonnées. Leur disparition faisait expirer la relation et effaçait le bit. Une annonce ordinaire venant de l’ancien aval devait provoquer un effacement immédiat : le voisin avait choisi une autre route ou une autre racine.

Réduire cet enchaînement à « bit 0 » puis « bit 1 » supprimerait la raison pour laquelle l’état avait changé.

La table unicast avait ses propres horloges

Toutes les dix secondes par défaut, un commutateur SSP envoyait sa table complète à ses voisins. Le coût du lien, généralement un, était ajouté aux métriques reçues. La meilleure métrique devenait la route préférée. Une défaillance locale, une route déclarée injoignable ou une hausse de métrique pouvait déclencher une mise à jour immédiate.

La vitesse de l’annonce ne prouvait pourtant pas la fin de la convergence. Comme dans RIP décrit par RFC 1058, le vecteur de distance pouvait entretenir une croyance périmée. Split horizon avec poisoned reverse et les triggered updates réduisaient le risque de comptage vers l’infini sans transformer le réseau en transaction atomique.

Après trente secondes sans rafraîchissement, ou à réception de la métrique 16, une route devenait injoignable. Elle restait encore trente secondes dans la table afin que la mauvaise nouvelle puisse être propagée, puis le garbage collection l’effaçait. Ce délai de conservation n’avait pas le même sens que le forward delay : l’un maintenait une route morte pour annoncer sa mort, l’autre retenait une relation nouvelle pour éviter de l’utiliser trop tôt.

Une mise à jour reçue n’était pas un chemin bidirectionnel

La section d’implémentation décrit un cas révélateur : la connexion à sens unique. Un port pouvait encore recevoir tandis que son canal d’émission était défaillant. Les mises à jour SSP continuaient d’arriver ; le trafic sortant tombait dans un trou noir.

Des indications SONET/SDH pouvaient signaler l’état du canal émis tel qu’il était vu à distance. Mais tous les services ne préservaient pas les octets de supervision nécessaires. Même une route fraîche, une métrique inférieure à 16 et un timer non expiré ne démontraient donc pas que le chemin transportait les données dans l’autre sens.

RFC 2174 ne rapporte ni déploiement général, ni mesure de convergence, ni incident réel. Le document est Informational, extérieur à un groupe de travail IETF et au Standards Track. Il n’aborde pas les questions de sécurité.

Sa leçon historique tient précisément à cette retenue. Le protocole distinguait l’information reçue, l’état construit, l’autorisation différée et le résultat absent. La route pouvait être assez crédible pour être inscrite sans être encore assez sûre pour porter une diffusion.

Sources

1. RFC 1058 — Routing Information Protocol
2. RFC 2171 — MAPOS Version 1
3. RFC 2173 — Node Switch Protocol
4. RFC 2174 — Switch-Switch Protocol
5. RFC 2176 — IPv4 over MAPOS Version 1