Passerelles, architectures, et féhélambes

Résumé

La croissance des réseaux informatiques autonomes a conduit au désir, de la part de leurs propriétaires respectifs de "faire des passerelles" de l'un à l'autre. Malheureusement cependant, les implications et les insuffisances des passerelles qui doivent traduire ou transposer entre les différentes suites de protocoles ne sont pas très bien comprises. Certains ensembles de protocoles ont de si sévères disfonctionnements que des T/MG (Media Gateway, passerelle de supports) appropriés ne peuvent pas être générés pour eux ; toutes les tentatives de maillage de suites hétérogènes se heurtent à de nombreux problèmes, dont celui de l'introduction de "points de singularité" sur des connexions logiques qui seraient autrement capables de jouir des avantages de l'acheminement des communications sur des sous-réseaux de remplacement, de perte de fonctionnalités, des difficultés de la résolution du contrôle de flux, de coûts plus élevés que celui des passerelle qui ne font pas de traduction/transposition, et de la nécessité de recréer des T/MG lorsque change une suite donnée. La préférabilité d'un internet aux protocoles compatibles est aussi en cause, comme l'est la psychologie de ces soi-disant architectes qui ont inventé les T/MG.

Dans notre zèle collectif à rester (ou nous mettre) au courant de l'état de l'art, nous tombons parfois dans l'une ou l'autre (ou l'une et l'autre) d'une paire d'ornières. Une seule de ces ornières est particulièrement bien connue : les "mots à la mode" – et même là, de simplement connaître le nom ne donne pas nécessairement une idée spontanée de ce qu'il recouvre. L'autre mérite un peu plus d'attention : une familiarité inadéquate avec la littérature pertinente.

La clé est la notion de ce qui est réellement pertinent. Souvent, c'est la tradition orale qui importe, les articles publiés, dans leurs efforts pour paraître pédagogiques, présentent les mauvais niveaux d'abstraction ou, parce que la formation de leurs auteurs a subi de si graves lacunes qu'ils ne réussissent pas à bien communiquer. Parfois cependant, ce qui est authentiquement pertinent reste introuvable par une recherche de littérature conventionnelle parce que cela ne se trouve pas "dans le champ" de la recherche.

J'ai rencontré récemment un cas instructif à ce propos quand il m'a fallu plus d'une heure pour convaincre un néophyte (qui est très bien considéré dans au moins un des autres domaines de la science informatique, et n'est en aucun cas un demeuré) des mystères de l'inter réseautage informatique et en particulier qu'une proposition d'architecture de réseau de zone locale qui faisait appel en passant à la notion de "passerelle" vers trois ou quatre autres réseaux avec lesquels il n'avait pas de protocoles en commun était une très mauvaise chose. "Passerelle" est, bien sûr, un autre de ces fichus mots à la mode, et dans certains contextes, il pourrait être suffisant de l'étiqueter comme cela. Mais c'était une conversation avec un brillant professionnel qui avait récemment lu quelque chose sur les réseaux et qui voulait réellement comprendre ce qui était si problématique.

J'ai donc commencé par faire appel à la tradition orale, soulignant que dans la communauté reine de la recherche inter réseautage de l'ARPA (d'où est probablement sorti pour la première fois le terme de "passerelle" – et d'où provient avec certitude la preuve du concept des internets) il avait été explicitement décidé qu'il serait trop difficile de traiter la connexion de réseaux autonomes dont les ensembles de protocole différaient "au-dessus" du niveau du protocole de processus d'hôte à sous-réseau de communications. C'est à dire, de la sorte de passerelle qu'on sait construire -- et, bien sûr, tout ce qu'on appelle une passerelle – rattache deux (ou plus) sous-réseaux communs comme si ils étaient un hôte sur chacun d'eux, en interprétant de la façon appropriée leurs protocoles H-CSNP respectifs et en faisant les bonnes choses sur le matériel (voir la Figure 1) mais pour les passerelles de l'ARPA Internet, chaque réseau rattaché est supposé avoir le même protocole d'hôte à hôte (TCP/IP, en fait de toutes façons, IP et TCP ou quelque autre protocole commun aux deux réseaux au dessus de IP) et le même protocole de niveau traitement (par exemple, Telnet, FTP, etc.). La raison de cette supposition d'ensemble de protocoles homogènes est qu'ils "savaient" que l'alternative était indésirable, parce qu'elle impliquait la traduction ou la transposition entre des ensembles de protocoles différente dans la passerelle et que de tels T/MG devaient à l'évidence être évités.

