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

Ce chapitre revient sur l'année 1979 et retrace l'évolution concomitante des réseaux informatiques et de l'émergence des normes de communication.
Comme observé au chapitre 8, dès 1982, les forces du marché ont engendré une multitude d'alternatives en matière de réseaux, créant une confusion telle que les acheteurs ont été paralysés et le marché a stagné. Faute de demande, la plupart des entreprises de réseaux ont vu leur situation financière se dégrader et les besoins des clients en matière d'interconnexion de leur parc informatique et de périphériques en pleine expansion se sont trouvés confrontés à une incertitude paralysante. Les événements relatés dans ce chapitre, jusqu'en 1982, étaient connus, ou auraient pu l'être, des entrepreneurs et ingénieurs du secteur des réseaux. Les événements de 1983-1984 étaient quant à eux anticipés par les acteurs du secteur, avec un succès variable. L'impact réel sur les entreprises de réseaux sera analysé au chapitre 10.

Au début des années 1980, l'immense potentiel du marché des réseaux locaux (LAN) et la confusion qui régnait alors étaient parfaitement reconnus.
En décembre 1980, un cabinet d'études de marché réputé publiait un rapport prévoyant une croissance des ventes de LAN, passant de quasiment zéro à 3,2 milliards de dollars d'ici 1990. Un an plus tard, le magazine The Economist résumait la situation des réseaux comme « une jungle technologique où les experts s'affrontent violemment et où les acheteurs potentiels sont consternés ». Un ordre technologique pouvait-il émerger de ce chaos ?

Il existe une alternative historique à la concurrence sur le marché pour déterminer les résultats en matière de technologies de communication : l’établissement d’une norme. Une autorité compétente, telle qu’un organisme institutionnel ou une association professionnelle, définit la technologie optimale et dispose des moyens nécessaires pour faire respecter ou consolider la conformité à cette norme. Toutefois, il convient de noter que la mise en place des structures sociales nécessaires à l’élaboration et à l’administration des normes peut s’avérer tout aussi complexe que la création de nouvelles entreprises.

L'histoire de cinq initiatives majeures de normalisation sera retracée, de leurs débuts à l'établissement d'un ordre technologique en 1984.
Il s'agit notamment d'une entreprise cherchant à asseoir sa position dominante sur le marché (XNS), ou collaborant avec d'autres entreprises dans ce but (DIX) ; de gouvernements tentant d'imposer des normes (TCP/IP), ou s'accordant sur des normes (OSI) ; et d'utilisateurs parvenant à un consensus (IEEE 802).
Dès 1984, ces efforts conjugués ont permis de résoudre les questions relatives aux normes des réseaux locaux (LAN), et les ventes de ces derniers ont explosé. L'histoire, en apparence si simple, des protocoles LAN réserve cependant une surprise. Une histoire qui sera racontée dans les chapitres suivants.

11.1 L'élaboration de normes et le modèle de référence OSI

Bien que la majeure partie de l'histoire retracée ici se concentre sur l'émergence de nouveaux marchés initiés par de nouvelles entreprises, un ordre de marché ne s'établit pas toujours spontanément lorsqu'il existe de nombreuses technologies nouvelles pour résoudre des problèmes similaires.
Le recours à des institutions pour dénouer de telles situations d'impasse s'avère souvent fructueux. Ce chapitre relate l'histoire de l'élaboration de normes visant à instaurer un ordre de marché dans le domaine des réseaux locaux (LAN) et à amorcer une période de croissance fulgurante pour le secteur des réseaux.
Les entrepreneurs sociaux à l'origine de la création de ces nouvelles instances de normalisation ont dû relever des défis davantage politiques qu'économiques. Pour réussir, il fallait obtenir le soutien des structures d'autorité existantes, puis amener des parties souvent hostiles à prendre des décisions collectives.
Les deux initiatives examinées plus en détail sont celles du comité 802 de l'Institute of Electrical and Electronics Engineers (IEEE) et du sous-comité 16 du comité technique 97 (ISO/TC 97) de l'Organisation internationale de normalisation (ISO). La première est une organisation américaine et la seconde une organisation internationale ; toutefois, toutes deux ont fait l'objet d'une attention soutenue et ont été influencées par des individus et des organisations, indépendamment de leur pays d'origine (voir l'encadré 9.0, « Organisations de normalisation »).

Encadré 11.1.1 Organisations de normalisation

