Summary

  • RFC 1294, a January 1992 Standards Track specification, defined a multiprotocol Frame Relay encapsulation for routed and bridged traffic. Its abstract required prior knowledge of which virtual circuits carried which encapsulation method and limited this method to VCs explicitly configured for it.
  • The Q.922 frame’s NLPID or SNAP information let the receiver identify what followed in one PDU. That dispatch information did not configure the VC, prove that the endpoints had agreed, or establish that a correctly labelled frame was delivered, bridged or routed.

The opening rule in RFC 1294 — Multiprotocol Interconnect over Frame Relay can look like a detail of packet engineering: use the specified encapsulation only over virtual circuits explicitly configured for it. But the rule draws a durable line between two kinds of knowledge that networking descriptions often flatten into one successful-looking frame.

One kind of knowledge arrives inside the frame. A receiver needs to know how to interpret the bytes after the Frame Relay address and control fields. RFC 1294 uses a Network Level Protocol ID, or NLPID, for that purpose. If a protocol does not have an assigned NLPID, a SNAP header can introduce an organisation identifier and protocol identifier; with OUI 00-00-00, the final identifier is an EtherType. These are meaningful instructions for parsing the next part of this PDU.

The other kind of knowledge exists before the PDU is sent. A station capable of this encapsulation and another one needs to know which virtual circuit carries it, rather than another encapsulation method. The RFC calls for prior knowledge and explicit VC configuration. A protocol label describes the frame presented to a receiver. Configuration constrains the space in which such a frame is entitled to be used. The label cannot silently supply the configuration it presupposes.

A DLCI named a local attachment, not a complete operating policy

RFC 1294 begins with a Frame Relay group made of virtual circuits. The group may be fully meshed or partial. Each circuit is identified at each Frame Relay interface by a Data Link Connection Identifier, and the RFC says that DLCIs have strictly local significance in most circumstances. A DLCI therefore makes a precise claim at one interface: this is the local label through which that virtual connection is addressed here.

It does not follow that the same numeric value identifies the same circuit elsewhere, names a remote machine, records a protocol choice, or proves that a peer is currently willing to process a particular frame. RFC 1294 later explains that the network can rewrite a DLCI as a packet crosses it. The local number at the receiving side can be different from the local number at the sending side. The address field is part of a local handoff, not a portable statement of the whole path.

This matters because an interface label is easy to mistake for a policy handle. A trace may show a DLCI. An operations record may report a circuit. A frame may be addressed through it. Those statements establish different things. The RFC does not turn any one of them into proof that the endpoints have made the required encapsulation assignment, or that an implementation accepts every syntactically identifiable protocol type on that circuit.

The frame had to say what it carried

The specification required all protocols to be encapsulated in a Q.922 Annex A frame and required the frame to contain information that identifies the protocol in its PDU. The ordinary control value was UI 0x03, unless negotiated otherwise. Padding could be present for alignment, but it had to be zero. This led to a small but revealing exclusion: NLPID 0x00 was invalid because it could not be distinguished from padding and did not have useful meaning in the Frame Relay encapsulation.

That is an example of a label doing its limited job. An identifier is useful only if the receiver can distinguish it from surrounding structure and give it a defined interpretation. RFC 1294 made room for directly assigned NLPIDs, including 0xCC for an IP datagram. It also set out a SNAP route for protocols that did not possess a specific NLPID: NLPID 0x80, OUI 00-00-00, then the EtherType. Stations were required to accept both the NLPID and SNAP forms for routed packets.

The requirement to accept two encodings is an interoperability rule about decoding. It is not an instruction that either format may be placed on any VC without the pre-existing assignment stated in the abstract. Acceptance grammar and circuit admission are separate questions. A receiver can know what a byte sequence claims to be while the system still lacks the configuration that would make that sequence an allowed use of this particular virtual connection.

Routed and bridged did not become one assertion

RFC 1294 distinguished routed and bridged packets because they have distinct formats. That distinction is carried in NLPID and SNAP header information so a destination can interpret the incoming frame appropriately. For bridged traffic, NLPID 0x80 announces SNAP and OUI 00-80-C2 identifies the 802.1 organisation; the following PID distinguishes the MAC-header form and whether an original frame check sequence is preserved.

Those fields can be exact and still modest. They help a receiver decide which framing procedure applies. They do not certify that the original LAN frame was authentic, that a bridge will forward it, that another bridge has agreed on the same service, or that a remote LAN outcome has occurred. A classification token chooses a parsing path. It does not complete the path.

This is particularly important when a description moves from packet capture to operational conclusion. “It was marked as bridged Ethernet” may be a well-supported observation about a header. “The Ethernet was bridged successfully” is an additional claim about processing and forwarding. “The VC was configured for that service” is a claim about prior endpoint policy. RFC 1294 gives readers tools to keep those propositions apart rather than a licence to merge them.

Negotiation was not a substitute for all configuration

The document also describes optional Exchange Identification, or XID, at Frame Relay circuit initialisation. XID can negotiate selected data-link parameters: maximum frame size N201, retransmission timer T200 and maximum number of outstanding I frames K. If XID is not used, those values must be statically configured by mutual agreement of the data-link endpoints or use the Q.922 defaults. A receiver that supports XID and receives an XID frame must respond; if the remote maximum frame size is smaller, the local system must reduce the size it uses over that DLC before it sends the response.

This is a narrow example of a real agreement procedure. It does not erase the RFC’s earlier requirement to know which VCs carry which encapsulation method. Nor does one successful XID exchange establish a packet’s delivery, the content of an upper-layer protocol, a bridge result or a service guarantee. It gives particular parameters an agreed or defaulted basis. Its precision is the lesson: the RFC names what the exchange covers instead of letting the existence of an exchange stand in for every other operational decision.

The useful record is a chain, not a header field

For an operator investigating an old Frame Relay interconnect, the necessary records would be separate: the local interface and DLCI, the VC’s encapsulation assignment, any XID or static parameter agreement, the captured Q.922 frame, the NLPID/SNAP interpretation, the receiving implementation’s action and any later upper-layer result. RFC 1294 gives strong evidence about some of these records. It does not manufacture the rest.

A correct NLPID can support “the frame presented itself as this protocol.” A matching SNAP OUI/PID can support “this was the indicated bridged framing.” A configuration record can support “this VC was assigned this encapsulation.” A later counter or trace can support a forwarding observation. None automatically proves the adjacent step. Keeping the chain intact avoids the tempting sentence “the circuit worked” when the available evidence may concern only one labelled frame.

RFC 1294’s contribution was not simply a menu of header layouts. It made a multi-protocol shared transport legible without pretending that legibility was authority. The PDU carried a clue for its receiver. The VC carried an explicit, prior allocation of permitted encapsulation. The endpoints could negotiate some parameters or statically agree them. Each mechanism had a boundary, and interoperability depended on not asking one boundary to do another’s work.

Sources and evidence limits

The sole source is RFC 1294 — Multiprotocol Interconnect over Frame Relay. It supports the January 1992 Standards Track status, the explicit-configuration requirement, local DLCI significance, Q.922/NLPID/SNAP formats, routed/bridged distinction and optional XID/static parameter arrangement. It does not prove a current carrier, PVC, configuration, peer, implementation, security property, forwarding event, delivery or service outcome.