Mais cela ne suffisait pas à le convaincre. "Pourquoi un T/MG est-il une si mauvaise chose ?" disait-il. "Parce qu'il donne la possibilité de discordances irréconciliables dans les fonctionnalités". "Par exemple ?" "L'adressage est le plus couramment cité". "Adressage ?"

En supposant que le lecteur est tout aussi ennuyé que moi par ce morceau de dialogue, je vais essayer de rentrer dans le vif du sujet afin d'être plus précis sur les sortes d'incompatibilités qu'on peut trouver entre des ensembles de protocoles d'une façon un peu moins théâtrale. Noter que les prémices de tout cela sont que nous ne voulons changer aucun des ensembles de protocoles préexistants. Supposons pour la forme que nous essayons d'attacher simplement deux réseaux ensemble avec un T/MG, et supposons de plus que l'un des réseaux utilise le "NCP" original de l'ARPANET qui consiste, strictement parlant, en le protocole original ARPANET d'hôte à hôte sans nom et du bien mal nommé "1822", ou du protocole ARPANET d'hôte à IMP – et que l'autre utilise TCP/IP.

L'adressage des hôtes est le problème le plus significatif. Les hôtes qui utilisent NCP ont des adresses "unidimensionnelles". C'est à dire qu'il y a un champ dans l'en-tête hôte - IMP où vient le numéro de l'hôte. Lorsque vous avez alloué les valeurs disponibles de ce champ, votre réseau est plein, et cela jusqu'à ce que vous reveniez et changiez tous les IMP et tous les NCP pour qu'ils traitent un plus grand champ. D'un autre côté, en utilisant IP, les adresses des hôtes sont "bidimensionnelles". C'est à dire qu'il y a un champ d'en-tête IP dans lequel désigner le réseau étranger et un autre champ dans lequel désigner l'hôte étranger. (En fait, ce qui précède est délibérément une simplification exagérée.) De sorte que si vous voulez faire communiquer un hôte sur un réseau fondé sur NCP avec un hôte sur un autre réseau fondé sur TCP, vous allez passer un très mauvais moment si vous ne souhaitiez pas vous embourber à l'intérieur de toutes les différentes mises en œuvre NCP, parce que vous n'avez aucun moyen d'exprimer l'adresse étrangère au sein de votre complément actuel de mécanisme d'adressage.

Il y a plusieurs 'trucs" disponibles, bien sûr. Vous pouvez trouver assez de bits libres dans l'en tête hôte-IMP ou dans l'en-tête hôte-hôte peut-être, et mettre là l'adresse internet dont vous avez besoin. Ou vous pourriez changer le protocole de connexion initial, ou même faire que l'adresse internet soit la première chose transmise comme "données" par le côté utilisateur de chaque protocole de niveau traitement. Le défaut commun à toutes ces astuces est que vous changez les protocoles préexistants, quoique si cette sorte de chose était vue avec équanimité par les propriétaires de système, vous pourriez aussi bien aller jusqu'au bout et changer tout l'ensemble de nouveaux protocole de la console. D'accord, c'est un grand saut, mais il faut réaliser que ce n'est que le premier d'une série de problèmes.

