Résumé

  • En 1986, le LANBridge 100 de DEC a transformé le spanning tree distribué en fonction d’un pont Ethernet commercial. Les chemins redondants pouvaient rester en réserve plutôt que créer une boucle d’acheminement.
  • IEEE 802.1D produisait le même arbre logique, mais ses messages Hello différaient de ceux de DEC. Les ponts de migration pouvaient reconnaître puis exécuter un mode ou l’autre; publier la norme ne mettait pas à niveau les équipements en service.

Un pont Ethernet devait répondre à une question très concrète : quels liens peuvent transporter les trames sans qu’une redondance physique ne les fasse tourner indéfiniment ? Deux segments reliés par plusieurs ponts offrent une solution de secours, mais une trame de diffusion peut revenir sur un segment déjà traversé. Couper définitivement une liaison évite la boucle au prix de la redondance. Il fallait donc une règle commune pour en bloquer certaines et les réactiver en cas de changement.

Dans un article de 1985, Radia Perlman décrivit un calcul distribué de spanning tree pour un LAN étendu. Les ponts échangent leurs informations, élisent une racine, déterminent quel pont dessert chaque LAN et écartent les chemins supplémentaires de l’arbre actif. L’abstract indique un temps de convergence proportionnel au diamètre de la topologie, tandis que la mémoire par pont et la bande passante de communication par LAN ne dépendent pas du nombre total de ponts ou de liens. Le texte démontre les propriétés de l’algorithme; il ne mesure ni les ventes d’un produit ni son adoption par les réseaux.

Chez DEC, la règle est entrée dans un programme d’ingénierie avant de devenir une norme. Le Digital Technical Journal de septembre 1986 raconte qu’un prototype surnommé Brooklyn Bridge a d’abord fonctionné en laboratoire, puis entre un Ethernet et l’Engineering Network de Digital à Tewksbury. Le projet de produit Janus a donné le LANBridge 100. Les concepteurs voulaient que le pont fonctionne sans intervention au démarrage, détecte des configurations impossibles à exploiter comme les boucles, et fournisse malgré tout des compteurs et des paramètres observables au responsable réseau. L’arbre n’était donc qu’un élément d’un produit qui devait aussi apprendre les adresses, acheminer les trames, gérer les ports et conserver des chemins de secours.

Le pont ne transforme pas toute topologie physique en un ensemble de liens actifs. Il choisit une structure logique sans boucle et laisse certains ports en attente. Si une panne change la topologie, le calcul peut changer les ports actifs. Cela établit une règle de transfert au niveau des ponts; cela ne prouve pas à lui seul qu’une application a reçu ses données ni qu’un réseau fonctionne sans interruption.

DEC a proposé l’algorithme à IEEE. La norme de pontage MAC 802.1D a ensuite défini le même résultat logique. La fiche IEEE distingue les étapes : approbation du conseil le 31 mai 1990, approbation ANSI le 18 octobre et publication le 8 mars 1991. Aucune de ces dates n’est le jour où les équipements installés ont tous changé de mode.

Le manuel de référence de Digital expose ce qui restait différent. Les deux versions pouvaient aboutir au même arbre, mais l’adresse multicast des messages Hello n’était pas la même. Un LANBridge 100 ne décodait pas le Hello IEEE, et un pont IEEE n’interprétait pas le Hello DEC. Dans un LAN étendu comprenant les deux types, chaque famille pouvait construire son propre arbre. Selon la topologie et l’ordre de démarrage, le résultat pouvait être indéterminé ou instable. Dire que deux ponts suivent le même algorithme ne garantit donc pas qu’ils savent se parler.

Digital a ajouté une voie de migration dans les LAN Bridge 150 et 200 et les DECbridge 500/600. Le mode Auto-Select détectait les messages d’un LANBridge 100 et faisait passer le pont au mode DEC. Quand aucun appareil ancien ne subsistait, le réseau pouvait revenir au mode IEEE; un administrateur pouvait aussi verrouiller ce dernier. Le pont ne calculait qu’un arbre à la fois. Le manuel décrit les sondages qui aident à localiser un appareil ancien et la séquence de remplacement, mais ne dit pas combien de clients l’ont menée à terme.

L’histoire tient dans cette séparation : une idée d’arbre distribué, un produit qui la met en œuvre, une norme qui fixe un résultat commun et un mécanisme pour faire coexister deux conversations de contrôle incompatibles pendant la transition. La publication d’IEEE 802.1D n’a pas rendu cette transition automatique. Les sources attestent l’architecture et le chemin prévu; elles ne démontrent ni une adoption universelle ni que le spanning tree aurait, à lui seul, « sauvé » Ethernet.

Sources