Summary

  • NORDUnet's May 1988 application to NSFNET did not describe an Internet-only backbone. It proposed one Nordic transport network for Internet IP, DECnet, X.25, EARN and OSI services, with national organisations operating the network and the Nordic countries paying the US connection costs.
  • The “NORDUnet plug” turned that mixed design into a service image: different communities could use a shared backbone without pretending that their protocols, histories or needs had already converged. The four pins represented services, not four Nordic countries.
  • The arrangement brought a regional connection toward NSFNET, but it did not remove decision rights or dependencies. The application accepted NSFNET rules and even promised migration to ISO IP if NSF later chose it. Local carriers, national operators, shared funding and the US endpoint remained part of the system.

A request is not yet a connection

On 25 May 1988, Peter Villemoes, chairman of the NORDUNET Steering Committee, sent NSF a document titled “Application for connection to the NSFnet.” Its first sentence was a request for approval. The distinction matters. A proposal can show what its authors intended and what they were willing to promise; it cannot by itself prove that a circuit was installed, routing was active or researchers could use a service.

The application set out an unusually broad plan. NORDUNET wanted Internet services such as mail, file transfer and Telnet; DECnet; X.25-based services; BITNET/EARN traffic using NJE and RSCS; and OSI network services. The initial Nordic backbone would run at 64 kbit/s, be operated by the national organisations, and connect the participating countries to NSFNET. The application said the Nordic countries would bear the US-connection costs, follow RFC 1009 gateway recommendations and NSFNET rules, and migrate the connection to ISO IP if NSF decided to do so. Those commitments belong to the application, not to a claim that the later migration occurred. The original application preserves the plan in the participants’ own words.

That combination looks less like a protocol winner’s declaration than a negotiated operating brief. The network wanted immediate Internet reach, but it was also responsible for institutions already using other systems. It could not treat their installed software, colleagues or routines as if they had vanished because a new architecture had become attractive.

A Nordic programme before a Nordic backbone

The organisation behind that request had been forming through recurring meetings. Nordic networking specialists began meeting in 1980; a funded NORDUNET programme followed in 1985. Its purpose was cooperative infrastructure for research and education across Denmark, Finland, Iceland, Norway and Sweden. The programme and the operating network were not the same thing: the programme provided a political and administrative frame; networkers still had to make lines, routers and services work together. NORDUnet’s institutional history reconstructs that transition through interviews and archival material.

The first practical opportunity came from EARN, the European Academic and Research Network. Its IBM-based NJE/RSCS service already linked universities. In 1987, a project called X.EARN began by asking how the Nordic community could use EARN’s existing lines for more than EARN traffic. The objective widened: keep the service that institutions relied on, but make a common backbone carry other traffic too.

That change did not make the engineering easy. The plan to reuse existing EARN circuits could not be carried through as intended. NORDUnet obtained new leased lines instead. Its initial network joined national Ethernet environments through routers and gateways, then used Ethernet bridges across the Nordic backbone. The topology shifted from a proposed square to a cheaper star centered at the Royal Institute of Technology in Stockholm. The physical implementation changed while the service goal stayed recognizable: join national networks without requiring each country to rebuild its own systems in lockstep.

Four pins, several kinds of service

Einar Løvdal introduced the “NORDUnet plug” at a Reykjavík conference in September 1988. In the illustration, each pin stood for a service that the backbone should provide to national academic networks. Four broad families appear: ARPA Internet IP, DECnet, X.25 and EARN. The image was an explanation of the service concept, not a count of countries or an exhaustive service catalogue.

The contemporaneous NSF application makes that limit visible. It lists five planned groups, with OSI network services shown separately, alongside IP, DECnet, X.25 and EARN. The icon compresses a complicated programme into a memorable picture; the application is the better source for the full commitment. Keeping both records in view avoids turning the metaphor into a misleading protocol inventory.