(Le fait est qu'on peut résoudre le problème de l'adressage en faisant que le T/MG devienne plus clairement un hôte véritable et en faisant terminer le côté fondé sur NCP dans un programme d'application qui "demanderait" à l'utilisateur à quel hôte étranger il veut parler du côté fondé sur TCP – au moins pou les connexions Telnet. Lorsqu'il n'y a pas d'utilisateur à qui s'adresser, comme ce serait le cas dans la plupart des transferts de fichier, c'est encore perdu, sauf à jouer une berceuse à votre FTP. En général, cette sorte "d'hôte Janus" – d'après la divinité romaine à deux visages, qui était d'après certaines sources le dieu des passerelles (!) – ne confère de toutes façons que des fonctionnalités extrêmement limitées ; mais dans certains cas pratiques, cela peut être mieux que d'essayer une fonctionnalité complète et de revenir les mains vides.)

Ensuite, il y a la question de ce qu'il convient de faire des "Prêt pour le prochain message" (RFNM, Ready For Next Message). C'est à dire que les NCP suivent la discipline de l'attente que l'IMP étranger indique qu'un état Prêt pour le prochain message existe avant d'envoyer plus de données sur une connexion logique donnée, mais si vous êtes en train de dialoguer avec un T/MG, son IMP est celui dont vous allez obtenir le RFNM (l'hôte étranger réel peut même n'être pas rattaché à un IMP). Maintenant, j'ai réellement vu une proposition qui suggérait de résoudre ce problème en altérant l'IMP des T/MG pour différer les RFNM, mais je ne pense pas que ce soit une solution viable. Au minimum, le T/MG va devoir aller mettre une énorme quantité de données en mémoire tampon (voir la Figure 2). Dans un des pire cas possibles, le réseau étranger pourrait même ne pas vous faire savoir que votre dernière transmission est passée sans changer ses protocoles.

Au delà de l'exemple NCP-TCP, un sujet générique qui encourt un grave risque de discordance des fonctionnalités est celui du signal hors bande. (Il y en a qui disent que c'est aussi un problème NCP-TCP.) L'idée est que bien que "tout bon protocole d'hôte à hôte" devrait avoir un moyen de communiquer à côté des messages normaux "sur" les connexions logiques, la mécanisation et bien sûr la sémantique de tels signaux hors bande diffère souvent. On peut craindre que les différences conduisent à des incompatibilités. Par exemple, dans NCP, OOBS est une commande d'interruption "sur" la liaison de contrôle, alors que dans TCP c'est un bit Urgent dans l'en-tête d'un message "sur" la prise. Si vous voulez que Urgent soit utilisable afin d'avoir un "bouton d'abandon virtuel", la sémantique du protocole doit rendre très clair que Urgent n'est pas simplement la sorte de chose que le protocole d'hôte à hôte NBS/ECMA appelle "Données expédiées". Si, c'est à dire, si l'intention du mécanisme est de faire que le processus/tâche associé entreprenne une action particulière plutôt que de simplement interpréter le protocole associé (qui n'a pas besoin de faire partie du processus) vous feriez mieux de le dire – et aucun des protocole dérivés de l'ISO dont j'ai connaissance ne le fait encore. Et il n'y a pas grand chose que puisse faire un T/MG si il obtient une réponse NCP Interrupt sur une liaison de contrôle, remarque un code de contrôle Telnet Processus interrompu sur la prise associée et n'a rien d'autre qu'un Données en cours d'expédition à mettre en face. (Données en cours d'expédition, on peut le noter, présente une ressemblance frappante avec le fait de prendre le Concorde pour traverser l'Atlantique, pour se trouver devant un Bureau des douanes où personne n'est de service – et la porte de sortie est fermée de l'intérieur.)

