Summary

  • RFC 1306 describes a 1992 Cray project in which a routing lookup could generate a request for an external, by-request circuit-switched T3 connection.
  • The report requires an incomplete connection to remain a no-data state: an attempted transfer must not automatically activate the circuit, and TCP must wait for circuit completion before sending through the route.
  • A request, therefore, is evidence of an attempted control action—not of an existing circuit, transport progress, delivery, capacity entitlement or application completion.

Analysis

The route had a second job

Most descriptions of a route begin and end with forwarding: a destination is looked up and the packet follows the selected next step. RFC 1306 records a more unusual arrangement. In a Cray project using a circuit-switched T3 network by request, the result of a routing lookup could help generate a message to a controller outside the host. The controller could make a connection at a point between the communicating hosts if it could. The route had become a carefully bounded trigger for a separate control action.

That does not make a route a circuit. The host had special knowledge that an ordinary downstream machine did not possess: this traffic might need a switched connection, and this controller was the place to ask. The switch request carried that knowledge outward. It did not collapse the switch's work, its capacity, its state or its decision into the routing table.

This distinction is easy to lose because the sequence can be fast. A lookup produces a request; the controller may act; the path may later become usable. Looking only at the first visible event invites a false shorthand: “the route made the connection.” RFC 1306 instead preserves the conditional. A controller makes the connection after receiving a request if it can. The phrase is not a rhetorical hedge. It tells an operator where evidence changes character. Before completion, there is a request and an unresolved external process. After completion, there may be a circuit. Neither statement says data have already travelled.

A transfer attempt could not be the activation mechanism

The report makes the boundary explicit: an attempted transfer over an incomplete connection should not automatically activate the circuit. TCP must not transfer data through that route until the circuit is complete. This is more than a guard against an untidy implementation. It prevents a data plane action from being silently reclassified as a control-plane authorization.

If a first send attempt itself created the circuit request, then an application can accidentally become the scheduler of an external resource. The failure modes become hard to read. Did the host request a circuit? Did the controller reject it? Is the circuit still being established? Was the first byte actually sent? Was it held, dropped or retried? One bare “connection” label makes all of those states look alike.

The Cray design chose a narrower chain. A route lookup identifies the special route. Kernel code can make a switch-control request. The circuit must become complete. Only then may TCP use it for data. The report also describes route aliases: alternate routes presented to a source through a familiar routing interface. Their policy and routing questions were deliberately outside its scope. That restraint matters. An alias can offer a possible route choice; it cannot settle who should choose it, whether a requested circuit will be created, or what a completed path means to any application.

The timer was a witness, not a verdict

The most revealing implementation detail comes before the first byte. In the first kernel implementation, normal TCP retransmission timers could back off while the switch connection was being made, even though no data had yet been transmitted. The later implementation added a separate timer for the circuit-establishment period.

Why does that small change deserve attention? A retransmission timer normally has a particular interpretive job: it measures the absence of an expected response to traffic that was sent. Letting it advance while an external circuit was still being requested confused two different absences. The host had not yet put data into a completed path, so the timer's backoff could not be cleanly read as a failure of an already-started data exchange.

The separate timer does not make the circuit succeed. It makes the waiting state legible. It records that the system is pending an external setup rather than pretending a familiar transport signal describes an event it has not observed. That is an operational discipline as much as a protocol detail: use a signal only for the state it actually measures.

What the report does—and does not—let us say

RFC 1306 is an Informational project report from March 1992. It gives a useful historical model, not a current deployment map or a guarantee about modern networks. It describes request and abort messages, controller interaction, route aliases and implementation observations in that setting. It does not prove that any present circuit, carrier arrangement or product behaves the same way.

Its durable lesson is more modest and more reusable. A control request may be necessary for a path to exist; it is still not proof that the path exists. A circuit may be complete; that is still not proof that TCP delivered data. Data may arrive; that is still not proof that an application goal, an operator obligation or a commercial promise was fulfilled. Keeping those layers distinct avoids turning a visible request into an imaginary result.

Sources

RFC 1306 documents a 1992 project experience. It does not establish a current deployment, route authority, capacity right, circuit completion, packet delivery or user outcome.