Résumé

  • La RFC 1074 décrit un sous-ensemble de l’IS-IS ANSI limité au niveau 2 et aux liaisons permanentes point à point. Le NSFNET faisait voyager les PDU IS-IS et ES-IS au-dessus d’IP, sous le numéro 85, et inscrivait adresses IPv4 et domaines administratifs dans des champs à la forme NSAP.
  • Une annonce EGP ne devenait pas automatiquement une route du cœur. Un NSS la confrontait à la Routing Policy Data Base, construisait un préfixe pour un PDU End System et lui attribuait un coût issu de cette politique avant de diffuser le nouvel état.

Le backbone présenté dans la RFC 1074 reliait treize sites des États-Unis continentaux. Les circuits T1 permanents offraient 1,544 Mbit/s ; plusieurs liaisons logiques pouvaient partager cette capacité. Chaque site disposait d’un Nodal Switching Subsystem, ensemble multiprocesseur à base d’IBM RT/PC sous un noyau 4.3BSD modifié. Pour le calcul de routes, un NSS comptait comme un seul nœud.

La fiche technique ne raconte pourtant que la moitié du système. À l’intérieur, les NSS échangeaient une adaptation du protocole IS-IS en cours de normalisation chez ANSI et ISO. À la périphérie, les réseaux régionaux parlaient EGP. Entre les deux, un enregistrement extérieur changeait de représentation et ne franchissait la limite qu’après une décision de politique.

Choisir IS-IS ne signifiait pas tout prendre

L’IS-IS ANSI distinguait le niveau 1 à l’intérieur d’une zone et le niveau 2 entre zones. Le NSFNET ne conserva que le second. Parmi les fonctions liées aux sous-réseaux, son environnement se réduisait aux topologies générales constituées de circuits point à point permanents. La RFC est donc une description d’implémentation, non l’annonce que l’ensemble du modèle OSI aurait été déployé sur le backbone.

Dans le cadre ISO, les PDU de routage se plaçaient directement sur la couche liaison. Ici, les PDU IS-IS et ES-IS étaient encapsulés dans IP. Le champ Protocol de l’en-tête portait la valeur 85, encore enregistrée comme NSFNET-IGP dans le registre IANA. Un discriminateur interne distinguait ensuite les familles de PDU.

Cette attribution ne suffit pas à démontrer une route. Elle prouve la réservation d’un code. Dans une observation historique, un paquet 85 reçu prouverait au mieux le transport d’une enveloppe de contrôle. Il resterait à vérifier son décodage, son entrée dans la base d’état de liens, le résultat SPF et l’installation dans la table de transfert.

Le choix d’IP fixait aussi le traitement des grandes unités : le NSFNET s’appuyait sur la fragmentation et le réassemblage IP, sans ajouter une fragmentation IS-IS propre à ce milieu. Le transport n’était donc pas un détail neutre ; il déterminait déjà une partie des limites et des modes de panne du plan de contrôle.

Le NSAP était une forme à remplir, pas une identité retrouvée

L’algorithme emprunté attendait des adresses NSAP. Le réseau exploité possédait des adresses IPv4, des numéros de réseau et des numéros d’Autonomous System. La solution fut de construire une forme intermédiaire explicite.

Dans la partie spécifique au domaine, longue de neuf octets, deux octets représentaient le domaine administratif, deux restaient vides, quatre recevaient l’adresse IP et le dernier restait vide. La partie initiale du domaine n’était pas utilisée. L’identifiant de routeur, sur six octets, commençait lui aussi par deux octets vides puis reprenait les quatre octets IP. Le Network Entity Title dérivait de cette construction.

Les blancs ont un sens. Ils signalent une correspondance fabriquée, avec ses positions et ses limites. Dire que « l’adresse IP devenait une adresse OSI » serait trop généreux : elle était placée dans le format dont le protocole de contrôle avait besoin.

Pour ce routage NSFNET, chaque Autonomous System était traité comme un domaine administratif. Cette équivalence locale rendait possible l’association entre le réseau annoncé par EGP et l’organisation qui le représentait. Elle ne fournit pas une définition universelle de ces deux notions.

La base de politique se trouvait sur le chemin de la croyance

