Résumé

  • La RFC 795 mettait en correspondance la préséance, le délai, le débit et la fiabilité demandés dans l’IP d’origine avec les commandes propres à AUTODIN II, ARPANET, PRNET et SATNET.
  • Les tableaux révélaient les pertes de sens : PRNET n’indiquait aucune priorité, ARPANET ne disposait que d’un bit, plusieurs demandes aboutissaient au même service et 111 renvoyait une erreur dans deux correspondances.

Le paquet arrive au guichet avec une commande : rapide, fiable, prioritaire. Derrière le comptoir, quatre réseaux disposent chacun d’une autre carte. Dans sa RFC 795 de septembre 1981, Jon Postel a consigné les conversions nécessaires pour que l’IP parle à AUTODIN II, à ARPANET, à PRNET et à SATNET. Quatre pages de tableaux ont suffi pour dévoiler un problème durable : une demande commune ne donne pas à tous les réseaux les mêmes moyens d’y répondre.

Le formulaire IP de l’époque tenait sur un octet de Type of Service. Trois bits codent la préséance, puis viennent le délai, le débit et la fiabilité ; deux bits restent réservés. Les rangs vont de « routine » à « network control », en passant notamment par « flash override ». L’en-tête permet d’exprimer des préférences différentes. Postel avertit d’emblée que les réseaux considérés proposent des choix de service très particuliers. Les tableaux qui suivent énumèrent ces choix, avec leurs angles morts.

AUTODIN II répartissait les commandes entre catégories d’acceptation du trafic et types d’application. La préséance IP se rapprochait assez directement des premières. Pour le reste, I/A favorisait le délai, B1 le débit, B2 le débit avec la fiabilité, tandis que Q/R correspondait au réglage ordinaire. À la conversion inverse, plusieurs motifs de trois bits aboutissaient à Q/R ou I/A. Le motif 111, lui, menait à « error ». Trois demandes cochées ne fabriquaient pas une cinquième catégorie locale.

ARPANET avait une palette plus courte. Un seul bit de priorité pouvait rejoindre le bit de plus fort poids de la préséance IP. Les autres choix concernaient les messages ordinaires de type 0, les messages non contrôlés de type 3 et la taille à un ou plusieurs paquets. Le type 3 multipaquet était exclu. Une série de demandes DTR se rabattait sur le même type 0 multipaquet ; 100 et 110 conduisaient au type 3 en un paquet ; 101 au type 0 en un paquet ; 111 était encore une erreur. Le paquet avait plusieurs façons de demander, le réseau moins de façons de répondre.

PRNET supprimait même la case « priorité » de sa carte locale. Il proposait un routage de station ou point à point, avec ou sans accusé de réception. Le bit de délai IP guidait le type de parcours ; celui de fiabilité commandait l’accusé. Des demandes qui différaient par le bit de débit menaient au même couple de choix. Une préséance élevée dans l’en-tête restait une information, sans bouton équivalent dans PRNET.

SATNET compliquait l’histoire autrement. Il n’indiquait pas non plus de priorité, mais permettait de choisir entre blocs et flux, quatre catégories de délai, deux stratégies de conservation et trois niveaux de fiabilité. Postel multipliait les possibilités : 2 × 4 × 2 × 3, soit 48. La petite demande IP ne nommait pas à elle seule chaque combinaison. Quelqu’un devait choisir comment traduire la préférence en réglage local.

La beauté de cette RFC tient à son refus des grands mots. Elle montre précisément quand deux souhaits produisent la même prestation, quand une combinaison échoue et quand le réseau sait faire quelque chose que la demande IP décrit mal. L’interconnexion donnait une langue commune à des machines diverses. Les tables de Postel rappelaient aux ingénieurs de regarder la carte du restaurant avant d’annoncer au client que son plat serait servi.