Les fonctions discordantes ne sont bien sûr pas le privilège de protocoles d'hôte à hôte. La situation intéressante suivante a été observée à University College, Londres : Dans leur "passerelle terminale", qui traduit/transpose le Telnet ARPANET en "Triple X" (CCITT X.25, X.28, X.29) ils sont capables de faire passer les données au travers, comme on pouvait s'y attendre, mais avec une seule option (écho), ce qui est plutôt pire que ce à quoi on pouvait s'attendre. (Et les gens de UCL sont plutôt compétents, de sorte que le problème ne vient presque certainement pas de leur inexpérience.)

On pourrait objecter que le vrai problème avec Expedite Data et Triple X est que certains ensembles de protocoles sont bien pires que d'autres. Je ne vais pas rentrer dans cettediscussion. Mais il arrive toujours que pour paraphraser un grand auteur,

parfois, quand on essaye de changer une pomme en orange, on obtient un citron.

Pas plus qu'il n'est probable de rencontrer qu'une fonctionnalité insoluble ne dérange que le seul inconvénient des passerelles de traduction/transposition. Un problème assez subtil mais fascinant est soulevé si on se demande ce qui arrive lorsque le trafic est assez dense pour garantir plus d'un T/MG entre une paire donnée de réseaux à protocoles incompatibles (ou même si on voudrait ajouter un peu de fiabilité, sans considération du trafic). Ce qui arrive, si on y réfléchit un petit peu, est un grand problème. Supposons que vous trouviez réellement un moyen de traduire/transposer deux ensembles donnés de protocoles. Cela voudrait dire que pour chaque connexion logique que vous avez ouverte, vous allez avoir une abondance d'informations d'état sur elle pour chaque réseau dans lequel vous mènent les passerelles. Mais "vous" vous figurez maintenant comme un seul T/MG – et votre clone juste à côté n'a pas ces informations d'état, donc toute connexion logique qui a commencé sa vie avec vous doit passer le reste de sa vie avec vous, dans un état de monogamie perpétuelle, comme elle l'était. Naturellement, cette paire collée à l'époxy pourrait encore peut-être se régler avec un nouveau protocole entre les T/MG, mais il est parfaitement clair qu'il n'y aura pas d'analogie facile avec un divorce sans faute. C'est à dire, pour poser le problème de façon un peu moins métaphorique, il devient au mieux extrêmement complexe de faire la traduction/transposition sur plus d'un T/MG pour la même connexion logique. Comme avec la question plus large de la réconciliation d'ensembles donnés de protocoles, le faire en plusieurs endroits de contrôle peut se révéler faisable ou non en pratique et sera certainement une tâche délicate et complexe de conception.

Un problème de plus avec NCP/TCP : quand on envoie un message sur un réseau fondé sur NCP, le protocole de messagerie (en fait, le protocole de transfert de fichiers) utilise actuellement seulement le nom du destinataire, parce que l'hôte a été déterminé par le protocole d'hôte à hôte. Si vous essayez d'avoir de la messagerie à partir d'un réseau fondé sur NCP pour un réseau fondé sur TCP, vous allez cependant retourner dans le lien d'adressage par hôte déjà évoqué. Si vous ne voulez pas changer NCP (qui, après tout, est dépassé), vous devez faire quelque chose au niveau du process. Vous le pouvez, mais le "Protocole simple de transfert de messagerie" pour le faire prend 62 pages de spécifications dans la Request for Comments 788 de l'ARPANET.

