Summary

  • RFC 2171 described a switch-made multiple-access network over point-to-point SONET/SDH. A node inherited the identifier of its switch port; in a cluster, the address combined switch and port portions.
  • The destination field told switches where to forward an HDLC frame. It did not authenticate the attached machine, its owner or an organisation, and an invalid destination could be discarded without a delivery receipt.
  • The June 1997 memo was Informational, not an IETF working-group or standards-track product. Its possible topologies and companion protocols were design descriptions, not evidence of broad deployment or interoperability.

Move the cable, change the address

The most revealing sentence in RFC 2171 is not about optical capacity. It says that a node attached to a switch port must inherit the address of that port. Within one switch, the node address and the port identifier were equal. The apparent address of the machine therefore began as a property of the attachment selected by the switching fabric.

That choice solved a forwarding problem. SONET/SDH supplied point-to-point optical transmission. MAPOS placed network-protocol datagrams inside HDLC frames and inserted a frame switch between several such links. The switch made those separate links behave like a multiple-access LAN: a sender placed a destination in the frame, and the switch used that value to choose an output port.

RFC 2171 showed a direct link, a star around one frame switch and a cluster of linked switches. In a cluster, the address was divided. High-order bits identified the switch; the remaining low-order bits identified the node address within that switch. The companion Node Switch Protocol in RFC 2173 states the rule even more bluntly: the HDLC address was equivalent to the port number to which the node was connected.

This is useful precision. “Node address” can sound like a durable name for a machine. In MAPOS it was a compact route through a bounded topology. If the attachment changed, the forwarding fact changed. The computer, operator and legal owner did not have to change with it.

Six bits for a reachable attachment

The RFC 2171 address field was eight bits wide. Its least-significant bit marked the end of the field. For unicast, the most-significant bit was zero, leaving six bits for the destination node address. All ones meant broadcast, while 0x01 was reserved for the switch's control processor. The frame carried no separate source-address field.

In a single switch, those usable bits selected a port. Across a cluster, part of the same small field selected a switch and the rest selected a port under it. RFC 2174 described how a switch extracted the switch portion, consulted a routing table when the destination was remote, and used the port portion when the destination was local.

Uniqueness was consequently scoped. A value could be unique inside one switch or one configured cluster without being a global identifier. RFC 2173's direct point-to-point special case makes the boundary unmistakable: both endpoints could receive 0x03, and the memo said this caused no problem because any address worked in that arrangement. An identifier that may be duplicated harmlessly when the topology changes is not an intrinsic identity token.

Automatic assignment did not alter that conclusion. A newly connected node could send a request to the local switch control processor and receive its address. It had to verify the value every 30 seconds; absence for more than 90 seconds could make the switch assume that the node was down. These messages maintained local attachment state. They did not prove who owned the node, which organisation operated it or whether the same physical machine had appeared somewhere else.

A forwarding decision is not a delivery receipt

RFC 2171 described connectionless transmission. A node filled in a destination, placed the frame in one or more SONET/SDH payloads and sent it. A switch or cluster forwarded according to the destination. If the address was invalid, the frame was silently discarded.

That last rule exposes the evidence boundary. The presence of a destination value proves what the sender asked the fabric to select. A routing-table match shows that a switch found a next hop or local port. Neither fact alone proves that the intended host received the frame, that an upper-layer protocol accepted it or that an application completed useful work. Silent discard supplies no positive acknowledgement at all.

The namespaces above MAPOS remained separate. RFC 2176 required an ARP cache to map an IPv4 address to an 8-bit HDLC address. The need for that mapping is itself instructive: an IP address was not the port-derived MAPOS value, and the MAPOS value did not become a persistent host identity merely because a cache associated the two.

MAPOS also inherited HDLC-like framing mechanics from RFC 1662. That lineage explains the frame format, not real-world adoption. RFC 2171 expressly said that it was Informational, was not produced by an IETF working group and had not necessarily received standards-track review. It discussed no security issues and even catalogued SONET/SDH implementation differences that could cause interoperability problems.

The historical lesson is narrower and stronger than “optical networks had addresses.” MAPOS encoded a switching decision in a short field. The field could be operationally sufficient while remaining evidentially modest: it located an attachment inside a particular fabric, and nothing more should be inferred without another source of proof.

Sources and limits

These documents do not establish broad deployment, measured interoperability, authenticated host identity, ownership, successful end-to-end delivery or present operational use.