Histoire des communications informatiques
James Pelkey (texte original en ligne)

Chapitre 1 Introduction
Chapitre 2 Arrière-plan (Dans lequel on retrouve le télégraphe et le télephone aux US... le modem ... le microprocesseur)
Chapitre 3 Communications de données : émergence 1956-1968
Chapitre 4 Réseautage : Vision et commutation de paquets 1959 - 1968
Chapitre 5 Communications de données : concurrence sur le marché 1969-1972
Chapitre 6 Réseautage : Arpanet 1969-1972
Chapitre 7 Communications de données : ordre du marché 1973-1979
Chapitre 8 Réseautage : Diffusion 1972-1979
Chapitre 9 Réseautage : Émergence 1979-1981
Chapitre 10 Réseautage : concurrence sur le marché 1981-1983
Chapitre 11 Normes : une institution habilitante 1979-1984
Chapitre 12 Réseaux : Ordre du marché : LAN 1983-1986
Chapitre 13 Communications de données : Adaptation 1979-1986
Chapitre 14 Interconnexion de réseaux : émergence 1985-1988


Chapitre 8 Réseautage : Diffusion 1972-1979

8.0 Vue d'ensemble

La démonstration réussie d'Arpanet lors de la Conférence internationale sur les communications informatiques (ICCC) en octobre 1972 a marqué un tournant dans l'histoire des communications informatiques.
Il restait cependant beaucoup à faire avant qu'Arpanet ne fonctionne comme l'avaient imaginé ses créateurs, un travail qui se poursuivrait sous l'égide de l'IPTO. Mais la mise en place d'un réseau opérationnel posait également un problème de taille : ni l'IPTO ni la DARPA n'étaient habilitées à exploiter un tel réseau. Il fallait donc confier cette responsabilité à une organisation privée. AT&T ne manifesta aucun intérêt et BBN, l'autre organisation la plus probable, semblait tout aussi désintéressée. Du moins, jusqu'à ce que certains de ses employés clés démissionnent pour fonder une entreprise de ce type. Contrainte de se résoudre à cette tâche, BBN engagea Larry Roberts pour commercialiser la technologie Arpanet.

Le fonctionnement d'Arpanet a également incité l'IPTO à construire un réseau de radiocommunication par paquets. Pour diriger le projet, ils ont recruté Robert Kahn de BBN. Il s'est immédiatement attaqué aux problèmes logiciels du réseau Arpanet ainsi qu'à la question de l'interconnexion d'Arpanet à un réseau de radiocommunication par paquets. En collaboration avec Vinton Cerf, ils ont conçu un protocole logiciel réseau entièrement nouveau : le protocole de contrôle de transmission (TCP).

Les Européens, soucieux de ne pas être en reste, lancèrent plusieurs projets de mise en réseau à peu près au même moment que l'ICCC. Outre la création de réseaux très différents d'Arpanet, notamment des réseaux à datagrammes purs, ils furent à l'origine de la création d'un Groupe international de mise en réseau qui devint par la suite le Groupe de travail 6.1 de la Fédération internationale pour le traitement de l'information (IFIP). Pour ceux qui débattaient de la nature des communications informatiques, le Groupe de travail 6.1 de l'IFIP devint un véritable tourbillon. Le fossé entre les communications de données et les communications vocales semblait infranchissable.
Les chercheurs en informatique se réfugièrent alors dans les organismes de normalisation et mirent en place de nouveaux protocoles de mise en réseau connus sous le nom d'interconnexion de systèmes ouverts (OSI).

Parallèlement, la prolifération des ordinateurs aux États-Unis a stimulé la création de nombreux nouveaux réseaux. David Farber a été à l'origine de l'innovation du réseau en anneau à jeton, interconnectant de nombreux ordinateurs et périphériques à l'aide de câbles à paires torsadées.

Chez Xerox PARC, Robert Metcalfe a brillamment repris de nombreuses idées d'Arpanet et d'ALOHAnet pour créer un nouveau type de réseau local. Ethernet permettait aux ordinateurs de diffuser leurs paquets à leur guise, comme dans ALOHAnet, sans avoir besoin de jetons d'autorisation comme avec Token Ring. Ethernet fonctionnait à merveille et a nécessité la conception d'un nouveau protocole réseau : PARC Universal Packet (Pup). Pup a ensuite été repensé pour devenir le Xerox Network System (XNS), afin de prendre en charge un Etherent encore plus rapide.

À la fin des années 1970, les travaux amorcés par le projet de réseau radio par paquets, précisés lors des réunions du groupe de travail 6.1 de l'IFIP et intensifiés par l'innovation des réseaux locaux, n'ont pas abouti à une approche unifiée des communications informatiques, mais à trois protocoles de réseau et à une multitude de réseaux. Comment donner un sens à ce chaos ?

8.1 Commercialisation d'Arpanet 1972 - 1975

En 1971, Larry Roberts constata qu'un réseau Arpanet opérationnel posait un nouveau problème : l'ARPA ne disposait pas de l'autorité légale pour exploiter un réseau de communication. Il fallait trouver un nouveau gestionnaire, vraisemblablement une organisation privée, pour assumer cette responsabilité sans pour autant priver l'armée de l'usage préférentiel et du contrôle du réseau pour ses recherches. Roberts contacta AT&T et BBN. AT&T rejeta sa demande et BBN manifesta peu d'intérêt. Croyant avoir le temps de résoudre ce problème, Roberts se consacra, avec sa petite équipe, aux nombreux autres projets de l'IPTO, tels que l'intelligence artificielle, la compréhension vocale, divers projets informatiques, dont Illiac IV, et d'autres projets de communication comme ALOHAnet. Pourquoi ? D'un point de vue budgétaire, Arpanet figurait à peine parmi les projets importants de l'ARPA. Après quatre ans, on estime que 3,5 millions de dollars avaient été dépensés pour l'achat d'IMP auprès de BBN afin de construire le sous-réseau. (L'investissement total, incluant les coûts de connexion des ordinateurs hôtes au sous-réseau et de gestion de l'IPTO, est estimé à 10 millions de dollars.) Au cours de ces mêmes quatre années, les dépenses totales de l'ARPA s'élevaient à 833 millions de dollars, ce qui représente entre 0,5 % et 1,5 % du budget de l'ARPA ; autrement dit, un montant à peine significatif.

En attendant sa privatisation, Arpanet nécessitait un développement et une amélioration constants. En juin 1974, le réseau comptait 46 nœuds.
Le tableau suivant résume la croissance du nombre de nœuds par type d'utilisateur. (Voir l'annexe 6.0 : Nœuds Arpanet par type et par date.)
Les agences gouvernementales, principalement militaires, ont été à l'origine de la majeure partie de cette croissance entre 1972 et 1974. L'utilisation militaire s'est accompagnée de tout le discours relatif à la sécurité nationale, ce qui a encore compliqué la privatisation d'Arpanet.

Roberts avait suffisamment d'expérience dans le développement technologique pour savoir qu'exploiter et améliorer un système destiné à être cédé était une source de problèmes à éviter. Fin 1971, il pressa donc BBN de prendre les choses en main pour résoudre son dilemme et celui de l'ARPA. Cependant, BBN se considérait comme un prestataire de services pour le gouvernement, éventuellement un vendeur de produits sur les marchés commerciaux, mais jamais comme un opérateur de réseau de communication. La simple idée de traiter avec la FCC, à commencer par les démarches pour obtenir l'autorisation d'exploiter un réseau sans être soumis à la réglementation, constituait un obstacle insurmontable. Pourtant, pour paraître à l'écoute de Roberts, la direction de BBN créa un comité chargé d'étudier la question.

Annexe 8.1.0 Nœuds Arpanet par type et par date

À la date Nombre de nœuds Universités Entreprises sous contrat avec le gouvernement Agences gouvernementales Entreprises

Le carcan institutionnel contraignant Roberts à se séparer d'Arpanet s'est considérablement resserré le 23 mars 1972, lorsqu'une directive du Département de la Défense (DoD) a rebaptisé l'agence « Defense Advanced Research Projects Agency » (DARPA) et en a fait une agence civile relevant directement du Bureau du Secrétaire à la Défense. Cette directive limitait également les responsabilités de la DARPA à la conduite de « recherche et développement fondamentaux et appliqués pour des projets de pointe ». Bien que cela n'ait jamais été une pratique courante, la DARPA s'est vue interdire la création de centres de recherche et développement (R&D) distincts. De plus, des plafonds ont été fixés quant au montant maximal des fonds pouvant être alloués annuellement à un organisme de R&D. Heureusement, Roberts avait déjà anticipé le message, à la fois discret et clair, l'incitant à se séparer d'Arpanet ; il ne disposait cependant d'aucune autre solution que d'espérer que BBN vienne à la rescousse.

Les projets de Roberts concernant le transfert d'Arpanet ont subi un revers lorsque trois membres du comité BBN, chargé d'étudier la commercialisation d'Arpanet, ont quitté le comité et annoncé la création d'une entreprise proposant des services de réseau de communication de données. Leur produit serait « conceptuellement similaire » à Arpanet . Ils considéraient les technologies d'Arpanet comme un bien public, ayant été financées par des fonds publics, et présumaient obtenir des droits sur cette technologie car elle « devrait théoriquement être accessible à tous ». Ils ont même affirmé avoir reçu des assurances officieuses à ce sujet de la part du ministère de la Défense .

La direction de BBN se sentait contrainte d'agir. Ayant besoin d'un chef de file, elle entreprit de recruter Roberts pour qu'il quitte l'IPTO et devienne président de Telenet Communications Corp. (Telenet), filiale créée en décembre 1971. Le timing de BBN était parfait. Roberts avait déjà décidé qu'une fois le sort d'Arpanet réglé, il serait temps pour lui de quitter l'IPTO, y étant resté bien plus longtemps qu'il ne l'aurait jamais imaginé et que ce que la norme culturelle exigeait. Fidèle à son style inimitable, Roberts se plongea donc dans l'analyse de cette opportunité et conclut qu'un investissement de 10 à 20 millions de dollars en temps de calcul permettrait de créer un réseau national d'une quinzaine d'ordinateurs de taille moyenne, offrant un rapport coût-efficacité optimal. Convaincu de la viabilité économique de Telenet, Roberts accepta l'offre de BBN. ??Mais il lui fallait du temps pour éviter tout conflit d'intérêts apparent, notamment concernant la cession d'Arpanet. Pour l'aider, il suggéra à RAND, l'organisme de recherche, d'étudier les différentes options et de formuler une recommandation.

Lorsqu'on lui proposa la mission, Keith Uncapher, directeur de la division informatique de RAND, pensa immédiatement à faire appel à Paul Baran. Ce dernier avait quitté RAND en 1968 pour fonder l'Institute for the Future, afin d'étudier comment la société résolvait les problèmes à long terme. Baran accepta sans hésiter de devenir consultant pour RAND. La direction de RAND réalisa alors que la directive du département de la Défense de mars fixait des plafonds de financement pour les institutions de recherche et que RAND avait atteint ces plafonds. Baran se souvient : Alors j'ai dit : « Tant pis. Je vais créer une entreprise, si cela ne vous dérange pas, RAND, et mener l'étude, si la DARPA n'y voit pas d'inconvénient, et si elle la souhaite. » C'est ainsi que Cabledata Associates a vu le jour, en réalisant une étude sur la cession d'Arpanet.

Baran contacta Cerf, qui venait de commencer à enseigner à l'université Stanford, située à seulement un kilomètre de là. Cerf accepta sans difficulté d'aider Cabledata Associates (CDA). Baran en tant que chercheur principal et Cerf en tant que scientifique du projet, les travaux débutèrent durant l'été 1972, avec un rapport attendu pour janvier 1974.