La RFC 1092 expose le problème qu’EGP ne résolvait pas. Son modèle supposait une arborescence construite, alors que les réseaux régionaux disposaient de routes « par l’arrière » et pouvaient présenter plusieurs chemins vers le même réseau. EGP ne disait pas, à lui seul, quel régional avait le droit de représenter ce réseau ni lequel devait être primaire.

Le NSFNET formalisa des accords bilatéraux de représentation : principal, secondaire, puis autres solutions de repli. Le Network Operations Center les inscrivait dans la Routing Policy Data Base. Le NSS de raccordement pouvait contrôler l’adresse du pair, son numéro d’AS, le numéro de réseau annoncé et la priorité prévue. Une discordance était susceptible d’être rejetée et signalée.

Les paquets EGP acceptés n’étaient pas diffusés tels quels dans le backbone. Le numéro de réseau et le domaine administratif du pair étaient encodés dans un préfixe de forme NSAP. Ce préfixe prenait place dans un PDU End System ; son coût venait de la base de politique. L’IS-IS interne distribuait donc un nouvel énoncé, composé d’une observation extérieure et d’une décision locale.

Cette chaîne fournit une méthode de lecture. L’annonce EGP est la parole du pair. L’entrée de politique décrit une autorisation administrative. Le PDU ES montre qu’un état converti a été émis. La base de liens, le calcul SPF, la table de transfert et le trajet d’un paquet sont encore d’autres preuves. Aucun voyant ne peut résumer les six.

La politique orientait l’information, non chaque utilisateur

La RFC 1104 indique que le mécanisme de politique du NSFNET fonctionnait depuis juillet 1988. Elle distingue quatre contrôles : identité du pair par son adresse source, vérification du domaine administratif ou AS, vérification des numéros de réseau et maîtrise des métriques via la base.

Ce modèle filtrant la distribution de routes agissait à la granularité d’un réseau ou d’un domaine. Il pouvait façonner la table sans consulter une base pour chaque paquet, d’où un coût faible dans le chemin de transfert. En revanche, il n’authentifiait pas un utilisateur final et ne neutralisait pas toutes les attaques par routage à la source. Une politique de plan de contrôle n’est pas un pare-feu universel.

La présence d’une autorisation ne garantissait pas non plus la fraîcheur. Une base différente sur deux NSS, une représentation devenue obsolète ou un chemin approuvé mais défaillant pouvaient séparer l’intention, la topologie diffusée et le service réel.

L’Integrated IS-IS vint ensuite, autrement

La RFC 1195, publiée en 1990, spécifia un IS-IS intégré pour les domaines IP, OSI et mixtes. Elle ajoutait des informations propres à IP et conservait les paquets IP et OSI « tels quels » sur les services de liaison. Son ambition et sa syntaxe ne se réduisaient pas au montage particulier de la RFC 1074.

Les deux histoires partagent une intuition : un algorithme à état de liens n’appartient pas éternellement à une seule famille de couche réseau. Mais la RFC 1074 montre un sous-ensemble de niveau 2, des PDU de contrôle portés par IP et des faits Internet rangés dans une forme NSAP. La RFC 1195 formalise plus tard un protocole intégré. Les confondre ferait disparaître le travail de traduction réalisé en production.

Le bilan de la RFC 1222 éclaire le but. La phase T1 sépara fortement l’IGP du backbone des IGP de ses clients, en utilisant un protocole extérieur à la limite. Chaque entité administrative pouvait garder sa méthode interne. L’interopérabilité n’exigeait donc pas une monoculture ; elle exigeait une frontière contrôlée.

Sources et limites

La RFC 904 fournit la grammaire de base d’EGP, mais pas la politique de représentation que le NSFNET ajouta ensuite. La RFC 1093 replace la limite IGP/EGP dans l’architecture d’ensemble. Les RFC 1074, 1092 et 1104 sont des récits d’implémentation rédigés par leurs acteurs. Elles documentent une intention et des choix, pas un taux de disponibilité ni chaque paquet réellement transmis. La RFC 1222 est une rétrospective ; la RFC 1195, une spécification ultérieure. Le registre IANA atteste une attribution, non un usage actuel.

La conclusion peut rester précise. IP transportait l’enveloppe ; une forme NSAP transportait l’adresse Internet ; EGP apportait une prétention de joignabilité ; la politique décidait si elle était recevable et à quel coût ; IS-IS diffusait l’état produit. La route n’avait jamais une preuve unique.