Si les choses deviennent si compliquées quand on passe de NCP à TCP, où il y a un lien évolutif étroit entre les protocoles d'hôte à hôte, et où les protocoles de niveau process sont nominalement les mêmes, que se passera-t-il quand voulez évoluer à partir de DECNET, ou de SNA, ou de l'encore incomplet NBS ou de l'ensemble des protocoles ISO ? Il peut ou non se trouver que l'un ou l'autre aspect ne puisse être réconcilié par aucun moyen, mais il est extrêmement clair que traduire/transposer des passerelles va nécessiter des systèmes beaucoup plus puissants que les passerelles IP (qui sont ce que vous utilisez si les deux réseaux utilisent les mêmes ensembles de protocoles au dessus de l'hôte pour le protocole de communication de processeur de sous-réseau). Et vous allez avoir besoin d'un T/MG différent pour chaque paire d'ensembles de protocoles. Et il se peut que vous ayez à faire avec ce qu'il y a à l'intérieur de CSNP.... Une analogie vient à l'esprit avec le jeu du téléphone des enfants (appelé aussi la commère) : quelle quantité d'information perdez vous chaque fois que vous chuchotez à l'oreille de votre voisin qui à son tour chuchote à l'oreille du prochain ? Qu'en est-il, sur ce sujet, si vous transposez le jeu aux Nations Unies et changez les chuchoteurs en traducteurs qui ont des orateurs de langue différente de chaque côté ?

