Multiprotocol Interconnect over Frame Relay

Frame Relay fragmentation has no reassembly timer because the Frame Relay service is required to deliver frames in order; if a fragment is corrupted or missing during reassembly, the entire message is dropped and retransmission is the responsibility of the upper layer protocol.

In a Frame Relay network, bridging requires a full mesh of virtual circuits between all bridges in a remote bridge group. If the Frame Relay network is not a full mesh, the bridge network must be divided into multiple remote bridge groups, each of which is internally fully meshed.

The 802.6 bridged frame format includes the Common PDU Header and Trailer to allow pipelining at egress bridges: the BAsize field contains the PDU length, enabling the bridge to begin transmitting segmented PDUs onto the 802.6 subnetwork before receiving the complete frame. The encapsulated BEtag must not be copied directly to the outgoing 802.6 subnetwork as it may conflict with a previously transmitted BEtag.

To eliminate conflicts among multiple valid encapsulation paths, SNAP encapsulation is used only when no NLPID value is defined for a given protocol. Protocols with an assigned NLPID (e.g., IP = 0xCC, CLNP = 0x81) use the NLPID directly.

Unlike IP fragmentation, Frame Relay fragmentation is scoped to the Frame Relay network boundary (DTEs only). A packet is first encapsulated as normal, then large frames are broken up and wrapped in the fragmentation format, allowing reassembled packets to pass through the same processing path as non-fragmented packets.

Because DLCIs are locally significant, a Frame Relay station has no valid source hardware address to place in ARP requests or replies. The receiving station must extract the correct Q.922 address from the Frame Relay header and insert it into the ar$sha field; target hardware addresses in both request and reply are also invalid and may be zeroed.

ip

For ISO protocols such as CLNP (NLPID 0x81), the NLPID is considered the first octet of the protocol data and must not be removed before passing to upper layers; it serves double duty as both the demultiplexor and the start of the PDU. For non-ISO protocols like IP, the NLPID is not part of the protocol data.

Systems that can transfer both this encapsulation method and others must have a priori knowledge of which virtual circuits carry which encapsulation method; this encapsulation must only be used over VCs explicitly configured for it.

A Frame Relay DTE must allow the maximum acceptable frame size to be configurable; the network must support at least a 262-octet maximum frame, though it is generally 1600 octets or greater.

All protocols must encapsulate their packets within a Q.922 Annex A frame, and frames shall contain information sufficient to identify the protocol carried within the PDU.

All stations must be able to accept and properly interpret both the NLPID encapsulation and the SNAP header encapsulation for routed packets.

Fragments must be sent in order starting with a zero offset, ending with the final fragment (F=1), and must not be interrupted by other packets or information intended for the same DLC. An end station must be able to reassemble up to 2K octets.

Frame Relay LAN-modeled bridges must provide a mechanism to dynamically learn associations between destination MAC addresses and DLCIs; it is unreasonable to require static configuration of every possible destination MAC address.

If a station supporting XID receives an XID frame, it shall respond with an XID response. If the remote maximum frame size is smaller than the local maximum, the local system shall reduce the maximum size to the remotely specified value before generating the response.

IP data shall be encapsulated using NLPID value 0xCC (indicating IP directly) rather than the SNAP method, because it is 48 bits more efficient and consistent with IP encapsulation in X.25.

ip

BPDUs are bridged using OUI 0x00-80-C2 and PID 0x00-0E, identifying them as Bridge Protocol Data Units as defined by IEEE 802.1(d) or 802.1(g). The BPDU frame does not carry a preserved LAN FCS field.

Frame Relay bridges support two virtual port models: (1) LAN view, combining all VCs into a single virtual bridge port requiring dynamic MAC address-to-DLCI learning and artificial flooding; (2) point-to-point view, treating each VC as a separate bridge port. The extended Spanning Tree Algorithm (IEEE 802.1g) is required when more than one virtual port exists within a remote bridge group.

Frame Relay stations may optionally negotiate data link layer parameters via the Q.922 Appendix III XID exchange: maximum frame size N201 (default 260 octets), retransmission timer T200 (default 1.5 s), and maximum outstanding I-frames K (3/7/32/40 depending on link speed). A window size K of zero signals unwillingness to support acknowledged mode.

Inverse ARP (RFC 1293) is supported for resolving a protocol address when the DLCI (hardware address) is already known, following the same source-hardware-address replacement pattern as ARP and RARP: the receiving station inserts the Q.922 address from the frame header into the ar$sha field.

ip

NLPID value 0x08 (CCITT Q.933) is used for protocols that have neither an assigned NLPID nor a SNAP encapsulation. The four octets following the NLPID carry both layer 2 and layer 3 protocol identification using code points defined in ANSI T1.617.

The Network Level Protocol ID (NLPID) field, administered by ISO and CCITT per ISO/IEC TR 9577, identifies the encapsulation or protocol following it. A NLPID of 0x00 (Null Network Layer) is invalid under this encapsulation because it is indistinguishable from a pad octet.

The RFC explicitly states that security issues are not discussed in this memo. No authentication, integrity, or confidentiality mechanisms are defined for multiprotocol encapsulation over Frame Relay.

security

ARP over Frame Relay is encapsulated as a SNAP frame with OUI 0x00-00-00 and PID 0x0806 (ARP Ethertype). The hardware type field ar$hrd is assigned value 15 (0x000F) for Frame Relay; ar$hln is 2, 3, or 4 bytes matching the Q.922 address length.

ip

Bridged frames use NLPID 0x80 (SNAP), OUI 0x00-80-C2, and a two-octet PID that identifies both the MAC frame type (802.3/802.4/802.5/FDDI/802.6) and whether the original LAN FCS is preserved. PIDs 0x00-01 through 0x00-04 preserve FCS; 0x00-07 through 0x00-0B do not.

Fragmented packets use NLPID 0x80, OUI 0x00-80-C2, PID 0x00-0D, followed by a 2-octet sequence number, then a word containing: 1-bit Final flag (F), 4-bit reserved (must be 0), and 11-bit offset (logical byte offset divided by 32). The first fragment has offset 0; the last fragment has F=1.

Routed frames for protocols with an Ethertype but no NLPID use: Q.922 Address, Control 0x03, pad 0x00, NLPID 0x80 (SNAP), OUI 0x00-00-00, Ethertype (2 octets), Protocol Data, FCS. Protocols with an assigned NLPID omit the SNAP header and pad, saving 48 bits.

The basic frame format wraps each PDU in a Q.922 Annex A frame containing: flag (0x7E), Q.922 Address (2–4 octets with 10-bit DLCI), Control (UI = 0x03), optional pad (0x00), NLPID, Data, and two-octet FCS, terminated by a closing flag (0x7E).

ip, multicast

The SNAP header is five octets: a three-octet Organizationally Unique Identifier (OUI) followed by a two-octet Protocol Identifier (PID). OUI 0x00-00-00 indicates the PID is an Ethertype; OUI 0x00-80-C2 is reserved for IEEE 802.1 bridging PIDs.