Nor did the plug mean that a single gateway translated every packet or application into every other protocol. The system connected networks through a combination of routers, gateways, bridges and service-specific arrangements. RFC 1277 later recorded CLNS pilots in both NSFNET and NORDUnet, evidence that OSI work existed alongside the Internet path, not proof that one universal translation layer made the protocols interchangeable. RFC 1277 is a contemporary standards record; the NORDUnet book supplies the network’s broader history.

The metaphor’s political usefulness lay elsewhere. It allowed national organisations to discuss what their researchers needed before they settled every question about protocol doctrine. A user cared whether a colleague could be reached, a file transferred or a service maintained. Those outcomes depended on protocols, but they were not identical to choosing a single protocol as the only legitimate future.

The Atlantic link had several dates

The Nordic network also sought a connection to the US research backbone. The May 1988 application asked NSF for approval and a site at which to begin physical discussions; it said the proposed connection would serve all Nordic countries. The NORDUnet history describes a 56 kbit/s satellite link to the John von Neumann Center at Princeton. FUNET’s chronology records routing-level readiness on 1 December 1988. The history distinguishes availability, testing and the November Morris worm period; FUNET supplies a specific routing milestone. These are not interchangeable dates for one event.

This was not Europe’s first-ever Internet connection to the United States. SATNET and individual research projects had earlier links, and the NORDUnet history also mentions INRIA. Its narrower significance was that an international research network could provide a shared route for universities across the Nordic countries. The NSF application is unusually clear about the control boundary: NORDUNET would pay the connection cost and follow US gateway rules, while the NSF retained the decision about its end of the link and any later ISO-IP migration.

Iceland shows why a common plug did not mean identical paths

Iceland did not simply inherit the same physical route as the other four countries. In July 1989, Iceland’s SURIS connected to a NORDUnet point in Denmark using IP over X.25 over satellite. The NORDUnet history gives 2,400 bit/s for the circuit; ISNIC’s retrospective reports an observed range of 300–1,200 bit/s. Those accounts describe a constrained path, not the capacity of the Nordic backbone. It enabled direct Telnet and FTP where earlier international access had relied on email and Usenet, then gave way about a year later to a leased line to Stockholm. ISNIC’s account is useful for this local operating history.

The Iceland route is a small but important correction to the picture of a seamless regional network. Common service intent did not produce identical equipment, price, capacity or user experience in every country. The architecture could accept a local exception; the exception still had a cost and a performance ceiling.

Trieste was a debate, not a verdict

At the RARE Networkshop in Trieste in May 1989, Europe was beginning the implementation phase of COSINE, whose plan centered on OSI. Løvdal presented NORDUnet’s services and argued that TCP/IP should count as a European service, not merely an American one. The NORDUnet history recalls a divided response: applause from some attendees, silence from others, followed by intense discussion. A contemporaneous RARE meeting report documents the setting, while the later institutional history attributes the reaction to participants.

That episode does not prove that “Europe chose TCP/IP” in one room, or that every network operator shared one position. The 1988 application itself had listed OSI services and a possible future migration to ISO IP. The practical question was how to keep services running while evidence, products and policy changed. NORDUnet had a working case to show: a regional backbone could carry IP and other services before the European debate had settled.

The plug therefore did two jobs. Technically, it described a way to connect distinct service families over a shared regional infrastructure. Politically, it gave networkers a common object to discuss without treating one side’s installed systems as illegitimate. It did not settle the debate; it made continued work possible inside it.

What the plug left outside the picture

NORDUnet was neither a protocol-neutral utopia nor a network without a centre. The programme had a steering committee; national organisations operated the network; Scandinavian telecommunications companies supplied leased lines; and NSF controlled the US-side approval and rules. A service metaphor could not make those dependencies disappear. Nor does the surviving record prove that every planned service ran everywhere, that users experienced the same performance, or that the design gave all participants equal influence.

The useful historical claim is narrower: the Nordic project did not make interconnection wait for a single winner. It built a shared route around services already in use, added Internet IP, and left an explicit future decision point with NSF. That is why the plug matters. It represented a practical way to coordinate change without confusing a common backbone with a common answer to every future question.