D'autres zones de problème pourraient être invoquées. Par exemple, il est clair qu'interpréter deux ensembles de protocoles plutôt qu'un seul prendrait plus de temps, à supposer que cela puisse se faire. Aussi, on devrait noter que le problème du RFNM se généralise en souci de résoudre les discordances de contrôle de flux pour toute paire d'ensembles de protocoles, et pourrait conduire à la nécessité d'avoir plus de capacité sur les mémoires tampon sur le T/MG que sur tout hôte, même pour les cas où elle est doublée par principe. Mais une seule autre zone de problème semble vraiment majeurs, et c'est le vieux problème de la cible mouvante : car quand un protocole quelconque change, ainsi doivent faire tous les T/MG qui l'impliquent, et comme il y a déjà eu trois versions de SNA, vraisemblablement un même nombre de versions de DECNET, et comme il y a au moins deux niveaux supplémentaires dont l'ISO devrait reconnaître l'existence, la crainte d'avoir à refaire les T/MG devrait servir de dissuasion considérable à commencer par cela. (Cette contradiction apparente de la Loi de Padlipsky à l'effet que "les protocoles mis en œuvre ont une inertie de repos à peine finie" est expliquée par une toute nouvelle Loi de Padlipsky : "Pour le néophyte technologique, changement égale progrès, pour le fabricant, changement égale profit".)

De toutes façons, on n'est pas sûr qu'une passerelle de traduction/transposition donnée puisse jamais être construite ; il faut regarder très attentivement les ensembles de protocoles en question pour déterminer même cela. Il est très clair que si on pouvait en construire une, cela ne serait pas facile à faire (voir la Figure 3 (Non fournie dans la version française)). Et pourtant "architecte de système" après "architecte de système", apparemment de bonne foi, assènent de telles choses dans leurs schémas fonctionnels. En supposant que la question architecturale ne se résout pas en une appétence pour le gothique de préférence à la vision plus moderne que la forme devrait suivre la fonction, faisons une brève pause pour visualiser un immense microprocesseur, gardé de tours crènelées et à gargouilles ... et retournons à la question de savoir pourquoi cette sorte de chose arrive.

Il est clair que les mots à la mode sont un des facteurs. Après tout, les "architectes de système" dans notre contexte sont habituellement des employés contractuels et leur rôle réel dans la vie n'est pas de construire des demeures plus spacieuses mais d'obtenir des contrats, de sorte qu'il n'est pas si surprenant qu'on se laisse prendre à des boniments de bateleurs qui n'ont rien à voir avec la précision de l'homme de l'art. Une autre analogie : Je suis allé un jour dans un magasin d'une grande chaîne de produits électroniques à la suite d'une publicité pour un lecteur de cassettes qui "fonctionne sur pile ou sur le réseau" pour 18 €, pour découvrir qu'ils voulaient 9 € de plus pour le transformateur (externe). Étant donnée la complexité des T/MG, c'est cependant dans notre cas plutôt un lecteur de cassettes à 18 € et un adaptateur à 36.

Mais est-ce seulement une histoire de mots à la mode ? Évidemment non, car comme je l'ai mentionné plus haut, il y a aussi l'ignorance de la tradition orale qui est en jeu. Il vaut mieux ne pas se poser la question de savoir si l'ignorance est voulue ou non, mais si nous nous voulons entretenir l'idée que ce n'est pas du tout un appât pour attraper les gogos comme dans l'histoire de l'adaptateur de courant continu à payer en plus, on voit que ceux qui proposent avec désinvolture des T/MG n'ont pas assez travaillé leur copie pour que cela constitue l'état de l'art réel.

Qu'en est-il cependant de cette référence du début à la littérature pertinente ? Vous pensez sûrement que je ne me le suis jamais demandé. Les réponses sont toutes deux impliquées dans l'assertion que :

Les passerelles sont des féhélambes

comme vous allez tout comprendre une fois que vous vous serez remémoré ce que sont les féhélampes. En piochant dans la littérature pertinente, reproduisons ici l'ouverture de l'histoire des féhélambes :

Un jour, comme Christophe Robin, Winnie-L'Ourson et Cochonnet discutaient ensemble, Christophe Robin finissant la tartine qu'il était en train de manger laissa tomber négligemment :

"J'ai vu un féhélambe aujourd'hui, Cochonnet."

"Qu'est-ce qu'il faisait ?" demanda Cochonnet.

"Il lambinait juste par là," dit Christophe Robin.

"Je ne crois pas qu'il m'ait vu."

"J'en ai vu un une fois," dit Cochonnet. "Au moins, je pense que je l'ai vu," dit-il. "Sauf que peut-être ce n'en était pas un."

"Moi aussi," dit L'Ourson, se demandant à quoi ressemblait un féhélambe.

"On ne les vois pas souvent," dit Christophe Robin négligemment.

"Pas ces temps ci," dit Cochonnet.

"Pas à cette époque de l'année," dit L'Ourson.

Puis ils se sont mis à parler d'autre chose, jusqu'à ce qu'il soit temps pour L'Ourson et Cochonnet de rentrer ensemble à la maison.

(Pour satisfaire le lecteur paresseux – qui aurait bien mieux fait de chercher dans les deux – c'est tiré de "Winnie L'Ourson", pas de "La maison du coin de l'ours".)

Pour le cas où l'(histoire ne vous reviendrait pas, L'Ourson décide de fabriquer un piège à féhélambe. (Cochonnet se désole de n'y avoir pas pensé le premier.) Il l'appâte avec une jatte de miel, après s'être assuré que c'est bien du miel, jusqu'au fond de la jatte, naturellement. Au milieu de la nuit, il va jusqu'au piège pour récupérer ce qui reste du miel et se coince la tête dans la jatte. Arrive alors Cochonnet, qui voit cette étrange créature avec une tête comme une jatte et qui pousse des cris effrayants, et, n'en sachant pas plus que L'Ourson sur ce que sont réellement les féhélambes, suppose qu'un féhélambe a réellement été piégé, et il est positivement terrifié.

Il aurait sans doute été trop moral de se demander ce que Christophe Robin savait réellement des féhélambes dès le début. Le "dessinateur", sur la base de l'image de la page 60 de mon édition, pense évidemment que pour C.R. c'étaient des éléphants, mais je me le demande encore. Au mieux, cependant, il n'en savait pas plus sur eux que le contractuel n'en sait sur les passerelles dans la proposition qui a débuté toutes ces interrogations.

NOTE : La FIGURE 1 : Définir les caractéristiques de toutes les sortes de passerelles, la FIGURE 2 : Passerelle et passerelle de traduction/transposition, approximativement à l'échelle, et la FIGURE 3 : Schémas internes respectifs, peuvent être obtenus en écrivant à : Mike Padlipsky, MITRE Corporation, P.O. Box 208, Bedford, Massachusetts, 01730, ou en envoyant un message à Padlipsky@ISIA.