Pourtant, à peine CDA avait-elle commencé ses activités que trois anciens employés de BBN, Lee Talbert (président), Ralph Alter (vice-président des opérations) et Stephen Russell (vice-président de l'ingénierie), fondèrent Packet Communications, Inc. (PCI) en juillet 1972. Ils annoncèrent qu'ils bénéficiaient d'un soutien en capital-risque, qu'ils avaient obtenu les droits sur la technologie Arpanet et qu'ils allaient soumettre leur demande pour offrir des services de communication de données à la FCC.

À la mi-septembre, Roberts, frustré de ne pas avoir trouvé de remplaçant et subissant la pression de rejoindre Telenet, accepta la proposition informelle de JCR Licklider de prendre sa place s'il ne parvenait pas à lui trouver un successeur. Le 1er octobre 1972, Roberts annonça sa démission d'IPTO pour devenir président de Telenet et, le lendemain, Telenet déposa sa demande auprès de la FCC. Trois mois plus tard, PCI fit de même. Les deux demandes furent approuvées en tant qu'entreprises de télécommunications réglementées, bien qu'elles prévoyaient de louer des lignes auprès d'AT&T, elle-même déjà un opérateur de télécommunications réglementé.

Un nouveau marché se formait. Dans un premier temps, l'accent serait mis sur la vente de services de communication de données. À l'avenir, les entreprises vendraient des produits de commutation de paquets. Les services et produits de commutation de paquets se révéleraient moins importants qu'un autre marché qui émergerait du nouveau paradigme de la commutation de paquets : les réseaux locaux (LAN), sujet principal de ce chapitre. Quant à PCI, elle n'a jamais levé suffisamment de capital-risque et a disparu. Telenet est entrée en bourse en décembre 1977 avec une capitalisation boursière de 20,6 millions de dollars. Le 13 juin 1979, General Telephone Company, la deuxième plus grande compagnie de téléphone, a racheté Telenet pour environ 58 millions de dollars. BBN a reçu 13,9 millions de dollars pour son investissement cumulé de 5,3 millions de dollars .

Lorsque la CDA a soumis sa recommandation le 14 janvier 1974, il était déjà trop tard. Malgré cela, et reflétant sa profonde inquiétude quant à la possibilité qu'un petit nombre d'entreprises dominent la commutation de paquets en formant un oligopole, elle a recommandé une nouvelle forme institutionnelle, un consortium, qui assurerait « trois fonctions essentielles :
Un mécanisme de compensation pour le transfert des paiements entre entités coopérantes.
Un mécanisme permettant de créer et de faire respecter des normes industrielles communes.
Un mécanisme permettant un accès libre et ouvert en permanence, afin d'éviter la formation de toute structure oligopolistique fermée qui exigerait une surveillance ou une réglementation gouvernementale étroite.

Le ministère de la Défense avait également ses propres préoccupations et, après une autre année de réunions explorant des alternatives, y compris les recommandations de la CDA, la gestion d'Arpanet a été transférée de la DARPA à la Defense Communications Agency (DCA) le 1er juillet 1975.

8.2 La radio par paquets et Robert Kahn : 1972-1974

Peu après l'ICCC, l'infatigable Robert Kahn quitta BBN pour rejoindre la DARPA afin de concevoir le premier réseau radio par paquets au monde. Ingénieur accompli, il s'appuyait sur son expérience des réseaux Arpanet et ALOHAnet pour élaborer son plan. Comme le souligne Kahn : Le système ALOHA était à la radio par paquets ce que l'ordinateur à temps partagé d'origine était à Arpanet.

Kahn réunit rapidement un groupe de travail informel, comprenant Vint Cerf et Robert Metcalfe, afin de stimuler sa réflexion et de susciter leur intérêt. Deux défis devaient être relevés pour interconnecter le réseau de radiocommunication par paquets à l'Arpanet. Premièrement, il fallait résoudre les problèmes connus du protocole de communication de l'Arpanet, le protocole de contrôle de réseau (NCP). Deuxièmement, il était nécessaire de concevoir une interface entre un réseau de radiocommunication par paquets et l'Arpanet.

Le problème le plus flagrant du protocole NCP résidait dans l'absence de correction d'erreurs de bout en bout, ou entre hôtes. Dans l'Arpanet, la correction d'erreurs NCP était assurée pour le routage des paquets entre les IMP, mais pas pour les messages échangés entre les hôtes et les IMP. Or, en pratique, des erreurs se produisaient, empêchant ainsi toute fiabilité de bout en bout au sein de l'Arpanet. La probabilité d'erreurs provenant d'un terminal radio mobile était nettement supérieure à celle des terminaux câblés de l'Arpanet. Dans un réseau radio, les signaux pouvaient être perturbés par des parasites atmosphériques ou d'autres signaux radio, ou encore interrompus lorsque les terminaux communicants pénétraient dans des tunnels ou des bâtiments. D'autres fonctions intégrées au protocole NCP, telles que le contrôle de flux et la segmentation des paquets, devaient également être prises en charge au niveau de l'hôte. Le protocole NCP devait donc être repensé afin d'améliorer le fonctionnement de l'Arpanet et de permettre l'interconnexion d'un réseau radio.

Le second défi consistait à interconnecter l'Arpanet, relativement lent, à un réseau radio à commutation de paquets rapide. L'Arpanet avait été conçu pour des débits de 50 kilobits par seconde (kbps), tandis qu'un réseau radio à commutation de paquets fonctionnerait entre 100 et 400 kbps. Dans un premier temps, la solution à cette différence de débit semblait simple : créer une passerelle entre les deux réseaux, convertissant les messages de l'un en messages compatibles avec l'autre. Cependant, l'utilisation d'une passerelle posait problème, notamment en présence de nombreuses passerelles/réseaux et de terminaux mobiles passant de l'un à l'autre. Le protocole NCP supposait l'existence d'un seul réseau, et donc de moins de passerelles, sans parler du cas encore plus complexe d'un terminal envoyant un message à une passerelle et attendant une réponse sur une autre, potentiellement imprévisible. Il a donc fallu repenser le protocole NCP.

En juin 1973, lors de la conférence AFIPS NCC à New York, Kahn a présidé une réunion consacrée aux problèmes liés au protocole hôte-à-hôte. À la suite de cette réunion, Kahn et Cerf ont entrepris la tâche incertaine de repenser le protocole NCP.

8.3 Réseau CYCLADES et Louis Pouzin 1971 - 1972

En novembre 1971, Louis Pouzin intègre la Délégation à l'Informatique, agence du gouvernement français chargée de coordonner toutes les activités liées à l'informatique. Il sera responsable de la création du premier réseau de communication informatique français. Son premier acte officiel est un voyage aux États-Unis pour renouer avec des contacts établis lors de son passage au MIT (1962-1965) et mieux comprendre le mystérieux Arpanet.
Pouzin se souvient : J'ai fait un aller-retour aux États-Unis pour observer le développement d'Arpanet. J'ai rencontré les principaux développeurs, notamment ceux de BBN, Larry Roberts, Vint Cerf, ceux de SRI et Len Kleinrock, que je connaissais déjà. J'avais lu des articles sur Arpanet avant mon voyage, mais cela me paraissait un peu abstrait. J'avais du mal à en saisir les aspects concrets. Après mon séjour aux États-Unis, j'ai compris comment le projet avait débuté, comment l'équipe était organisée, quelles étaient les principales tâches liées au développement du système et où se situaient les faiblesses. Ils m'ont expliqué tous leurs compromis et les problèmes non résolus. Nous avons commencé à discuter des améliorations possibles. Ils savaient que je souhaitais construire un autre réseau, mais ils n'y croyaient pas vraiment. Ils avaient l'impression qu'un système aussi complexe comme Arpanet ne pouvait être mis en œuvre que dans un pays comme les États-Unis, en raison des ressources financières, de l'expertise, etc. Ils ne croyaient pas que l'Europe puisse réaliser un tel projet.

De retour à Paris, Pouzin entreprit la conception du réseau de communication informatique et l'organisation d'une conférence réunissant des Européens intéressés par les réseaux. La plupart des participants à la réunion de juin 1972 étaient français. Parmi les exceptions notables figuraient Steve Crocker de la DARPA, Donald Davies du NPL et Peter Kirstein de l'University College de Londres. Deux décisions s'imposèrent rapidement. Premièrement, ils convinrent de la nécessité de se réunir à nouveau et de fonctionner sur le modèle du Groupe de travail sur les réseaux (NWG) d'Arpanet. Ils adoptèrent donc le nom de Groupe de travail international sur les réseaux (INWG). Deuxièmement, ils reconnurent que le contexte institutionnel européen était très différent de celui des États-Unis. Collaborer avec les puissantes compagnies de télécommunications publiques (PTT) et leur organisme de normalisation omniprésent, le Comité consultatif international de télégraphe et de téléphone (CCITT), s'annonçait complexe et chronophage. La plupart des participants estimaient avoir besoin de la crédibilité et de l'autorité d'une organisation existante pour rétablir l'égalité des chances. Pouzin, membre du comité technique 6 (TC 6) sur les communications de données de la Fédération internationale pour le traitement de l'information (IFIP), récemment créé, a suggéré à l'INWG d'envisager une affiliation avec l'IFIP, une organisation regroupant des informaticiens soucieux de l'harmonie internationale et du partage de l'information, placée sous l'égide des Nations Unies. Les membres de l'INWG ont autorisé Pouzin à s'entretenir avec Alex Curan, président du TC 6 de l'IFIP. Ils ont également fixé la prochaine réunion au mois de novembre à l'Université du Kent, en Angleterre, après la démonstration de l'ICCC qui se tiendra prochainement à Washington D.C.

Après la réunion, Pouzin reprit son travail de conception d'un réseau à commutation de paquets plus simple qu'Arpanet. Il consacra du temps à l'étude du réseau NPL et, dans la mesure où il avait accès à l'information, des réseaux MERIT, TYMNET et INTENET. Pouzin était convaincu que l'évolution des réseaux serait différente en Europe en raison du pouvoir des opérateurs de télécommunications : tandis que le monopole d'AT&T s'affaiblissait, celui des opérateurs de télécommunications restait incontesté. Imaginer qu'un réseau de communication distinct puisse se superposer aux réseaux des opérateurs, comme Arpanet l'avait fait pour ceux d'AT&T, paraissait tout simplement naïf.

En novembre 1972, quelques semaines seulement après l'enthousiasme suscité par l'ICCC, un atelier fut organisé à l'Université du Kent. Forts du succès d'Arpanet, source d'inspiration pour les concepteurs de communications informatiques et preuve de concept à perfectionner, les organisateurs espéraient encourager de nouvelles collaborations. Des participants venus des États-Unis, du Canada, du Japon et de plusieurs pays européens assistèrent à des présentations sur Arpanet, le NPL de Davies et le réseau CYCLADES que Pouzin projetait. (Voir l'annexe 6.2 : Le réseau CYCLADES.)

Annexe 8.3.0 Le réseau CYCLADES
schéma du réseau CYCLADES

CYCLADES devait être un réseau de datagrammes pur. Il était constitué d'ordinateurs hôtes connectés à des commutateurs de paquets interconnectés par des circuits téléphoniques PTT. Un logiciel embarqué sur les ordinateurs hôtes créait des circuits virtuels entre les hôtes du réseau et segmentait les données à communiquer en datagrammes. Les hôtes envoyaient ensuite ces datagrammes à leurs commutateurs de paquets, qui les relayaient aux commutateurs de paquets appropriés, lesquels les transmettaient à leurs hôtes respectifs. L'ensemble des commutateurs de paquets et des liaisons réseau était appelé « cigale » (le sous-réseau dans Arpanet). CYCLADES différait radicalement d'Arpanet par le fait que les hôtes envoyaient les datagrammes directement entre eux et assuraient une correction d'erreurs de bout en bout.

Pouzin a utilisé un système de datagrammes, sachant pertinemment qu'il était impossible d'imposer la correction d'erreurs ou l'ordonnancement des responsabilités liées aux paquets aux commutateurs PTT. De plus, comme l'avait démontré l'expérience avec Arpanet, même en cas de communication sans erreur entre les commutateurs de paquets, rien ne garantissait l'absence d'erreurs dues aux communications entre les hôtes et ces commutateurs. L'ingénieuse conception de Pouzin a permis d'isoler CYCLADES de l'autorité et des complications des commutateurs PTT.

En confiant la responsabilité de communications de bout en bout fiables par datagrammes aux ordinateurs communicants et en prouvant la viabilité de l'architecture, CYCLADES allait avoir des répercussions durables sur l'avenir des communications informatiques.
Pouzin se souvient de sa réflexion de l'époque : L'idée des datagrammes m'est venue de deux sources. La première, les travaux de Donald Davies. Il avait réalisé des simulations de réseaux de datagrammes, sans toutefois en construire aucun, et le concept semblait techniquement viable. La seconde, c'est mon goût pour la simplicité. Je ne voyais aucune réelle justification technique à superposer deux niveaux de protocoles de bout en bout. Un seul me paraissait suffisant.

