Résumé

  • La RFC 877 a défini une interface étroite entre IP et X.25 : un marqueur de protocole, des séquences complètes de paquets pour les datagrammes et des paramètres négociables.
  • Le circuit virtuel s’ouvrait à la demande et se fermait après une période d’inactivité liée au coût local ; il ne suivait pas chaque connexion TCP.

Analyse

Le circuit avait son propre compteur

En septembre 1983, J. T. Korb a décrit dans la RFC 877 une méthode pour transporter des datagrammes IP sur les réseaux publics de données fondés sur X.25. Le texte précise que CSNET, la VAN Gateway et d’autres organisations avaient adopté cette norme. Il nomme des adopteurs, sans dresser la liste de tous les réseaux qui l’utilisaient.

Le problème n’était pas de fondre IP et X.25 en un seul protocole. IP envoyait des datagrammes ; X.25 fournissait des circuits virtuels sur le réseau de transport public. La RFC a donc défini une petite interface commune tout en laissant aux sites des choix opérationnels importants.

Un octet pour reconnaître le protocole

Le premier octet du champ Call User Data dans l’appel X.25 servait à identifier le protocole réseau. La valeur 0xCC désignait IP. Les données étaient ensuite transmises sous forme de séquences complètes de paquets X.25 : le datagramme commençait à une frontière de paquet et le bit More indiquait qu’il se poursuivait sur d’autres paquets. La RFC n’ajoutait pas d’en-tête dans les paquets de données.

La taille restait encadrée. Sans négociation d’une taille de paquet supérieure, un datagramme IP ne pouvait dépasser 576 octets. La RFC cite 1 024 octets comme exemple de taille plus grande négociée. Les paramètres de fenêtre et de paquet pouvaient donc varier d’un accord entre sites à l’autre au lieu d’être figés dans un profil unique.

Le transport public ne suivait pas la conversation TCP

Le circuit suivait un autre rythme. Selon la RFC 877, il s’ouvrait à la demande quand un datagramme arrivait à l’interface pour être transmis. Il pouvait ensuite être fermé après une période d’inactivité, dont la durée dépendait du coût d’un circuit ouvert. L’interface pouvait aussi fermer un circuit si elle n’en avait plus de disponible ; chaque site pouvait également le fermer.

La RFC précise que TCP et les autres protocoles au-dessus d’IP n’influent pas sur cette norme. Elle exclut explicitement l’ouverture d’un circuit X.25 par connexion TCP. Une connexion TCP de longue durée ne garantissait donc pas qu’un circuit de transport lui soit réservé. L’adaptateur gérait une ressource du réseau ; l’état de la connexion TCP restait au-dessus de cette interface.

La conséquence documentée est précise : si le circuit était fermé ou réinitialisé pendant la transmission, le datagramme était perdu. La RFC ne dit ni à quelle fréquence cela se produisait, ni ce qu’observait ensuite l’application. La réaction d’un transport supérieur relève d’autres mécanismes et d’autres preuves.

« Recommandé » ne signifie pas « partout déployé »

En 1984, le rapport officiel des protocoles ARPA-Internet, la RFC 924, classait « Internet Protocol on X.25 Networks » comme Recommended et renvoyait à la RFC 877. Dans ce rapport, cette mention encourageait les hôtes à implémenter le protocole ; elle n’affirmait pas que tous l’avaient fait. En 1992, la RFC 1356 décrivait la méthode de la RFC 877 comme largement utilisée, puis la remplaçait pour lever des ambiguïtés et tenir compte de besoins nouveaux : taille des datagrammes et des paquets, gestion des circuits et interconnexion multiprotocole.

La chronologie réunit un premier accord adopté par CSNET et la VAN Gateway, une recommandation officielle, puis une révision fondée sur l’expérience. Elle ne fournit ni décompte des sites, ni tarif, ni durée d’inactivité chiffrée.

La Note 64 comme grille de lecture ultérieure

La Note 64 de Heng Lu défend une règle de conception : définir le minimum commun nécessaire à l’interopérabilité, puis laisser les participants qui exploitent le système décider des évolutions. Comme grille éditoriale, elle éclaire la forme de la RFC 877 : le marqueur 0xCC et les frontières de paquets sont communs ; le délai de fermeture et les paramètres négociables ne sont pas fixés mondialement.

Cette lecture est rétrospective. La RFC 877 ne cite pas la Note 64 et celle-ci ne prouve pas l’intention de J. T. Korb. Le document montre simplement qu’IP pouvait être reconnu sur un service X.25 public sans imposer une durée de circuit identique à chaque opérateur.

Sources