Summary

  • TransPAC’s 1998 path joined APAN and KDD-side networks in Tokyo to STAR TAP in Chicago, where traffic could reach the U.S. research backbone; the trans-Pacific circuit was one segment, not a campus-to-campus service guarantee.
  • The project report dates circuit establishment, service start, IP routing, round-the-clock operations and later capacity changes separately. Those distinctions show where international research networking depended on coordination beyond bandwidth.

A circuit is not an end-to-end service

The National Science Foundation’s September 1998 announcement gave TransPAC a public frame: a five-year research and education network connection between the United States and Asia-Pacific. It described a path from NSF’s very-high-performance Backbone Network Service (vBNS) to the Asia Pacific Advanced Network (APAN), through STAR TAP in Chicago, with AT&T and Japan’s Kokusai Denshin Denwa (KDD) supplying major carrier infrastructure. Japan, Korea, Singapore and Australia were named in the initial scope. The release also described a $10 million Indiana University award; a 2018 IU retrospective gives $12 million for the initial award.

Because the sources conflict, the amount is not needed to explain the network.

The contemporary TransPAC annual report is more precise about what the first circuit physically connected. It describes a 35 Mbps variable-bit-rate, non-real-time ATM permanent virtual path between APAN’s Tokyo Exchange Point and KDD networks on one side, and an Ameritech/Lucent switch at STAR TAP on the other. STAR TAP then provided an interconnection point to the U.S. research network. That is a chain of organizations, facilities and network services. It is not evidence that every university named in the programme had a direct TransPAC port or the same route to every other participant.

This difference matters because a large international circuit is only one input into useful connectivity. A carrier can provide a transmission path; a regional research network aggregates participating institutions; an exchange point supplies a place to connect; network operators must establish routing and peering; and a staffed operations function must detect and resolve failures. The annual report’s diagram and milestones reveal these layers more clearly than the word “link” does on its own.

Several dates, several kinds of progress

The project report lists July 30, 1998 as the date ATM service was established from the APAN Tokyo Exchange Point to STAR TAP. Its progress section says the 35 Mbps service began August 1. On August 18, it records IP routing between KDD and Indiana University through vBNS at Downers Grove, Illinois. The September 21 NSF release announced the award and described the programme as operational, but the report still records later milestones: a 24-hour, seven-day TransPAC network operations center at IU on October 18, APAN/vBNS peering on October 23, and demonstrations using TransPAC at SC’98 in November.

These dates need not contradict one another. They describe a circuit being established, service being counted as in operation, a particular routing relationship, a public award announcement, a staffed operations capability and an interconnection milestone. Treating them as synonyms would erase the work that made the path usable and supportable. It would also make the September press release carry more technical detail than it actually supplies.

APAN itself had been proposed in 1996 and formed as a consortium in June 1997 to support advanced networking for research and education in the region. TransPAC therefore connected into a regional project already organizing networks and applications, rather than creating Asia-Pacific research networking from nothing. Conversely, an APAN backbone did not mean that every campus in the region was automatically connected. The available records describe a growing network and selected collaborations; they do not establish uniform access or service levels for all named institutions.

Capacity grew, but topology still mattered

The 1998–99 report describes a later JST-funded increase to 73 Mbps. Its milestone list dates completion to March 14, 1999, while a separate description says the infrastructure was expanded to 73 Mbps in May. Both statements are retained here: the report appears to use distinct milestone and infrastructure descriptions, and the evidence does not justify collapsing them into one exact date. The report further says the original 35 Mbps was augmented by 38 Mbps; 3 Mbps supported a commercial NAP.NET connection over a distinct ATM virtual circuit that did not affect the research service.

Capacity totals therefore require attention to what the circuit carried and how it was provisioned.

Applications supplied a more concrete test than headline bandwidth. The annual report records TransPAC-based demonstrations at SC’98. A near-contemporary STAR TAP account later described remote use of an Osaka electron microscope by researchers in San Diego over a high-capacity path. Such examples show why research networks pursued low-friction, high-performance access to instruments and large data sets. They do not prove that every application had the same path, that bandwidth was continuously available at its nominal rate, or that all institutions shared access on equal terms.

In April 1999, APAN, the U.S. University Corporation for Advanced Internet Development (UCAID) and TransPAC representatives met to discuss terms for an APAN/UCAID memorandum and outline APAN/Abilene peering through TransPAC. The report describes a discussion and outline, not a completed peering relationship. That distinction is another reminder that naming two networks in a diagram does not itself establish an operational route.

The enduring lesson is less about a single speed than about the control points between networks. International reach depended on carrier capacity, an exchange facility, regional aggregation, routing agreements, operational staffing and funding that could sustain upgrades. A link could exist before every route was configured; a route could exist before a 24-hour support function was in place; a demonstration could succeed without proving universal availability. TransPAC’s early history makes those dependencies visible.

Sources: TransPAC Annual Report 1998–99; NSF PR 98-53; APAN history; IU’s 20-year retrospective; STAR TAP’s 1999 account; Ninf over TransPAC.