Résumé

  • Le logiciel de passerelle conçu à BBN par Ginny Strazisar ne reliait pas des réseaux rendus identiques : il dut être adapté à des frontières concrètes, coordonné avec des PDP-11 et installé aux États-Unis, à Londres et en Norvège.
  • Les archives distinguent utilement l'installation d'un site, le trajet réellement testé et l'exploitation durable ; elles conservent même un désaccord sur la date de la démonstration de 1977 au lieu d'offrir un récit artificiellement lisse.

Une panne de protocole n'a pas retardé l'installation d'Oslo. C'était plus élémentaire : le matériel attendu par l'ingénieure n'était pas encore en place. Ginny Strazisar devait charger son logiciel de passerelle après une réunion consacrée à TCP/IP. Elle attendit, voyagea quelques jours en Norvège, puis revint lorsque le PDP-11 fut disponible. La scène rappelle qu'un réseau de réseaux ne naît pas au moment où une flèche est tracée entre deux nuages. Il naît lorsque le programme peut réellement parler aux deux équipements placés de part et d'autre.

Strazisar était entrée chez Bolt Beranek and Newman en avril 1975. Dans l'entretien d'histoire orale du Computer History Museum, elle explique avoir rapidement travaillé sur les « gateways », les machines chargées de relier les réseaux. BBN possédait déjà un passage entre son Resource Computer Network expérimental et ARPANET. Vinrent ensuite les frontières entre ARPANET et le Packet Radio Network, puis entre ARPANET et l'Atlantic Satellite Network.

Le musée la présente comme l'autrice du premier logiciel de routeur d'internetworking pour les nouveaux protocoles TCP/IP, lorsque l'appareil s'appelait encore une passerelle. Cette formule ne fait pas d'elle l'autrice solitaire de l'Internet. Elle désigne une responsabilité précise dans une œuvre distribuée : rendre praticable le point où des réseaux conçus selon des contraintes différentes devaient échanger des datagrammes.

Le réseau radio devait composer avec le mouvement, les relais et une disponibilité liée aux essais du véhicule. ARPANET avait ses propres interfaces. SATNET ajoutait des stations séparées par l'Atlantique et des équipes situées dans plusieurs pays. La promesse de TCP ne consistait pas à effacer ces différences. Elle consistait à transporter une conversation au-dessus d'elles. La passerelle était donc le lieu où l'abstraction rencontrait le détail local.

Ce détail changeait d'un site à l'autre. Pour le Packet Radio Network, le code de la station radio et celui de la passerelle cohabitaient dans un PDP-11. Aux frontières du réseau satellite, les passerelles étaient des PDP-11 séparés : une interface vers ARPANET, une autre vers SATNET, et un logiciel décidant où envoyer le paquet. Il existait une fonction commune, mais pas une installation indifférente au matériel.

La chronologie donnée par Strazisar est éloquente. Elle se souvient d'une installation chez BBN pendant l'été 1976, de Londres en décembre de la même année, puis de la Norvège à l'été 1977. Une autre équipe préparait le matériel ; elle apportait et installait le logiciel. À Londres, les séquences s'enchaînèrent. À Oslo, un retard matériel obligea à revenir. Ce contretemps ne relève pas de l'anecdote périphérique : il révèle une dépendance de production.

Les essais progressèrent eux aussi par frontières. Le magazine du Computer History Museum consacré à cette histoire situe à l'été 1976 des transmissions radio restant à un saut de la station qui hébergeait la passerelle bidirectionnelle de Strazisar vers ARPANET. Il date du 27 août 1976 une démonstration cérémonielle entre deux réseaux. L'étape suivante devait faire circuler les données à travers trois familles de réseau, sans traduction spéciale inventée pour chaque paire.

