Summary

  • RFC 1223 carried ES-IS and IS-IS over HYPERchannel, a medium that offered neither genuine broadcast nor multicast.
  • The repair was list-driven replication: configured and learned recipients received individual, paced copies while the routing protocol was allowed to experience the operation as multicast.
  • A valid control PDU or one observed copy did not prove that the list was complete, every copy was transmitted and received, an adjacency formed, routing converged or data was delivered.

A broadcast protocol met a network without broadcast

RFC 1223, published in May 1991, explained how OSI CLNS and other LLC1 traffic could run on Network Systems Corporation HYPERchannel equipment. Its RFC Editor record classifies the memo as Informational, and the IETF Datatracker preserves it in the Legacy stream. It described a historical implementation contract, not an Internet Standard or a census of deployed networks.

The hard part was not the LLC1 type value or the header offset. ES-IS and IS-IS assumed a subnetwork where one control message could reach a group. HYPERchannel negotiated point deliveries and sometimes fanned several hosts through shared equipment, but its technology supplied no genuine broadcast facility. RFC 1223 said so plainly. The document's techniques solved specific routing problems; they did not manufacture general multicast.

That distinction turns an abstract protocol event into several operational records. The originator can construct one ESH, ISH or IS-IS PDU. A local process then selects recipients. The adapter sends each copy. Each listener may or may not receive and process it. Only later can adjacency or topology state change. “A multicast was sent” compresses all those stages into a sentence the medium itself never performed.

Membership came from configuration and observation

With real Intermediate Systems present, each End System was profiled with a list of them. To originate an End System Hello, it sent an individual copy to each known IS. The static list was not the only source: if the End System received an ISH from an unlisted IS, it should remember that address for the Hello's holding time.

The recipient set therefore had provenance. One address might come from operator configuration; another from a recently observed control packet. One could persist until an edit; the other expired with a timer. A merged in-memory list did not erase those differences. To audit coverage, an operator needed the list version, its sources and the time at which the fan-out occurred.

RFC 1223 recommended spacing End-System copies, with 0.1 seconds described as probably suitable on most systems. Pacing protected useful traffic, but it also meant that the copies did not share one instant. Queue admission, transmission and failure could differ for the first and last member. A receipt from one member did not stand for the series.

The routers needed a complete list

Intermediate Systems were also profiled with the addresses of other Intermediate Systems. For IS-IS, completeness mattered. The protocol's designated-IS behavior made partitioning the IS set especially dangerous. When an IS sent an IS-IS message, it consulted the list of all relevant Level 1 or Level 2 systems and emitted an individual copy to each. RFC 1223 intended the multiple transmissions to remain transparent to IS-IS.

Transparency was useful for protocol software and risky for evidence. The upper layer could report one successful send even though lower layers held a fan-out plan, several queue events and several outcomes. RFC 1142 records the contemporary IS-IS model, while RFC 1195 shows its use in IP and dual environments. Neither turns a local recipient list into proof of complete topology dissemination.

The same caution applied to ES-IS. RFC 995 supplies the End-System/Intermediate-System exchange context. RFC 1223 supplied a subnetwork-specific imitation. Correct PDU syntax proved the control object was intelligible. It did not prove all intended peers were named, reachable or updated.

Without a router, an address manager played one

RFC 1223 also handled a HYPERchannel network with no true Intermediate System. One or more systems could act as SNARE address managers. End Systems had to be configured with every system serving that role. Multiple managers offered redundancy, but redundancy depended on the same list being complete.

A SNARE appeared as an IS, recorded ESH information, forwarded a packet toward the correct End System and returned a redirect to the originator. Those verbs describe separate observations. Being designated an address manager did not prove it had heard the current ESH, forwarded a particular packet or delivered the redirect.

There was no ES-IS query-configuration function on this medium. Every system needed at least one configured true IS or SNARE. The absence matters: discovery could supplement a list in some cases, but it could not rescue a system that began without the required seed. The configuration record was part of reachability, not mere administrative decoration.

One protocol action, many physical liabilities

RFC 1223's emulation preserved a clean interface for routing software. It also exposed why interface-level success is not network-wide evidence. Protocol intent, membership selection, copy creation, pacing, transmission, receipt, database update, convergence and data delivery belonged to different actors and clocks.

The durable lesson is not that unicast replication is defective. It is that abstraction transfers responsibility. When software presents many sends as one multicast, the system must still retain the plural evidence underneath. Otherwise a missing recipient becomes indistinguishable from a missing list entry, an expired learned member, a queued copy, a failed link or a control packet that arrived but changed no route.

Sources