Suite à la démonstration probante, à la conférence ICCC de 1972, d'ARPANET, le marché naissant du réseau allait pouvoir se développer. En parallèle, différents projets, au États-Unis, se sont mis en place, par exemple pour faire passer des paquets du réseau ARPANET vers le réseau radio ALOHAnet. Comme il s'agit de radio, les concepteurs ont dû s'intéresser à des problématiques d'accusé de réception. Le mécanisme d'accusé de réception était utilisé pour détecter et corriger les collisions créées lorsque deux machines clientes tentaient toutes deux d'envoyer un paquet en même temps. Ensuite, le protocole d'ARPANET (Network Control Protocol ou NCP) ne présentait pas de mécanisme de correction d'erreur end-to-end ou Host-to-Host. Avec ce protocole, il y avait bien un mécanisme de correction d'erreurs entre IMPs, mais pas en Hosts et IMPs.
Donc, très rapidement, Robert Kahn et Vint Cerf prirent conscience qu'il fallait développer un nouveau protocole : TCP (Transmission Control Program), ce qui fut fait à partir de 1973, pour traiter les deux problèmes que nous venons d'évoquer. Ainsi, TCP doit être vu comme un éclairage entièrement nouveau du protocole NCP.
En France, Louis Pouzin, après des rencontres et des voyages aux États-Unis, chercha à définir un protocole orienté "packet switching" plus simple qu'ARPANET. Comme les PTT avaient le monopole de la transmission électronique, il a imaginé différentes manières de se superposer au réseau des PTT, et pas de le remplacer, en examinant plus particulièrement les réseaux MERIT, TYMNET, TELENET. Toute cette période est racontée dans une interview datée de 1988.
Dans le réseau CYCLADES proposé par Louis Pouzin, l'idée majeure est que les HOSTS pouvaient envoyer directement leurs datagrammes à d'autres Hosts, avec une correction d'erreurs. Pouzin savait très bien que sur le réseau de communication des PTT on ne pouvait pas ordonner les paquets ni faire de la détection d'erreur. Il a donc contribué à l'idée que ce sont les ordinateurs communiquants qui doivent assurer ces propriétés (via un protocole) et pas le support physique.
Le premier article de Kahn et Cerf sur TCP est une publication intitulée A protocol for packet network intercommunication, publié en mai 1974. Dans cet article, la proposition d'interconnexion de différents réseaux et de "gateways" est faite. Une des formes de transformation assurée par les "gateways" est la conversion d'un protocole vers un autre. Une autre transformation est la fragmentation de paquets en plus petits paquets. C'est seulement le "Host" qui reçoit qui est informé que la gateway a fragmenté les paquets, et ceci afin de reconstruire le « gros » paquet initial.
Pouzin et les européens font immédiatement remarquer que cette proposition implique que ce sont les "Hosts" qui doivent corriger les erreurs introduites par les opérateurs de réseaux (les gateways relient deux réseaux d'opérateurs). Pour Pouzin, cela veut dire qu'on l'on donne la main et le contrôle aux PTT. Pouzin préfère qu'il n'y ait pas de couplage de la sorte et, comme on l'a dit plus haut, souhaiterait une gestion des erreurs de "Host" à "Host", sans intermédiaire. Il pense de plus que sa proposition est meilleure pour les performances car on court-circuite les intermédiaires. Cependant, dès novembre 1974, le CCITT (l'agence des Nations unies pour le développement spécialisé dans les technologies de l'information et de la communication, basée à Genève -- ITU de nos jours) annonça l'arrivée d'une interface standard dans la communication de paquets appelée X.25.
Cerf, de son côté, proposa une version remaniée de TCP pour se passer des contraintes fortes liées à la fragmentation, en passant par un mécanisme de fenêtrage. Pouzin argumenta que c'était un peu de la bidouille... mais rien n'y fit. Les idées de Pouzin (des datagrammes et que des datagrammes) ne triomphèrent pas, X.25 vécu sa vie un moment, avant d'être supplémenté par TCP. C'est quand même la notion de circuit virtuel qui l'emporte, mais pas celle purement basée sur les datagrammes de Pouzin.
Les services de circuits virtuels (CV) de X.25 et de TCP sont essentiellement équivalents (mais avec des formats d'adresses moins contraints dans le cas de X.25 car ils ne sont pas contraints par ceux des adresses de datagrammes IP). Tous deux permettent des transmissions bidirectionnelles de suites d'octets avec garantie de bonne livraison. Pour cela, les récepteurs et le réseau exercent un contrôle de flux sur les émetteurs, et des retransmissions automatiques sont mises en œuvre là où les taux de perte ou de corruption sont non négligeables. Si, à la suite d'un incident irrécupérable dans le réseau ou chez un utilisateur, la garantie de livraison ne peut plus être assurée, les CV concernés sont automatiquement réinitialisés ou terminés.
Nous passons en revue maintenant deux exemples de protocole réseau pour réaliser réseau local.
En 1973 apparu le réseau Token Ring, une idée de réseau de communication poussée par David Farber qui avait plutôt comme objectif de faire communiquer des stations de travail entre elles sur du réseau local plutôt que les machines sur un réseaux longue distance.
Le principe du protocole Token Ring, tel qu'il est décrit à la Figure 1, est simple a comprendre. Les ordinateurs sont organisés selon un anneau et ils ont le droit d'émettre quand il reçoivent un jeton. Sinon, les machines sont à l'écoute de ce qui se passe sur le réseau local. Il n'y a donc pas de risque de collisions.
Le fait d'éviter le temps perdu en « collisions » devait rendre le token-ring 16 Mbit/s cinq fois plus rapide que l'Ethernet (10 Mbit/s à l'époque) ; considération importante pour la sauvegarde nocturne des stations de travail.
Sur l'idée de réseau en anneau, en 1974, Edsger W. Dijkstra publie un article intitulé Self-stabilizing systems in spite of distributed control. Cet article introduit la notion théorique d'auto-stabilisation qui est une brique fondamentale parmi les techniques de la tolérance aux pannes. L'article présente trois algorithmes auto-stabilisants basés sur le concept d'anneau à jeton. Le principe de l'anneau à jeton est ici de résoudre le problème de l'exclusion mutuelle en faisant circuler un jeton, qui représente le droit pour le seul processus qui le possède d'effectuer une action qui poserait problème si plusieurs processus l'effectuaient en même temps, par exemple envoyer du texte à une imprimante. Il y a ici une nécessité de synchronisation.
L'exercice consiste à lire et comprendre cet article fondateur en refaisant et en détaillant les exemples qui sont proposés, ceci afin de vous approprier le texte.
Note : pour plus de détails sur le concept de synchronisation, d'un point de vue Système, vous pouvez lire ces notes de cours à l'université de Sherbrooke au Canada.
L'histoire personnelle de Robert Metcalfe, le père d'Ethernet est intéressante à plus d'un titre. Un lisant le lien précédent, on apprend qu'une première demande pour passer sa thèse a été refusée. bob Metcalfe a dû alors retravailler les concepts, dont celui d'"ether", c'est à dire de médium de communication qui propage simultanément l'information à toutes les stations de travail, lui permettant de soumettre sa thèse en juin 1973.
Les idées d'Ethernet sont présentées dans l'article intitulé Ethernet: Distributed Packet Switching for Local Computer Networks que nous vous invitons à lire immédiatement. Vous expliciterez en particulier pourquoi le terme Distributed est présent dans le titre et vous en ferez un résumé de deux pages maximum. Ce sont les idées clés qu'il faut faire ressortir, pas les détails !
Lire et comprendre l'énoncer et la correction de l'exercice suivant qui porte sur du codage et décodage de trames Ethernet.
A partir de la ressource en ligne suivante, explicitez les schémas qui vous sont présentés pour la méthode d'accès. Le but de cet exercice est de vous approprier le texte, donc de construire un discours qui accompagnera chaque figure, voire à ajouter des figures intermédiaires pour expliciter l'évolution du système. Veuillez construire des explications avec un sujet, un verbe et un complément. Merci.
Bob Metcalfe a reçu le Turing Award en 2022. A cette occasion, il a donné une conférence. Faites un résumé de la vidéo, sur une demie page, afin de faire ressortir ses contributions scientifiques et techniques, telles qu'il nous les présente.
En 1976, la DARPA fit circuler la version 2 de TCP. L'introduction de ce document nous résume les avancées proposées dans cette version. Devant la complexité grandissante du protocole, nous devinons d'intenses discussions pour aller dans telle ou telle autre direction. Nous devinons également une multiplication de systèmes et de réseaux, notamment de réseaux locaux. Pour s'accommoder de la multiplicité des réseaux, il est apparu qu'il fallait dorénavant séparer les protocoles de communications en deux niveaux. Le niveau du bas fournir les fonctions de base pour délivrer un message à des destinations variées (le niveau transport) alors que le niveau supérieur est destiné aux différentes variétés de protocoles (le niveau network). Ce point de vue est documenté dans l'article An introduction to local area networks de Clark, Pogran et Reed, publié en 1978.
L'argumentaire des auteurs est ici :
A two-layer structure is a very natural one for low-level protocols in a local area network. The bottom layer should provide the basic function of delivering an addressed message to its (one of many) destinations. This level corresponds to the concept of a datagram network… Above this first layer should be made available a variety of protocols. One protocol should support a virtual circuit mechanism, since a virtual circuit is definitely the appropriate model for a great deal of the communication that will go on in any network, local or otherwise.
Pour chacune des topologies réseaux évoquées dans l'article, faites un inventaire de leurs forces et de leurs faiblesses. Vous pouvez constituer un tableau comparatif.
Faites un commentaire de la Table 5 de l'article en détaillant le problème et la solution technique.
Faites un commentaire de la Figure 9 de l'article en détaillant le problème et la solution technique.
Faites un résumé de la notion de "bridge" telle qu'elle est introduite dans l'article à partir de la page 1514.
La version 4 de TCP reprend les principes de séparation. La figure 2 reprend les éléments historiques de cette version qui a été largement déployée. Les éléments historiques sont jalonnés par des RFC que vous pouvez consulter également. Ces nouveaux protocoles organisés en couches sont aussi connus sous le nom de Internet Protocols (IP = Interconnected Protocols)
Jon Postel décrit succinctement cette organisation dans un article intitulé The ARPA internet protocol. On y lit :
In summary, the ARPA Internet Protocol (TCP/IP) supports delivery of datagrams from an internet source to a single internet destination. IP treats each datagram as an independent entity unrelated to any other datagram. There are not connections or logical circuits (virtual or otherwise). There are no acknowledgments either end-to-end or hop-to-hop. There is no error control for data, only a header checksum. There are no retransmissions. There is minimal flow control. For flexibility, it is explicitly left to higher level protocols to provide these functions.
En 1975, les membres européens du groupe de travail 6.1 de l’IFIP ont conclu à contrecœur que les Américains étaient déterminés à s’engager dans la voie de TCP. Plus important encore, la stratégie des Européens visant à influencer l'organisme CCITT (ancêtre de l'ITU) avait échoué : le CCITT allait clairement créer X.25, un protocole de circuit virtuel et un standard de réseau, façon PTT. Cependant, la norme X.25 laisse les utilisateurs d'ordinateurs sans protocole de bout en bout. Frustrés, mais non sans combativité, ils (Hubert Zimmerman en tête) se sont regroupés et ont contacté l'organisation internationale de normalisation (ISO) pour défendre leurs arguments en faveur de normes de communication de bout en bout, ou d'hôte à hôte. L'ISO, la seule organisation internationale de normalisation aussi puissante que le CCITT, était organisée sous la forme d'une série de comités techniques dotés de sous-comités spécialisés. Les normes relatives au traitement et à la communication des données relèvent du Comité technique 97 (TC 97). Au sein du TC 97, le sous-comité 6 (SC 6) était responsable des normes de communication de données et était le siège logique des membres du groupe de travail 6.1 de l'IFIP. Hubert Zimmerman, haut responsable de la délégation française et de l'IFIP, rappelle les choses suivantes :
We approached Subcommittee 6, explained what we were doing and requested their requirements for going forward with a communication standard for host-to-host communications, or data processing oriented communications standards. There was a low level of acceptance of the message at that time. We were accepted as people, but the ideas did not really get through!
We worked with Subcommittee 6 on the definition of the HDLC. That was the time when HDLC was just getting out of the oven after ten years of hard work. Now, there was a fair amount of politics in this, and HDLC had been blocked for some time. Until IBM got SDLC through, HDLC couldn’t get through. There was a lot of politics, and we were probably not good enough politicians at that time.
A cette époque, les liens entre les organisations de normalisation étaient ceux décrits à la Figure 3... et la question est de savoir qui contrôlait L'ISO ?
Après avoir lu la spécification du protocole HDLC, faites les exercices 4 et 5 de cette feuille d'exercices. Attention, il faudra peut-être envisager de préciser certaines hypothèses qui sont implicites et pas explicites dans la feuille de TD. A vous de voir.
Même exercice que précédemment mais avec cette feuille d'exercices.
Le SC 16 s'est réuni pour la première fois à Washington D.C. en mars 1978. Après avoir réglé les questions d'organisation nécessaires au bon déroulé des échanges, chaque pays a présenté sa position. Chacun a appelé à une architecture de protocole multicouche. Compte tenu de l'accord unanime, les protagonistes ont ensuite créé quatre groupes de travail pour répartir le travail de création de normes. (Voir Table 1).
| Working Group | Responsibilities | Chairman | Country of Chair |
|---|---|---|---|
| WG 1 | Overall Architecture | Hubert Zimmerman | France |
| WG 2 | Layers up through Transport | George White | US |
| WG 3 | Upper Layers | Alwin Langsford | UK |
| WG 4 | Network Management | Kenji Naimura | JAPAN |
En octobre 1978, le SC 16 s'est réuni à Paris pour résoudre les modifications demandées au modèle de référence et finaliser une deuxième version. Et au final, la publication suivante fait référence au modèle en sept couches que nous connaissons : Hubert Zimmerman, “OSI Reference Model - The ISO Model of Architecture for Open Systems Interconnection,” IEEE Transactions on Communications, Vol. Com-28, No. 4, April 1980, pp. 424-432. Cet article est à lire et relire.
Les septs couches sont rappelées à la Table 2.
| Layer | Name | Function |
|---|---|---|
| 7 | Application | Selects appropriate service for application |
| 6 | Presentation | Provides code conversion, data reformatting |
| 5 | Session | Coordinates interaction between application processes |
| 4 | Transport | Provides for end-to-end data integrity and quality of service |
| 3 | Network | Switches and routes information |
| 2 | Data | Transfers unit of information to other end of physical link |
| 1 | Physical | Transmits bitstream to medium |
La naissance du Modèle de Référence OSI a bénéficié de toutes les connaissances accumulées lors de la création de protocoles de communication depuis NCP et ARPANET. En segmentant les communications en couches logiques, des protocoles de bout en bout pourraient être assemblés en sélectionnant les protocoles appropriés de chaque couche pour refléter la diversité du réseau, tout en partageant autant de protocoles intermédiaires que possible pour réduire la complexité des protocoles. Le partage des protocoles signifiait également que le développement et les tests pouvaient être considérablement réduits. Le modèle de référence reconnaissait des couches de transport et de réseau distinctes, le SC 16 devenant responsable des quatre couches supérieures, et le SC 6 conservant la responsabilité des trois couches inférieures. Par conséquent, la coordination essentielle entre les couches transport et réseau reposait sur deux comités, une séparation structurelle qui poserait des problèmes futurs.
Lire les documents de IUT en ligne à propos du modèle OSI, et pour chaque planche, donnez la (les) page(s) où la notion présentée se retrouve dans l'article de Zimmerman. Justifiez votre réponse.
Lire tout simplement les pages suivantes/ pour apprendre ce que le monde industriel et les entrepreneurs faisaient à cette époque, ainsi que ces pages.
Christophe Cérin