Summary

  • RFC 1307 offered a transport provider only up and down while DSLCP maintained six internal states to reconcile controller replies with connect and release requests that could reverse before earlier work finished.
  • From Up, a release caused DSLCP to send a teardown request, enter Going Down and immediately tell the provider that the link was down; the logical answer therefore preceded controller completion.
  • The RFC always returned teardown success to the provider and could continue as if success after the controller reported an unknown transaction, so local convergence, controller state and physical teardown remained distinct evidence.

The cheap interface governed an expensive link

Circuit switching created an unusual problem for an Internet host in 1992. The link that could carry a large transfer was too expensive to leave connected, yet arranging it took work outside the host. The useful moment to acquire it was when a transport session needed the path; the useful moment to release it was when that demand ended.

RFC 1307 documented the Dynamically Switched Link Control Protocol, or DSLCP, as an Experimental answer. The transport provider knew that a special downstream link had to be prepared. A link controller knew the hardware and administrative details. DSLCP stood between them and gave the transport side a simple request-and-release interface.

That division was practical. A transport implementation did not need a private vocabulary for every switch. The controller could absorb equipment differences. The host could make an expensive network resource temporary instead of permanent. But the simplicity was achieved by hiding state, not by eliminating it.

The RFC's enduring subject is therefore not merely a T3 circuit. It is the relationship between a clean local promise and a complicated external act. What did the caller know when the control layer said down? What remained pending? Which record owned the truth if a late response contradicted the current state?

These questions do not weaken the interface. They describe its boundary.

The control path existed before the data path

DSLCP prepared a downstream link, but the messages that requested that preparation needed another route. RFC 1307 required a network path between the host providing transport services and the link controller before the DSLCP transaction began. Control messages could be carried by IP or UDP datagrams; the protocol did not require reliable transport.

The distinction is easy to overlook in a picture of a single connection. The host could reach the controller while the requested data link was absent. A delivered control request therefore proved neither that the controlled link existed nor that application data could already cross it. One path carried an instruction about another path.

This made at least four observations possible at once: the control route was usable, the setup request left the host, the controller had or had not replied, and the physical data link remained in some state. Reporting only “the network worked” would erase which network and which operation had been observed.

RFC 1307 left the details of link preparation to the controller. That was the correct abstraction for interoperability. It also meant the transport provider was not the authority for the switch's internal work. Its view had to be constructed from messages.

A transaction was more than its short identifier

The control message carried an identifier, total length, function, event status, two endpoint addresses and a controller-specific body. The 16-bit identifier was intended to be combined with the endpoint addresses when the controller identified a transaction.

That compound context matters. An identifier alone was small enough to recur. The endpoints placed it within a particular requested connection. The function said whether the message concerned bring-up or bring-down. Event status described the controlled link relative to the last function request.

“Relative to the last request” is a strong limitation. A setup-success value was not a timeless certificate that the link must still be up. A teardown result could arrive after user demand had reversed. An asynchronous network-down event belonged to yet another cause. The status gained meaning from transaction, endpoints, prior state, outstanding action and time.

If those fields are separated in storage and later recombined by an observer, a control exchange can be reconstructed. If they are flattened into a line saying “success”, the word becomes transferable to claims the protocol never made.

Two visible states required six hidden states

The transport provider was aware of only two possible states: up and down. DSLCP, however, used six.

Down meant no active transport connection and no prepared controlled link. Coming Up meant demand existed, setup had been sent and a controller response was pending. Up meant the link was prepared and at least one transport connection was active. Going Down meant demand had ended, matched up/down requests had accumulated, teardown had been sent and a response was pending.

The two remaining states existed because people and applications do not wait politely for external operations to finish. In Bring Down, a release arrived while setup was still pending. DSLCP could not pretend the setup request had never been sent. It waited for the response and, if setup succeeded, followed with teardown. In Bring Up, new demand arrived while teardown was pending. DSLCP waited for that operation to resolve, then sent setup again.

The visible binary state was therefore a projection of a temporal process. An internal state could say: the present intention is down, the previous setup is outstanding, and a compensating action may be required. Another could say: present intention is up, teardown is already in flight, and setup must follow.

No single Boolean could preserve all of that. The Boolean was still useful because the provider needed an instruction—proceed or wait—not a controller transcript. Trouble begins only when the instruction is later cited as if it were the transcript.

One link could serve more than one request

RFC 1307 also recognised that multiple transport users might depend on the same controlled link. If one connection already kept the link active, another setup request could receive an immediate ready answer, provided the link supported multiple transport connections. Teardown waited until the corresponding demand had been released.

This created another separation. A user's release was not necessarily a link teardown. It reduced demand. The external link could remain needed by another transport connection. Conversely, the last local release could initiate teardown without proving that the controller had finished it.

The relevant record was not simply “user closed”. It was the active-demand count, capability for concurrent connections, internal state and controller transaction. Capacity accounting and service ownership lived outside a single user's action.

The RFC required errors when a link unable to support multiple connections encountered multiple setup requests. Even there, a capability limit differed from the current physical state. The link might exist and still be unavailable for another transport session.

Down was an instruction before it was a physical receipt

