Résumé

  • Le VLN de Cronus promettait une interface stable aux logiciels situés au-dessus d’IP, même lorsqu’on remplaçait le réseau local physique.
  • Pour tenir cette promesse, il fallait organiser les adresses individuelles et collectives, les passerelles, une correspondance avec les adresses Ethernet et des règles de livraison précises.

Un réseau local trop cher, trop lent ou trop fragile finit par réclamer son remplacement. La question moins spectaculaire est celle de la facture logicielle. Faut-il retoucher tous les programmes qui s’appuyaient sur l’ancien réseau ? William I. MacGregor et Daniel C. Tappan ont répondu dans RFC 824 par une séparation nette : le Virtual Local Network de Cronus, ou VLN, offrirait aux clients une façade constante; l’installation physique, elle, pourrait changer. IP continuait sa journée, sans visite guidée de la nouvelle plomberie.

La note date du 25 août 1982 et décrit un système d’exploitation distribué conçu chez Bolt Beranek and Newman. Son schéma empile TCP et UDP, IP, le VLN, puis le réseau local physique. Les auteurs nomment leurs deux objectifs : compatibilité avec les protocoles Internet de DARPA et possibilité de substituer un réseau physique à un autre. Cette substitution reste soumise à une condition capitale : conserver la sémantique de l’interface VLN. Le logiciel situé au-dessus dépendait de ce contrat, et non des détails d’une prise ou d’un câble.

« Interface constante » ne voulait pas dire « opération gratuite ». La représentation des opérations pouvait différer selon les machines, tandis que leurs capacités fonctionnelles devaient rester identiques. Pour changer le réseau local, il fallait réimplémenter le VLN sur chaque hôte Cronus. Le texte cite le coût, les performances et la robustesse mécanique ou électrique parmi les motifs possibles. On pouvait choisir un meilleur support sans renégocier la signification de chaque appel fait par les programmes. Mais quelqu’un devait tout de même écrire et vérifier la nouvelle implémentation.

La compatibilité d’IP n’était pas un slogan. Les auteurs exigent qu’aucune modification ni extension d’IP ne soit nécessaire au-dessus du VLN. Dans une grappe Cronus, les hôtes partageaient un même réseau local physique. Pour joindre l’extérieur, le VLN remettait les datagrammes à une passerelle Internet. Il était lui-même considéré comme un réseau de l’Internet, doté d’un numéro de réseau; le réseau physique pouvait porter le même numéro ou un autre. Garder le visage visible d’un réseau ne dispensait donc personne de choisir correctement la sortie.

Les adresses donnent à cette abstraction sa consistance. L’interface devait permettre de viser un hôte précis, tous les hôtes ou un groupe multicast. Dans la table proposée, les valeurs locales de 0 à 1 023 désignent des hôtes précis, celles de 1 024 à 65 534 des groupes, et 65 535 la diffusion générale. Les auteurs recommandent un réseau de classe A ou B afin de loger toute cette plage. Il s’agit de l’organisation proposée pour Cronus en 1982. Son intérêt est de faire de trois modes de livraison une promesse commune, quelle que soit la technique employée plus bas.

L’exemple Ethernet révèle le métier caché sous la façade. Chaque hôte garde une VPMap qui associe une adresse d’hôte VLN sur 32 bits à une adresse Ethernet sur 48 bits. Si l’adresse physique d’une machine change alors que son adresse VLN reste stable, les correspondances mémorisées ailleurs peuvent devenir fausses. La note envisage la remise à zéro de l’interface afin de reconstituer ses tables dynamiques. L’étage supérieur peut ignorer le déménagement; le facteur chargé de la distribution, lui, doit recevoir la nouvelle adresse. Sans cela, la belle abstraction distribue surtout du silence.

La taille et la fiabilité ont elles aussi des frontières. Le VLN garantit le transfert entre clients de datagrammes de 576 octets ou moins; au-delà, cela peut fonctionner pour certains couples de machines. Il ne fragmente ni ne réassemble les datagrammes IP et ne traite pas les options Internet. Il ne garantit pas que tout paquet arrivera et n’envoie pas d’accusé négatif lorsqu’un paquet est perdu ou abîmé. En revanche, le datagramme livré doit représenter fidèlement l’original. Pour un destinataire donné, l’exemplaire arrive une fois ou pas du tout.

Dans la grappe, les paquets reçus constituent une sous-séquence de ceux envoyés : des absents sont possibles, le désordre ne fait pas partie du contrat.

Le charme de ce document est sa précision. Il ne se contente pas d’annoncer qu’on pourra remplacer le réseau physique. Il dit ce qu’il faut préserver pour que les autres couches n’aient pas à s’en apercevoir : sens des adresses, comportement des passerelles, taille commune des datagrammes et discipline de livraison. Le réseau local virtuel était une promesse adressée aux logiciels. Comme toute promesse technique solide, elle avait un mode d’emploi et un responsable.