Face aux attentes croissantes concernant la définition de normes, les organisations ont amélioré ou modifié leurs technologies pour répondre aux résultats escomptés. Elles n'avaient pas toujours raison. Parfois, le fait d'avoir raison relevait davantage de la politique que de la supériorité technologique. En fin de compte, l'architecture directrice sera le modèle de référence d'interconnexion des systèmes ouverts (modèle OSI), approuvé en tant que projet de travail par l'ISO à la fin de 1979.
Fondé sur des couches et des piles, ce modèle représente l'aboutissement d'efforts cumulés remontant à la conception des systèmes d'exploitation et aux expériences menées avec Arpanet (voir l'illustration 9.1 : Couches et piles).
Les évolutions technologiques et les migrations à étudier sont les suivantes :
Passage du protocole Pup de Xerox au protocole XNS
Passage du protocole TCP de la DARPA au protocole TCP/IP
Normalisation d'Ethernet (CSMA/CD) et des protocoles à jeton par le comité 802 de l'IEEE (sous l'influence de DIX — DEC, Intel et Xerox —, d'IBM et de bien d'autres)
Création par l'ISO de protocoles de transport et de réseau, sous l'influence du CCITT, de l'ECMA, de DIX, de XNS et de TCP/IP
Création par l'ISO de protocoles de couche physique et de liaison de données, sous l'influence du CCITT et de l'IEEE

Illustration 11.1.21 : Couches et piles

11.2 Comité IEEE 802 : 1979-1980

Après avoir coprésidé le Symposium sur les réseaux de communication locaux en mai 1979, Robert Rosenthal, galvanisé, retourna au Bureau national des normes (NBS) et entreprit de mettre sur pied des normes fédérales de traitement de l'information (FIPS) pour les réseaux locaux. Preuve que l'innovation et la créativité n'ont pas de limites, le NBS adopta une approche novatrice pour l'élaboration de ces normes, une approche qui allait avoir des répercussions considérables.

Rosenthal se souvient : Nous cherchions à nous positionner pour élaborer des normes au sein de la communauté volontaire, normes que nous pourrions ensuite adopter pour le gouvernement. C'est un concept important. Nous avons dit : « Voici notre approche. Nous voulons collaborer avec l'industrie dans un cadre volontaire afin d'obtenir son soutien pour les produits et ainsi pouvoir les acheter. » Il y avait une différence fondamentale entre cette façon de faire et celle du ministère de la Défense. À l'époque, le ministère de la Défense investissait massivement dans un problème jusqu'à ce qu'il soit résolu. Vint Cerf et son équipe ont inventé le protocole TCP car ils avaient reçu d'importants fonds du ministère de la Défense pour faire fonctionner les réseaux. Nous avons dit : « Très bien, faites ce que vous voulez, mais notre approche consiste à travailler avec l'industrie. »

Peu après, Rosenthal, en sa qualité de président du comité technique des communications informatiques (TCCC) de l'IEEE (Institute of Electrical and Electronic Engineers), apprit qu'un projet était en cours pour former, au sein de son comité technique sur les microprocesseurs, un groupe chargé d'étudier les réseaux de données. (Le terme « réseau de données » désignait également les réseaux locaux ; il était utilisé dans le domaine du contrôle des procédés pour désigner les connexions électriques entre les capteurs de contrôle et les équipements de surveillance.)

Les problèmes d'interconnexion du matériel informatique n'étaient pas propres aux bureaux. Des besoins similaires existaient dans les usines ou pour l'interconnexion des instruments de mesure. Maris Graube, qui deviendra une figure majeure de l'évolution des normes LAN, ignorait tout des développements en la matière, que ce soit pour les bureaux ou les usines. Graube se souvient : Je n'avais jamais rien lu sur les réseaux locaux. Je ne connaissais rien aux communications de données, absolument rien.

En 1976, Graube, ingénieur, intègre Tektronix Inc. à Portland, dans l'Oregon, non pas pour des raisons professionnelles, mais parce qu'il souhaitait vivre dans cet État. Après avoir essuyé deux refus de la part de Tektronix, un ami lui fait part de leur besoin de recruter quelqu'un pour étudier la nouvelle norme d'interface d'instrumentation IEEE 488. Hewlett Packard (HP), leur principal concurrent, avait commercialisé des équipements utilisant cette norme, et la direction de Tektronix craignait un désavantage concurrentiel. Bien que ce poste « nul ailleurs ne le convoitait », Graube saisit l'opportunité et s'installe dans l'Oregon.

La conversion à la norme 488 s'est avérée impérative et Graube a piloté son introduction et sa diffusion dans l'ensemble des produits Tektronix. Son intérêt et ses motivations étant bien présents, il a commencé à participer à des réunions – d'abord pour formuler des « codes et des formats », et non plus des normes. L'accent a été mis sur les protocoles de couche supérieure – les formats – qui permettraient d'intégrer des informations aux données transmises – les codes. Il se souvient : Je me suis rendu compte que la spécification d'interface 488 présentait de sérieuses limitations. La distance maximale entre les instruments est de 20 mètres. Pour automatiser un grand laboratoire, cette limite était insuffisante. De plus, les différentes techniques permettant d'étendre la portée de cette technologie se révélaient inadéquates. Je me suis alors dit : « Il doit bien exister une solution permettant une portée plus importante et un débit de données de l'ordre du mégabit par seconde. » Pas besoin d'une vitesse extrême. Je ne savais pas exactement de quoi il s'agissait.

Lors d'une conversation informelle avec un journaliste, Graube apprit que le professeur Ted Williams de l'université Purdue animait un atelier sur le contrôle des procédés industriels. Graube s'y impliqua de nouveau, allant même jusqu'à présider le groupe pendant deux ans, avant de conclure que leur système « PROWAY » (Process Control Data Highway) était inadapté à un environnement de laboratoire. Une fois encore, sa curiosité et son besoin de s'atteler à une tâche que personne d'autre ne voulait accomplir le poussèrent à réfléchir : Je me suis dit : « Tiens, ce serait bien d'avoir un comité de normalisation pour quelque chose de plus adapté à l'instrumentation informatique et à un environnement plus commercial. » J'ai donc commencé à me renseigner pour voir si d'autres organismes de normalisation travaillaient sur un sujet similaire, et j'ai constaté que personne ne le faisait. En 1979, j'ai rencontré Bob Stuart, de l'IEEE, qui avait joué un rôle déterminant dans le lancement de nombreux projets de normalisation pour les microprocesseurs au sein de l'IEEE. Il m'a dit : « Eh bien, pourquoi ne pas créer un petit groupe de normalisation sous l'égide des normes relatives aux microprocesseurs ? »

Je ne savais rien de la manière de procéder pour établir des normes, obtenir des autorisations de projet, etc. Il m'a donc un peu aidé et m'a expliqué ce qu'il fallait faire et quels formulaires remplir – je ne savais toujours pas ce qu'était un réseau local.

Avec de l'aide, Graube soumit une proposition au comité des normes de l'IEEE afin de créer une norme de réseau local pour les laboratoires et les bureaux. Après s'être assuré qu'aucun autre projet de normalisation n'était en cours, le comité des normes de l'IEEE autorisa le projet de norme 802 en octobre 1979, sous l'égide du TCCC de Rosenthal, et non du groupe de travail sur les microprocesseurs. Graube , nommé président, devait ensuite constituer un comité technique chargé d'élaborer la norme. Les membres du comité 802, comme il serait connu par la suite, devaient être membres de l'IEEE, ne pouvaient représenter les intérêts d'aucune organisation – pas même leurs employeurs – et devaient participer bénévolement. L'objectif : un projet de norme approuvé par les trois quarts des participants à son élaboration. Rosenthal se souvient de ce moment : Tout était en place.

Graube programma la première réunion du Comité 802 pour le 28 février 1980, en même temps que la réunion de printemps de CompCon. (Comme la participation des membres était volontaire, les réunions se tenaient généralement en marge de salons professionnels ou d'autres réunions techniques.) Incertain du nombre de participants à cette réunion publique obligatoire, Graube réserva une petite salle à l'hôtel Jack Tar de San Francisco. À sa grande surprise, et à celle de tous les autres, la foule, estimée à 150 personnes, déborda dans le couloir et retarda le début de la réunion, ajoutant encore à la confusion qui régnait alors que le processus était encore balbutiant. Nombre d'entre eux étaient simplement des ingénieurs curieux, préférant se retrouver entre eux plutôt que de passer la soirée à visiter la ville. D'autres, comme Robert Metcalfe et John Shoch, avaient des intérêts particuliers, et d'autres encore, comme les nombreux ingénieurs des Bell Labs, étaient venus par habitude.

Lorsque la réunion commença enfin, Rosenthal se souvient avec stupéfaction : Nous n'avions que Maris pour se lever et organiser tout cela.

Avec l'aide de personnes plus expérimentées, Graube a résisté à la mêlée et a établi l'objectif d'une norme unique : Avec un débit d'environ un mégabit par seconde et une longueur d'un kilomètre, il permettrait de connecter une centaine d'appareils et serait conçu pour un usage commercial.

Avant de lever la séance, Rosenthal proposa que leurs travaux se conforment au modèle de référence OSI récemment publié. Après approbation de cette proposition, la réunion suivante fut fixée du 27 au 31 mai 1980 au NBS.

En tant que président, Graube exerçait une influence et une autorité considérables, tant pour transformer sa vision en norme que pour structurer les sous-comités nécessaires. À cet égard, il s'appuyait fortement sur son expérience avec PROWAY. Par exemple, il souhaitait suivre l'approche de PROWAY, qui consistait à établir d'abord les exigences fonctionnelles de la norme et à éviter le flot incessant d'entreprises faisant pression pour que leurs produits soient déclarés conformes. Une fois les exigences fonctionnelles validées, Graube voulait toutefois procéder différemment de PROWAY, qui s'était enlisé dans l'évaluation de la conformité des produits de chaque entreprise à la norme. Il se souvient : Au bout du compte, ils pensaient qu'un produit se distinguerait des autres et serait retenu comme norme.

Graube savait pertinemment qu'aucun fournisseur ne voterait pour le produit d'un concurrent ; l'émergence d'une norme semblait donc peu probable. Il préférait créer lui-même la norme et laisser ensuite les entreprises concevoir des produits conformes à celle-ci — des produits non propriétaires bénéficiant d'une concurrence ouverte.
Malgré sa vision claire de la marche à suivre, Graube a sous-estimé le nombre d'alternatives technologiques existantes, les enjeux économiques en présence et les efforts que les entreprises déploieraient pour influencer le comité 802. Rosenthal a perçu les tensions d'intérêts inhérentes aux profils des participants présents lors de cette première réunion : L'atmosphère était électrique !

Bien que Graube ait voulu empêcher les entreprises d'exercer une influence indue sur le processus d'élaboration des normes, il n'a pas réussi à imposer sa volonté.

11.3 DIX (Digital Equipment Corporation, Intel et Xerox) : 1979-1980

Au cours de l'été 1979, Metcalfe a continué de promouvoir l'idée d'une coopération tripartite entre Xerox, DEC et Intel en vue de commercialiser Ethernet. Finalement, à l'automne, les trois entreprises se sont réunies au Sheraton de Boxborough (Massachusetts). Reconnaissant le rôle essentiel de Metcalfe, elles l'ont convié au dîner précédant la réunion. Le lendemain, les équipes techniques des trois sociétés se sont réunies sans le personnel marketing ni Metcalfe.
Loin de s'en offusquer, Metcalfe s'est concentré sur la manière dont sa jeune entreprise, 3Com, pourrait financer la fabrication de produits conformes aux spécifications techniques que DEC, Intel et Xerox (DIX) allaient, selon ses prévisions, négocier puis publier.
Pour éviter les complications juridiques liées aux lois antitrust, les membres du groupe DIX ont dû convenir de placer les résultats de leur collaboration dans le domaine public afin d'établir une norme. En apparence, la création du projet IEEE 802 semblait être le moyen idéal de faire d'Ethernet une norme, voire *la* norme. Toutefois, l'hostilité de Graube à l'égard de toute entreprise cherchant à outrepasser l'autorité du comité 802 a placé les deux initiatives sur une trajectoire de confrontation.

Le fait de convenir d'une coopération ne signifiait pas pour autant que les membres du groupe DIX partageaient la même vision de ce que devait être la norme Ethernet. En réalité, leurs divergences suscitaient souvent des tensions qui mettaient la collaboration à rude épreuve, au point de risquer la rupture. Mais à chaque fois, la force de leur engagement collectif envers les opportunités commerciales offertes par les réseaux locaux l'emportait, et ils parvenaient à surmonter leurs différends. (La description et le lexique d'Ethernet à cette époque figurent dans la pièce 11.3.1, « Modèle Ethernet ».)

Pièce 11.3.1 Modèle Ethernet
diagramme du modèle Ethernet

L’équipe technique de chaque entreprise est venue avec ses propres préjugés, compétences et exigences. Kaufman d'Intel se souvient :
Les problèmes étaient en réalité le câblage et les puces du contrôleur. Il n'y avait aucun problème à faire fonctionner les puces à 10 mégahertz, et il y avait beaucoup de problèmes de câblage, et je pense que ce qui a le plus fait grimper les coûts, dans les premières années, était l'insistance de Xerox et DEC pour avoir un câble coaxial, parce qu'ils étaient intéressés par tous les problèmes très réels liés à l'installation de ce matériel, à son fonctionnement et à sa fiabilité. Alors que le reste d’entre nous étaient beaucoup plus des hackers, nous étions prêts à tout faire si cela fonctionnait.
Il y a eu des débats sur la question de savoir si quelqu'un pourrait construire un émetteur-récepteur qui fonctionnerait réellement à n'importe quelle vitesse de manière fiable malgré la preuve de l'existence de ce qui fonctionnait au PARC. Il s’agissait d’un art noir réalisé par un gars dans un placard, et beaucoup de travail théorique a été consacré par les gens à « Que devrait faire un émetteur-récepteur et pourrait-il fonctionner ?
Lidddle de Xerox, en revanche, se souvient : Nous pensions que la conception de Xerox était conservatrice, puis ces gars-là l'ont améliorée, mais ce n'était pas grave, car ils voulaient qu'elle soit fiable. C’est donc un travail d’ingénierie très serré qui a été réalisé !

Alors que les travaux avançaient, la question centrale du transfert de technologie propriétaire et brevetée de Xerox vers DEC et INTEL restait en suspens. Xerox avait prospéré en contrôlant sa technologie. Dès le début, le désir de Xerox de garder secrètes les innovations de PARC suggérait que Xerox pourrait ne pas accepter de licence Ethernet. Néanmoins, les travaux ont progressé sous la direction de Liddle, Kaufman et Dave Rodgers du DEC.
Après d'intenses négociations, les trois sociétés ont décidé de conclure deux accords : l'un entre Xerox et DEC et l'autre entre Xerox et Intel. Il n'y aurait pas d'accord à trois, même si les deux accords étaient liés par des conditions. Lidl rappelle : Les trois parties ont dû accepter de mettre en œuvre ce produit comme norme pour leurs futurs produits. Il n’était pas nécessaire que ce soit le seul réseau qu’ils utilisaient, mais ils devaient tous accepter de le mettre en œuvre et de le soutenir. Xerox a proposé de concéder sous licence, pour mille dollars chacun, la technologie Ethernet et de leur réserver un bloc d'adresses, etc. Intel a dû accepter de fabriquer un jeu de puces de circuit intégré pour mettre en œuvre les protocoles et le contrôle. Digital a dû accepter de concevoir et fabriquer un émetteur-récepteur à faible coût.

Liddle a alors dû relever le défi d'obtenir l'accord de Xerox. La force de son argument reposait sur sa conviction qu'il était dans le meilleur intérêt de Xerox d'octroyer une licence sur la technologie et que DEC et Intel étaient des organisations idéales avec lesquelles s'associer. Heureusement, Peter McCullough, le président, a estimé que Xerox devrait utiliser sa technologie de manière créative pour acquérir la technologie et les engagements des autres. Lorsque Liddle a fait sa présentation à McCullough, il se souvient que McCullough avait dit rapidement : Quelle excellente idée. Échanger les droits de ce brevet contre des améliorations et tout le reste, s'engager à fabriquer les composants, puis en faire un standard. Quelle excellente idée.

À ce stade, la nouvelle du projet DIX s'était répandue. D'autres entreprises souhaitaient y participer. Toutefois, l'arrivée de nouveaux participants risquait davantage de compliquer le processus que de l'aider. Gordon Bell, de chez DEC, se souvient : « J'ai reçu des appels de toutes parts ; on voulait rejoindre l'équipe de conception. Intel me mettait la pression. Intel a envoyé Olivetti vers moi ; j'ai discuté avec un représentant d'Olivetti qui m'a dit : "Nous voulons en faire partie." J'ai répondu : "Hors de question. Nous avons déjà huit des meilleurs experts que je connaisse sur la conception. Ajouter du monde ne ferait que nuire au projet. Nous avons énormément de gens chez DEC qui aimeraient y participer. Je suis sûr qu'Intel a beaucoup de monde aussi. Xerox pourrait probablement mobiliser des équipes. Tout se passe si bien. Ne gâchons pas tout. Vous pourrez faire des commentaires une fois que ce sera disponible." »

Kaufman, en revanche, cherchait à susciter le plus grand soutien possible. Intel voulait des clients prêts à adopter sa nouvelle puce.
« Nous avons travaillé à influencer de nombreuses autres entreprises car, pour nous, l'objectif — au-delà de considérations altruistes visant à rendre les communications opérationnelles et à faire progresser l'état de la technique — était de créer une clientèle prête pour les puces que nous allions fabriquer. »

Hewlett-Packard (HP) figurait parmi les clients potentiels les plus convoités par Intel. Tous les deux mois environ, Kaufman déjeunait avec Dave Crocket, responsable de la stratégie et de la planification chez HP. Outre le fait de déplorer les difficultés liées à l'élaboration de stratégies au sein de leurs organisations respectives, ils discutaient des évolutions technologiques, notamment en matière de réseaux. HP développait plusieurs standards réseau ; Crocket estimait que les équipes seraient plus enclines à soutenir un standard externe qu'à abandonner le leur au profit de celui d'un autre groupe. Il a donc défendu Ethernet comme étant la meilleure solution.
Intel souhaitait également rendre la puce Ethernet aussi complexe que possible. Kaufman :
Nous avons poussé la conception de la puce de contrôle Ethernet pour en faire un composant extrêmement complexe capable d'effectuer de nombreuses tâches, car c'est là que résidait l'atout d'Intel. Si nous parvenions à placer la barre assez haut — obligeant ainsi tous les autres acteurs à s'aligner pour proposer un contrôleur viable —, nous pourrions faire valoir notre supériorité technique et tirer parti de nos compétences. En somme, cette première puce constituait véritablement un ordinateur à elle seule.

Toutefois, l'idée d'intégrer davantage de partenaires et de concevoir une puce Ethernet plus complexe comportait un risque : celui d'être laissés pour compte par le comité 802, l'instance chargée de définir la norme. Alors que le consortium DIX était encore loin d'avoir trouvé un terrain d'entente en interne, ses membres s'inquiétaient de la prochaine réunion du comité 802 et craignaient qu'une technologie concurrente ne prenne de l'ampleur. Pour prévenir toute décision précipitée de la part du comité 802, ils décidèrent d'annoncer, juste avant la réunion de mai, qu'ils publieraient leur norme en septembre.
Liddle se souvient que la rédaction du communiqué de presse s'est avérée « plus difficile à mener à bien que la négociation du contrat initial ».

11.4 Comité IEEE 802 et DIX : 1980-1981

Lors de la réunion du comité 802 de l'IEEE en mai, DIX a complété le communiqué de presse par une description de deux pages d'Ethernet, accompagnée du message suivant : Il s'agit d'une approche raisonnable pour la création d'un réseau local et si le comité souhaite l'examiner, nous serions disposés à collaborer avec lui. S'il ne souhaite pas l'examiner, nous le ferons quand même, mais nous serions toujours disposés à y participer .

L'opposition a immédiatement dénoncé les méthodes brutales de DIX, qui compromettaient l'objectif d'une normalisation indépendante de toute influence commerciale. DIX a également bénéficié du soutien public, notamment de Greg Hopkins, président de l'IFIP, qui, à l'instar de l'IEEE, avait créé un groupe de travail ou un comité chargé d'élaborer une norme pour les réseaux locaux. Dans un article paru dans Data Communications en juin 1980, Hopkins déclarait : Il s'agit d'une annonce importante compte tenu de la taille des entreprises impliquées et d'un pas vers le bureau intégré du futur .

Graube désapprouvait les actions de DIX. Si Ethernet devenait une norme de facto en dehors du processus IEEE 802, cela risquait de compromettre l'autorité et la légitimité du Comité 802 pour l'élaboration d'une norme viable. Malgré sa désapprobation des initiatives de type DIX, il ne souhaitait pas non plus que DIX agisse indépendamment du Comité 802. Dans ce même article de Data Communications de juin 1980, Graube encourageait la coopération :

D'autres entreprises peuvent avoir des opinions différentes, et Xerox ne sera peut-être pas en mesure de satisfaire les besoins de chacun … Les États-Unis ne sont plus les seuls leaders technologiques ; nous devrons donc nous conformer aux normes internationales – le simple fait que les États-Unis aient une norme de facto ne signifie pas qu'elle sera acceptée à l'étranger.

Dans ce contexte d'intrigues en toile de fond, l'ordre du jour de la réunion de mai, visant à organiser la structure d'un comité pour entamer les efforts de normalisation, a abouti à la création de trois sous-comités : les sous-comités de niveau physique, de niveau liaison et d'interface de haut niveau. En remplaçant le niveau par couche, ils correspondent au schéma suivant. (Voir l'annexe 9.3 : Architecture LAN IEEE. )

Figure 11.4.1 Architecture LAN IEEE

Le sous-comité du niveau physique présidé par Jerry Clancy (de Honeywell) avait pour objectif de créer les spécifications fonctionnelles du support physique et de la manière de transmettre des signaux sur celui-ci.
Le sous-comité de niveau de liaison présidé par Nathan Tobol (Codex) 10 définirait le protocole imposé aux signaux de niveau physique – qu’ils soient interrogés ou transmis par jeton par exemple.
Le sous-comité d'interface de haut niveau, présidé par Allen Rochkind (physique du spectre), était plus ouvert. Graube se souvient : Je pensais qu'un groupe se pencherait sur les problèmes d'interface. À l'époque, j'entendais par interface matérielle : comment une puce, un composant semi-conducteur, interagit-elle avec un microprocesseur ? C'est à cette interface que j'avais en tête. En réalité, il s'agit davantage d'une interface logique que matérielle, et nous avons très peu d'éléments à prendre en compte concernant le fonctionnement des microprocesseurs.

Grabe se souvient que le rythme effréné est devenu une caractéristique du Comité 802 : Nous avons démarré avec beaucoup d'enthousiasme. De nombreuses réunions ont été organisées. Je crois qu'on en tenait une tous les deux mois environ, et elles sont rapidement passées de trois jours à une semaine complète. Souvent, on commençait le dimanche et on travaillait toute la semaine.

Après la réunion du sous-comité Physical Level de juin, tenue en même temps qu'une réunion de PROWAY, de nombreux membres de PROWAY ont réorienté leurs efforts vers la norme IEEE 802. Dans un autre effort pour accélérer le travail du comité, un autre sous-comité, le Media Access Group, a été formé et a programmé une réunion pour septembre.

Lors de la réunion de septembre du Media Access Group, qui s'est tenue chez Gould-Modicom à North Andover, dans le Massachusetts, les discussions ont pris un tournant résolument plus technique. Jusqu'alors, les participants aux réunions du Comité 802 s'étaient livrés à un dialogue informel entre quatre camps technologiques. Le premier était celui de DIX et de sa technologie Ethernet, ou CSMA/CD. Le deuxième était composé des partisans de PROWAY, beaucoup moins structurés, qui privilégiaient une technologie à jeton. Le géant informatique IBM constituait le troisième camp ; la rumeur disait qu'il était favorable à Token Ring, mais il refusait de dévoiler clairement ses intentions ! Sa position dominante sur le marché lui donnait apparemment l'opportunité d'imposer une norme de facto. L'indécision d'IBM planait comme une ombre sur toutes les conversations. Le Comité 802 pouvait-il agir sans qu'IBM ne révèle son réseau local. Le quatrième camp, le plus chaotique, grossissait chaque semaine, les entreprises annonçant des solutions de réseau local propriétaires de toutes sortes. L'objectif de Graube, à savoir une norme unique, devenait-il incertain ?

Lors de la réunion de septembre, Mike Kryskow, de Gould-Modicom, a présenté un article sur un protocole de bus à jeton qu'il avait créé. Le contraste entre un réseau à jeton déterministe et le protocole probabiliste CSMA/CD a amené beaucoup à se demander si ce dernier pouvait devenir la norme. Un standard à jeton a ainsi gagné du terrain.

Le 30 septembre, DIX a publié ses spécifications Ethernet comme promis. Connues sous le nom de « Livre bleu » en raison de la couleur de sa couverture, ces spécifications, comme le rappelle Kaufman : Environ 25 000 exemplaires ont été imprimés avec le budget d'Intel et distribués dans le monde entier. Notre message était clair : « Voilà. Nous nous sommes engagés. Nous allons faire en sorte que ça fonctionne, et si vous voulez y apposer une norme, pas de problème. » Bien sûr, nous n'avions pas vraiment anticipé le fait que beaucoup d'autres personnes, avec leurs propres intérêts, chercheraient à perturber la norme. Avec le recul, nous aurions peut-être dû attendre encore quelques années, le temps de la finaliser. Mais nous l'avons présentée à l'IEEE, et beaucoup ont dépensé des sommes considérables pour lutter contre Ethernet.

Liddle décrit le comité d'attente d'ingénieurs sceptiques comme suit : La foule hurlante à l'IEEE.

Dans une annonce d'octobre visant à freiner la prolifération des tokens, HP a apporté son soutien à la norme CSMA/CD et s'est engagée à la soutenir activement. (Une initiative initiée lors des réunions mensuelles entre Kaufman et Crockett.) Don Loughry, de HP, revient sur ces tensions : Lors de la réunion de mai à Washington D.C. [NBS], DEC, Intel et Xerox ont présenté leur solution Ethernet. Ils ont commis une erreur stratégique. Ils ont affirmé en substance : « Nous avons LA solution. »
Mais cela s'est retourné contre eux. Ils n'avaient pas compris les étapes nécessaires pour vendre un produit, qu'on ne peut pas simplement présenter une solution et s'attendre à ce qu'une centaine d'autres entreprises l'adoptent, surtout les grandes entreprises impliquées. La situation s'est alors un peu calmée, et le 30 septembre, la première version d'Ethernet a été produite. À ce moment-là, il était devenu impératif de structurer le projet de manière méthodique.

La prochaine réunion à Phoenix en décembre s'annonçait comme un combat de championnat. S'il devait y avoir une norme, le choix entre CSMA/CD et le passage de jetons semblait impératif.

Le président Graube rappelle : Il me devenait évident que les choses n'allaient aboutir à rien .

Loughry de HP, qui allait jouer un rôle important pendant et après la réunion, se souvient : Lors de cette réunion de décembre, il était de notoriété publique, et même anticipé par les initiés, qu'il s'agirait d'une véritable confrontation. C'était le moment où ils comptaient couler CSMA/CD et l'enterrer définitivement, et de grandes entreprises étaient déterminées à y parvenir. J'ai été en quelque sorte élu, ou promu, ou je ne sais quoi – nommé – par des gens comme Metcalfe et John Schoch, pour défendre et porter haut et fort CSMA/CD.

Kaufman d'Intel se souvient de l'attitude des membres du DIX, en particulier d'Intel : Notre stratégie était fondamentalement la suivante : « Ils ne vont pas tuer Ethernet, et si l'IEEE le tue, cela nous est égal car il n'y a rien d'autre pour le moment. » IBM parlait d'un anneau à jeton, mais sans spécifications. S'ils en avaient eu, ils ne les publieraient pas, et les personnes qu'ils avaient envoyées ne parlaient manifestement pas au nom d'IBM et répétaient sans cesse qu'elles ne parleraient pas en son nom. Par conséquent, les discussions de l'IEEE concernant le jeton étaient pour nous totalement hors sujet. Nous allions commercialiser le CSMA/CD quoi qu'il arrive, et nous allions suivre les recommandations de l'IEEE. S'ils prenaient une décision, nous l'adopterions. S'ils n'avaient pas pris de décision avant que la puce ne soit prête, nous la commercialiserions telle quelle. C'est pourquoi nous l'appelions la puce « Ethereum », en raison des nombreuses variantes qui apparaissaient au sein du CSMA/CD, et non parce que nous allions y intégrer un anneau à jeton. Personne ne savait comment en fabriquer un.

Lors de la réunion, les partisans de PROWAY et d'IBM se sont unis pour soutenir la technologie des jetons comme base de la future norme LAN du Comité 802. Lors du vote en faveur du tokenisme, la majorité des trois quarts requise n'a pas été atteinte. Il était tout aussi évident, cependant, que CSMA/CD (Ethernet) ne pourrait pas non plus obtenir une majorité des trois quarts. Semblant dans une impasse, le Comité 802 a élaboré un compromis : deux normes seraient créées. Ce choix a permis d'éviter l'échec, voire la dissolution du Comité. Deux nouveaux sous-comités, CSMA/CD et token passing, sont venus s'ajouter aux trois sous-comités existants. Loughery est devenu président du sous-comité CSMA/CD.(Voir l'annexe 9.4 : Structure des sous-comités du Comité 802.
Afin de maintenir une apparence de norme unique, le Comité a exigé que toutes les spécifications, à l'exception des algorithmes d'accès, soient identiques et tous les membres ont continué à voter sur les deux normes ; des règles susceptibles d'engendrer de futurs conflits.

Rosenthal, une utilisatrice avertie, s'est sentie trahie : À mon avis, c'était une véritable catastrophe. J'essayais d'établir des normes pour le gouvernement, et voilà que je devais choisir entre deux technologies ! J'étais furieuse, mais je n'avais pas le choix. Je me suis donc tourné vers le protocole CSMA/CD, car je le maîtrisais parfaitement et j'avais un réseau.

En janvier 1981, le titre de l'éditorial du magazine Data Communications, dans sa rubrique Viewpoint, était le suivant : « La décision de l'IEEE fait obstacle au développement des réseaux locaux. » L'éditorial cinglant se terminait ainsi : L'IEEE devrait réunir à nouveau son comité des normes de réseau local dès que possible et relever le défi de l'industrie en décidant d'une norme pertinente pour l'accès au réseau local.

Grabe, dans un article du même numéro de Data Communications, a qualifié la décision du Comité 802 de : « une sorte de lâcheté ».

Annexe 9.4 Structure du sous-comité du comité 802 de l'IEEE

Figure 11.4.2 Structure du sous-comité du comité 802 de l'IEEE

Les technologies et l'économie des réseaux locaux avaient compliqué les plans du Comité 802.
Quel sort attendaient les normes OSI développées par l'ISO ?

11.5 ISO/OSI (Open Systems Interconnection) : 1979 - 1980

Lors du dernier point d'étape fin 1979, le comité technique de l'Organisation internationale de normalisation (ISO/TC 97) venait d'approuver le modèle de référence OSI en tant que projet de travail (WD) et avait autorisé le sous-comité 16 (SC16) à y apporter les modifications demandées pour le soumettre à nouveau sous forme de projet de proposition (DP). Le modèle de référence (WD) reposait sur le postulat fondamental selon lequel la communication s'effectue par l'établissement de connexions plutôt que par l'envoi de datagrammes ; cela, alors même que les principales technologies de réseaux locaux (LAN) utilisaient des datagrammes — et non des connexions — pour la communication entre équipements. Comme le modèle de référence (WD) ne prenait pas en compte les protocoles de datagrammes, il ne pouvait satisfaire la communauté des réseaux locaux, alors en pleine expansion.
Voici un extrait de l'introduction de la norme finale : L'hypothèse selon laquelle la connexion constitue un préalable fondamental à la communication dans l'environnement OSI imprègne le modèle de référence ; il s'agit de l'un des concepts unificateurs les plus utiles et les plus importants de l'architecture décrite.

Dans la terminologie OSI, les circuits physiques et virtuels relevaient de protocoles avec connexion, tandis que les datagrammes étaient associés à des protocoles sans connexion. Les architectures à circuits physiques ou virtuels établissent des connexions avant de transmettre des données, alors que les architectures à datagrammes transmettent simplement les données sans établir de connexion (d'où le terme « sans connexion »). Les principales technologies de réseaux locaux, telles que CSMA/CD et le passage de jeton (token passing), fonctionnaient sans connexion et n'étaient donc pas prises en compte par le modèle de référence (WD).
Si le modèle de référence fondé sur la connexion satisfaisait les administrations des postes et télécommunications (PTT), il impliquait, pour ceux qui souhaitaient des communications de bout en bout fiables sur les réseaux publics de données ou les réseaux locaux, la création :
- d'un protocole de couche transport assurant un service fiable de bout en bout
- d'une modification du modèle de référence pour permettre des communications sans connexion
- d'un protocole de couche réseau sans connexion
L'absence de prise en compte des communications sans connexion dans le modèle de référence (WD) préoccupait de nombreux informaticiens européens ainsi que Rosenthal et ses collègues du National Bureau of Standards (NBS), qui œuvraient pour que le gouvernement américain adopte les futures normes OSI. Toutefois, le réseau pionnier du NBS, NBSnet, reposait sur un protocole CSMA/CD, c'est-à-dire sans connexion.
Si le modèle OSI n'intégrait pas de protocoles sans connexion comparables à ceux qui émergeaient aux États-Unis, le NBS serait contraint d'abandonner son objectif d'adopter les normes OSI. En réponse, le NBS a mis en œuvre une stratégie à plusieurs volets. Dans un premier temps, il a sollicité l'aide de l'American National Standards Institute (ANSI), représentant américain auprès de l'ISO. Or, les membres de l'ANSI — des entreprises privées — privilégiaient les technologies propriétaires et remettaient en question l'intérêt économique des normes internationales.

Le NBS s'est ensuite tourné vers l'European Computer Manufacturers Association (ECMA). Bien qu'elle ne fût pas membre officiel de l'ISO, l'ECMA assistait aux réunions du sous-comité SC16 sur invitation. Elle partageait les préoccupations du NBS concernant l'absence de protocoles OSI sans connexion pour les réseaux locaux (LAN). Depuis des années, l'ECMA suivait ou participait aux discussions de l'INWG et de l'IFIP sur la nécessité de protocoles de type datagramme. L'ECMA a donc accueilli le NBS comme un allié et a invité ses représentants à ses réunions.
John Heafner, responsable de la division « Architecture des systèmes et des réseaux » du NBS à partir de janvier 1979 — et chargé de toutes les activités du NBS liées aux réseaux, y compris les protocoles OSI —, se souvient avoir souhaité que l'ISO adopte des protocoles de transport similaires au protocole TCP du département de la Défense (DoD) : « Ainsi, par l'intermédiaire de l'ECMA et d'autres canaux, nous avons promu des définitions — rédigées dans le jargon de l'ISO — des protocoles du DoD, notamment la classe de transport IV, qui correspond au protocole TCP. Notre objectif, dès le départ, était d'œuvrer au sein de l'ISO, et dans une certaine mesure du CCITT, pour garantir que les besoins du gouvernement seraient pris en compte lors de l'élaboration de ces protocoles. »
Au début de l'année 1980, consciente de l'urgence, l'ECMA a soumis une proposition préliminaire à l'ISO et au CCITT, recommandant quatre classes de protocoles de transport, allant d'un protocole minimal pour les réseaux avec connexion à un protocole de type TCP pour les réseaux sans connexion. (Toutes ces classes devaient fonctionner au-dessus d'une couche réseau orientée connexion.) Toutefois, l'ECMA avait besoin d'un allié interne pour défendre sa cause.

Au printemps 1980, le champion de l'ECMA entra en scène. L'administration française des PTT, influencée par l'évolution du contexte réglementaire aux États-Unis — notamment la déréglementation et les procédures « Computer Inquiries » — et consciente de la convergence entre informatique et télécommunications, recruta Zimmerman.
Ce dernier quitta l'IRIA, un institut de recherche en informatique, pour rejoindre le Centre national d'études des télécommunications (CNET), l'organisme de recherche des PTT — l'équivalent français des Bell Labs. Son nouveau poste le plaçait idéalement pour concilier les positions divergentes de l'ISO et du CCITT. Il se souvient : L'une des raisons de ce changement était la volonté des PTT d'intégrer davantage la culture informatique. Il avait été convenu que je continuerais à participer aux travaux de normalisation, comme je le faisais auparavant ; j'étais alors bien mieux placé pour servir d'intermédiaire entre l'ISO et le CCITT. Au sein de l'ISO, je restais responsable du groupe chargé du modèle de référence OSI, et tout le monde savait que j'avais rejoint les PTT. On voyait bien que cela ne modifiait ni ma façon de gérer les dossiers ni ma détermination à faire avancer les choses, et il était évident que je bénéficiais du soutien des PTT.
En août 1980, grâce à l'action de Zimmerman et à une attitude plus ouverte du CCITT envers les normes orientées vers l'informatique, le CCITT et l'ISO annoncèrent conjointement un soutien de principe à la proposition de protocole de transport de l'ECMA.
Le défi suivant pour Zimmerman consistait à faire approuver le modèle de référence lors de la prochaine réunion du sous-comité SC16 à Berlin. Le succès était loin d'être garanti. Zimmerman savait que la version actuelle du modèle de référence présentait des défauts. Comment aurait-il pu en être autrement, alors qu'il avait été conçu par un comité international en un temps record ? Certains problèmes étaient d'ordre purement formel, comme la qualité de la langue anglaise. D'autres étaient plus sérieux. La délégation américaine, par exemple, remettait régulièrement en question l'objectif fondamental d'un modèle de référence. Elle plaidait pour que le modèle soit diffusé comme un simple rapport technique plutôt que d'être adopté comme une norme aux conséquences durables. Zimmerman estimait que les Américains sous-estimaient l'avantage de rendre le modèle de référence difficile à modifier. (Il percevait également l'ambivalence des Américains, dont beaucoup auraient préféré que le marché tranche les questions technologiques plutôt qu'un organisme public.)
La question qui préoccupait le plus Zimmerman était de savoir si le juste équilibre avait été trouvé entre le « délai de mise sur le marché » et l'élégance technologique, Zimmerman compris, reconnaissaient qu'un processus collaboratif d'élaboration de normes ne débouchait pas nécessairement sur une solution technique parfaite. Toutefois, pour qu'une norme fonctionne dans le monde réel, elle devait être largement acceptée, malgré ses faiblesses techniques et les exigences contradictoires. Zimmerman se souvient : À l'époque, il a bien fallu admettre — et j'en étais convaincu assez tôt — qu'il ne fallait pas viser la perfection technique absolue, mais plutôt une solution acceptée et soutenue par les principaux acteurs. Nous avons exercé une pression considérable pour que, à un moment donné, les choses soient simplement figées, avec cette règle : « Sauf raison majeure de modifier un élément, nous n'y toucherons pas. »

Lors de la réunion du SC16 à Berlin, en novembre 1980, une atmosphère d'effervescence, née de près de trois années de travail acharné, animait les salles de réunion bondées. Alors que les quelque 200 participants attendaient avec impatience le vote d'approbation du modèle de référence en tant que DP (projet de proposition), chaque délégation nationale présentait officiellement son évaluation du modèle et recommandait — ou non — son adoption. John Aschenbrenner, d'IBM, dirigeait la délégation américaine qui, une fois de plus, soutenait que le modèle de référence devait être approuvé en tant que rapport technique, et non comme une norme. Le bruit sourd qui suivit eut à peine le temps d'atteindre le fond de la salle que Mike Purton, du British Standards Institute, prononçait ce que Bachman qualifierait plus tard de « tristement célèbre discours », fustigeant le modèle de référence pour son mauvais usage de la langue anglaise.
Zimmerman se souvient de la réaction suscitée par le discours de Purton, la délégation britannique ayant déclaré : Qu'elle avait soumis le document à ses experts et que ceux-ci avaient conclu à l'unanimité qu'il fallait le jeter à la corbeille.
C’est ainsi que les choses se sont terminées, car dire à une équipe qui avait travaillé d’arrache-pied pour produire quelque chose — consciente que le résultat n’était pas parfait mais qu’il avait de la valeur — que leur travail n’était bon qu’à finir à la corbeille, c’était mettre un point final à l’affaire.
Tout le monde était d’accord. Les États-Unis ont déclaré : « Nous allons simplement nous abstenir. Nous ne nous y opposerons pas » ; c’est de cette manière que le modèle de référence OSI a accédé au stade de DP (projet de norme).

Le passage du modèle de référence OSI au stade de DP a concrètement imposé une structuration en couches des protocoles de communication informatique, alors même qu’OSI n’avait pas encore élaboré de norme protocolaire proprement dite.

11.6 TCP/IP et XNS : 1979-1980

Tout au long de l'année 1979, Kahn et Cerf ont fait pression sur le département de la Défense (DOD) pour que TCP/IP devienne une norme officielle de protocole de communication.
En janvier 1980, après une année de tests de code, Postel a publié les deux nouveaux protocoles, TCP et IP, sous forme de « Request for Comments » (RFC) et, simultanément, en tant que normes du DOD.
Une fois ces normes publiées, le travail ardu de conversion de tous les réseaux — y compris ARPANET — vers TCP/IP a commencé.
La date du 1er janvier 1983 a été fixée pour la bascule d'ARPANET vers TCP/IP.

Les implications de ces évolutions n'ont pas échappé à Rosenthal et à d'autres membres du NBS, qui avaient précédemment décidé d'adopter les protocoles OSI comme norme pour le gouvernement fédéral. Étant donné que de nombreux services fédéraux avaient besoin d'assurer des communications informatiques efficaces avec le DOD, comment TCP/IP et OSI allaient-ils pouvoir interopérer ?
Pour examiner ces questions et d'autres sujets, le NBS a organisé, en mai 1980, un atelier intitulé « Trends and Applications 1980: Computer Network Protocols » (Tendances et applications 1980 : protocoles de réseaux informatiques).
Parallèlement, la DARPA a poursuivi ses efforts et, en août 1980, avait mis en œuvre le nouveau protocole TCP/IP sur 12 passerelles interconnectant 10 réseaux25. Signe encourageant d'une volonté de coopération, le DOD a présenté publiquement TCP/IP au NBS en décembre 1980.
Les travaux de la division de développement des systèmes (SDD) de Xerox visant à faire évoluer le protocole Pup vers XNS ont progressé presque parallèlement à ceux concernant TCP/IP durant ces mêmes années. Yogen Dalal, qui avait pris la direction de la majeure partie du groupe réseau de la SDD après le départ de Metcalfe fin 1978, suivait de près l'évolution de TCP et d'OSI. Dalal se souvient : Nous étions conscients du concept de modèle de référence d'interconnexion de systèmes ouverts (OSI). Hubert Zimmermann et son équipe tentaient de le définir. Nous avons essayé d'influencer bon nombre de ces réflexions. Je suppose que notre approche était un peu plus axée sur la pratique ; ainsi, alors que le modèle de référence regorgeait de terminologie formelle, nous avons tenté d'y intégrer une traduction accessible au profane — ou reflétant la façon de penser d'un programmeur. Nous le considérions comme quelque peu académique : il s'agissait d'un modèle de référence visant à formaliser des connaissances que nous partagions tous. Comme la plupart des modèles de l'époque, il se concentrait sur les couches inférieures — domaine où l'on disposait d'une certaine expérience — tandis que les couches supérieures restaient assez floues, faute d'avoir encore approfondi ce volet. Notre influence fut négligeable, principalement parce que Xerox restreignait notre liberté d'évoquer certaines de nos expériences ; par ailleurs, nos divergences de vues concernant le modèle portaient essentiellement sur les protocoles de haut niveau.
En 1979, lorsque Dalal apprit de son supérieur, David Liddle, que Xerox, DEC et Intel collaboraient pour normaliser Ethernet, il soutint que Xerox devait également commercialiser XNS ou tenter d'en faire un standard. Dalal se souvient avoir demandé à Liddle : « Pourquoi ne pas amener Xerox à vendre ou à normaliser son produit d'architecture réseau, en plus de son produit commercial ? » Nous tenions quelque chose d'exceptionnel, une véritable révolution, et nous étions déterminés à en faire un succès.
D'autres services de l'entreprise nourrissaient des ambitions tout aussi vastes, mais craignaient de perdre le contrôle s'ils diffusaient le standard. Ce fut la plus grave erreur jamais commise par Xerox.
La direction de Xerox redoutait encore plus de rendre XNS public qu'Ethernet, car l'intelligence différenciatrice — celle qui permettait de concevoir des imprimantes, des serveurs d'impression et des serveurs de fichiers sophistiqués — résidait dans XNS, et non dans Ethernet. Le premier produit commercial reposant sur les nouvelles capacités de XNS et d'Ethernet fut le Xerox 8000 Network System (X 8000), annoncé en novembre 1980 — soit deux mois seulement après la publication du « Livre bleu » par le consortium DIX et un mois avant la présentation publique de TCP/IP. Le X 8000 se composait d'un ordinateur utilisateur à interface graphique (la station de travail 860), d'imprimantes laser et de divers autres périphériques, le tout interconnecté via Ethernet et XNS. Dans le numéro de décembre de la revue *Data Communications*, Metcalfe — alors chez 3Com — estimait que l'architecture du X 8000 : ouvrait la voie à la conception future de réseaux à ressources partagées.

11.7 ISO/OSI (Interconnexion de systèmes ouverts) : 1981-1982

En novembre 1980, le soulagement collectif suscité par l'avancement du modèle de référence OSI jusqu'au stade DP a redonné de l'énergie à ceux qui cherchaient à influencer la conception des différents protocoles. Pour les membres du comité technique 97/sous-comité 16 de l'ISO, la définition des protocoles de la couche transport, et notamment la nécessité d'un protocole de datagramme de bout en bout, est devenue une priorité.
Le CCITT avait déjà fait connaître ses exigences en approuvant, quelques mois auparavant, sa norme de couche transport pour le télétexte – la recommandation S.70.
En janvier 1981, l'ECMA a normalisé les cinq classes de protocoles de transport qu'elle avait précédemment recommandées à l'ISO et au CCITT : la classe 2 étant équivalente à la recommandation S.70 du CCITT et la classe 4 à TCP.
Sans surprise, ces décisions ont influencé les travaux du sous-comité 16, qui privilégiait un accord avec le CCITT et l'ECMA, et des réunions conjointes ont été organisées.

Avec l'avancement du Modèle de Référence vers la phase de développement (DP), il est quasi certain que la normalisation a engendré une intense activité commerciale. Lors de la National Computer Conference (NCC) en mai, les communications de données ont occupé le devant de la scène pour la première fois, avec des séminaires tels que « Protocoles de transport et de session dans le contexte du Modèle de Référence ISO » et « Réseaux locaux et Ethernet en particulier ». Des personnalités telles que Cerf, Greg Hopkins, David Potter et John Day y ont pris la parole. Trente articles sur le modèle OSI (« L'avènement d'une norme attendue depuis longtemps pour les réseaux hétérogènes » et « Réalité et proposition de norme OSI » ) ont commencé à paraître dans des publications techniques et industrielles. L'importance indéniable du protocole de connexion X.25 a été confirmée par l'annonce de produits par AT&T en janvier, puis par IBM en juin. Rien d'étonnant à ce que Zimmerman ait ressenti la pression de finaliser le Modèle de Référence afin de pouvoir entamer les travaux sur les normes de protocoles : les forces du marché étaient déjà à l'œuvre.

En janvier 1982, moins d'un an après avoir soumis le modèle de référence DP 7498 à ses membres pour approbation, le TC 97 l'a approuvé en tant que projet de norme internationale (DIS) et l'a transmis à l'ISO pour vote par l'ensemble de ses membres. L'incertitude quant à la transformation du modèle de référence en norme étant pratiquement levée (malgré les critiques persistantes de la délégation américaine, qui estimait qu'il devait s'agir d'un document technique et non d'une norme), les deux comités, SC6 et SC16, se sont sentis contraints d'entamer la production des protocoles nécessaires à la fabrication des produits. Cela impliquait la création de deux normes – Services et Protocoles – pour chaque couche .

En juin 1982, lors de sa réunion de Tokyo, le SC16 a été le premier à approuver, en tant que projets de propositions (DP), les normes de service (ISO/DP 8072) et de protocole (ISO/DP 8073) de la couche transport. Les États-Unis (ANSI) ont de nouveau voté contre, invoquant l'incompatibilité entre les cinq classes du DP 8073 et affirmant que ce dernier était irréalisable. Les efforts déployés pour résoudre les objections américaines, ainsi que celles d'autres parties prenantes, avant la transmission des DP au TC 97, ont pris une nouvelle dimension. La modification du TP-4, protocole de circuit virtuel sur les réseaux sans connexion, a été confiée au NBS, garantissant ainsi un protocole similaire au TCP. Malgré les différences, la rapidité avec laquelle les DP 8072/73 ont été adoptés a témoigné d'une réelle coopération avec le CCITT et l'ECMA. (Après tout, CCITT et ECMA ont obtenu ce qu'ils voulaient et plus encore : la classe TP-0 offrant des fonctionnalités minimales, compatibles avec une couche réseau de connexion telle que X.25, et la classe TP-4, offrant des fonctionnalités comparables à TCP, recherchées par la communauté informatique.)

En revanche, les progrès au sein du SC6 concernant la création d'un protocole sans connexion au niveau de la couche réseau ont été bloqués pendant que le comité finalisait ses normes de service et de protocole basées sur la connexion. Ce retard s'explique en partie par le fait que le modèle de référence ne prévoyait pas encore de communications sans connexion. Quelle motivation un comité axé sur la connexion aurait-il à créer un protocole sans connexion ?

À l'automne 1982, les votes concernant le modèle de référence DIS 7498 commencèrent à arriver et les États-Unis votèrent une nouvelle fois contre. Bien que les trois objections accompagnant ce vote négatif fussent les mêmes que celles invoquées par les États-Unis lors des précédents votes positifs, le fait que le secrétariat américain ait voté contre semblait source de division. Dans un article de décembre 1982 de la revue Data Communications intitulé : « Un groupe d'utilisateurs de réseaux sous le choc du vote de l'ANSI contre le modèle OSI », Sheldon Blauman, fondateur de la Network Users Association (NUA), était cité : C'est à la fois une surprise et un choc pour moi. Voter contre l'interconnexion des systèmes ouverts, c'est comme voter contre la tarte aux pommes et la maternité. Je trouve la situation plutôt inquiétante.

Bien que le vote final sur la norme DIS 7498 ait donné 22 voix pour, 2 voix contre et 1 abstention, sa reconnaissance comme norme internationale est restée suspendue le temps de résoudre les objections des États-Unis. (L'Allemagne s'est jointe aux États-Unis pour voter contre.)

Fin 1982, la promesse du modèle OSI d'harmoniser les technologies conflictuelles des communications informatiques restait lettre morte. L'architecture globale du modèle de référence DIS 7498 semblait sur le point de devenir une norme internationale. Cependant, le modèle DIS 7498 reposant sur un paradigme de connexion, l'intégration du monde sans connexion des réseaux locaux (LAN) impliquait la création d'un addendum au modèle de référence – un document modifiant une norme existante – qui, bien qu'en cours d'élaboration, devait être soumis au vote selon la même procédure DP, DIS et ISO.

Un point positif à noter : la norme SC16 a adopté une version TP-4 de la norme DP 8073 : un protocole de circuit virtuel sur un réseau à connexions. Cependant, tant que la norme SC6 n’avait pas adopté de couche réseau sans connexion, les produits LAN utilisant les normes ISO OSI restaient une perspective lointaine. Que pouvaient faire les fabricants de réseaux LAN en attendant ?

Fin 1982, deux protocoles de communication sans connexion, ou par datagrammes, existaient pour les réseaux locaux : TCP/IP et XNS. Leur succès allait influencer l’issue du modèle OSI.

11.8 TCP/IP et XNS (1981-1983)

En novembre 1980, lorsque Xerox a lancé XNS sur le marché dans le cadre du système réseau Xerox 8000, TCP/IP n'avait été codé que pour démontrer sa viabilité, et non pour assurer une fonctionnalité opérationnelle. La date prévue pour la bascule d'Arpanet — le réseau le plus important de l'époque — était fixée au 1er janvier 1983, soit plusieurs années plus tard.
Le calendrier du projet comportait des risques. Tout d'abord, BBN devait rendre le sous-réseau d'Arpanet compatible avec TCP/IP.
Vint ensuite la question complexe du développement du code TCP/IP pour tous les ordinateurs hôtes essentiels connectés à Arpanet. Il n'était pas question de laisser chaque site hôte créer sa propre version de TCP/IP, une leçon apprise à ses dépens lors de la création du logiciel hôte initial, alors en passe d'être remplacé.
En 1981, la DARPA a attribué sept contrats pour le développement de code destiné aux ordinateurs hôtes.
Le contrat pour le portage de TCP/IP sous UNIX a été confié à BBN. (Voir Illustration 11.8.1 : Portage de TCP/IP) BBN a ensuite transmis son code TCP/IP à Bill Joy, à Berkeley, pour qu'il l'intègre à la version améliorée d'UNIX qu'il développait pour l'ordinateur VAX.
Le développement des portages pour les hôtes a débuté une fois que Postel a publié la norme TCP/IP sous forme des RFC 791 et 702, en septembre 1981.

Illustration 11.8.1 : Portage de TCP/IP

La stratégie de Xerox concernant XNS contrastait radicalement avec la politique de large diffusion adoptée par le département de la Défense (DOD) pour le protocole TCP/IP. Xerox souhaitait conserver le caractère propriétaire de XNS et en garder le contrôle. L'entreprise avait créé XNS pour assurer une intégration fluide entre tous ses produits bureautiques, espérant ainsi acquérir un avantage concurrentiel sur des sociétés mieux établies, comme IBM, dans la course au « bureau du futur ». Or, les clients se méfiaient des solutions imposant un fournisseur unique et exigeaient l'interopérabilité des équipements de tous les fabricants. C'est ce constat qui a conduit Xerox, à l'automne 1980, à confier à Ungermann-Bass le contrat d'adaptation de XNS à son commutateur de terminaux NUI. Autoriser les clients à connecter des terminaux informatiques d'autres fournisseurs aux réseaux XNS de Xerox était une décision mineure comparée à celle de rendre XNS public, ce qui revenait à céder ce que beaucoup, chez Xerox, considéraient comme un véritable avantage concurrentiel. Les partisans de l'ouverture de XNS voulaient faire d'Ethernet le réseau local (LAN) de référence, et il ne faisait aucun doute que XNS permettait à Ethernet de donner toute sa mesure. Metcalfe se souvient : Nous travaillions sur des réseaux locaux, tandis que lui [Cerf, à la DARPA] travaillait sur des circuits téléphoniques à 50 kilobits par seconde ; c'est une différence considérable. C'est la raison pour laquelle TCP est si lent alors que XNS est si rapide. XNS a été conçu pour fonctionner sur des infrastructures de transport offrant des débits de plusieurs mégabits par seconde, alors que TCP a été élaboré en tenant compte des modems et des liaisons lentes. Résultat : si vous utilisez TCP sur un réseau local, il est lent ; en fait, il est deux fois plus lent, soit moitié moins rapide que XNS.

En octobre 1981, la pression du marché incitant Xerox à rendre XNS public s'est considérablement accrue lorsque l'entreprise a annoncé le lancement de son système d'information 8010 Star ; ...une station de travail conçue comme un « bureau électronique » et qui a inauguré l'interface utilisateur basée sur des icônes. (Son prix de 15 000 dollars s'est avéré bien trop élevé, vouant le produit à l'échec.)
Ne pouvant justifier le maintien du secret absolu autour de XNS, Xerox en a rendu une partie publique en décembre 1981, sans toutefois tout dévoiler.
Dalal se souvient : Ce qui s'est passé, c'est qu'avec l'existence d'Ethernet, ils ont estimé nécessaire de divulguer les niveaux supérieurs ; ils ont donc rendu public XNS pour ce qui est des datagrammes, du protocole de session et du protocole Courier de Jim White — un moyen d'échanger des appels de procédure. En revanche, ils hésitaient à divulguer les protocoles de gestion de fichiers, d'impression, de recherche de noms ou de courrier électronique, c'est-à-dire tous les protocoles réellement nécessaires pour accomplir des tâches concrètes. Encore une fois, je pense qu'ils jugeaient acceptable de diffuser les protocoles de bas niveau, permettant ainsi à des entreprises comme Ungermann-Bass ou Bridge de fabriquer du matériel de connectivité, tout en empêchant quiconque de créer des serveurs capables de concurrencer le système Star ou les systèmes de gestion de fichiers produits par Xerox.

Le fait que Xerox n'ait publié que les couches inférieures de XNS importait peu aux jeunes entreprises de réseaux locaux (LAN), dont les produits de première génération n'étaient guère plus que des commutateurs de terminaux, surnommés avec dérision « machines à traire ».
Les fournisseurs de LAN avaient le choix : attendre patiemment ou inventer leurs propres protocoles réseau, car à la fin de l'année 1981, ni TCP/IP ni OSI n'étaient disponibles.
Ainsi, malgré ses fonctionnalités limitées, l'usage de XNS s'est répandu, faisant de lui le premier leader du marché des protocoles LAN.

Puis, à la mi-1982, un événement inattendu — nouvel exemple de hasard historique illustrant l'importance constante de l'individu dans l'histoire — s'est produit : Berkeley a lancé une nouvelle version d'UNIX intégrant une version réécrite de TCP/IP. Il ne s'agissait toutefois pas de la version de TCP/IP que la DARPA avait chargé BBN de réécrire pour la confier à Joy, lequel devait l'intégrer à UNIX. Jugeant le code TCP/IP insatisfaisant, Joy a décidé de le réécrire lui-même. Kahn se souvient : Bill Joy estimait tout simplement que ce code [le code de BBN] n’était pas aussi efficace que ce qu’il aurait pu produire lui-même. Alors, Joy l’a tout bonnement réécrit. On lui a livré le travail, il a déclaré : « C’est de la camelote », et il l’a refait. Il n’y a eu aucune discussion. Il l’a simplement refait de sa propre initiative.

Une entreprise, une université ou tout autre utilisateur pouvait acquérir une licence du code source UNIX auprès de Berkeley pour 32 000 dollars et obtenir le code TCP/IP pratiquement gratuitement. De plus, comme le portage d'UNIX réalisé par Joy visait l'architecture VAX, le protocole TCP/IP fonctionnait avec Ethernet.
D'autres acteurs ont commencé à porter ce code sur d'autres ordinateurs et, du jour au lendemain, XNS s'est retrouvé face à un véritable concurrent ; un produit compétitif qui n'était pas tributaire du déploiement de fonctionnalités de couches supérieures.
La diffusion de TCP/IP a également été favorisée par l'accord que Kahn avait conclu avec Gordon Bell et Sam Fuller, de chez DEC : DEC s'engageait à vendre des systèmes VAX à des prix extrêmement bas aux universités. Kahn se souvient :J'ai convaincu Gordon Bell et Sam Fuller que s'ils mettaient ces VAX à disposition, les gens exploreraient des méthodes intéressantes pour y effectuer du calcul distribué — ce qui représentait l'avenir du secteur et méritait d'être compris. DEC a accepté en ces termes : « D'accord, nous le ferons, mais vous devez garantir que ces machines ne seront pas utilisées comme des systèmes autonomes de partage de temps. »
Grâce à la disponibilité du trio VAX/UNIX/TCP/IP et au portage ultérieur du code TCP/IP de Joy sur d'autres ordinateurs, les forces du marché ont propulsé TCP/IP d'une manière que personne n'aurait pu prévoir.
Une fois de plus, la DARPA a joué un rôle déterminant dans l'essor des réseaux locaux (LAN), non pas comme objectif premier, mais comme conséquence indirecte d'une autre mission (tout comme l'utilisation des IMP et des TIP avait permis de créer une première version de réseaux locaux).
Toutefois, au sein de la DARPA, l'attention restait focalisée sur l'échéance de janvier 1983 — date prévue pour la migration de l'ARPANET vers TCP/IP — plutôt que sur l'impact de cette transition sur le succès commercial des réseaux locaux.

La migration de l'ARPANET vers TCP/IP nécessitait des responsables et une planification rigoureuse. Cette tâche a été confiée à Dan Lynch qui, en 1980, a quitté le SRI pour prendre en charge les infrastructures informatiques de l'Information Sciences Institute (ISI) de l'Université de Californie du Sud, alors « le plus grand nœud de l'ARPANET ». Tout comme Roberts avant lui, Lynch allait devoir recourir à des méthodes musclées pour contraindre les utilisateurs d'Arpanet à adopter le protocole TCP/IP. Cerf se souvient d'une tactique particulièrement marquante : Au milieu de l'année 1982, nous avons désactivé la prise en charge du protocole NCP sur Arpanet pendant une journée entière ; seuls ceux qui avaient implémenté TCP pouvaient alors communiquer. Cela a suscité beaucoup de remous, mais a permis d'attirer l'attention.
Les plaintes et les problèmes se multiplièrent à l'approche du mois de septembre. Lynch se rappelle : Je me souviens du moment où nous sommes vraiment passés aux choses sérieuses, en septembre : nous avons commencé par des demi-journées réservées exclusivement à TCP, puis des journées entières ; c'est devenu une sorte d'événement mensuel, et je crois même que nous avons organisé une session de trois jours aux alentours de Thanksgiving.

Alors que la date fatidique du 1er janvier 1983 approchait à grands pas, tous les regards se tournèrent d'abord vers Lynch, puis vers Clark, que Cerf avait nommé président de l'Internet Working Group en septembre 1981. Cerf savait qu'il était temps pour lui de quitter la DARPA ; il s'était d'ailleurs progressivement mis en retrait de l'action directe. Lorsqu'il annonça sa démission de la DARPA en décembre 1982 pour rejoindre MCI et y diriger les projets de messagerie électronique, la nouvelle passa presque inaperçue aux yeux de ceux qui, sur le terrain, s'affairaient frénétiquement pour préparer le passage à la nouvelle année. Pour marquer le coup et souligner les efforts fournis, Lynch fit fabriquer à ses frais 500 badges blancs portant un message en rouge : « J'ai survécu à la transition TCP, 1/1/83 ». Et ils survécurent effectivement, car la transition eut lieu comme prévu. Ainsi, malgré les pannes et les problèmes persistants, nul ne pouvait plus douter de l'efficacité de TCP/IP, qui prenait désormais en charge des réseaux aussi variés qu'Ethernet et Arpanet.
Alors que TCP/IP et XNS fournissaient tous deux des services de couche réseau et transport sur les réseaux locaux (LAN) Ethernet, une question majeure se posait : l'IEEE 802 allait-il valider une norme CSMA/CD proche de l'Ethernet ?

11.9 Le comité IEEE 802 : 1981 - 1982

La réorganisation salvatrice du comité IEEE 802 en décembre 1980, visant à créer deux normes — le passage de jeton (*token passing*) et le CSMA/CD —, a apaisé les tensions immédiates sans pour autant résoudre les problèmes fondamentaux. Les factions soutenant le *token-bus* et le *token-ring* s'étaient alliées uniquement pour contrer l'adoption du CSMA/CD, masquant ainsi des divergences de fond. Comme les normes basées sur le jeton et celles basées sur le CSMA/CD devaient progresser de concert — conformément au règlement de l'IEEE 802 —, la coalition pro-jeton a multiplié les obstacles pour freiner la communauté CSMA/CD, pourtant mieux préparée. Cette réorganisation a également eu une conséquence imprévue : les difficultés du comité 802 à définir des normes pour les réseaux locaux (LAN) ont commencé à attirer l'attention du public.
Les communautés techniques et commerciales, plus larges, allaient désormais scruter les actions futures du comité 802 comme jamais auparavant ; les normes LAN étaient devenues un enjeu majeur.
Graube, fondateur et président du comité 802, était déçu de voir son objectif d'une norme unique compromis ; il savait que s'il n'affirmait pas son autorité, l'engrenage des débats conflictuels risquait d'empêcher l'émergence de toute norme. Cherchant à comprendre l'avancement des travaux des sous-comités afin de mieux cibler l'ordre du jour des réunions futures, il se souvient : J'ai simplement demandé à toutes les personnes travaillant sur des documents de me remettre ce qu'elles avaient produit. J'ai tout rapporté chez Tektronix pour élaborer un document de synthèse — notre premier « Draft A » — et c'était un désastre total. On voyait bien qu'il n'y avait aucune norme digne de ce nom. Nous ne faisions qu'énumérer un catalogue de méthodes possibles, au lieu de définir la manière dont les choses devaient être faites.
Désastre ou non, en mai 1981, ce « Draft A » marquait une première prise de position du comité 802, ou plus exactement, représentait un mirage sur des sables mouvants. Le travail sur la version suivante a débuté immédiatement.
L'absence manifeste de convergence a suscité une inquiétude croissante au sein du NBS et chez Xerox quant à la capacité du comité 802 à élaborer une ou plusieurs normes. Le NBS, ayant déjà opté pour le CSMA/CD, craignait que des retards et de nouveaux compromis n'aboutissent à une norme qui ne lui conviendrait pas. Pour susciter des soutiens en faveur du CSMA/CD et démontrer qu'il ne s'agissait pas simplement d'un projet secondaire issu de l'alliance DIX, le NBS se tourna de nouveau vers l'ECMA, l'organisation qui avait joué un rôle si constructif dans l'élaboration d'un protocole OSI de classe IV. Parallèlement, Xerox faisait pression sur Siemens pour que l'entreprise devienne revendeur de sa station de travail Star, dont le lancement était imminent. À mesure que l'intérêt de Siemens pour la revente du Star grandissait, il en allait de même pour son souhait de voir l'ECMA adopter une norme CSMA/CD équivalente à Ethernet, le réseau local (LAN) intégré au Star. En conséquence, Siemens commença à promouvoir une norme CSMA/CD au sein de l'ECMA.
Quant au comité 802, si ses tergiversations internes ne suffisaient pas à obscurcir l'avenir des normes de réseaux locaux, la presse se faisait l'écho d'un flux constant d'annonces concernant de nouvelles technologies LAN, toutes revendiquant une supériorité sur celles alors débattues au sein de l'IEEE 802.
Aucune annonce ne suscita autant de remous que celle de Wangnet par la société Wang, en juin 1981. Leader du traitement de texte et de la bureautique, Wang disposait d'une influence suffisante sur le marché pour créer l'événement à chaque lancement de nouveau produit, et Wangnet ne fit pas exception. En reconfigurant les technologies mêmes que le comité 802 étudiait, Wangnet acquit une crédibilité immédiate et perturba les débats en cours sur les normes. À l'instar du réseau à jeton sur bus (*token bus*) proposé par les partisans de PROWAY, Wangnet était un réseau à large bande. Au sein de son immense bande passante, il intégrait un canal CSMA/CD à 12 mégabits par seconde, contre 10 mégabits par seconde pour Ethernet. De plus, Wangnet promettait des canaux capables de transmettre de la voix, de la vidéo et même des données via des liaisons point à point traditionnelles. En somme, Wangnet avait de quoi satisfaire tout le monde.47 Wang annonçait des livraisons échelonnées entre février et octobre 1982.
L'annonce de Wangnet mit en évidence la nécessité pour le comité 802 de publier des normes de réseaux locaux dans les plus brefs délais. Au milieu de l'année 1981, il s'agissait de transformer le brouillon A (Draft A) — alors dans un état chaotique — en un brouillon B (Draft B) susceptible d'être soumis au vote des membres. En quête d'aide extérieure, Graube se souvient de ses frustrations vis-à-vis de l'ISO : Je ne pense pas que les gens de l'ISO savaient vraiment ce qu'ils faisaient ; il nous arrivait de solliciter leurs conseils sur la manière de décrire ces normes — notamment le modèle de référence — mais c'était un véritable casse-tête que de tenter de suivre leur démarche et de s'y référer pour nous guider.
L'annonce de Wang posa également problème à IBM, ce qui engendra à son tour des complications supplémentaires pour le Comité 802. Les factions favorables à la technique du jeton (*token*), bien qu'apparemment alignées, se retrouvaient désormais avec deux adversaires — IBM et Wang — sous le même toit. Robert Donan, sorti de sa retraite par IBM début 1981 pour coordonner les travaux de normalisation des réseaux locaux (LAN) de l'entreprise, occupait le poste de « Responsable du projet de normalisation » (*Standards Project Authority*). Son parcours comprenait notamment la direction de l'équipe à l'origine de l'annonce du protocole SDLC en 1969, ainsi que de nombreuses années d'expérience débutées avec le processus de normalisation SDLC/HDLC et marquées par des interactions avec l'ECMA, le CCITT et l'ISO. Il savait qu'il était primordial d'établir une distinction infranchissable entre le *token ring* (anneau à jeton) et le *token bus* (bus à jeton). Il se souvient de cette cohabitation improbable à l'automne 1981 : Il s'est avéré que les besoins du *Token Ring* et du *Token Bus* étaient fondamentalement divergents. Les partisans du *Token Ring* envisageaient, par exemple, un mécanisme de priorité très sophistiqué — toujours présent dans la norme actuelle — permettant des fonctionnalités complexes et variées impossibles à mettre en œuvre avec le *Token Bus*. Cette différence tient à la nature même du fonctionnement en anneau, où les données transitent par chaque station, contrairement au *Token Bus*. Vouloir uniformiser le *Token Ring* et le *Token Bus* revenait à les ramener au plus petit dénominateur commun, aboutissant ainsi au pire des deux mondes.

L'illusion d'une norme unique fondée sur le jeton, créée artificiellement pour contrer le CSMA/CD, était vouée à l'échec, une issue précipitée par l'arrivée de Wang sur le marché.
Finalement, en octobre 1981, le comité 802 publia le « Draft B » (projet de norme B), un document de 400 pages destiné à un public attentif mais critique. Les sceptiques prédisaient un échec inévitable, pointant du doigt une accumulation excessive de détails et d'options.

Les partisans de l'Ethernet étaient, quant à eux, frustrés de voir l'adoption de leur norme freinée par la nécessité d'élaborer parallèlement une norme basée sur le jeton. Comment faire pression sur le comité 802 pour qu'il adopte une norme CSMA/CD équivalente au « Blue Book » Ils sollicitèrent à nouveau l'aide des membres de l'ECMA. Leurs efforts portèrent leurs fruits en novembre 1981, lorsque l'ECMA créa le groupe technique TG LN, rattaché au comité technique 24, pour élaborer des normes de réseaux locaux (LAN).
Lors de la réunion du comité 802 en décembre, les incompatibilités entre le *Token Bus* et le *Token Ring* — exacerbées par les tensions entre IBM et Wang — conduisirent à une réorganisation des travaux de normalisation : on passa d'une approche fondée sur les méthodes d'accès (CSMA/CD contre jeton) à une approche fondée sur la topologie (bus contre anneau). On fit valoir que le *Token Bus* présentait davantage d'affinités avec le CSMA/CD, une technologie elle aussi basée sur une topologie en bus et dont l'efficacité avait été démontrée sur câble large bande (*broadband*), tout comme pour le *Token Bus*. Quelle logique plus pertinente, en effet, que de regrouper les réseaux locaux basés sur une topologie en bus, qu'il s'agisse de CSMA/CD en bande de base (*baseband*) ou de *Token Bus* en large bande (*broadband*) ...et les réseaux locaux (LAN) à jeton (Token Ring).
Le débat radical sur les réseaux locaux a suscité de la confusion ainsi qu'une guerre de mots opposant les partisans de la bande de base (*baseband*) à ceux de la large bande (*broadband*). Le conflit opposait désormais DIX à Wang, plutôt qu'IBM à Wang.
Jerry McDowell, qui avait participé aux réunions de l'IEEE 802 dès le début, a rejoint Wang fin 1981 pour prendre en charge l'ensemble des technologies de communication, y compris Wangnet. Il se souvient de la guerre des mots qui a agité le monde des réseaux locaux pendant des années : « Ce qui se passait généralement, c'est qu'à chaque salon professionnel, j'étais invité à parler de la large bande, tandis que Liddle ou Bell parlaient de la technologie en bande de base ; la presse alimentait alors la confrontation : bande de base contre large bande. Laquelle est la meilleure ? Nous échangions des piques : je disais "Écoutez, avec la large bande, je peux transmettre de la vidéo, de la voix et des données", et ils rétorquaient : "Oui, mais qui en a besoin ?" »

Alors que le projet B (*Draft B*) semblait définitivement abandonné, que des rumeurs annonçaient l'imminence de normes LAN définies par l'ECMA et que le comité 802 se réorganisait à nouveau, le processus de normalisation mené par ce comité semblait une fois de plus s'enliser. Loughry, représentant de HP et chef de file du camp CSMA/CD, livre son analyse : « Des dissensions apparaissaient dans nos rangs. À l'époque, la presse critiquait le comité 802, affirmant qu'il n'avançait pas, qu'aucun accord n'était possible, etc. En réalité, c'est parce que nous ne respections pas nos propres règles. Nous ne procédions pas de manière saine, ni sur le plan technique ni sur le plan politique. À un moment donné de notre histoire, nous n'étions pas un groupe démocratique. »
Graube se souvient : « Je me tournais et me retournais dans mon lit la nuit, et je me rendais à ces réunions comme si je partais à la guerre. »

En février 1982, le comité 802 s'est réuni sous une forte pression pour élaborer un projet C (*Draft C*) acceptable. Les projets A et B n'étaient que des documents de travail diffusés pour recueillir des avis susceptibles d'être intégrés aux normes finales. Toutefois, une telle approche itérative semblait désormais lente et indécise. Le moment était venu de définir des normes, un point c'est tout. Or, cela paraissait impossible s'il fallait maintenir l'objectif initial ambitieux consistant à faire fonctionner toutes les méthodes d'accès — CSMA/CD, Token Bus et Token Ring — sur tous les supports (câbles en bande de base et à large bande, paires torsadées, fibre optique). Une solution pragmatique, née de la réorganisation de décembre et confirmée par l'évolution du marché, a consisté à associer chaque méthode d'accès à un support privilégié. Bien que cette approche remît en cause l'objectif initial, elle semblait permettre de rationaliser le processus de normalisation. Ainsi, la méthode CSMA/CD a été associée au câble en bande de base, le Token Bus au câble à large bande et le Token Ring à la paire torsadée. La voie vers la normalisation semblait désormais ouverte.
Lors de cette même réunion de février, la norme CSMA/CD s'est davantage éloignée de la proposition DIX. Dans le numéro de mars 1982 de la revue *Data Communications*, Graube a évalué les deux propositions CSMA/CD : Une incompatibilité totale

Plus tard, en février 1982, la lutte pour définir une norme CSMA/CD s'intensifia. Le comité TG LN de l'ECMA, qui avait travaillé en étroite collaboration avec Xerox, DEC, Siemens et Olivetti, acheva un projet de norme CSMA/CD plus proche du « Livre bleu » (Blue Book) du consortium DIX que de la proposition du comité 802, laquelle s'éloignait de ce même Livre bleu. Renforçant encore la portée de l'appel de DIX en faveur d'une norme Ethernet, vingt-quatre entreprises rendirent publique leur intention de lancer des produits Ethernet.
Si les membres du comité 802 pensaient avoir enfin levé les obstacles à la normalisation, ils durent être stupéfaits en découvrant le titre de l'éditorial paru en mars dans la revue *Data Communications* : « La triste histoire d'un comité de normalisation qui a perdu de vue son rôle et son importance. » Critiquant vivement la proposition d'associer chaque méthode d'accès à un support de transmission spécifique, l'éditorial concluait en ces termes :
Avant de se rendre coupable d'une tentative de faire faire à la technologie un bond en arrière spectaculaire, le comité IEEE 802 devrait mûrement réfléchir aux conséquences de sa proposition. Si elle est approuvée, elle constituera l'exemple le plus flagrant jamais vu d'une norme qui n'en est pas une. Si elle est rejetée — ce qui serait tout à fait justifié —, le comité s'éloignera encore davantage de l'image de sérieux dont il jouissait autrefois auprès de tous. Un article paru dans ce même numéro de *Data Communications* s'intitulait « Normes de réseaux locaux : pas d'utopie ».
Il soulignait la nécessité d'une acceptation par le marché :
L'acheteur sait pertinemment que de nombreuses innovations technologiques majeures ont connu le succès commercial grâce à des jeunes pousses plutôt qu'à des géants établis. Par conséquent, les acheteurs devant choisir un produit de réseau local ne verront pas leurs attentes comblées par les organismes de normalisation. Ceux qui ne sont pas des adeptes de la première heure attendront que le marché impose ses propres normes, quel que soit le moment où le comité 802 — ou tout autre comité — les formulera.

La légitimité institutionnelle du comité 802 étant menacée, 22 membres — dont tous les présidents de comité, à l'exception de Graube et Rosenthal — rédigèrent une réponse publiée dans la rubrique « Viewpoint » du numéro d'avril de *Data Communications*. Ils y défendaient le rôle moteur des normes pour encourager la fabrication de semi-conducteurs VLSI et permettre ainsi de réduire le coût des puces pour réseaux locaux (LAN) : La solution au problème des volumes de production réside, bien entendu, dans l'élaboration de normes appropriées qui non seulement permettent l'interopérabilité d'équipements de fabricants différents, mais génèrent aussi les volumes nécessaires en restreignant le nombre d'options — ce qui constitue précisément la raison d'être du projet IEEE 802.

Les critiques de la presse et la confusion indéniable entourant les normes LAN causèrent des désagréments à bien d'autres personnes que Graube et le comité 802. Bell, de chez DEC, se souvient de réunions houleuses où il fallait justifier l'engagement de l'entreprise dans la bataille pour une norme CSMA/CD :
Je disais : « Écoutez, il nous faut cette norme. Ce n'est qu'un câble pour relier tous ces appareils. Rien de bien compliqué. » Pendant ce temps, la presse criait au scandale. Je répétais : « Il ne se passe rien de grave ici. C'est anodin. Je ne sais pas si tout cela aura un jour de l'importance, mais nous avons besoin de connecter les machines entre elles. » Le comité des opérations ne cessait de demander : « Pourquoi offrons-nous cela au monde entier ? » Je répondais : « Un instant. Nous n'offrons rien au monde. Nous n'avons pas de protocole, et nous ne détenons pas non plus le brevet, ni pour le CSMA/CD ni pour la topologie en anneau. »

En mars 1982, le comité 802 se réunit à nouveau pour tenter de débloquer la situation... ...l'achèvement du projet C.55. Quatre présentations techniques effectuées par des collaborateurs d'IBM ont permis de clarifier la vision de l'entreprise concernant la technologie *token ring* et de fournir les données nécessaires à l'élaboration d'une norme : un premier blocage était ainsi levé. Parallèlement, les initiatives de l'ECMA ont donné une impulsion à la création d'une norme CSMA/CD proche du « Livre bleu » (*Blue Book*), à l'opposé de ce qui avait été décidé en février. Beaucoup, dont Donan, ont perçu les actions de l'ECMA comme une manœuvre de contournement du comité 802, visant à imposer la conformité à sa propre version de l'Ethernet — essentiellement celle du « Livre bleu ». Cette stratégie a porté ses fruits. Le comité 802 a alors agi pour préserver sa légitimité institutionnelle et a modifié sa norme afin de l'aligner sur la proposition de l'ECMA.
Graube se souvient de la réaction de l'IEEE 802 : Ils ont tout simplement pris leur parti de la situation et se sont dit : « D'accord, rallions-nous à la position de l'ECMA » ; c'est ce type de technologie qui a été intégré à la norme IEEE 802.3. C'est essentiellement le résultat de ce processus visant à concilier ces différents points de vue. À mon avis, nous avons fait des choses qui auraient pu être réalisées différemment, ou mieux. Bien sûr, je suis ingénieur, donc je ne sais pas ce qui est « mieux », mais certaines décisions relevaient du compromis.

Alors même que le comité 802 peinait à aboutir à un projet C, Graube et Rosenthal se sont concertés, désireux de mettre fin aux tergiversations du comité. Ils ont été influencés par les suggestions accompagnant de nombreux votes de catégorie B, qui préconisaient l'approbation de trois, voire quatre normes (d'où la disposition de Graube à accepter les propositions de normes de février). Rosenthal se souvient de la conversation au cours de laquelle ils ont admis l'inévitabilité de trois normes : CSMA/CD, *token bus* et *token ring* : Maris et moi avons eu de longues conversations sur la manière de nous débarrasser des problèmes de personnalité et de nous concentrer davantage sur une organisation et une structure qui soutiendraient des résultats dont nous serions fiers, plutôt que sur des conflits internes. Nous avons donc dû nous débarrasser de cette ancienne structure. Nous devions mettre en place une infrastructure propice à la réalisation de choses concrètes. En fait, je me souviens que c'était une nuit froide et venteuse à Minneapolis lorsque nous avons fait cela. Nous faisions juste le tour du lac et nous avons trouvé comment faire cela. Nous avons demandé à John Riganetti, chef de division au NBS et qui était très proche des gens de New York qui étaient les acteurs de l'IEEE, de nous aider à orchestrer ce nouveau changement que nous voulions mettre en place dans 802. Il nous a appris comment faire cela, nous a vraiment aidé à le faire, et nous l'avons fait avec beaucoup de succès.

Graube se souvient des défis liés à la restructuration de l'IEEE 802 pour refléter trois normes : Je me souviens d'avoir eu des discussions à cœur ouvert avec certains des opposants à ce système particulier de fonctionnement, parce qu'ils perdaient leur emploi de présidents de ces groupes, ce qui n'était pas quelque chose qu'ils aimaient faire, et il n'était pas facile pour moi de les priver de leurs droits, mais c'était quelque chose qu'il fallait faire.

La probabilité que les normes créées par IBM et DIX renforcent son courage et sa logique. En juin, par exemple, l'ECMA a ratifié une norme LAN très proche de la proposition DIX par 13 voix contre 2, y compris le vote affirmatif d'IBM. (IBM a voté pour un CSMA/CD de type DIX avec l'accord tacite qu'il recevrait un support similaire pour sa norme LAN une fois annoncé - une date non encore fixée.)
Le même mois, DEC a annoncé publiquement son intention de fournir des produits Ethernet compatibles avec le Livre Bleu. En juillet 1982, 19 Les entreprises ont annoncé leur soutien public à la norme ECMA CSMA/CD. La presse a également fait état d’annonces de puces semi-conductrices Ethernet, ou de rumeurs, d’Intel, Seeq, Ungermann-Bass, Advanced Micro Devices et Mostek.
L’effort en coulisses pour réorganiser le Comité 802 s’est avéré opportun, car la normalisation de facto d’Ethernet remettait à nouveau en question le rôle et l’autorité du Comité 802. Lors de la réunion d'août, les résultats du vote sur le projet C ont été rapportés. CSMA/CD a obtenu une majorité des trois quarts supérieure à celle requise, tout comme Token Bus. Token Ring s'en est approché, à 73 pour cent, mais il a fallu un autre vote pour être adopté. DIX a ensuite proposé de se réorganiser en trois efforts d'élaboration de normes : CSMA/CD, token bus et token ring. Chacune des trois normes partagerait un protocole de couche liaison commun, bien que la définition diffère de celle créée au sein de l'OSI. De plus, les trois sous-comités des normes agiraient de manière indépendante. Loughry se souvient : Nous avons alors tenu des propos tels que : « L'assemblée plénière n'est plus une instance décisionnelle. » Auparavant, nous organisions des votes en séance plénière, où les deux cents participants tentaient de se prononcer sur diverses questions ; or, il est impossible d'obtenir un vote éclairé au sein d'une assemblée nombreuse qui ne se réunit que quelques heures au début et à la fin de la session. Ainsi, la plénière servait essentiellement à diffuser des informations et à faire le point sur l'avancement des travaux ; les votes proprement dits avaient lieu au sein des différents comités, tandis que le comité exécutif validait ou rejetait les propositions des groupes de travail. Il existait donc une obligation de rendre compte à une instance supérieure, mais tout membre du groupe 802 pouvait contester les décisions des présidents de groupes de travail ou du comité exécutif. Nous avions mis en place les mécanismes propres à tout processus démocratique normal et raisonnable.

Les nouveaux sous-comités furent établis comme suit : couche de liaison (802.2), CSMA/CD (802.3), Token Bus (802.4) et Token Ring (802.5). Loughry prit la présidence du groupe 802.3, Donnan celle du 802.5, et Dave Carlson (d'AT&T) celle du 802.2. Plusieurs présidents se succédèrent à la tête du groupe 802.4. Parallèlement à cette réorganisation, il fut décidé de soumettre à nouveau les trois normes à un vote, dans l'espoir d'améliorer leur taux d'acceptation (le vote ne portait toutefois que sur les modifications proposées).
C'est alors qu'un événement inattendu survint : Olaf Soderblom, un citoyen suédois, annonça qu'il détenait un brevet américain, délivré en 1980, pour un système de réseau à passage de jeton (*token-passing*) couvrant la technologie Token Ring alors à l'étude. En fait, IBM lui avait déjà versé 5 millions de dollars pour obtenir une licence illimitée en vue d'une utilisation future. Si les discussions précédentes sur le Token Ring avaient déjà été assombries par l'incertitude, l'annonce de Soderblom vint jeter un voile sombre sur l'avenir de cette technologie.
En novembre 1982, le consortium DIX publia la version 2.0 de son Ethernet « Blue Book », intégrant les modifications issues de longs mois de négociations avec le comité 802 et l'ECMA. Il s'alignait alors essentiellement sur le projet D du comité 802. En décembre, lors de la réunion organisée chez DEC, le comité 802 a transmis sa recommandation CSMA/CD — la norme 802.3 — au comité IEEE TCCC pour approbation. Toutefois, les technologies « token bus » et « token ring » nécessitaient encore des travaux supplémentaires.
Tout comme l'ECMA avait fait pression sur le comité 802 pour normaliser un protocole CSMA/CD similaire à celui du « Blue Book », la volonté d'achever la norme 802.3, conjuguée à la disponibilité de TCP/IP et de XNS, a exercé de nouvelles pressions sur l'OSI pour qu'il adopte rapidement des normes de protocoles pour réseaux locaux (LAN).

11.10 ISO/OSI (Interconnexion de systèmes ouverts) : 1982-1983

Durant l'été 1982, Graube et Rosenthal commencèrent à se concentrer sur ce qu'ils considéraient comme le prochain défi des réseaux locaux : les protocoles de couche supérieure. Tous deux partageaient des inquiétudes quant à la rapidité de développement des logiciels de couche supérieure, notamment la couche transport, indispensable à des communications fiables de bout en bout sur un réseau. Graube se souvient avoir réfléchi après qu'il soit devenu évident qu'au moins une norme LAN, CSMA/CD, serait adoptée : « Que faire pour ces protocoles de couche supérieure ? » C’était exactement comme pour la norme 488 : nous avions le mécanisme de transport, mais les instruments ne pouvaient toujours pas communiquer faute de format de données spécifié. Je voulais donc voir comment parvenir à des accords concernant ces protocoles de couche supérieure ; ce qui était réellement nécessaire.

Rosenthal reconnaissait également la nécessité de tester les protocoles que chaque fournisseur allait créer. Une norme OSI, bien que nécessaire, ne suffisait pas à garantir la compatibilité des produits LAN commerciaux. Les spécifications des normes pouvaient être mises en œuvre d'une infinité de manières, d'où la quasi-certitude d'implémentations incompatibles. Pour résoudre ce problème, Rosenthal envisageait le recours à des accords – des contrats – entre les organisations afin de mettre en œuvre des versions compatibles des normes de protocoles de transport. Mais comment parvenir à cet accord ? Rosenthal se souvient : Pour y parvenir, il nous fallait obtenir des accords. Le mot clé, c'est « accords ». Il nous fallait convaincre les plus hauts responsables de ces organisations de s'engager financièrement. Il nous fallait l'engagement des PDG, quelqu'un ayant le pouvoir de signature, capable de dire : « Voici le chèque, à vous de jouer. Faites tout votre possible. L'OSI est important. Il faut que ça marche. » Il fallait que les techniciens se demandent : « Faire en sorte que quoi se produise ? » Nous devions leur dire : « Faites en sorte que cela se produise », et leur expliquer clairement la situation.

Parmi les PDG ayant répondu à l'invitation de NBS à assister à une réunion figurait Roger Smith de General Motors (GM). GM avait constitué un groupe de travail en 1980 afin d'étudier la possibilité d'utiliser l'automatisation informatique pour contrer la concurrence croissante des entreprises produisant dans des pays à faible coût de main-d'œuvre. En 1981, GM a entamé des discussions exploratoires avec IBM, DEC et HP. Ces efforts ont abouti à la publication, en 1982, de la version 1.0 du protocole d'automatisation de la production (MAP) de GM. Le MAP fonctionnant sur les réseaux locaux interconnectant les équipements d'automatisation, GM était impatient d'entendre l'avis de NBS.

Après la réunion IEEE 802 qui s'est tenue au DEC en décembre 1982, Graube a réuni une poignée d'experts concernés afin de discuter de la création d'un logiciel de couche transport OSI. Des représentants d'environ six entreprises, ainsi que Rosenthal et Graube, étaient présents. Malgré leurs inquiétudes, personne ne savait précisément comment procéder et la réunion n'a abouti à rien avant que Graube ne remette son compte-rendu à Tektronix peu après. Graube se souvient : Le coup de tonnerre a frappé, porté par les avocats, via mon patron, jusqu'à moi, et paf ! « Tu ne referas plus jamais de telles choses ! »

Les avocats de Tektronix avaient récemment traité avec le Département du Commerce d'une autre question de normes, et des problèmes de concurrence avaient été soulevés. Les questions de normes entravant le commerce et de pratiques monopolistiques avaient refroidi l'enthousiasme des avocats de Tektronix quant à l'idée que des entreprises puissent se réunir, secrètement ou non, pour discuter et élaborer des normes.

Graube se souvient avoir dit à Rosenthal : « Eh bien, je me suis fait remonter les bretelles pour notre petite réunion à Tewksbury », dit Robbie. « Pas de souci. On organise régulièrement des ateliers au NBS sur divers sujets. Pourquoi ne pas en organiser un sur les responsables de la mise en œuvre des réseaux locaux ? » C’est comme ça que tout a commencé. Ça fonctionne bien car le Bureau national des normes dépend du ministère du Commerce, où se trouve également la division antitrust.

En février 1983 se tint le premier atelier international NBS destiné aux implémenteurs du modèle OSI. Graube, considéré comme le principal instigateur, fut élu président. Les discussions s'orientèrent rapidement vers les difficultés rencontrées pour garantir la compatibilité des implémentations et sur l'importance de favoriser la coopération. À l'instar de Roberts et Kahn qui, en 1972, avaient organisé une démonstration publique d'Arpanet au salon ICCC, les participants aux ateliers NBS sur le modèle OSI parvinrent à la même conclusion : une démonstration publique était nécessaire pour encourager la coopération. Conscients du temps que cela prendrait, ils optèrent pour le plus grand salon informatique au monde, la National Computer Conference (NCC), qui se tint en juillet 1984.

Le conflit entre les intérêts des réseaux locaux et les préoccupations antitrust s'est manifesté ailleurs lorsque, en février, IBM a proposé d'acquérir 12 % d'Intel pour 250 millions de dollars, ce qui a suscité des réserves de la part du ministère de la Justice et de la Commission fédérale du commerce. IBM a déclaré publiquement que son investissement visait à garantir à Intel, un important fabricant américain de semi-conducteurs et fournisseur du microprocesseur utilisé dans l'IBM PC, les capitaux nécessaires pour rester compétitif face aux fabricants japonais de semi-conducteurs, très agressifs. (IBM représentait 13 % du chiffre d'affaires d'Intel.) Mais IBM cherchait-elle à diversifier ses investissements dans les réseaux locaux ?

En mai 1983, l'ISO a officiellement approuvé la norme de référence : ISO 7498. Un addendum à cette norme, portant sur la transmission sans connexion, était déjà en cours d'élaboration. Le SC6, qui s'était concentré sur la création d'un protocole de couche réseau orienté connexion (8348) destiné à être soumis comme DP, a commencé à travailler sur un addendum relatif à la transmission sans connexion à la norme 8348.

À l'été 1983, l'ISO avait normalisé le modèle de référence et approuvé un protocole de transport sans connexion. Elle n'avait pas encore tranché concernant les protocoles LAN développés au sein de l'IEEE et pris en charge par l'ECMA, ni concernant un protocole de couche réseau sans connexion. Néanmoins, la perspective de normes mettant fin à la confusion autour des réseaux locaux semblait presque tangible.

11.12 En perspective

À la fin de l'année 1984, le long processus d'élaboration des normes pour les réseaux locaux (LAN) — entamé en mars 1978 lors de la première réunion du comité ISO/TC97/SC16 — aboutissait avec succès, tandis que la croissance du marché des LAN s'accélérait.
Les règles du jeu étant désormais établies, il restait à voir quelles entreprises sauraient le mieux tirer leur épingle du jeu.
L'avenir des LAN ne dépendrait plus de compromis, d'accords ou de votes, mais bien de l'offre de produits, des prix et de la disponibilité.

Ces nouvelles règles intégraient des protocoles sans connexion (ou protocoles de datagrammes) que le puissant CCITT avait pourtant rejetés ; la nécessité technologique et les initiatives individuelles avaient fini par l'emporter sur la puissance des acteurs bien établis.

Il est désormais temps de revenir à cette journée décisive d'août 1981 où IBM lança le PC, observant alors l'intense concurrence entre les entreprises des secteurs de l'informatique, des télécommunications, de la transmission de données et des réseaux locaux, ainsi que l'émergence du marché des réseaux.

Chapitre 12