Résumé

  • En 1991, BARRNet recensait 1 816 routes externes. Son premier déploiement OSPF a révélé un détour pour une partie du trafic NSFNET et une pression mémoire sur les petits routeurs.
  • Le rapport relie ces limites à deux fonctions d’OSPFv2 : l’adresse de transfert et les zones stub. Il décrit un cas opérationnel précis, sans prétendre expliquer à lui seul toute l’évolution du protocole.

En avril 1990, BARRNet a mis OSPF version 1 en service dans un réseau de recherche du nord de la Californie. En novembre, le réseau utilisait la version 2. Lorsque John Moy l’a décrit en juillet suivant, il ne s’est pas contenté de signaler un adopteur précoce. Son rapport montre qu’une route empruntait un détour inutile et que certains routeurs n’avaient pas assez de mémoire pour conserver toutes les routes venues de l’extérieur. Ces deux contraintes sont présentées comme la raison de deux fonctions ajoutées à OSPFv2. Le récit est concret : les opérateurs pouvaient montrer le trafic et les équipements auxquels le protocole devait mieux s’adapter. RFC 1246, §§6.0, 6.2.1–6.2.2

BARRNet ne se limitait pas à un campus. Le compte rendu de 1991 lui attribue environ 80 sites membres, de Sacramento à Monterey, reliés à des débits allant de 9,6 kbit/s au T1 complet. Les membres étaient des universités, des organismes publics et des entreprises. Le réseau régional rejoignait NSFNET à Stanford par des liaisons T1 et T3 ; il était aussi interconnecté à ESnet à Lawrence Livermore, au DDN par le Federal Internet Exchange de NASA Ames et aux réseaux universitaires californiens. BARRNet devait donc transporter la portée de ses sites tout en échangeant des routes avec plusieurs réseaux plus vastes. RFC 1246, §6.2

Son cœur comptait quatorze routeurs Proteon. Six formaient un anneau redondant, et des circuits T1 complets reliaient les sites centraux. Les sites membres se raccordaient à ces routeurs, le plus souvent en étoile autour de Stanford. Cette topologie plaçait les passerelles externes et les routeurs qui traitaient le trafic à différents endroits du même réseau régional. Le RFC dénombre alors 1 816 routes externes dans le système OSPF : la plupart provenaient de NSFNET ; d’autres venaient de NSN, de routeurs BARRNet qui utilisaient encore d’autres protocoles et d’ESnet. BARRNet importait dans OSPF des routes RIP et EGP, leur appliquait des métriques externes de type 1 et utilisait des étiquettes pour gérer certaines réannonces vers EGP. Il ne s’agissait pas de remplacer proprement un protocole par un autre : OSPF devait cohabiter avec les échanges de routage déjà en place. RFC 1246, §§6.2.1–6.2.2

Un répertoire contemporain de 1990 décrit aussi BARRNet comme un réseau régional composé de circuits loués, de liaisons hertziennes et de raccordements variés. Une rétrospective ultérieure d’Internet2 indique que la propriété et la maintenance des routeurs étaient particulièrement décentralisées entre les universités membres. Ces sources distinguent le système de routage partagé de la responsabilité de chaque équipement ; elles ne montrent pas que cette organisation ait causé le détour ou le manque de mémoire. RFC 1245 rend compte des essais d’interopérabilité OSPF et RFC 1131 fournit la première spécification : texte normatif, implémentations et expérience de terrain évoluaient en parallèle. The User’s Directory of Computer Networks (1990) ; rétrospective Internet2 ; RFC 1245 ; RFC 1131

Le premier problème se situait à la frontière. Seuls les routeurs BR5 et BR6 échangeaient des informations EGP avec le système que le RFC appelle NSS. Sans adresse de transfert distincte dans une annonce OSPF de lien externe, les routeurs BR10, BR16 et BR28 envoyaient d’abord le trafic NSFNET vers la passerelle qui annonçait la route, même quand le prochain saut externe était directement joignable. Un routeur de plus était traversé. Le champ d’adresse de transfert d’OSPFv2 permettait d’indiquer dans l’annonce le prochain routeur à utiliser pour la destination ; les routeurs internes pouvaient alors prendre le chemin direct. La spécification illustre le mécanisme en termes génériques, tandis que le rapport de Moy l’associe aux routeurs nommés de BARRNet. La source ne développe pas le sigle « NSS » ; nous le conservons donc tel quel. RFC 1246, §6.2.2 ; RFC 1247, §§2.2, 12.4.4

Le second problème concernait la mémoire. Certains routeurs ne pouvaient pas conserver toutes les routes externes. BARRNet utilisait quatre zones stub, chacune composée d’un seul réseau local sans routeur OSPF à l’intérieur. Ces zones excluaient les annonces externes et réduisaient les informations à conserver. Le rapport présente la fonction comme une tentative de faire fonctionner OSPF sur des équipements à mémoire limitée, et non comme la garantie que tout appareil peu doté conviendrait. Il ne donne ni capacité mémoire ni mesure avant/après. Le compromis consistait à réduire l’état de routage dans une zone en lui donnant une vue plus limitée des routes externes. RFC 1246, §§6.2.1–6.2.2 ; RFC 1247, §3.6

Le rapport de Moy situe BARRNet parmi plusieurs déploiements précoces. Il mentionne aussi le NASA Science Internet et OARnet : OSPF avait commencé à être déployé sur Internet au printemps 1990. Le premier déploiement n’avait pas révélé de bogue du protocole, mais il avait fait apparaître des fonctions souhaitables. L’intérêt de BARRNet est plus circonscrit et mieux documenté qu’une revendication de primauté : le rapport nomme le détour et la limite mémoire qui ont motivé deux fonctions de la version 2. RFC 1247 précise également que les versions 1 et 2 n’étaient pas interopérables ; le changement de version constituait donc une contrainte opérationnelle. Le compte rendu donne les dates d’adoption de BARRNet, sans journal de migration routeur par routeur ni preuve que la conversion fut simultanée. RFC 1246, §§6.0, 6.2.2 ; RFC 1247, annexe F

Cette limite permet de garder l’histoire à sa juste échelle. Une spécification pouvait décrire le comportement attendu ; le déploiement a montré où le modèle imposait un transit supplémentaire ou davantage d’état qu’un équipement ne pouvait en garder. La contribution documentée de BARRNet n’est pas d’avoir prouvé qu’une topologie ou un protocole résolvait tous les problèmes d’Internet. Elle est d’avoir fourni un cas opérationnel précis : annoncer le prochain saut réellement utilisable et permettre à une zone aux ressources limitées de conserver moins de routes externes.

Sources