En 1977, un véhicule radio mobile envoya des données vers l'infrastructure de SRI, puis à travers ARPANET et le réseau satellite jusqu'à un serveur en Californie après un trajet transatlantique. Mais les archives du même musée ne donnent pas une date unique : l'article publié en 2017 indique le mercredi 22 novembre, tandis que le magazine de 2002 légende son schéma au 27 novembre. La prudence impose de conserver cette divergence.

Une autre nuance est encore plus instructive. Strazisar avait installé le logiciel en Norvège, mais Vint Cerf se souvient que les paquets de la démonstration n'y sont pas passés. Les interlocuteurs discutent de la route effectivement forcée à travers certaines passerelles satellites. Une machine préparée prouve une capacité de déploiement ; elle ne prouve pas que ce trajet précis l'a exercée. Un échange de bout en bout réussi prouve un chemin, pas toutes les variantes possibles.

L'événement mobilisait plus de 35 personnes et huit institutions selon le musée. Bob Kahn et Vint Cerf sont crédités pour le concept TCP ; Jim Mathis et Dave Retz pour le client ; Ray Tomlinson et Bill Plummer pour le serveur ; SRI, Collins Radio, Linkabit, BBN, UCL et l'institut norvégien ont tenu d'autres parties du système. Strazisar apparaît à la rubrique des passerelles BBN. Son apport est précisément celui d'une ingénieure de frontière : elle ne contrôlait aucun des réseaux entiers, mais devait faire fonctionner leur articulation.

Les documents techniques prolongent ce travail au-delà de la démonstration. RFC 823 retrace une conception documentée dans IEN 30, Gateway Routing: An Implementation Specification, puis dans IEN 109 de Strazisar, How to Build a Gateway. Le RFC attribue un mérite particulier à V. Strazisar, M. Brescia, E. Rosen et J. Haverty. Le logiciel en marche devenait un objet transmissible par le texte, susceptible d'être discuté et reconstruit.

IEN 30 ne transforme pourtant pas le routage en certitude. Le document décrit un algorithme assez précisément pour l'implémenter et contourner des composants défaillants, mais reconnaît qu'une analyse ne prouve ni l'acheminement toujours correct ni l'absence de non-livraison indéfinie. Les vulnérabilités peuvent n'apparaître qu'après expérimentation et usage opérationnel. Il distingue aussi la faute de l'algorithme de celle de son incarnation : information corrompue, matériel défectueux, logiciel erroné ou implémentation incorrecte.

RFC 823 montre ensuite le passage du prototype au service. Les premières versions combinaient BCPL et le système ELF, puis MOS pour gagner en performance. À partir de la fin de 1981, une nouvelle réalisation en MACRO-11 devait répondre aux besoins d'une installation de communication opérationnelle, ménager de la place pour les tampons et ajouter des mécanismes de supervision. L'architecture restait, selon le texte, fondamentalement celle des versions de recherche.

Devenir opérationnelle signifiait donc rendre la limite mesurable. Chaque interface recevait une file de sortie bornée afin qu'un réseau lent ne consomme pas tous les tampons. Un paquet impossible à mettre en file était supprimé et signalé au système de supervision. État des interfaces, voisins, réseaux atteignables, débit et causes de perte pouvaient être observés. Le RFC se disait lui-même « instantané » de l'implémentation courante, non spécification définitive.

Pour une infrastructure actuelle, la leçon tient en quatre preuves distinctes : le binaire reproductible, la machine et le pilote réellement visés, l'interface effectivement testée, puis les compteurs qui expliquent la perte. Le schéma exprime une intention. Le paquet arrivé valide un parcours. Seule une installation répétable, observable sous contrainte, permet d'exploiter la frontière.

Le code a voyagé avant les paquets parce que l'interopérabilité possède toujours une géographie. Elle se cache dans un média d'installation, une révision de carte, un câble local, une fenêtre de maintenance et la personne capable de lire un état distant. Les protocoles ont rendu l'Internet pensable ; ce travail de terrain l'a rendu réel.

Sources