Summary

  • BARRNet reported 1,816 external routes in 1991; its first OSPF deployment revealed an extra hop for some NSFNET traffic and memory pressure at smaller routers.
  • The RFC authors linked those constraints to two OSPFv2 features: forwarding addresses and stub areas. The record describes a specific operational case, not a universal cause for the protocol revision.

In April 1990, BARRNet put OSPF Version 1 into service across a Northern California research network. By November it was running Version 2. When John Moy documented the network the following July, the report did more than list an early adopter. It described how a real route took an unnecessary detour, and how routers with too little memory could not keep pace with the routes arriving from outside. Those two constraints became the stated reason for two features in OSPFv2. The story is unusually concrete: the protocol changed because operators could point to traffic and hardware that made the missing behavior visible. RFC 1246, §§6.0, 6.2.1–6.2.2

BARRNet was not a single campus network. The 1991 account says it served about 80 member sites from Sacramento to Monterey, with connections ranging from 9.6 kilobits per second to a full T1. Its members included universities, government bodies and commercial organisations. The regional connected to NSFNET at Stanford over both T1 and T3 links; it also reached ESnet at Lawrence Livermore, DDN through the Federal Internet Exchange at NASA Ames, and California university networks. The network therefore had to carry local reachability while exchanging routes with several larger systems. RFC 1246, §6.2

Its core comprised fourteen Proteon routers. Six formed a ring with redundant connections; full T1 circuits joined the core sites. Member sites sat behind those core routers, mostly in a Stanford-centred star. That layout matters because it put the external gateways and the places handling traffic at different points in the same regional system. The RFC lists 1,816 external routes in the OSPF system at the time. Most came from NSFNET; others came from NSN, BARRNet routers that still spoke other protocols, and ESnet. BARRNet imported RIP and EGP information into OSPF, used Type 1 external metrics, and tagged routes so that selected information could be advertised back through EGP. This was not a clean replacement of one protocol by another. OSPF had to coexist with the network’s other routing conversations. RFC 1246, §§6.2.1–6.2.2

A contemporary 1990 network directory also describes BARRNet as a regional network built from leased circuits, microwave links and a range of site connections. A later Internet2 history says responsibility for router ownership and maintenance was unusually decentralized among member universities. Those records help separate the shared routing system from who owned or maintained particular equipment; they do not show that the governance arrangement caused either the extra hop or the memory limit. RFC 1245 documents OSPF interoperability testing, while RFC 1131 provides the earlier Version 1 specification: standard text, implementation and field experience were developing alongside one another. The User’s Directory of Computer Networks (1990); Internet2 retrospective; RFC 1245; RFC 1131

The first problem appeared at the border. Only routers BR5 and BR6 exchanged EGP information with the system the RFC calls the NSS. Without a separate forwarding address in an OSPF external link-state advertisement, routers BR10, BR16 and BR28 sent NSFNET traffic toward the advertising gateway first, even where the actual external next hop was reachable directly. The packet crossed one more router than necessary. OSPFv2’s forwarding-address field let the external advertisement name the next router for the destination, so internal routers could take the direct path. The standard’s explanation uses a generic example; Moy’s field report ties the same behavior to BARRNet’s named routers. The source does not expand “NSS,” so the article preserves the acronym. RFC 1246, §6.2.2; RFC 1247, §§2.2, 12.4.4

The second problem was smaller in scale but no less operational. Some BARRNet routers did not have enough memory to hold all the external routes. The network used four stub areas, each consisting of one LAN without an OSPF router inside it. Stub areas excluded external advertisements from those areas and reduced the information that their routers had to carry. The field report describes this as an attempt to make OSPF usable on routers with limited memory—not as a guarantee that any low-memory device would work. No memory sizes or before-and-after measurements are supplied. The design traded a complete view of external routes inside each area for a smaller routing-state burden. RFC 1246, §§6.2.1–6.2.2; RFC 1247, §3.6

Moy’s summary places BARRNet among several early deployments. The same report lists the NASA Science Internet and OARnet; the general OSPF rollout began in spring 1990, and the first deployment did not uncover protocol bugs, though it did suggest useful additions. BARRNet’s significance is narrower and stronger than a “first” claim: the report names the specific route detour and memory limit that motivated two Version 2 features. RFC 1247 also says Versions 1 and 2 were not interoperable, which made version change an operational boundary as well as an editorial one. The field report gives BARRNet’s adoption dates, but not a router-by-router conversion log or evidence that the change happened everywhere at once. RFC 1246, §§6.0, 6.2.2; RFC 1247, Appendix F

That distinction keeps the history in proportion. A protocol specification could state what routers should do; the deployment exposed where the model imposed an extra transit step or more state than a device could retain. BARRNet’s contribution, as documented, was not to prove that one topology or one routing protocol solved the Internet’s problems. It was to give the designers a particular operational case to answer: route to the actual next hop, and let a constrained area carry less of the outside world.

Sources