The sharpest boundary appears in the teardown table. When a provider requested release while DSLCP was Up, DSLCP sent a teardown request, entered Going Down and notified the provider that the link was down.

At that moment, the controller response was still pending by definition. The local answer told the transport layer how to behave. It did not certify that the external switch had already dismantled the circuit.

The RFC reinforced that abstraction in general terms. DSLCP informed the provider whether setup succeeded or failed, but the provider could assume teardown success because DSLCP would always return a successful response to a teardown request.

This asymmetry made sense. Setup success was a prerequisite for sending data, so false optimism could put traffic onto an unavailable path. Release was different. Once no local transport user should depend on the link, the provider needed to stop treating it as available. DSLCP could finish reconciliation below that boundary.

Yet a later audit asks different questions from a live caller. Did the controller receive the request? Did its transaction record exist? Did a physical switching action occur? When was capacity released? Did charging stop? A local down answer supplies none of those facts by itself.

Unreliable control meant repetition without repetition of intent

DSLCP deliberately avoided requiring reliable transport. It therefore needed timeouts and retransmissions. The authors reported a five-second timeout and three retransmits in their quick local-controller environment, while warning that other configurations would need different values and ideally an adaptive approach.

A retransmitted datagram repeated a control message because an observation was missing. It did not necessarily represent new user intent. The original request might have arrived and its reply might merely have been delayed. The second request might prompt a redundant response. Packets could be reordered.

RFC 1307 explicitly prepared for unexpected controller messages produced by duplicate requests after timeouts. This is why message receipt cannot be interpreted without the outstanding transaction and local state. The same setup-success code could be welcome in Coming Up, irrelevant in Up, or evidence of stale work in Down.

The timeout also did not identify which component failed. The request could be lost, the controller unavailable, the reply lost or the configured interval unsuitable. Retransmission was a recovery action under uncertainty, not a verdict about the controller.

A real success could already be obsolete

Consider setup success arriving while DSLCP was locally Down. The RFC says the message might have resulted from duplicate requests and network reordering. The prescribed response was not to reopen the link for an absent user. DSLCP sent teardown.

The success could be authentic within its original transaction and wrong for the present intention. This is a crucial property of asynchronous control: validity and applicability are separate.

In Bring Down, the same logic was expected. Setup had begun, the user then released, and a successful controller response completed the obsolete action. DSLCP immediately requested the opposite state and entered Going Down.

A monitoring system that records only the latest success code can invert the story. It may conclude that demand was satisfied at the very moment the state machine was cancelling the now-unwanted link. Preserving the request sequence shows that the setup succeeded historically but no longer governed the desired state.

A teardown success could reveal disagreement

Late teardown success had its own paradox. If it arrived while DSLCP was Up, the RFC said some error had occurred. A previous teardown apparently completed while the host's current view still supported an active link.

The conservative response was to bring down the connection and resynchronise, although the text noted that ignoring the message might sometimes cause no harm. That choice exposes the protocol's epistemic position. The message mattered, but it did not uniquely reconstruct the world. The implementation had to choose a recovery policy.

Resynchronisation is evidence that local and remote state were no longer assumed to match. It should not be disguised as ordinary success. The useful event record would include the unexpected response, state at receipt, outstanding request, recovery decision and subsequent physical or data-plane observation.

An unknown transaction could still end in local success

The most striking rule concerns teardown failure while Up. The controller reported that the teardown referred to an invalid transaction: it had no record for the identifier and endpoint pair. DSLCP was instructed to continue as though the request had succeeded.

This did not mean the controller confirmed a physical teardown. It meant that, from the protocol's local convergence perspective, there was no controller transaction left to dismantle under that identity. Continuing prevented an unresolvable record mismatch from trapping the transport provider forever.

Several histories could sit behind the same reply. A prior teardown might have removed the record. State might have been lost. The identifier context might not match. The RFC did not choose among them. It specified what DSLCP should do next.

“As if succeeded” is therefore procedural language. It authorises a state transition within the local protocol machine. It is not a retrospective statement that a named switch operation occurred. Converting the former into the latter would manufacture evidence.

Network-down was not user release

The controller could also send an asynchronous network-down event. In active or transitional up states, DSLCP moved to Down and notified the provider. This path did not begin with a transport user releasing service, and it was not a successful response to a host teardown request.

The provider might see the same binary result—down—from very different causes: no demand, setup failure, teardown progression, response timeout, controller-reported network failure or reconciliation after an unexpected message. Cause belonged to the transition record, not the Boolean output.

That distinction affects accountability. A planned release, controller rejection and external network loss cannot share one explanation merely because all leave the caller unable to use the link.

Security was outside the claim

RFC 1307's Security Considerations section says security issues were not discussed. The absence is a limit, not a favourable result.

The document does not establish how controller messages were authenticated, who was authorised to request costly links, whether datagrams had integrity protection, how endpoint claims were validated or whether controller-specific strings disclosed sensitive information. The state machine can be studied without filling those gaps by invention.

Likewise, the RFC is an Experimental protocol description from one historical project context. It is not evidence of a current carrier system, a live circuit or a universal implementation practice.

Sources

The source establishes the protocol's 1992 design, message semantics and state-machine rules. It does not establish a real controller exchange, physical teardown, capacity release, billing result, security property, packet delivery or application outcome.