Summary

  • In RFC 2024, a directory row said where a DLSw node currently believed a MAC address or NetBIOS name could be reached; it did not say an end-station circuit was up.
  • Transport, circuit, pacing and disconnect objects each answered a narrower question, and a defensible incident account had to preserve those boundaries.

A network manager asks a deceptively simple question: can this resource be reached? RFC 2024 answered by giving the manager several tables instead of one verdict. The directory could identify a location. An operational transport row could show that two DLSw peers had completed capability exchange. A circuit row could show the state of one end-station path. Pacing fields could show how much traffic was authorized before a sender had to wait. None of those records created the condition described by another.

That separation matters because DLSw carried traffic between older LAN environments across an IP network. A green value in the wrong table could look like service health while describing only one prerequisite.

A directory entry was a routing belief

The MAC-address and NetBIOS directory tables attached each resource to a location pointer. The pointer might lead to a local interface, a configured transport peer, an operational transport connection, a null reference or an implementation-specific table. The status was unknown, reachable or notReachable, but RFC 2024 framed it carefully: this was what DLSw currently believed about accessibility at that location.

The examples make the modesty concrete. A static entry could begin as unknown. The same remote resource could be listed through several partners. Ordering among candidate rows was not assured, and a tie between equally specific static and dynamic knowledge could be implementation-defined. A failed search could leave a notReachable entry specifically to prevent immediate repetition.

The directory therefore reduced the search space. It did not certify that the selected peer was connected, that circuit establishment had begun, or that an end station would answer.

The peer connection had its own clock

The transport operational table moved through connecting, initial capability exchange, connected, quiescing, disconnecting and disconnected. Here, connected meant that the peers had determined each other's capabilities and were ready for circuit-establishment messages. It was not shorthand for a functioning end-station session.

Even the link between configuration and operation could age. dlswTConnOperConfigIndex pointed to the configuration row governing a connection, but became zero if that row was deleted. If a manager changed configuration after the connection came up, some live settings could still reflect the earlier negotiation. RFC 2024 therefore made connection time and configuration modification time part of the evidence.

An implementation could also retain an operational row after disconnection to preserve statistics and failure information, without a mandatory retention interval. Partner capabilities recorded as received information could remain readable in that historical row. A populated capability field was consequently not proof of current availability.

Circuit establishment began after discovery

RFC 2024 described two stages of circuit bring-up. Explorer traffic first located the MAC address or NetBIOS name. Circuit establishment followed. Only when the second stage began did the circuit table acquire a row.

The circuit then had its own detailed state sequence. Its only settable state was disconnectPending; the MIB deliberately offered no management command to re-establish a circuit because the end stations drove establishment. Disconnect reasons and pointers into the underlying LLC or SDLC MIB could narrow an investigation, while traffic statistics sometimes required following those pointers. They were clues in a chain, not a self-contained root-cause report.

Pacing data was similarly specific. The granted-unit fields measured how many paced SSP messages a side was currently authorized to send before stopping to wait. Zero also covered the case in which pacing was not in use. A current window, or the largest represented window, was not a receipt for messages delivered and not evidence that application work completed.

Notifications captured transitions, not permanence

A transport-up trap could be emitted when a connection entered connected; a circuit-up trap could be emitted when a circuit entered connected. Trap generation was controllable and could be disabled. A received notification proved that one local agent reported a transition and that the notification arrived. It did not prove that the state persisted, that the partner recorded the same view, or that no later disconnect occurred. Silence, in turn, did not prove the transition never happened.

Disconnect time, reason and the active-circuit indicator could sharpen an outage account. The indicator said active circuits existed and end users might have been affected. It did not count affected users or establish business loss. RFC 2166 later carried broad HALT reasons aligned with categories such as end-station disconnect, DLC error, circuit-protocol error and operator action. Older peers could omit the reason, and vendor detail could vary. Better carriage narrowed the clue; it still did not make the clue an ultimate cause.

The whole view could require both nodes

RFC 2024 was unusually direct about cooperative management. Information available at both partner nodes was often defined as information received from the other side, reducing duplication in the MIB. A complete picture could require retrieving data from several DLSw nodes. The protocol also supplied no way to correlate a partner's managed transport address with the address used by the management protocol.

This makes every row local testimony with an explicit scope. Heng Lu's distinction between a record and the reality it describes offers a useful modern lens: the record can be accurate without being the whole operating state. That is an analytical application, not a claim about the RFC authors' intent.

The practical lesson is exact rather than sceptical. Use the directory to establish recorded location belief. Use the transport table to establish peer-connection state and negotiation timing. Use the circuit table for the end-station path. Follow DLC pointers for the lower-layer evidence, preserve notification settings, and compare both peers where possible. The tables become powerful when their joins are retained—and misleading when their labels are promoted into one universal green light.

Sources