Summary

  • RFC 1477 reported that an instrumented IDPR prototype preserved a Telnet session while a failed gateway and a changed transit policy each forced traffic onto the other side of a four-domain ring.
  • The report also said the prototype omitted source-policy support and multiple gateways between two domains, used manual mapping tables, tested simple cases and withheld its performance figures; those limits define what the successful demonstration could prove.

One session, two forced changes

The memorable result in RFC 1477 is almost cinematic. Four administrative domains form a ring. One contains the source host, one the destination, and two offer alternate transit. A Telnet session begins. The source-side path agent asks a route server for a policy route, establishes the path, and the application starts exchanging traffic.

Then the experimenters terminate the IDPR processes on a policy gateway in the active transit domain. The adjacent gateways detect the loss, distribute new routing information and tear down their remaining path sections. The source obtains a route through the other transit domain. The Telnet session remains intact.

After restoring the first route, the experimenters make a different change. They reconfigure the active transit domain so that it no longer accepts traffic from the source domain to the destination domain. Again the old path comes down, a new route is calculated through the alternative transit domain, and the session remains intact.

This is stronger evidence than a box-and-arrow architecture. It links a configured or induced change to observable control messages, path teardown, replacement route generation and continued application traffic. The prototype was heavily instrumented: the team could see changes in gateway connectivity, transit policy, routing-information exchange, generated routes, path-control traffic and path state. The events did not have to be inferred from a final ping.

But the precision of that evidence depends on keeping the experiment’s boundary intact.

The omission appears before the triumph

RFC 1477 says that the prototype implemented most, not all, IDPR functionality. To get working software quickly, the developers deliberately left out support for source policies and for multiple policy gateways connecting two domains.

That sentence changes the meaning of the demonstration. IDPR’s architecture did not treat source policy as decoration. It separated transit policies—rules set by domains about who could use their resources—from source policies, which expressed the service and route constraints of the traffic origin. The experiment changed a transit policy and observed a reroute. It did not thereby test the omitted machinery for applying source policy.

Likewise, a ring with one relevant gateway connection at each boundary avoids questions raised by multiple gateways between the same pair of domains. It can show that a path is replaced by another path. It cannot show how the omitted implementation would choose, coordinate or recover among several gateways representing the same inter-domain connection.

The developers did nothing improper by narrowing the first executable target. On the contrary, the report is useful because it names the narrowing. A minimum implementation can turn an abstract design into an observable mechanism. The error begins only when later readers let “working” absorb the functions that were explicitly outside the build.

The laboratory was real and bounded

Experiments began in February 1991 after prototype work that had started the previous summer. USC used SPARC1+ workstations on a laboratory Ethernet whose topology could be rearranged. SAIC used Sun3 systems at Sparta and MITRE, joined through Alternet over a 9.6 kb/s SLIP link and through an X.25 path across the DCA EDN testbed. BBN used SPARC1+ systems at BBN and ISI over DARTnet and TWBnet.

Those details matter. This was not a purely local simulation with invented delays. It crossed several period networks and technologies. Yet the principal failure and policy-change experiments still used a simple four-domain ring. Both transit domains initially had policies without access restrictions. The team did not use mapping servers; it configured address-to-domain mapping tables inside each policy gateway.

The manual tables were a legitimate test fixture. They supplied the lookup answer needed for the experiment. They were not evidence that a distributed mapping service had been built, updated correctly or scaled. A test substitute can close one dependency for one run while leaving the dependency itself untested.

That distinction is especially important in distributed systems. If an experiment injects correct mappings, the route computation can be assessed under the condition that the mappings are correct. It cannot establish how stale, conflicting or missing mappings would be discovered and repaired.

“Major functionality” meant the prototype’s major functionality

RFC 1477 calls the experiments simple and says they tested all major functionality of the prototype. Both clauses belong in the historical record. The prototype monitored connectivity, distributed link-state and policy information, generated a route, established a path, detected a component loss, invalidated an affected path and rebuilt traffic through another transit domain. It also reacted when a transit rule made the current path unacceptable.

The phrase does not erase the earlier omission. “All major functionality of the prototype” is a statement about the artifact that existed. It is not “all functionality of the architecture” described in RFC 1478 and the protocol machinery specified in RFC 1479. A requirements document and an executable subset occupy different reality layers even when they share a name.

The same care applies to the intact Telnet session. It demonstrates continuity for the reported session under two reported changes. The source does not provide a packet-loss count, convergence distribution, application transcript or set of repeated trials. It does not warrant that every application, topology, failure sequence or policy combination would remain uninterrupted. “The session remained intact” is already a strong and useful fact. It does not need to be inflated.

Encouraging numbers that readers could not inspect

The team measured the work required for path setup and message forwarding. It compared IDPR forwarding with IP encapsulation against ordinary IP forwarding, and compared messages with no integrity/authentication calculation against RSA/MD4 processing. RFC 1477 calls the results encouraging.

It does not list the figures. Instead, it provides contacts from whom they could be requested and warns readers not to extrapolate blindly to other implementations. The prototype had received little optimization work.

This creates a clean evidence boundary. We can say the measurements were performed, which components were compared, how the authors characterized the results, and what warning they attached. We cannot reconstruct latency, throughput or CPU cost from the adjective “encouraging”. We cannot compare IDPR numerically with another routing system. A result that once existed outside the document is not recoverable merely because the document reports its mood.

The second implementation changed the claim

RFC 1477 then moves from the multi-process prototype to a version integrated into the gated UNIX routing process. It says the gated version contained full IDPR functionality, added a configuration interface and operated more efficiently as a single process. It was freely available, allowing an operator with a UNIX machine to experiment without writing an implementation.

Availability moved the project into a new evidence phase. The report’s stated goal was to gain experience in operational networks with real constraints and real traffic requirements. At publication, a pilot deployment and demonstration were under way at selected Internet locations.

Three facts must remain separate: software was available; a pilot was under way; durable adoption had not been documented in this source packet. Downloadability does not reveal installation. Installation does not reveal enablement. Enablement does not reveal which traffic used a policy path. A pilot beginning is not its completion report.

The RFC Editor record supplies another instructive separation. Although the title says “IDPR as a Proposed Standard”, RFC 1477 itself is Informational. RFC 1478’s record and RFC 1479’s record preserve the documentary identities of the architecture and protocol. RFC 2026 explains the standards-process vocabulary. None of these labels is an execution receipt.

What the prototype deserves

The earlier RFC 1102 explored how policy routes could be constructed across administrative regions. RFC 1104 separated routing information, packet treatment, resource allocation and accounting. RFC 1477 adds something different: a candid implementation ledger. It shows implemented mechanisms working, names deliberate omissions, describes test fixtures and refuses to print performance claims it cannot safely generalize.

That is not a failed proof. It is a properly scoped one.

The history of the Internet is distorted when architecture is dismissed until it dominates the network, and it is equally distorted when one successful demonstration is treated as the whole architecture already deployed. The better account gives running code primacy over aspiration while asking exactly which code ran, under which configuration, with which observable receipts.

That is the connection to Heng Lu’s essays on running-code primacy, minimum initial specification and voluntary adoption, and reality layers. A bounded prototype can deserve confidence without acquiring authority over the functions it omitted or the networks that never adopted it.

Sources