Pouzin espérait que CYCLADES soit opérationnel fin 1973. À cette date, son projet ne serait plus le seul réseau d'envergure en Europe.
En 1971, le projet COST 11, un réseau de recherche multinational européen, était une copie quasi conforme de CYCLADES.
En 1973, COST 11 fut rebaptisé Réseau européen d'informatique (EIN) et Derek Barber, du NPL, en prit la direction. Les principaux fabricants d'ordinateurs européens, dont Olivetti, ICL, Siemens et CII (Compagnie Internationale pour l'Informatique), étaient étroitement associés à CYCLADES et à EIN. Ces entreprises savaient que, faute de proposer une alternative aux produits de communication de données des PTT, elles risquaient de compromettre leur avenir dans le secteur des communications. Ces constructeurs informatiques formaient le noyau de l'ECMA (Association européenne des fabricants d'ordinateurs), une organisation coordonnant des politiques industrielles mutuellement avantageuses.

Cependant, tous les chercheurs ne partageaient pas l'avis de Pouzin. L'un de ses compatriotes, Rémy Despres, dirigeait le réseau expérimental à commutation par paquets des télécommunications françaises (PTT), baptisé RCP. Annoncé en novembre 1973, le RCP reposait sur la fourniture de circuits virtuels par les PTT, et non de simples liaisons de communication. Le RCP devait servir de banc d'essai pour le réseau public à commutation de paquets que les PTT françaises projetaient de mettre en place, nommé TRANSPAC.
L'année suivante, Despres trouva des alliés en la personne de Roberts et Wessler de Telenet, qui avaient conclu que les produits de commutation de paquets de Telenet devaient impérativement reposer sur des circuits virtuels pour espérer conquérir les PTT.
Ces dernières pouvaient ainsi facturer plus cher la transmission fiable de l'information – c'est-à-dire la fourniture de réseaux à circuits virtuels – que la simple mise à disposition de liaisons.

8.4 Protocole de contrôle de transmission (TCP) 1973-1976

La confusion quant à la conception optimale d'un réseau de communication informatique a également alimenté les débats au sein du groupe désormais appelé Groupe de travail IFIP 6.1.
En 1973, lorsque Pouzin a proposé à Alex Curran, président du TC-6 de l'IFIP, d'associer le tout récent INWG à l'IFIP TC-6, ce dernier a immédiatement accepté et ils ont renommé l'INWG : Groupe de travail IFIP 6.1 (GT 6.1) sur l'interconnexion des réseaux. Steve Crocker, président du premier NWG d'Arpanet, a recommandé Vint Cerf pour la présidence, une suggestion aussitôt approuvée. Rapidement, les réunions du GT 6.1 sont devenues incontournables pour quiconque souhaitait influencer les communications informatiques. Ce qui n'était reconnu que par une poignée de personnes au milieu de l'année 1973 est devenu, en l'espace de vingt-quatre mois seulement, une évidence pour la quasi-totalité des acteurs des communications informatiques : le monde allait être peuplé de nombreux réseaux informatiques, des réseaux qui devraient inévitablement être interconnectés.

Comment résoudre la complexité des communications inter-réseaux alors que les caractéristiques techniques d'un réseau optimal restaient floues ? Quel rôle joueraient les entreprises des deux marchés clés : les télécommunications et l'informatique ? Ainsi, même si elle n'était pas un organisme de normalisation, l'IFIP (Groupe de travail 6.1) a réuni pendant quelques années cruciales les personnalités les plus influentes du secteur des communications informatiques pour débattre de l'avenir des réseaux et de leur convergence.

Tous s'accordaient à dire qu'Arpanet constituait une première preuve convaincante qu'il était possible de construire un réseau plus performant que celui conçu selon le modèle de commutation de circuits du système téléphonique. Arpanet présentait toutefois des lacunes : il ne s'agissait ni d'un véritable réseau à datagrammes, ni d'un réseau à correction d'erreurs de bout en bout. La question cruciale demeurait donc : était-il possible de créer un véritable réseau à commutation de paquets offrant une fiabilité de bout en bout ? Les débats du groupe de travail 6.1 se sont concentrés sur la conception d'un réseau basé sur les datagrammes mais proposant des circuits virtuels. Il s'agissait en effet d'un obstacle fondamental à l'évolution des réseaux.

En septembre 1973, lors d'une réunion dans le Sussex, en Angleterre, Cerf et Kahn ont présenté un protocole de communication, le Protocole de Contrôle de Transmission (TCP), fonctionnant sur des réseaux interconnectés de natures diverses. Leur article a été publié par l'IEEE Transactions on Communications en mai 1974 sous le titre « A Protocol for Packet Network Intercommunication ». Le TCP intégrait des circuits virtuels de bout en bout avec transmission de datagrammes et passerelles entre les réseaux.

Généralisant une solution d'interconnexion d'Arpanet avec un réseau radio à commutation de paquets, Cerf et Kahn ont proposé que différents réseaux soient interconnectés par des passerelles utilisant le protocole TCP. Les passerelles recevraient le trafic entrant d'un réseau et effectueraient les transformations nécessaires pour acheminer les données sur le réseau sortant. Parmi ces transformations figuraient les conversions de protocole. Une autre transformation, plus controversée, consistait à fragmenter la taille des paquets ou des datagrammes : si le réseau sortant exigeait une taille de paquet plus petite que le réseau entrant, la passerelle fragmenterait le paquet en plusieurs paquets avant de le renvoyer. Cette méthode nécessitait toutefois que les hôtes récepteurs soient informés des fragmentations effectuées par la passerelle afin de reconstituer la transmission originale. Une transmission pouvait traverser plusieurs réseaux et potentiellement être fragmentée à plusieurs reprises. Cerf et Kahn ont écrit : Si une passerelle fragmente un paquet entrant en deux paquets ou plus, ces derniers doivent être transmis à l'hôte de destination sous forme de fragments ou réassemblés pour ce dernier. On pourrait souhaiter que la passerelle effectue le réassemblage afin de simplifier la tâche de l'hôte (ou du processus) de destination et/ou de tirer parti d'une taille de paquet plus importante. Nous estimons que les passerelles ne devraient pas effectuer cette fonction, car le réassemblage par la passerelle peut entraîner de graves problèmes de mise en mémoire tampon, des blocages potentiels, l'obligation pour tous les fragments d'un paquet de transiter par la même passerelle et une augmentation du délai de transmission. De plus, il ne suffit pas que les passerelles assurent cette fonction, car la passerelle finale peut également avoir à fragmenter un paquet pour la transmission. L'hôte de destination doit donc être préparé à effectuer cette tâche .

Cette solution a immédiatement suscité l'inquiétude de Pouzin et des Européens soucieux de toute conception de réseau obligeant les hôtes à corriger les erreurs introduites par les opérateurs de réseau, c'est-à-dire les PTT. Coupler la correction des erreurs entre hôtes à celle des erreurs entre réseaux impliquait un couplage des protocoles utilisés par les ordinateurs et les PTT, ce qui semblait être un moyen infaillible de céder le contrôle aux PTT et de aboutir à un système de communication informatique sous-optimal.

En mars 1974, Pouzin répondit à la note de Cerf et Kahn (document CEKA74 du groupe de travail 6.1 de l'IFIP) par une proposition : « Proposition pour l'interconnexion des réseaux à commutation de paquets » (INWG60). Cette proposition suscita de nouvelles révisions et propositions de part et d'autre.
En novembre 1974, les inquiétudes des Européens s'accrurent lorsque le CCITT décida d'établir une interface standard pour les réseaux à commutation de paquets qu'il proposerait (X.25). En décembre, dans l'espoir de trouver une solution pour un protocole d'interconnexion unique, Cerf, Yogen Dalal et Carl Sunshine soumirent le document INWG72 : « Spécifications du programme de contrôle de transmission d'interconnexion » (révisé). Cette révision proposait un système de fenêtrage pour résoudre les problèmes de fragmentation. Pouzin se souvient : Vint, Bob Kahn et probablement quelques autres, comme Yogen Dalal, ont donc tenté d'utiliser ce système de fenêtrage : un paquet unique pouvait être fragmenté en plusieurs paquets tout au long de son parcours, tous arrivant dans le désordre, et pourtant, le flux était contrôlé par ce même système de fenêtrage. Techniquement, c'était astucieux – je veux dire ingénieux –, mais nous n'avons pas adhéré à l'idée car nous la jugions d'abord trop complexe à mettre en œuvre, et ensuite beaucoup trop difficile à vendre à l'industrie. Ensuite, le problème résidait dans le mélange des approches : le protocole gérait à la fois des aspects liés au transport et des aspects liés au protocole de bout en bout. Ce type de couplage était politiquement inacceptable, car ces deux niveaux de système étaient gérés par deux mondes différents : les opérateurs de télécommunications et les informaticiens. De toute évidence, c'était inacceptable d'un point de vue sociologique. Impossible de vendre un système nécessitant le consensus de ces deux mondes. Nous avons donc estimé que ce n'était pas une bonne façon d'organiser les choses, même si techniquement solide.

La recherche d'une solution commune a permis d'affiner la compréhension de la conception des réseaux, qu'il s'agisse de réseaux de datagrammes ou de circuits virtuels, et des réseaux interconnectés de nombreux réseaux. Cerf se souvient de ces années difficiles : Pendant des années, une véritable bataille a opposé les partisans des réseaux à datagrammes à ceux des réseaux à circuits virtuels. Les initiatives internationales de télécommunications par téléphone (PTT) ont opté pour les circuits virtuels, tandis que la communauté de recherche et développement est restée fidèle aux datagrammes. De ce fait, cette dernière a dû composer avec un environnement de communication sous-jacent bien plus complexe, où la transmission des datagrammes n'était plus garantie. Un datagramme pouvait être brouillé, perdu ou rejeté en raison de la congestion du réseau. Les protocoles de niveau supérieur, fonctionnant au-dessus du mode datagramme de base, devaient être beaucoup plus robustes et intégrer davantage de mécanismes de contrôle de flux, de retransmission et de détection des doublons que les protocoles développés sur la base des circuits virtuels. Ces deux communautés ont donc divergé. Elles se livraient une lutte acharnée, et j'y participais moi aussi. Je tapais du poing sur la table en disant : « Bon sang, il fallait que ce soit des datagrammes parce que cela nécessitait moins de réseau et qu'il fallait de toute façon faire les choses de bout en bout, parce qu'il fallait que les ordinateurs centraux garantissent à l'autre extrémité qu'ils avaient réellement reçu les données, et pas seulement que le réseau pensait que vous les aviez reçues », donc il y avait beaucoup de discussions dans ce sens.

Mais pour Kahn et la DARPA, le débat devait cesser. Ils souhaitaient coder TCP et vérifier son bon fonctionnement. Début 1975, la DARPA attribua trois contrats pour tester si les spécifications TCP étaient suffisamment détaillées et explicites pour permettre à différentes implémentations de fonctionner de manière transparente. Les trois équipes étaient dirigées par Cerf à Stanford, Ray Tomlinson et Bill Plummer chez BBN, et Peter Kirstein à l'University College de Londres. Pouzin avait bien compris l'importance de la mise en œuvre de TCP : Après cela, ils ont en quelque sorte figé leur projet, et nous avons commencé à nous désintéresser car nous ne pensions pas qu'il puisse vraiment fonctionner. Nous avons donc commencé à contourner le problème, considérant que c'était inévitable car ils bénéficiaient du soutien total de l'ARPA ; nous pensions donc que nous ne pouvions pas les arrêter. Par ailleurs, nous avions le sentiment qu'ils n'investiraient pas massivement l'Europe, nous avons donc commencé à réorganiser nos activités sur le continent.

Les membres européens ont conclu qu'ils avaient besoin du soutien d'un organisme de normalisation pour faire avancer leur cause – l'IFIP n'étant pas un organisme de normalisation – et ils se sont donc tournés vers l'Organisation internationale de normalisation (ISO) à la fin de 1975.

En janvier 1976, afin de concilier les divergences entre les communautés TCP et européenne, Alex McKenzie, de BBN, a élaboré un protocole international répondant aux exigences de ceux qui souhaitaient un protocole de bout en bout et de ceux qui préféraient une séparation des fonctions de bout en bout et de réseau à réseau. Un article co-écrit par McKenzie, Cerf, Scantlebury et Zimmermann, présentant ce protocole, a été soumis à l'IFIP puis publié dans la revue Computer Communications Review. Malheureusement, il s'est avéré insuffisant et trop tardif. Comme le souligne Cerf, il n'a pas pu « convaincre la communauté TCP d'adopter ce compromis , compte tenu de l'expérience d'implémentation de TCP à l'époque et du caractère non éprouvé du document de l'IFIP ».

8.5 Une prolifération des projets de communication

L'idée qu'un nombre limité d'ordinateurs puisse desservir tous les utilisateurs – vision qui avait inspiré le développement d'Arpanet – ne correspondait plus à la réalité informatique aux États-Unis. Le succès des systèmes IBM 360/370, les efforts continus des autres constructeurs d'ordinateurs centraux pour s'implanter sur le marché et le nombre croissant de fabricants de mini-ordinateurs ont créé une grande diversité d'usages informatiques, favorisant toutes sortes d'interconnexions.

Les entreprises, les universités, l'armée et diverses agences gouvernementales ont toutes contribué à la diversification croissante des réseaux informatiques. La plupart des réseaux commerciaux, tels que CYBERNET de Control Data Corp. et le réseau TSS d'IBM, utilisaient des produits de communication de données traditionnels – modems, multiplexeurs et concentrateurs frontaux – et continuaient de fonctionner selon le principe de la commutation de circuits. Les produits concurrents de jeunes entreprises, comme Tymshare et Telenet, employaient des variantes de la commutation de paquets. Les réseaux universitaires avaient également tendance à utiliser des techniques traditionnelles et, bien que généralement limités à un seul campus, plusieurs universités s'associaient parfois pour former un « réseau informatique éducatif », tel que le réseau MERIT de l'Université d'État du Michigan, de l'Université Wayne State et de l'Université du Michigan.

Les projets de mise en réseau les plus audacieux étaient généralement financés par l'armée ou des agences de recherche gouvernementales. Le système Octopus du Laboratoire Lawrence Berkeley est un exemple de réseau sophistiqué développé par une agence gouvernementale. Par ailleurs, des projets de mise en réseau financés par des agences gouvernementales étaient menés dans les universités, le plus important étant un réseau financé par la National Science Foundation à l'Université de Californie à Irvine (UCI), conçu et géré par David Farber.

8.6 Anneau à jetons et David Farber, UC Irvine et la NSF 1969-1974

Contrairement à la plupart de ceux qui se sont intéressés aux communications informatiques entre 1965 et 1972, David Farber possédait une solide expérience en communications et en informatique. En 1956, il intègre les Bell Labs d'AT&T, où il travaille dans le domaine des systèmes de communication. Pendant les dix années qu'il y passe, il se familiarise avec l'informatique et les besoins des utilisateurs, en tant que directeur du centre informatique de Holmdel (New Jersey) et secrétaire de SHARE, l'association des utilisateurs d'IBM. En 1966, il rejoint la RAND Corporation, où il travaille pendant deux ans et est influencé par les travaux de Paul Baran. Il intègre ensuite Scientific Data Systems (SDS), une division de Xerox, et donne des cours du soir à l'Université de Californie à Irvine (UCI). Fin 1969, il accepte un poste de professeur associé par intérim à l'UCI pour une durée de deux ans, avec deux ans supplémentaires pour obtenir un poste permanent.

Une question résumait l'intérêt de Farber : « Pourrais-je utiliser un grand nombre de ces mini-ordinateurs ensemble pour former un environnement de calcul plus efficace ? » Début 1970, encore indécis quant à ce qui constituerait un projet important, il assista à une conférence de l'IEEE en Géorgie et entendit la première présentation publique d'ABOHAnet par Abramson. Cependant, ce qui capta particulièrement l'attention de Farber fut une conférence sur les anneaux de communication donnée par John Newhall et David Farmer des Bell Labs. Il se souvient : Ce qui m'a surtout motivé, c'est l'idée qu'il existait une technologie pour les réseaux locaux. Je suis donc retourné à Irvine et j'ai commencé à réfléchir à des objectifs précis. Je me suis dit : j'avais deux ans pour concevoir un projet, obtenir des financements et réaliser suffisamment de publications et de travail pour pouvoir postuler à un poste permanent dans deux ans. Un sacré défi ! Les projets qui font progresser la technologie sont toujours passionnants. Pendant cette période, je voulais explorer le degré de décentralisation maximal que je pouvais atteindre. Je savais que je pouvais concevoir un système similaire aux boucles de transmission de jetons d'IBM pour la communication entre processeurs, et que je pouvais également créer un processeur maître/esclave. J'ai d'ailleurs participé à ce projet chez SDS. L'objectif de ce qui allait devenir le Système Informatique Distribué (DCS) était donc de vérifier si nous pouvions parvenir à une distribution totale, sans aucun point d'erreur vulnérable. La communication, le traitement et les logiciels devaient être entièrement décentralisés. Nous ne voulions surtout pas dupliquer le boîtier de contrôle central du réseau Newhall-Farmer.

Farber, Rusty Barbero, un jeune professeur, et quelques étudiants de troisième cycle ont commencé à échanger des idées, inspirées des concepts d'anneau de jetons développés par Newhall et Farmer. Deux questions ont orienté leurs recherches : « Est-il possible de construire un anneau de jetons entièrement décentralisé ? » et « Pouvons-nous construire un anneau de jetons, un système de communication, compatible avec les paradigmes logiciels que nous souhaitions ? » Farber ajoute : Au début, on parlait de machines spécifiques avec lesquelles on communiquait. Or, il était impensable de procéder autrement si les logiciels utilisateurs connaissaient ces machines, même indirectement. Nous avons donc imaginé un système logiciel fonctionnant par l'échange de messages indépendants. À ma connaissance, il s'agit de la première présentation du traitement par messages. De plus, si des messages devaient être échangés, ne pouvait-on pas faire en sorte que les adresses soient indépendantes des machines sur lesquelles les programmes s'exécutaient ? Nous avons ainsi développé l'idée d'un système logiciel structuré par processus, avec des messages adressés par processus. Si je voulais envoyer un message à un programme, il me suffisait de connaître son nom pour l'envoyer, et le système de communication sous-jacent se chargeait du reste.

En 1970, Farber a soumis une demande de financement à la National Science Foundation (NSF), sollicitant environ 250 000 dollars par an, une subvention importante. Farber se souvient : Elle a été récompensée, ce qui a surpris tout le monde, moi y compris, et le problème était maintenant de la concrétiser !

Le système informatique distribué devait se composer d'une série de mini-ordinateurs, de contrôleurs de terminaux et de machines de fichiers interconnectés par un réseau en anneau à jeton. Farber souhaitait initialement acquérir des PDP-11 auprès de Digital Equipment Corporation, mais, par un heureux hasard, il finit par utiliser un clone de PDP-11 de Lockheed Corporation, appelé SUE. Lockheed, spécialisée dans la mémoire à tores magnétiques, avait commencé à commercialiser des ordinateurs afin de « fixer un support de stockage à ses utilisateurs ». Le SUE était fourni avec un minimum de logiciels, obligeant l'équipe de Farber à développer l'ensemble des logiciels nécessaires, y compris un compilateur. S'ils avaient utilisé des PDP-11, ils auraient probablement abouti à une solution de fortune, car il existait déjà de nombreux logiciels pour ce modèle. Chaque SUE était connecté à une paire torsadée partagée via une carte de circuit imprimé spécialement conçue pour le réseau en anneau à jeton, appelée interface en anneau. L'architecture de communication entre les appareils imitait la spécification numérique T-1 du système Bell, à la différence près qu'elle utilisait des messages de longueur fixe avec une bande passante de 2,5 mégabits par seconde.

Un réseau en anneau à jeton interconnecte des dispositifs sous forme de connexions nœud à nœud formant un anneau. Chaque nœud est constitué d'un dispositif, tel qu'un ordinateur, doté d'une carte de circuit imprimé spéciale connectée au support de transmission (voir l'illustration 6.3 : Anneau à jeton). Dans le cas du réseau UCI, le support de transmission était un câble à paires torsadées. Les nœuds, ou stations, du réseau obtiennent le droit de communiquer en se transmettant un jeton, une séquence binaire unique (généralement huit bits à 1), de nœud en nœud. Si un nœud souhaite communiquer, il attend de recevoir le jeton, ce qui signifie qu'il est autorisé à communiquer, puis le récupère et y ajoute son message. Une fois envoyé, le jeton est automatiquement transmis au nœud suivant, qui répète le processus. Si un nœud n'a rien à envoyer, il transmet simplement le jeton au nœud suivant. Puisque chaque nœud reçoit le jeton dans un délai connu, limité par la disponibilité des données à communiquer pour tous les autres nœuds, un réseau en anneau à jeton est, par définition, déterministe.

En février 1973, Farber présenta une communication à la conférence internationale de l'IEEE Computer Society, bien que le réseau ne soit pas encore opérationnel. Il se souvient : « À l'époque, beaucoup de choses étaient publiées avant même d'être construites. Un jeu dangereux, mais souvent nécessaire dans le monde universitaire. » La NSF approuva le renouvellement du contrat.

Fin 1973, ils avaient finalisé le logiciel nécessaire pour connecter un ordinateur au réseau. Alors qu'ils s'attendaient à ce qu'il leur faille une ou deux semaines pour rendre un réseau multinœuds opérationnel, ils ont réussi à faire transiter des jetons par un réseau de trois ordinateurs en une seule journée. Comme le rappelle Farber : « Ça est allé très vite. »

Début 1974, ils disposaient d'un réseau relativement stable. Farber, se souvient : À ce moment-là, c'est devenu très populaire, et la situation était assez étrange. Les gens ont commencé à en entendre parler et nous recevions des appels : « Nous aimerions venir le voir. » Nous répondions : « Vous voulez dire que vous voulez en parler ? » Ils répliquaient : « Non, nous voulons le voir ! »

Farber et son équipe à l'UCI ont démontré qu'il existait une autre méthode pour interconnecter des ordinateurs distribués. Cependant, leur intérêt portait sur les systèmes logiciels distribués et non sur le développement des communications informatiques. Ils n'ont donc guère œuvré pour promouvoir activement leur technologie d'anneau à jeton. Mais leur succès ne passerait pas inaperçu. Quelques années plus tard, cette technologie, financée par le gouvernement et donc du domaine public, allait être remise au goût du jour en réponse à la demande du marché, suite au refus de Xerox de commercialiser sa technologie de réseau local, développée par Robert Metcalfe au Xerox PARC.

Pièce justificative 8.6.0 Anneau à jetons


8.7 Ethernet et Robert Metcalfe et Xerox PARC 1971-1975

Lors de la démonstration à l'ICCC, Metcalfe, incrédule, n'en croyait pas ses oreilles face aux rires moqueurs des dirigeants d'AT&T lorsque l'Arpanet connut une brève panne. Il les jugeait insensibles à tout le travail acharné et aux espoirs qu'il partageait avec ses collègues – un exemple de plus du comportement abusif et arbitraire de ceux qui détiennent l'autorité et le pouvoir. Il faut dire que sa colère était facilement provoquée, car son monde avait été bouleversé par une injustice ressentie quelques mois auparavant. Pour comprendre l'état d'esprit de Metcalfe et comment sa détermination sans faille l'a conduit à inventer la technologie révolutionnaire de réseau local Ethernet, il faut remonter à la fin de 1971.

Lorsque Kahn lui demanda de contribuer à l'organisation de l'ICCC, Metcalfe avait toutes les raisons de se sentir investi d'une mission au sein du cercle restreint des instigateurs de l'Arpanet. Aussi, malgré un premier semestre 1972 déjà surchargé – il devait terminer et soutenir sa thèse de doctorat en juin et trouver un emploi, idéalement pour juillet –, Metcalfe accepta de prêter main-forte. Sa décision, prise deux ans plus tôt sans avoir été suffisamment éclairée, de se concentrer sur le réseautage, puis de rédiger sa thèse sur l'Arpanet, lui semblait désormais d'une clairvoyance troublante, comme si une force prédestinée le propulsait vers un avenir prometteur.

Les entretiens ont confirmé son sentiment de participer à un projet important. La plupart des opportunités semblaient se limiter à former d'autres personnes, à transmettre ses connaissances, sans vraiment se soucier de l'ampleur du travail à accomplir. Ce ne fut pas le cas de ses entretiens avec Jerry Elkind et Robert Taylor, codirecteurs du Laboratoire d'informatique du Centre de recherche Xerox de Palo Alto (PARC). Elkind et Taylor, respectivement anciens de BBN et d'IPTO, l'ont mis au défi non seulement d'enrichir son expérience Arpanet, mais aussi de rejoindre une équipe dédiée à la création d'un nouveau paradigme de « bureautique ». Séduit par tout ce qu'il a entendu, notamment la situation géographique dans la région de la baie de San Francisco, il a accepté de commencer en juillet, après avoir soutenu sa thèse de doctorat.

Au début du printemps, les responsabilités de l'ICCC conduisirent Metcalfe à Washington D.C. et, comme à son habitude, il logea chez son ami Steve Crocker. Après une longue soirée de discussions animées, Metcalfe se retira sur son canapé, dans le salon. Agité, il prit les actes de la conférence conjointe d'automne sur l'informatique de 1970 sur la table basse voisine, espérant s'endormir en lisant, mais son attention fut immédiatement captivée par un article de Norm Abramson intitulé : « Le système ALOHA : une autre alternative pour les communications informatiques ». Metcalfe s'en souvient très bien : Je lisais un article sur le fonctionnement statistique d'ALOHAnet. Le modèle utilisé par Abramson m'a exaspéré. Exaspéré, car il reposait sur un modèle certes simple, mais inexact. Autrement dit, on fait des suppositions sur un système pour simplifier les calculs, mais ces suppositions sont très discutables. En lisant les travaux d'Abramson, j'ai eu la même réaction : imaginez une infinité de personnes assises devant un clavier, tapant sans cesse. Quoi qu'il arrive, elles continuent de taper. Même sans réponse, elles continuent. Voyons comment le système réagit. Or, en lisant cela, je me suis dit : « Mais non ! Les gens s'arrêtent de taper ! S'ils n'obtiennent pas de réponse, ils attendent. Ce n'est pas exact. » Il s'agissait alors de processus de Poisson, de distributions exponentielles et autres formules mathématiques complexes, aboutissant à une élégante formule explicite. Le problème, à mon avis, était que le système ALOHA n'était pas correctement modélisé. Il faut dire qu'à l'époque, j'étais étudiant en master et je cherchais désespérément des notions mathématiques à intégrer à ma thèse.

En juin, Metcalfe, plein d'assurance, a présenté sa thèse à ses professeurs de Harvard : Ma thèse a été refusée, et je me suis fait virer sur un plateau ! Imaginez la scène : un étudiant en master, qui a fait tout son cursus au MIT, se présente pour défendre sa thèse devant des professeurs qu'il n'a jamais écoutés pendant trois ans, et à qui l'on demande de juger le contenu intellectuel de sa thèse. Je me suis fait laminer.

La thèse de Metcalfe fut rejetée, jugée insuffisamment mathématique et théorique. Abasourdi, Metcalfe, doutant de pouvoir trouver dans Arpanet le contenu théorique et mathématique nouveau et inédit dont il avait besoin, décida de se rendre à Hawaï pour approfondir ses connaissances sur ALOHAnet. Après avoir contacté Abramson, il reçut une aimable invitation. Il lui fallut ensuite convaincre son nouvel employeur de lui accorder le congé nécessaire.

En apprenant la nouvelle décevante de Metcalfe, la direction du PARC s'est montrée extrêmement compréhensive. Outre la mise en service du PARC sur l'Arpanet (leur système IMP ne devant être installé qu'en octobre), Metcalfe a bénéficié d'une totale liberté pour mener à bien ses travaux de recherche et honorer ses engagements envers Kahn. Avant son départ pour Hawaï, Metcalfe, le nouveau « spécialiste des réseaux » du PARC, a été informé du fonctionnement des routeurs Data General Nova 800 et de l'adaptateur de communication multiprocesseur (MCA) qui assurerait leur interconnexion. Le MCA était un câble parallèle 16 bits reliant les machines entre elles, avec un débit de données de 1,5 mégabit par seconde.

À Hawaï, Metcalfe, très sérieux, se concentrait sur ses études et, mis à part quelques parties de tennis et quelques bières partagées avec deux doctorants d'Abramson, Charlie Bass et John Davidson, il travaillait et ne faisait guère plus. Abramson se souvient : « Nous sommes allés dîner ensemble à deux ou trois reprises, ce genre d'échanges, mais il restait très discret sur ses recherches et je ne voulais pas le brusquer. »

Pour comprendre le réseau ALOHAnet, Metcalfe a commencé à construire des modèles mathématiques et à comparer les résultats aux données réelles. Il a également modélisé ce qui se passerait si les utilisateurs ne tapaient que lorsqu'ils obtenaient une réponse ; et, en l'absence de réponse, s'ils s'arrêtaient et attendaient d'en recevoir une – une situation appelée blocage. Metcalfe se souvient : Cela a eu un impact considérable sur les performances du système observé. Lors de la modélisation, il est apparu clairement que le système présentait des problèmes de stabilité. En effet, lorsqu'il était saturé, il générait de nombreuses retransmissions. Autrement dit, une surcharge excessive pouvait entraîner un dysfonctionnement complet. Cependant, en modélisant ce problème avec un modèle de population finie (les utilisateurs cessant de taper lorsqu'ils n'obtenaient pas de réponse), j'ai trouvé une solution évidente à ce problème de stabilité.

J'avais étudié la théorie du contrôle au MIT, et c'était un problème de contrôle. Autrement dit, plus il y a de collisions, moins il faut être agressif dans la transmission. Il faut se calmer. En fait, le modèle que j'ai utilisé était l'autoroute de Santa Monica. Il s'avère que les caractéristiques de débit du trafic autoroutier sont similaires à celles d'un système ALOHA : le débit augmente avec le trafic disponible jusqu'à un certain point où il y a congestion, puis il diminue avec du trafic supplémentaire, ce qui explique les embouteillages. Le phénomène est simple : psychologiquement, les gens ont tendance à ralentir lorsqu'ils sont proches de la voiture qui les précède. Ainsi, à mesure que les voitures se rapprochent et que les gens ralentissent, le débit diminue, et le système se dégrade. Il était donc très simple de prendre le réseau ALOHA et, lorsqu'on envoyait un message et qu'une collision survenait, de considérer cela comme la preuve que le réseau était saturé. Donc, lorsqu'on tentait de retransmettre, on faisait une pause d'un laps de temps aléatoire, puis on réessayait. Si vous aviez une autre collision, vous diriez « Wouah, c'est vraiment bondé », et vous changeriez de stratégie et reculeriez un peu. L'expression « détection de porteuse » signifiait donc : « Y a-t-il déjà quelqu'un ? »

En fait, le système ALOHA n'a pas fonctionné ainsi ; il a simplement été lancé. Par conséquent, une grande partie de la bande passante a été consommée en raison de collisions qui auraient pu être évitées par une simple vérification. La détection des collisions, pendant la transmission, permettait, du fait des distances, à deux ordinateurs de vérifier, de décider d'envoyer, puis de découvrir ultérieurement une collision. Ainsi, en surveillant la transmission pendant l'envoi, on pouvait détecter une collision et l'interrompre immédiatement. Cela permettait de minimiser le gaspillage de bande passante dû aux collisions.

Metcalfe ne se doutait pas encore que son intuition révolutionnaire concernant la détection des collisions aurait des implications majeures une fois de retour au PARC, confronté à l'interconnexion de nombreux ordinateurs. Il présenta ses résultats lors d'une conférence sur les systèmes informatiques à l'Université d'Hawaï.

De retour au PARC, Metcalfe s'est attelé aux problèmes d'interconnexion des ordinateurs du PARC à l'Arpanet et à la rédaction des scénarios pour le prochain salon ICCC. Fin octobre, lorsqu'il a enfin pu s'exprimer, les deux projets achevés, la direction du PARC l'a mis au défi de concevoir et de développer un réseau de communication capable de répondre aux besoins de nombreux ordinateurs Altos et de périphériques tels que les imprimantes laser, alors en cours de développement. Cet environnement informatique de « nouvelle génération » imposait des exigences de communication sans précédent en raison de l'utilisation de graphismes bitmap pour l'interface utilisateur et l'impression de documents. Les communications informatiques volumineuses seraient la norme, et non plus l'exception comme avec l'Arpanet. Si les communications requises ne pouvaient être assurées de manière fiable, la nouvelle vision informatique du PARC risquait de rester un simple rêve.

Heureusement pour Metcalfe, la direction du PARC comprenait qu'elle cherchait à créer un nouveau paradigme informatique et que l'innovation propriétaire pouvait constituer un frein à la concurrence. Elle ne souhaitait pas que Metcalfe reproduise le travail d'autrui et l'encourageait plutôt à aborder le problème avec objectivité et à concevoir la meilleure solution possible. Pour Metcalfe, le mandat de la direction l'incitait à considérer son intuition grandissante en matière de communications informatiques non pas comme une simple spéculation théorique, mais comme une opportunité à saisir. En bref, un homme préparé et motivé se trouvait dans un contexte favorable.

Metcalfe comprenait parfaitement l'évolution rapide des communications informatiques et consultait la littérature à la recherche de développements pertinents susceptibles d'influencer ses travaux. Ayant pris connaissance des travaux de Farber à l'UCI, il se procura un exemplaire de son article paru dans l'IEEE en février. (Metcalfe : « Nous sommes devenus des rivaux acharnés, mais amicaux. ») Il contacta également Cerf, alors professeur assistant à Stanford, à seulement dix minutes de là, et commença à assister à son séminaire de troisième cycle sur les réseaux ; il y devint rapidement enseignant. Début 1973, Metcalfe participa aux discussions entre Cerf et Kahn concernant la refonte du protocole NCP d'Arpanet.

Le 22 mai 1973, Metcalfe a distribué à l'équipe ALTO ALOHA une note confidentielle portant la mention « Documentation Xerox sensible ». Objet : Acquisition d'éther. Pour citer la page de couverture :
"Voici quelques éléments supplémentaires, encore à l'état d'ébauche, concernant le réseau ALTO ALOHA.
Je propose que nous cessions d'appeler ce système « réseau ALTO ALOHA ». D'abord, parce qu'il doit prendre en charge divers types de stations — disons, des NOVA, des PDP-11, etc. Ensuite, parce que son architecture commence à paraître bien plus élégante que celle du réseau radio ALOHA — pour reprendre le terme « beautiful » (élégant/beau) employé par Charles.
Peut-être : le « réseau ETHER ». Des suggestions ?
J'espère pouvoir bientôt effectuer des simulations. De l'aide ? Des contributions ?
J'espère que vous ne serez pas froissés par mes tentatives de présenter cette réflexion et cette conception sous un angle théorique."
Dans cette note de service, Metcalfe évoque le réseau ETHER :
"Nous prévoyons de construire un réseau de communication informatique par diffusion, assez proche du réseau radio du système ALOHA, mais spécifiquement destiné aux communications entre mini-ordinateurs au sein d'un même bâtiment. Nous envisageons des systèmes NOVA et ALTO reliés par des câbles coaxiaux.
Bien que nous finissions peut-être par utiliser des arborescences de câbles coaxiaux pour acheminer nos transmissions par diffusion, il semble judicieux de parler d'un « éther » plutôt que « du câble », aussi longtemps que possible. Cela permet de conserver une approche générale ; qui sait quels autres supports pourraient s'avérer plus performants que le câble pour un réseau de diffusion ? Peut-être la radio, les lignes téléphoniques, le réseau électrique, la télédistribution (CATV) par multiplexage fréquentiel, les liaisons par micro-ondes, voire une combinaison de ces technologies.
La caractéristique essentielle de notre support — l'éther — est qu'il achemine les transmissions et propage les bits vers toutes les stations. Nous allons étudier la pertinence des réseaux basés sur ce concept d'éther."

Metcalfe explique l'éther : L'éther, à l'origine, était un milieu passif omniprésent pour la propagation des ondes électromagnétiques. Il devait servir de support à la propagation des ondes électromagnétiques, des paquets de données ; d'où l'éther assimilé au câble. Il s'agissait donc d'un réseau utilisant l'éther : l'EtherNet.

Metcalfe se souvient d'avoir rencontré Leonard Kleinrock à l'aéroport national de Washington et de lui avoir montré les mathématiques de sa thèse de doctorat.

Il m'a dit que ce n'était « pas très rigoureux ». Il a balayé la chose d'un revers de main.

En mai, Metcalfe avait terminé d'intégrer les explications mathématiques du fonctionnement d'ALOHAnet à sa thèse et l'a soumise à nouveau à son nouveau directeur de thèse, Jeff Busen. Cette fois, elle fut acceptée et Metcalfe obtint son doctorat en juin 1973. Metcalfe remarque avec ironie : Pour vous donner une idée de la façon dont je l'ai obtenue : l'université Harvard n'a pas publié ma thèse de doctorat. Elle a été publiée par le MIT, dans le cadre du projet MAC, où j'avais effectué tous les travaux. Il s'agissait donc d'une thèse réalisée chez Xerox, pour un doctorat de Harvard, publiée par le MIT – Rapport technique MAC n° 114.

En juin , Metcalfe reçut le feu vert pour construire un prototype d'Ethernet. (Comme Ethernet deviendra son nom officiel, on l'utilisera par convention dès le début.) Metcalfe se souvient : Il me fallait lancer le projet : concevoir la logique, fabriquer les cartes, écrire le microcode, etc. Et je n’aime pas travailler seul. En fait, je pense que l’équipe idéale est composée de deux personnes. Trois, c’est trop, et une, c’est insuffisant. Deux, c’est parfait. Alors, je me suis mis à la recherche d’un collaborateur, et un jour, j’ai aperçu un type en mocassins, les cheveux longs jusqu’au bas du dos, qui déambulait dans le bâtiment 34 du PARC. Il n’avait pas l’air occupé. On aurait dit qu’il n’avait pas grand-chose à faire. Alors, je me suis renseigné et j’ai découvert qu’il était étudiant en master à Stanford et qu’il travaillait pour David Liddle. J’ai donc posé des questions à David à son sujet, et il m’a dit : « Pourquoi ne pas lui proposer de travailler sur ton projet ? » J’ai donc contacté David R. Boggs, je lui ai fait une proposition et nous avons entamé un projet commun de deux ans.

Le projet Ethernet nécessitait de développer la conception préliminaire de Metcalfe, de construire le matériel permettant de connecter les ordinateurs au câble coaxial et de concevoir et programmer le protocole réseau afin que les ordinateurs et les périphériques puissent partager des informations. Metcalfe comprit qu'il lui fallait un protocole de communication plus simple que le NCP d'Arpanet ou le nouveau protocole conçu par Cerf et Kahn, qui devait fonctionner sur différents types de réseaux.

À la fin de l'année 1973, alors que Metcalfe et Boggs passaient de la conception à la mise en œuvre, Metcalfe constata qu'il disposait de peu de temps pour participer aux sessions animées par Cerf. Il devait respecter des échéances de projet impératives, ce qui impliquait de faire des choix et de les limiter au matériel et aux logiciels. Les exigences de confidentialité de Xerox, qui restreignaient les informations que Metcalfe pouvait divulguer à Cerf et à ses collègues, limitaient encore davantage sa relation avec Cerf. Ne pouvant discuter ouvertement de son travail, Metcalfe tira peu de profit des discussions plus académiques et ouvertes animées par Cerf. Ce dernier, agissant sous l'égide de la DARPA, cherchait à imposer une norme au sein d'une communauté très hétérogène, peu encline à coopérer ou à résoudre les problèmes dans des délais fixes. Par conséquent, le développement initial des protocoles de réseau local, initié par Metcalfe et Boggs, suivit une voie très différente de la refonte du NCP par Cerf et Kahn, une digression qui allait bientôt s'avérer importante.

L'objectif de conception d'Ethernet par Metcalfe était de créer un système de communication capable d'évoluer de manière fluide pour s'adapter à plusieurs bâtiments abritant des ordinateurs personnels et les infrastructures nécessaires à leur fonctionnement. (Figure 6.4 Ethernet) Deux objectifs secondaires, tout aussi souhaitables, étaient un coût réduit et, de préférence, une distribution du contrôle afin d'éliminer le goulot d'étranglement inhérent à un contrôle centralisé. La conception de Metcalfe intégrait des contributions architecturales d'Arpanet et d'ALOHAnet : des communications par paquets avec diffusion. Partant du principe de collision et de retransmission de paquets développé dans le réseau ALOHA, Metcalfe y ajouta sa propre approche de la détection des collisions. Les ordinateurs et périphériques écoutaient en permanence le canal de communication (l'« Ether ») et n'envoyaient (diffusaient) leurs messages que lorsqu'ils détectaient un canal libre. En cas de collision avec des paquets émis par d'autres stations, toutes les stations émettrices interrompaient leur transmission, attendaient un intervalle de temps proportionnel à la fréquence des collisions, puis retransmettaient. Si de nouvelles collisions survenaient, les ordinateurs émetteurs attendaient un intervalle plus long et réessayaient ; ce processus se répétait jusqu'à ce que la transmission réussisse. Ce qui rend Ethernet possible, c'est que la plupart des messages sont courts, de l'ordre de centaines ou de milliers de bits, comparés à la bande passante du canal de communication de 3 mégabits par seconde – le même principe que celui reconnu une décennie plus tôt par Baran et Davies.

La conception finale du réseau Ethernet s'est avérée d'une simplicité élégante : du matériel pour interconnecter les ordinateurs et les périphériques afin qu'ils puissent échanger des données, et un protocole réseau pour interpréter ces données. Le matériel se compose de contrôleurs d'interface, d'émetteurs-récepteurs et de prises, ainsi que d'un support de transmission. Un contrôleur d'interface, ou adaptateur, se connecte au fond de panier, ou bus, des équipements informatiques (stations Ethernet) et envoie et reçoit des données formatées vers l'émetteur-récepteur. Ce dernier convertit les données numériques provenant du contrôleur d'interface ou lui étant destinées en signaux analogiques requis par le support de transmission (infrastructure de communication). En pratique, l'émetteur-récepteur agit comme un modem. Des prises sont nécessaires pour connecter physiquement les émetteurs-récepteurs au support de transmission avec un minimum de perturbations lors de la connexion ou de la déconnexion. Enfin , il y a le support de transmission nécessaire au transport des signaux. Le premier support de transmission était le câble coaxial, initialement reconnaissable à sa gaine jaune. Pour interconnecter deux réseaux Ethernet ou plus, un équipement supplémentaire, un répéteur, est nécessaire.

Annexe 8.7.1 Ethernet
Schéma d'un réseau Ethernet

Le protocole réseau est implémenté par logiciel pour s'exécuter à la fois sur les stations Ethernet et les contrôleurs d'interface. Il fournit les services essentiels de correction d'erreurs, de contrôle de flux, de dénomination des processus, de sécurité et de comptabilisation. Le protocole réseau créé par Metcalfe et Boggs – PARC Universal Packet, ou Pup – s'appuyait sur les connaissances et l'expérience acquises lors de la création du protocole NCP par l'ARPA et de sa recréation sous la direction de Cerf et Kahn. Pup était en réalité une hiérarchie de protocoles permettant une fonctionnalité de bout en bout, incluant le transfert de fichiers et la messagerie électronique. (Voir l'annexe 6.5 : Protocole Pup)

Fin 1974, Metcalfe et Boggs disposaient d'un réseau Ethernet à 3 mégabits par seconde avec Pup fonctionnel. Forts de ce succès, Xerox déposa des brevets pour la technologie Ethernet sous les noms de Metcalfe, Boggs, Butler Lampson et Chuck Thacker. (Metcalfe insistait pour que les noms de Lampson, « le gourou intellectuel sous la direction duquel nous avons tous eu le privilège de travailler », et de Thacker, « le concepteur des Altos », figurent sur le brevet.)
Une fois le brevet déposé, Metcalfe et Boggs purent publier leurs travaux en soumettant un article à la revue Communications of the ACM, intitulé : « Ethernet : Commutation de paquets distribuée pour les réseaux informatiques locaux ».
Publié en juillet 1976, cet article devint une référence pour tous les travaux ultérieurs sur les réseaux locaux. Dès le milieu de l'année 1975, le PARC avait installé un réseau Ethernet de cent nœuds, pleinement opérationnel en 1976.

Pièce 8.7.2 Le protocole Pup


8.8 Institut de technologie du Massachusetts 1974 - 1977

En 1974, le seul moyen efficace dont disposaient les informaticiens du MIT pour interconnecter leurs ordinateurs était l'utilisation de deux IMP, une solution de plus en plus inacceptable, surtout compte tenu des travaux de Metcalfe, surnommés avec envie « ALOHAnet sur un fil ». Les scientifiques du MIT se sont donc trouvés face au défi de construire ou d'acheter des réseaux locaux.

Le Laboratoire d'Intelligence Artificielle (IA) a pris l'initiative. Accaparé par son propre programme de recherche, il n'était guère enclin à développer sa propre technologie de réseau local et a contacté PARC pour l'achat de produits Ethernet. Xerox a décliné l'offre. Xerox considérait Ethernet comme une technologie propriétaire et essentielle à ses systèmes bureautiques, et non comme un produit à vendre séparément. Le professeur Jerry Saltzer, l'un des premiers à s'impliquer dans le développement du réseau pour le Laboratoire d'Informatique (LCS), se souvient : Xerox avait inventé et construit la première version d'Ethernet, mais la considérait toujours comme une technologie propriétaire et interdisait à quiconque d'utiliser son savoir-faire interne. Son bon fonctionnement a suffi à convaincre quelqu'un d'autre : « Dans ce cas, nous allons en construire une aussi. » C'est ainsi que le Laboratoire d'IA a créé Chaosnet. Sa création était motivée par l'impossibilité d'utiliser Ethernet. Chaosnet était essentiellement une autre version d'Ethernet, présentant de légères différences, mais celles-ci étaient négligeables.

En 1975, le LCS s'intéressa sérieusement aux réseaux locaux. Michael Dertouzos, directeur du LCS, Saltzer et Dave Clark, chercheur associé, chargèrent Ken Pogran d'étudier les technologies de réseaux locaux disponibles. Informée des intérêts du LCS, la DARPA fit pression sur le MIT pour qu'il importe la technologie Token Ring développée à l'UC Irvine par Farber, plutôt que d'en créer une nouvelle.

Pogran s'est rendu au PARC et a passé une journée en réunion avec un Metcalfe rasé de près, un homme d'affaires au look très professionnel, bien loin de celui qu'il avait connu à l'époque d'Arpanet. Pogran a ensuite visité Farber et a appris son projet de créer un anneau à jetons de deuxième génération, en employant des doctorants. L'objectif n'était pas d'étudier les anneaux à jetons en tant que tels, mais de disposer d'un anneau à jetons amélioré pour mener des recherches sur les systèmes distribués.

À son retour au MIT, Pogran présenta ses conclusions à Dertouzos, Saltzer et Clark. Ils rejetèrent Chaosnet, craignant que le support et le développement futurs du produit, dont ils savaient avoir besoin, ne soient pas une priorité pour le laboratoire d'IA ; un problème majeur puisque LCS ne disposait pas des capacités de développement matériel du laboratoire d'IA. Xerox refusant de partager sa technologie, leurs seules options étaient soit de créer une nouvelle technologie, soit d'importer la technologie Token Ring de l'UC Irvine. LCS opta pour Token Ring, sachant pourtant que des étudiants de troisième cycle développaient la version du produit qu'ils allaient utiliser.

LCS a commencé à planifier ce que Dertouzos appelait le « réseau 76 ». Pogran a débuté comme chef de projet, mais a rapidement pris en charge des tâches d'ingénierie directe pour lesquelles personne à l'UC Irvine n'avait ni le temps ni les compétences. Malgré ses efforts, Pogran n'a pas pu respecter le calendrier initial et a finalement livré des interfaces réseau locales (LNI) fonctionnelles en 1977, permettant un réseau en anneau à jeton d'un débit de 1 mégabit par seconde.

Cette même année, en 1977, Saltzer prit son année sabbatique au MIT et passa un an à travailler pour IBM : Je travaillais à White Plains, mais je voyageais beaucoup, et l'une de mes escales fut Zurich. J'y ai découvert qu'ils s'intéressaient aux réseaux à jeton (token ring). Nous avons donc comparé nos notes, et je leur ai fourni toutes les informations dont nous disposions. Le laboratoire de Zurich avait pour mission les communications et cherchait à déterminer s'il pouvait apporter une contribution utile dans le domaine des réseaux locaux. À cette époque, le seul réseau local en Europe était le Cambridge Ring de l'université de Cambridge, au Royaume-Uni. L'Ethernet était déployé à 8 000 kilomètres de là. Xerox était également une entreprise concurrente, et il était difficile d'obtenir des informations sur leurs travaux.

Les opinions de Saltzer, fondées sur sa première expérience avec le protocole Token Ring au LCS, ont conforté la préférence historique d'IBM pour les protocoles déterministes et synchrones. La diffusion initiale de la technologie Token Ring de Farber et de l'UC Irvine chez IBM avait eu lieu quelques mois auparavant avec Philippe Janson. Clark ajoute : Après avoir obtenu son doctorat au MIT en 1976, Philippe Janson a rejoint IBM à Zurich. Je suis convaincu que lorsque Zurich a cherché à construire un réseau, et qu'ils ne souhaitaient pas opter pour Ethernet, car ils étaient très attachés à leurs traditions, Janson a suggéré de construire des réseaux en anneau, en s'appuyant sur son expérience au MIT.

Le réseau LCS représentait une innovation progressive de la technologie en anneau à jeton importée de l'UC Irvine. Par exemple, soucieux de détecter les défauts de câblage, le réseau LCS connectait chaque nœud du réseau via une « armoire de câblage » centrale, donnant naissance à une topologie en étoile qui allait devenir la norme pour les futurs réseaux en anneau à jeton.

8.9 Metcalfe rejoint la division de développement des systèmes de Xerox (1975-1978)

Malgré son succès, Metcalfe se sentait frustré dans un environnement strictement axé sur la recherche. Il aspirait à l'énergie et à l'enthousiasme liés à la recherche de pointe, mais aussi à la satisfaction de concrétiser ses idées. Il voulait être plus qu'un simple ingénieur. En novembre 1975, il quitta Xerox PARC pour Transaction Technology, Inc., une filiale de Citibank spécialisée dans le développement de produits avancés. Sept mois plus tard, David Liddle le convainquit de revenir chez Xerox pour intégrer la toute nouvelle Division de développement des systèmes (SDD). La mission de la SDD prévoyait notamment la commercialisation des technologies Altos, dont Ethernet.

La commercialisation des technologies Altos nécessitait bien plus que la simple vente de l'existant. L'ensemble du système, y compris Ethernet, devait être repensé pour améliorer les performances, réduire les coûts et préparer la production. L'objectif initial pour Ethernet était d'augmenter les performances de 3 mégabits par seconde à 20 mégabits par seconde et d'améliorer d'autant le PUP (taux d'utilisation pseudo-utile) .

Liddle se souvient de la controverse entourant la décision d'augmenter le débit, ou la bande passante, d'Ethernet à 20 mégabits par seconde : Les gens de PARC se plaignaient beaucoup, demandant : « Pourquoi trois mégabits ne suffisent-ils pas ? » Nous avons simplement répondu : « Nous pensions que trois mégabits ne seraient pas suffisants sur cette période », car nous anticipions une augmentation des transferts de fichiers volumineux, de bases de données et de l’impression d’images de grande taille. Le produit jouait en réalité quasiment le rôle d’un bus, et non plus celui d’une simple ligne de communication avec des signaux sonores. Cette décision a suscité une certaine controverse, car elle a engendré une augmentation du coût et une complexité accrue dans la conception de certains composants.

À la fin de l'été 1976, Metcalfe devait trouver une personne maîtrisant les dernières évolutions en matière de protocoles, notamment TCP, pour piloter la refonte du protocole Pup. Metcalfe connaissait parfaitement la conception d'Ethernet, mais se sentait un peu perdu face au développement des protocoles. Heureusement, une personne aussi expérimentée existait : Yogen Dalal. Metcalfe connaissait Dalal et le tenait en haute estime. Dalal allait terminer son doctorat sous la direction de Cerf à Stanford début 1977.

Convaincre Dalal ne serait pas chose aisée, car il était également courtisé avec insistance par Kahn à la DARPA, Tomlinson au BBN, Taylor au PARC et Steve Crocker à l'Information Sciences Institute. L'intérêt constant de Dalal pour les protocoles de communication constituait un atout majeur pour Metcalfe. En 1975, il avait fait partie de l'équipe de Cerf chargée du codage et des tests du protocole TCP. Dalal était également membre du groupe de travail TCP et s'impliquait fortement dans la conception d'une seconde version de TCP, intégrant les enseignements tirés des tests et de l'utilisation de la première version.

En septembre 1976, indépendamment de ses propres efforts, le mentor de Dalal, Cerf, démissionna subitement de son poste d'enseignant à Stanford et de la présidence du groupe de travail 6.1 de l'IFIP pour rejoindre la DARPA, où il dirigea les technologies de communication par paquets, le projet Internet et le programme de sécurité des réseaux. L' influence de Cerf sur les réseaux se poursuivit, tant par ses propres contributions que par celles de ses nombreux étudiants, parmi lesquels Dalal, Carl Sunshine, Richard Karp, Jim Mathis, Ron Crane, Darryl Rubin, John Shoch et Judith Estrin, fille de Jerry Estrin, directeur de thèse de Cerf à l'UCLA.

Avec Cerf à la DARPA, Dalal décida de se lancer en solo, indépendamment de lui. Finalement, l'offre de Metcalfe de créer le protocole successeur de Pup était tout simplement trop alléchante pour être refusée. Après avoir rejoint SDD en 1977, Dalal commença à constituer son équipe – comprenant notamment Will Crowther, ancien membre clé de l'équipe Arpanet de BBN, et Hal Murray – et à mener une analyse approfondie de Pup.

Metcalfe recruta également James White, qu'il connaissait de l'époque d'Arpanet et qui travaillait alors au Stanford Research Institute, pour devenir responsable du groupe de logiciels de communication en 1977.⁴⁰ Outre la refonte de Pup, le groupe de White prit en charge la commercialisation de « Grapevine », un système de messagerie électronique distribué basé sur Ethernet et développé par PARC.⁴¹

Début 1978, alors qu'Ethernet fonctionnait et que les ventes de produits n'étaient pas plus avancées qu'à son arrivée chez SDD, Metcalfe se sentait frustré et impatient. Souhaitant voir sa technologie Ethernet commercialisée avant que d'autres n'exploitent l'opportunité, il plaida pour que Xerox vende les produits Ethernet séparément des systèmes informatiques. Cependant, la direction ne partageait pas son point de vue. Au printemps 1978, Metcalfe lança un ultimatum à la direction, menaçant à peine de démissionner si Ethernet n'était pas mis en vente. Il se souvient : À mon retour chez Xerox en 1976, il nous restait environ deux ans et demi avant la commercialisation du produit, et c'était toujours le cas en 1978. Mon analyse, alors un peu naïve, était que d'autres facteurs que l'ingénierie étaient nécessaires à la réussite. Apparemment, puisque nous étions si performants en ingénierie, les problèmes devaient venir du marketing, de la production ou d'un autre domaine. Je voulais donc en savoir plus, car je détestais l'échec, et nous étions en train d'échouer – nous, pas eux, nous échouions. Étant donné que j'étais très impliqué dans le service d'ingénierie, j'ai donné mon préavis de sept mois à Xerox et j'ai demandé à être rattaché à un directeur général.

Metcalfe n'obtint pas gain de cause et, fidèle à sa parole, il quitta Xerox fin 1978 pour devenir consultant indépendant.

8.10 Système de réseau Xerox (XNS) 1977-1978

Lorsqu'il a rejoint la division de développement des systèmes (SDD) de Xerox en 1977 pour diriger la refonte du protocole de communication Pup, Dalal, comme la plupart des informaticiens curieux, avait une certaine connaissance de l'ampleur des innovations en cours au sein du PARC et donc au sein de la SDD. Cependant, les quelques faits avérés, mêlés à des rumeurs, ne pouvaient remplacer l'expérience concrète de l'utilisation d'un ordinateur Altos à interface graphique, connecté à d'autres ordinateurs Altos/mini-ordinateurs et à des périphériques (tels que des imprimantes laser), via le réseau local Ethernet haut débit. Dalal a rapidement compris que la vision d'Altos n'était pas une simple innovation informatique, mais annonçait un bouleversement majeur qui allait révolutionner l'informatique. Il savait également que les concepteurs de la refonte du TCP n'avaient pas envisagé un avenir composé de milliers, voire de millions, de réseaux. Dalal se souvient de sa révélation surprenante : Après avoir quitté Stanford pour rejoindre Xerox, j'ai clairement compris l'impact que les réseaux locaux auraient sur l'interconnexion de réseaux, et que si les problèmes théoriques liés à l'interconnexion de réseaux avaient été résolus dans le contexte de la DARPA, de nouvelles perspectives étaient mises en lumière sur ce que les ordinateurs personnels pourraient attendre d'un protocole d'interconnexion de réseaux.

Comme Metcalfe avant lui, Dalal tenta de s'intégrer à la fois au monde propriétaire de Xerox, où le statut d'employé impose des restrictions à la liberté d'expression, et au système socio-universitaire et gouvernemental qui sous-tendait la création de TCP. Lui aussi constata qu'il n'avait ni le temps ni l'envie de gérer les conflits d'intérêts liés à son appartenance à ces deux communautés et se concentra donc sur Pup. Il mit à profit sa connaissance approfondie de TCP, connaissance qui lui permit d'influencer la refonte de Pup.

Fin 1977, les premières spécifications du protocole de communication de nouvelle génération de Xerox étaient finalisées. Baptisé Xerox Network System (XNS), ce protocole était conçu pour le nouveau réseau Ethernet à haut débit et étendait l'architecture de datagrammes de Pup afin d'intégrer des passerelles, ou routeurs, entre les réseaux. XNS séparait les fonctions de routage d'un datagramme (appelé Pup chez Xerox) ou d'un paquet Internet à travers plusieurs réseaux des fonctions de communication de bout en bout sur un réseau, tel qu'un réseau local Ethernet. (Dans XNS, la couche réseau comprenait une « sous-couche Internet » et une « sous-couche spécifique au réseau ».) (Voir l'illustration 6.2 : XNS et Ethernet.) À l'instar de Pup, XNS prenait en charge plusieurs protocoles de transport, dont un protocole de circuit virtuel en tant que sous-couche spécifique au réseau. Cette séparation des fonctions réseau et transport allait influencer tous les protocoles réseau ultérieurs.

Annexe 8.9.1 XNS et Ethernet
Schéma de XNS et Ethernet

L'avenir de multiples réseaux hétérogènes, notamment les réseaux Ethernet qui, par conception, impliquaient de nombreuses retransmissions, posait de sérieux problèmes à la version 2 du protocole TCP.

8.11 TCP vers TCP/IP 1976-1979

En 1976, la DARPA transmit sa nouvelle spécification TCP version 2 au Laboratoire d'informatique (LCS) du MIT, espérant obtenir son soutien. Michael Dertouzos, directeur du LCS, confia à Dave Reed la responsabilité de l'examiner et de formuler des commentaires. Reed, avec l'aide de Dave Clark et d'autres, rédigea une note à l'attention de la DARPA en novembre 1976, proposant une alternative à TCP : le protocole de flux de données (DSP). Kahn, opposé catégorique à ce que l'un des principaux centres de recherche de la DARPA développe un protocole orthogonal à TCP, convoqua immédiatement une réunion.

Kahn se souvient : Dave Reed avait imaginé un autre protocole car il n'appréciait pas TCP. Je me suis entretenu avec Dave et d'autres collègues du MIT, qui m'ont décrit le protocole de flux de données. J'ai alors déclaré : « Mais c'est le même principe que TCP, à une petite différence près. » Ils ont rétorqué : « Non, pas du tout. Lisez ce que Vint dit dans ce rapport. » J'ai alors expliqué : « Ce n'est que son interprétation. Relisez notre article initial, et vous verrez qu'on peut aussi l'interpréter à sa façon. » Ainsi, même notre article initial était sujet à de multiples interprétations quant à sa mise en œuvre concrète.

Kahn, sachant qu'il devait convaincre le MIT de se rallier à TCP et d'abandonner le traitement numérique du signal (DSP), leur promit un rôle influent s'ils renonçaient à leurs idées sur le DSP. Reed et Clark commencèrent à assister aux réunions et bientôt Clark – qui travaillait alors à la fois sur l'interconnexion de l'ordinateur Multics du LCS à l'Arpanet et sur le développement de leur réseau local à jeton, le LCS Net – devint un acteur clé des activités liées à TCP. 44 Clark se souvient : Nous avons donc commencé à assister aux réunions et, en réalité, bien que ce soit Dave [Reed] qui ait rédigé les notes de service sur le traitement du signal numérique, c'est moi qui me suis intéressé aux réunions et qui ai commencé à y aller. Et pendant le reste de la décennie, tandis que de nombreux projets de réseau local étaient en cours au MIT, je me suis davantage impliqué dans les activités liées au protocole TCP.

Très vite, Clark a lui aussi compris la nécessité de séparer les fonctions de communication réseau (ou Internet) des fonctions de bout en bout (ou de transport) au sein du protocole TCP. Dalal se souvient : Le concept de datagramme est né de quelques allusions de John Shoch, David Boggs et moi-même, qui travaillions alors sur Pup et XNS. Pup commençait à être divulgué, mais avant même cela, nous avions tenté de convaincre Vint, Jon Postel et d'autres de l'importance de séparer les protocoles en datagrammes (Internet) et en protocole de session (transport), principalement parce que les datagrammes sont utiles dans les réseaux locaux. Vint, Dave Clark et Jon Postel l'ont immédiatement compris et ont progressivement entrepris de modifier TCP.

En 1978, Clark, Reed et Kenneth Pogran ont publié un article de l'IEEE préconisant la séparation des protocoles de communication LAN en deux couches :

Une structure à deux couches est tout à fait naturelle pour les protocoles de bas niveau dans un réseau local. La couche inférieure assure la fonction de base d'acheminement d'un message adressé vers l'une de ses destinations. Ce niveau correspond au concept de réseau de datagrammes. Au-dessus de cette première couche, divers protocoles doivent être disponibles. L'un d'eux doit prendre en charge un mécanisme de circuit virtuel, car ce modèle est parfaitement adapté à une grande partie des communications qui s'effectuent sur tout réseau, local ou non.

En 1978, il était devenu évident que la version 2 du protocole TCP devait être modifiée pour prendre en charge tous les types d'interconnexions réseau, et les travaux visant à la diviser en deux couches, réseau et transport, ont commencé. (Voir l'annexe 6.3 : TCP vers TCP/IP.) TCP/IP était initialement connu sous le nom de version 4 du protocole TCP.

Figure 6.3 TCP vers TCP/IP
Schéma de conversion TCP vers TCP/IP

Les nouveaux protocoles de couche réseau, également appelés protocoles Internet (pour réseaux interconnectés), ont permis une interconnexion transparente des réseaux sans impacter leur fonctionnement interne. Jon Postel décrit le protocole de couche Internet ou protocole IP : En résumé, le protocole Internet ARPA (TCP/IP) prend en charge la livraison de datagrammes d'une source Internet vers une destination Internet unique. IP traite chaque datagramme comme une entité indépendante, sans lien avec aucun autre. Il n'y a ni connexion ni circuit logique (virtuel ou autre). Il n'y a pas d'accusés de réception, ni de bout en bout ni de saut en saut. Il n'y a pas de contrôle d'erreur pour les données, seulement une somme de contrôle d'en-tête. Il n'y a pas de retransmissions. Le contrôle de flux est minimal. Par souci de flexibilité, ces fonctions sont explicitement laissées aux protocoles de niveau supérieur.

Les passerelles, ordinateurs spécialisés utilisés pour interconnecter les réseaux, acheminaient le trafic sur les réseaux en utilisant les protocoles Internet 49 (Voir l'annexe 6.3.1 Modèle de transmission TCP/IP). La séparation des fonctions réseau de TCP a ensuite permis la création de différents protocoles de couche transport, y compris un service de bout en bout fiable, tels que les circuits virtuels (TCP).

Figure 6.3.1 Modèle de transmission TCP/IP
Schéma du modèle de transmission TCP/IP

En 1979, la DARPA décida de privilégier l'utilisation des nouveaux ordinateurs VAX de DEC. DEC ayant déjà opté pour l'Ethernet pour l'interconnexion de ses ordinateurs VAX et de leurs périphériques, le fonctionnement du protocole TCP/IP sur ce réseau devint indispensable. Restait alors la question du choix du système d'exploitation. Kahn explique : En 1979, après avoir largement consulté la communauté, nous avons conclu qu'il nous fallait opter pour le VAX, car c'était la seule machine adaptée. Malheureusement, ils n'étaient pas très satisfaits de VMS ni d'UNIX.

La DARPA a donc attribué un contrat à l'Université de Californie à Berkeley pour porter le système UNIX sur le VAX et y ajouter toutes les fonctionnalités nécessaires, ce que Bill Joy a fait. La DARPA a également attribué un contrat à BBN pour convertir TCP/IP en UNIX. Joy devait ensuite intégrer le portage TCP/IP de BBN au portage UNIX sur le VAX.

La nécessité de séparer les couches réseau et transport, rendue si évidente par les réseaux locaux, a également influencé les efforts de développement des protocoles en Europe. Cette histoire commence en 1975, lorsque le groupe de travail 6.1 de l'IFIP a changé d'affiliation institutionnelle pour rejoindre l'ISO.

8.12 Interconnexion de systèmes ouverts (OSI) 1975 - 1979

En 1975, les membres européens du groupe de travail 6.1 de l'IFIP durent se résoudre à l'idée que les Américains étaient résolus à adopter le protocole TCP.
Plus important encore, leur stratégie visant à influencer le CCITT avait échoué : ce dernier allait clairement imposer la norme X.25, un protocole de circuit virtuel, comme norme pour les réseaux PTT. Or, la norme X.25 laissait les utilisateurs d'ordinateurs sans protocole de bout en bout. Frustrés, mais non sans détermination, ils se regroupèrent et se tournèrent vers l'Organisation internationale de normalisation (ISO) pour plaider en faveur de normes de communication de bout en bout, ou d'hôte à hôte. L'ISO, seule organisation internationale de normalisation aussi influente que le CCITT, était structurée en une série de comités techniques et de sous-comités spécialisés. Les normes de traitement et de communication des données relevaient du Comité technique 97 (TC 97). Au sein du TC 97, le Sous-comité 6 (SC 6) était responsable des normes de communication des données et constituait le lieu de réunion logique des membres du groupe de travail 6.1 de l'IFIP. Hubert Zimmerman, membre éminent de la délégation française et de l'IFIP, se souvient : Nous avons contacté le sous-comité 6, expliqué notre projet et sollicité leurs exigences pour l'élaboration d'une norme de communication entre hôtes, ou de normes de communication axées sur le traitement des données. À l'époque, notre message a été mal accueilli. Nous étions considérés comme des personnes, mais nos idées n'ont pas vraiment été entendues.

Malgré l'accueil mitigé, les membres du groupe de travail 6.1 de l'IFIP ont commencé à collaborer avec le SC 6, pour se retrouver une fois de plus pris dans les méandres politiques de la technologie, au détriment de ses mérites. Zimmerman, se souvient encore une fois : Nous avons collaboré avec le sous-comité 6 à la définition du HDLC. À cette époque, le HDLC sortait tout juste de l'œuf après dix ans de travail acharné. Il y avait alors une forte dimension politique, et le HDLC était bloqué depuis un certain temps. Tant qu'IBM n'avait pas obtenu l'approbation du SDLC, le HDLC ne pouvait pas être adopté. Les enjeux politiques étaient importants, et nous n'étions probablement pas assez habiles en politique à ce moment-là.

Pour les Européens, qui espéraient que le comité d'étude 6 du TC 97 (SC 6) créerait des normes de protocoles de communication de bout en bout, un autre obstacle vint mettre leur détermination à l'épreuve. La plupart d'entre eux estimaient n'avoir d'autre choix que de coopérer et de faire pression pour l'adoption de la norme HDLC, tout en exhortant le SC 6 à relever le défi des protocoles de bout en bout. Cependant, tous les Européens n'étaient pas prêts à se montrer aussi conciliants. Agissant indépendamment, les Britanniques commencèrent à faire pression sur les membres du TC 97 pour la création d'un sous-comité complet consacré aux protocoles de bout en bout, ou, comme on les appellerait plus tard, aux protocoles de « couche supérieure ».

Alors que la question des protocoles de couche supérieure devait être soumise au vote lors de la réunion du SC 6 de mars 1977 à Melbourne, en Australie, une résolution semblait probable. Malheureusement, l'assemblée plénière du SC 6 – organe décisionnel de tous les comités ISO – rejeta la proposition, concluant que les protocoles de couche supérieure n'étaient « pas suffisamment matures ». Une semaine plus tard, à la surprise générale, l'organisation mère, le TC 97, décida, malgré l'opposition de la délégation américaine, que les protocoles de couche supérieure étaient suffisamment matures pour entamer leur normalisation et autorisa la création du Sous-comité 16 (SC 16) sur l'interconnexion des systèmes ouverts (OSI) – un sous-comité de même statut que le SC 6. La dimension politique des décisions technologiques avait ainsi donné naissance à une nouvelle institution.

La première étape de la création d'un nouveau sous-comité consistait à désigner une organisation membre pour en assurer le secrétariat, puis à faire nommer un président par ce secrétariat. (Le secrétariat gère toutes les responsabilités administratives du sous-comité.) Une lutte pour le poste de secrétariat opposa les délégations britannique et américaine, cette dernière l'emportant malgré son opposition initiale à la création de ce nouveau sous-comité. (L'argument retenu était que les États-Unis ne disposaient pas d'un nombre suffisant de secrétariats de l'ISO.)

Le comité ANSI/X3 (American National Standards Institute Committee on Computers and Information Processing) représentait les États-Unis au sein de l'ISO et en assurait ainsi le secrétariat. Le comité SPARC (Systems Planning and Resources Committee) de l'ANSI/X3 a mandaté un groupe d'étude, initialement dirigé par Jerry Foley de Burroughs, pour constituer la délégation américaine auprès du SC 16 et élaborer le document de position initial des États-Unis. Foley a alors recruté Charles « Charley » Bachman de Honeywell au sein du comité, malgré son absence d'expérience préalable en matière de protocoles de communication. Bachman, qui venait de présider le groupe d'étude ANSI/X3/SPARC/DBMS, chargé d'examiner le potentiel de normalisation des systèmes de gestion de bases de données (SGBD), avait démontré son engagement envers les normes, et Foley était convaincu que le comité bénéficierait de son leadership.

Une fois constitué, le groupe d'étude devait convaincre les entreprises informatiques américaines de coopérer et d'élaborer des normes volontaires. Si les avis divergeaient quant à l'impact positif ou négatif de ces normes sur la prospérité économique des entreprises américaines, la plupart des dirigeants estimaient que leur élaboration visait à permettre aux entreprises étrangères de grignoter des parts de marché à la société américaine, largement dominée par cette dernière. Comme le rappelle Bachman : IBM et Burroughs n'étaient pas certains de vouloir des normes. Honeywell non plus, jusqu'à ce que je leur dise : « Vous, vous voulez des normes. » Quand la question de la participation a été soulevée, j'ai insisté : « Nous devrions participer. » Ils ont répondu : « Non, nous ne sommes pas sûrs de vouloir une norme mondiale », car ils craignaient davantage de perdre des ventes que d'en gagner. En fait, j'ai réussi à impliquer Honeywell en me proposant comme président du comité. IBM a jugé inapproprié que je préside ce groupe, car le président devait rester neutre, se contenter d'administrer le projet et ne pas prendre parti. J'étais un président très actif !

S'appuyant sur son expérience en matière de SGBD, Bachman estimait que les normes devaient se concentrer sur les interfaces, points de rencontre des composants des systèmes. Sa philosophie est résumée dans un extrait du document intitulé « Résumé du cadre de référence ANSI/X3/SPARC pour les SGBD » :

Lors des premières discussions du groupe d'étude, il est apparu clairement que toute normalisation devait porter sur les interfaces. Élaborer des normes décrivant le fonctionnement des composants présente un risque d'échec et peu d'intérêt. Ce qui importe pour les normes, c'est la manière dont les composants s'articulent ; autrement dit, la spécification des interfaces.

Zimmerman, qui allait devenir un membre clé du SC 16, se résignait à l'inévitabilité des réseaux de données publics à circuits virtuels. 53 Pourtant, loin de le démoraliser, cela devint une source de motivation. Cerf se souvient de l'état d'esprit de « Zim » avant même la première réunion du SC 16 : Je me souviens d'une promenade dans les rues de Genève avec Zimmerman en 1977. Il m'expliquait qu'il allait commencer par des concepts de circuits virtuels, car c'était la seule chose qui, selon lui, se vendait dans le domaine de l'architecture. Il savait – je ne sais pas s'il l'a admis publiquement, mais je pense qu'il le savait et me l'a confié en privé – qu'il souhaitait introduire la notion de datagrammes plus tard, une fois que tout le monde serait familiarisé avec le modèle architectural basé sur les circuits virtuels. Il était alors bien plus avisé politiquement que je ne l'étais.

Bachman et Zimmerman allaient devoir faire preuve de toute leur habileté politique, car le SC 16 allait devenir non seulement le théâtre d'affrontements autour des normes de protocoles de niveau supérieur, mais aussi un organe de coordination essentiel, œuvrant à la coopération entre l'ISO et le CCITT. À leur avantage, les 40 à 50 ingénieurs et scientifiques qui avaient fait le chemin depuis l'INWG jusqu'à l'IFIP, puis l'ISO, constituaient une grande partie des membres des délégations des pays participants et s'étaient regroupés au sein d'un groupe de consensus partageant un large accord sur l'élaboration des normes. Leur détermination serait mise à l'épreuve par la présence de représentants invités du CCITT et de l'ECMA – des organisations dont les intérêts économiques pèsent sur chaque décision et action du SC 16. (Voir l'annexe 6.5 : Structure organisationnelle du SC 16)

Le SC 16 s'est réuni pour la première fois à Washington D.C. en mars 1978. Après avoir réglé les questions d'organisation, chaque pays a présenté un document de position : tous préconisaient une architecture de protocole multicouche. Face à cet accord unanime, quatre groupes de travail ont été créés pour répartir l'élaboration des normes (voir tableau 6.0 : Groupes de travail initiaux du SC 16). Forts de ces avancées, Bachman a suggéré de clore les travaux.

Annexe 8.12.1 Structure organisationnelle du comité technique ISO TC97/SC 16
Schéma de la structure ISO TC97/SC16

Seul Zimmerman, endurci par des années de discussions et de lenteur, en voulait plus. Il souhaitait que les membres formalisent leurs accords par écrit et signent le document avant la levée de la séance. Bachman, tout en jugeant l'exercice « prématuré », a déclaré que si l'on pouvait élaborer le document, alors d'accord. Zimmerman se souvient de leurs efforts tardifs : Nous sommes restés sur place le soir avec quelques collègues et nous avons commencé à découper, coller et noter les informations. Il s'agissait probablement d'un document d'une douzaine de pages contenant tous les éléments essentiels de la version finale du Modèle de Référence. Nous avons retenu sept niveaux – certains avaient organisé leurs éléments en cinq, six ou sept – je crois que c'est la contribution américaine qui a imposé cette structure à sept niveaux. Nous avons choisi cette option car elle n'était pas pire que les autres, et ces dernières pouvaient s'y intégrer.

L'élaboration du modèle de référence OSI a bénéficié de l'ensemble des connaissances accumulées lors de la création de protocoles de communication informatique depuis le NCP d'Arpanet. En segmentant les communications informatiques en couches logiques, il a été possible d'assembler des protocoles de bout en bout en sélectionnant les protocoles appropriés de chaque couche afin de refléter la diversité du réseau, tout en partageant autant de protocoles intermédiaires que possible pour réduire la complexité des protocoles. Le partage des protocoles a également permis de réduire considérablement le développement et les tests. (Voir l'annexe 6.6 : Le modèle de référence OSI). Ce modèle de référence reconnaissait des couches de transport et de réseau distinctes, le SC 16 étant responsable des quatre couches supérieures et le SC 6 conservant la responsabilité des trois couches inférieures. De ce fait, la coordination essentielle entre les couches de transport et de réseau reposait sur deux comités, une séparation structurelle susceptible d'engendrer des problèmes ultérieurs.
Tableau 8.12.2 Groupes de travail initiaux SC 16

Contrairement aux pratiques alors en vigueur, le Modèle de référence représentait un cadre dans lequel les normes de communication s'inséraient. Il ne s'agissait pas d'une norme technique en soi. Élaboré pour des raisons similaires à celles qui avaient motivé l'adoption rapide de la norme X.25 par le CCITT, le Modèle de référence était perçu comme un moyen d'orienter les actions du marché et de contrer les normes propriétaires des fournisseurs – ou du CCITT lui-même. En effet, c'était le pouvoir du CCITT de dicter les protocoles de communication utilisés par les ordinateurs (sur les réseaux de données publics) qui constituait la menace la plus sérieuse pour les intérêts des membres du SC 16. En créant le protocole de circuit virtuel X.25 et en formulant une norme pour le télétexte, une application destinée à l'utilisateur final, le CCITT semblait bien parti pour figer la manière dont les applications de couche supérieure s'interfacent avec les réseaux PTT et, par conséquent, pour dicter définitivement la manière dont les ordinateurs étaient interconnectés sur les réseaux .

En octobre 1978, le SC 16 s'est réuni à Paris pour examiner les modifications demandées au Modèle de référence et finaliser une deuxième version. Comme lors de la première réunion, les membres clés ont travaillé presque toute la nuit pour achever le document révisé. John Day, participant aux réunions des groupes de travail du réseau Arpanet (NWG), de l'INWG et de l'IFIP, a été invité par Zimmerman à contribuer à la formalisation du Modèle de référence pour le SC 16. Day se souvient : Les responsables des normes se réunissaient de 9 h à 16 h et prenaient leur temps pour discuter des problèmes ; c'était un cercle d'initiés, mais à l'époque, même si les normes étaient importantes, elles n'avaient pas l'impact économique, ou plutôt l'impact économique potentiel, que cela allait avoir. Les règles avaient donc considérablement changé. Des sommes considérables étaient en jeu, et tout le monde le savait. C'est de là que vient l'expression « ingénierie électro-politique ». Chacun a compris que la manière dont nous définissions les limites des différents niveaux, et dont nous élaborions les solutions techniques, déterminait les lignes de marché, la situation économique, et donc qui finirait dans la poche de certains. Ce n'était plus ce cercle d'initiés privilégié.

8.12.3 Le modèle de référence OSI
Couche - Nom - Fonction
7 - Application - Sélectionne le service approprié pour l'application
6 - Présentation - Assure la conversion de code et le reformatage de données
5 - Session - Coordonne l'interaction entre les processus d'application
4 - Transport - Garantit l'intégrité des données de bout en bout et la qualité du service
3 - Réseau - Informations sur les commutateurs et les itinéraires
2 - Données - Transfère une unité d'information à l'autre extrémité de la liaison physique
1 - Physique -Transmet le flux binaire au support

En juillet 1979, moins de dix-huit mois après sa création, le SC 16 a transmis le Modèle de référence d'interconnexion de systèmes ouverts à son organisme parent, le TC 97, sous forme de projet de travail. Le TC 97 a rapidement approuvé ce projet avant la fin de l'année 1979. Le SC 16 a ensuite intégré les modifications suggérées avant de soumettre à nouveau le Modèle de référence au TC 97 sous forme de proposition. Le TC 97 devait alors approuver cette proposition avant de la transmettre à l'ISO en tant que projet de norme internationale. Dans un geste de coopération encourageant, le Groupe du rapporteur du CCITT sur les services de réseaux de données publics s'est joint à la reconnaissance du Modèle de référence. Alors que les institutions et les marchés s'efforçaient de façonner l'avenir, les protocoles de communication étaient devenus un enjeu majeur.

8.13 Bureau national des normes et MITRE 1971 - 1979

Alors que les communications informatiques via les réseaux téléphoniques publics préoccupaient les Européens, l'organisme américain de normalisation, le National Bureau of Standards (NBS), se concentrait sur la technologie émergente des réseaux locaux privés. Ce choix ne résultait pas de délibérations bureaucratiques, mais de l'initiative d'un seul homme : Robert Rosenthal.

Après l'installation par le NBS de son infrastructure Arpanet TIP fin 1971, Rosenthal fut chargé de concevoir des instruments de mesure des performances du réseau : non pas celles du réseau lui-même, tâche alors dévolue au NMC de l'UCLA, mais celles du point de vue de l'utilisateur. Le NBS souhaitait comprendre l'intérêt de la mise en réseau afin d'en recommander l'utilisation à d'autres organismes, une responsabilité conforme à sa charte.

Élaborer des normes fédérales de traitement de l'information, aider d'autres agences à déployer des technologies qui prennent en charge ces normes et mener des recherches appropriées pour garantir que les agences fédérales restent à la pointe de l'utilisation de la technologie.

En 1976, Rosenthal, connaissant bien les travaux menés au PARC, commença à réfléchir à la manière de concevoir des réseaux locaux adaptés à une utilisation au sein du gouvernement fédéral.
( Rosenthal : « De mon point de vue, c’était : “J’ai une équipe ici et je dois vraiment maîtriser cette technologie.” Nous avions plusieurs contrats avec d’autres organismes pour installer les premiers équipements Ethernet 3 Mbits/s, et j’avais mis en place un laboratoire avec des imprimantes Altos et Dover, entre autres. Nous travaillions également pour des clients du centre-ville. Nous étions donc parfaitement au courant des activités de Xerox. Si je me souviens bien, à l’époque, Xerox ne cherchait pas à dissocier la technologie LAN, mais à vendre un système bureautique. Notre motivation était de dissocier cette technologie et de fournir l’équivalent d’un opérateur, mais pour les réseaux locaux. À l’époque, nous insistions sur des définitions comme “propriété et administration locales”. » Tous les aspects négatifs que nous connaissions des opérateurs, du point de vue de l'utilisateur – ils ne sont pas forcément négatifs, mais plutôt liés à la réglementation – nous voulions nous en passer, car nous cherchions à connecter des terminaux au sein de nos propres bâtiments. Les services des opérateurs n'étaient pas nécessaires ; nous gérions donc tout nous-mêmes. C'est ce que nous entendions par « réseaux locaux » à l'époque.)
Bénéficiant du soutien inconditionnel de son supérieur, le Dr Ira Cotton (qui, comme Rosenthal s'en souvient avec émotion, lui aurait lancé : « Tiens, une corde, vas-y, pends-toi ! »), Rosenthal contacta Metcalfe, Boggs et Shoch au PARC, ainsi que d'autres spécialistes des réseaux, comme Charlie Bass, alors chez Zilog. Rosenthal se souvient : Notre idée consistait à prendre des terminaux très basiques, à les distribuer aux employés de tout le Bureau des normes et à leur permettre d'accéder aux quelques serveurs très puissants dont nous disposions.

En 1978, trois prototypes fonctionnels avaient été construits et un appel d'offres pour la production en série fut lancé et remporté par une petite entreprise de Floride. Fin 1978, avec la réception et l'installation des cartes réseau, le réseau NBS-Net vit le jour. Commentaire de Rosenthal :

Nous avons donc mis en place un réseau basé en partie sur la technologie Ethernet. Il présentait la particularité d'être alimenté par une seule source d'alimentation et de distribuer jusqu'à huit connecteurs RS-232, ce qui était à l'époque totalement différent de l'approche de Xerox consistant à construire une station de travail de type Alto prise en charge par une technologie de réseau local.

Rosenthal se souvient : J'étais tellement enthousiaste que j'ai pensé qu'organiser un atelier serait une bonne idée. J'ai donc contacté tous mes contacts professionnels locaux. MITRE a été l'un des premiers que j'ai appelés.

MITRE, entreprise de Bedford (Massachusetts) spécialisée dans les contrats gouvernementaux, principalement avec l'Armée de l'air américaine, avait installé son système Arpanet TIP en même temps que NBS, fin 1971. Parallèlement, MITRE obtint l'un des deux contrats attribués par l'Armée de l'air pour le développement de prototypes de réseaux locaux et la réalisation d'études de mise en réseau. L'autre contrat fut attribué à Ford Aerospace, de Sunnyvale (Californie). Fin 1972, Ash Dohad, de MITRE, travaillait sur un réseau haut débit à accès multiplexé, baptisé MITRE-Net. Ce réseau utilisait la technologie radiofréquence (RF) sur câble pour créer de nombreux canaux de communication simultanés, à l'instar du multiplexage par répartition de fréquence (FDM). Le haut débit se distinguait radicalement d'Ethernet et de Token Ring par le multiplexage de nombreux canaux sur le support de transmission. Ethernet et Token Ring, quant à eux, ne créaient qu'un seul canal de communication sur le câble coaxial ou la paire torsadée.

En 1976, Greg Hopkins apporta des modifications au réseau MITRE-Net afin qu'un ou plusieurs canaux puissent gérer un trafic de type Ethernet. Bien que les performances de ces canaux similaires à Ethernet ne fussent pas exceptionnelles (trois cent mille bits par seconde), MITRE obtint un brevet pour sa contribution. (Leurs travaux s'appuient sur les travaux antérieurs d'Abramson et Metcalfe.)

Fin 1978, l'Armée de l'Air américaine demanda à MITRE d'étudier les problématiques liées aux réseaux locaux et de formuler des recommandations sur les mesures à prendre. Le moment était opportun, car peu après, Rosenthal proposa l'organisation d'un atelier. Il ne fallut pas longtemps pour convenir de la tenue d'un forum sur les « Protocoles de réseaux locaux », prévu le 31 janvier 1979 à Columbia, dans le Maryland. Lors de leurs échanges ultérieurs avec d'autres participants potentiels, il apparut clairement que si presque tous ceux qui avaient été en contact avec les réseaux locaux en percevaient l'importance, tous se montraient perplexes quant à leur signification et aux actions à entreprendre. Un sujet idéal pour un forum.

8.14 En perspective

Un réseau Arpanet opérationnel a stimulé une décennie de recherche et d'innovation dans le domaine des communications informatiques. Il a d'abord fallu modifier les choix de conception inhérents à Arpanet et le préparer à l'interconnexion avec un réseau de radiocommunication par paquets. Cela impliquait à la fois de repenser le protocole NCP, qui ne fournissait ni circuits virtuels de bout en bout ni véritable connectivité par datagrammes, et d'intégrer des passerelles entre les réseaux. Cerf et Kahn ont présenté une première proposition en 1974 avec leur article sur le protocole TCP (Transmission Control Protocol).

Les Européens ne devaient pas rester en retrait. Le réseau CYCLADES a démontré que des circuits virtuels de bout en bout pouvaient être associés à une transmission de messages par datagrammes. L'organisation de l'INWG et sa transformation en IFIP WG 6.1 ont offert un forum où les multiples approches des communications informatiques ont été débattues. La présentation du protocole TCP a engendré une profusion d'alternatives de conception et, finalement, la séparation des deux côtés de l'Atlantique quant à leur volonté d'une architecture réseau globale.

Parallèlement, la prolifération des ordinateurs aux États-Unis a incité les ingénieurs à résoudre les problèmes de communication rapide entre ordinateurs, non pas par lignes téléphoniques, mais par câbles coaxiaux ou paires torsadées. Farber a été le premier à concevoir le Token Ring, puis Metcalfe a fusionné les concepts d'Arpanet et d'ALOHAnet pour créer Ethernet. Ces réseaux locaux nécessitaient un logiciel de communication différent de TCP, voire même de TCP version 2. XNS a contribué à l'élaboration d'une nouvelle version de TCP, qui allait devenir TCP/IP, où la fonctionnalité de transport de bout en bout serait dissociée de la connectivité réseau.
Cette approche par couches est devenue une norme avec le modèle de référence OSI en 1979. Cependant, toute cette activité a semé la confusion chez les utilisateurs, incitant le NBS et le MITRE à organiser un atelier début 1979 pour y voir plus clair. Très vite, des entrepreneurs se sont engouffrés dans la brèche des opportunités offertes par les réseaux locaux et, ce faisant, ont délogeé les gouvernements et leurs institutions de leur rôle prépondérant.

Chapitre 9