Summary

  • RFC 1483 let several protocols share one ATM virtual circuit when each PDU carried an LLC/SNAP identifier. Its alternative, VC-based multiplexing, omitted that per-PDU type label and required one protocol per virtual circuit.
  • VC multiplexing reduced header and processing overhead, but it made configuration or call negotiation part of the payload's meaning. A valid AAL5 PDU proved reassembly, not that the receiver had the right circuit binding, parser or application result.

The receiver had a complete envelope and an unfinished question

After the last ATM cell arrived, AAL5 could reconstruct a variable-length PDU and check its trailer. The receiver knew the envelope's length. It could detect corruption covered by the CRC. It knew which virtual circuit had delivered those ordered cells. It still needed to decide what parser should consume the payload.

RFC 1483, published in July 1993, answered with two deliberately different methods. LLC encapsulation placed an IEEE 802.2 header in front of the carried PDU, sometimes followed by SNAP. The leading bytes named the protocol or bridged media. Several protocols could therefore share the same virtual circuit because every PDU brought enough type information for the receiver to dispatch it.

VC-based multiplexing took the opposite course. The AAL5 payload did not carry a general multiprotocol label. The circuit itself identified the one protocol permitted on it. If two endpoints wanted to carry several protocols, they needed a separate VC for each.

Both methods could deliver an identical IP datagram to the IP layer. They did not place the evidence for that interpretation in the same object. With LLC/SNAP, the PDU testified about its type. With VC multiplexing, the PDU depended on a prior statement about the circuit.

The RFC Editor record compresses the choice into one sentence about several protocols on one VC versus one protocol on each VC. Operationally, that sentence divided the system's state ledger.

A smaller header did not mean less state

For routed non-ISO traffic, RFC 1483 used LLC AA-AA-03, a SNAP OUI and a protocol identifier. A zero OUI made the following value an EtherType; 0x0800 identified IP. A receiver could read that sequence in the payload it was processing.

Bridged traffic made the label do more. The SNAP OUI and PID identified the source-media family and whether the original frame check sequence had been preserved. A clean AAL5 envelope was therefore only the outer receipt. The bridge still needed the encapsulation fields to know how to reconstruct and handle the inner frame.

VC multiplexing removed those general dispatch bytes. That saved bandwidth and parsing work, and in some packet sizes could avoid extra fragmentation into ATM cells. Yet the protocol association still had to exist somewhere. For a permanent virtual circuit, operators configured it at both ends. For a switched virtual circuit, signalling negotiated it during call establishment.

This is a recurring systems mistake: treating absent bytes as absent complexity. RFC 1483 did not abolish a type field. It allowed the type to be represented by a relationship in a control-plane table—this VC means IP, that VC means a bridged Ethernet frame. A header lookup became a state lookup.

The trade also changed failure shape. A malformed LLC/SNAP label could be rejected within a PDU. A wrong VC binding could make every otherwise valid PDU on that circuit reach the wrong parser. The standard defined formats and selection; it did not provide evidence that a named installation configured every endpoint consistently.

Permanent and switched circuits placed the agreement at different times

RFC 1483 expected permanent circuits to use manual configuration. Before traffic arrived, both endpoints had to agree whether the VC used LLC encapsulation or VC multiplexing and, for VC multiplexing, which protocol the circuit represented.

Switched circuits moved that agreement into call control. RFC 1755 later specified how Broadband Low Layer Information could offer and select encapsulations. An endpoint could prefer VC multiplexing while also offering LLC/SNAP. The called side selected a supported choice or cleared the call if the offers were incompatible. The RFC 1755 information record describes the document as an implementers' guide for Classical IP over ATM signalling.

That exchange mattered, but it was not a data-plane success receipt. A SETUP message could be well formed. A CONNECT could select an encapsulation. Resources could be assigned along the path. None of those facts proved that a later PDU arrived, that its CRC passed, that its circuit binding remained correct, that IP accepted it or that the application completed useful work.

RFC 1755 made the dependency visible because the B-LLI information element was mandatory for specifying IP encapsulation. It also defined explicit rejection when required information was missing or no offered method was supported. In other words, negotiation could prevent one class of ambiguity before traffic. It could not certify the later chain.

Classical IP chose a default without pretending defaults were observations

RFC 2225 made LLC/SNAP the default packet format for Classical IP and ARP over ATM when there was no other knowledge or agreement. That decision gave independently built endpoints a common starting point. The RFC Editor record places it in the stable baseline for Classical IP and ARP over ATM.

The same text carefully located other facts outside each cell. The AAL type associated with a VC was administratively configured for a PVC or conveyed during SVC setup; it was not carried in the ATM cell header. A station supporting PVCs needed a way to know which circuits used LLC/SNAP. The architecture already relied on a mixture of in-band data and external association.

It also refused to overstate AAL5. Cell ordering was preserved on a VC, and the adaptation layer detected errors, but its service was non-assured. Higher layers supplied retransmission. A correct trailer was evidence about one assembled envelope, not a promise of end-to-end delivery.

PPP showed that authentication did not fuse the receipts

RFC 2364 later applied both choices to PPP over AAL5. It said plainly that VC-multiplexed payload type was agreed implicitly for the circuit through provisioning or control-plane procedures, while LLC encapsulation identified the type explicitly in-band for each PDU. The RFC 2364 information record locates that design in a point-to-point service that could use PPP negotiation, authentication and compression.

Even there, the receipts stayed separate. PPP authentication concerned the PPP session. RFC 2364 warned that it did not secure other LLC-encapsulated flows sharing the same virtual connection. A common carrier and common outer envelope did not merge the authority of the inner conversations.

This distinction blocks a tempting but false inference. If the circuit was provisioned, the protocol was negotiated and one session authenticated, an operator still could not use that chain to assert that every flow on the VC was authenticated, that every PDU was interpreted correctly or that an application transaction completed.

The replacement preserved the choice and narrowed the claim

RFC 2684 replaced RFC 1483 in 1999. It retained the same two-method architecture while clarifying ambiguities found by implementers. LLC generally meant fewer VCs in a multiprotocol environment. VC multiplexing generally meant less per-PDU overhead. The RFC Editor record marks the replacement without claiming that every earlier implementation ceased to exist.

Its later survey offered the most useful limit: multiprotocol encapsulation was necessary but generally insufficient for routing and bridging over ATM. Classical IP still needed address resolution and a logical-subnet model. Other environments needed their own control services. PPP used its own point-to-point contract. Encapsulation answered how to recognize and carry a PDU; it did not answer every question needed to operate the network above it.

Sources