Multiprotocol Interconnect over Frame Relay

Because DLCIs have only local significance and are modified in transit, a Frame Relay station has no source hardware address to populate in ARP requests. The solution is to use the DLCI from the incoming Frame Relay header to back-fill the ARP source hardware address at the receiver, violating strict layering but enabling correct address resolution.

Fragmentation was removed from this document (compared to RFC 1490) because no interoperable implementations of the RFC 1490 fragmentation algorithm existed and the mechanism was considered insufficient for some Frame Relay applications. Fragmentation is now handled by FRF.12.

IP is encapsulated using NLPID 0xCC rather than SNAP because it saves 48 bits per frame and is consistent with the established practice for IP encapsulation in X.25. Where a protocol has an assigned NLPID, SNAP is wasteful and should not be used.

ip

The Common PDU Header and Trailer are carried in bridged 802.6 frames to enable pipelining at the egress bridge: the BAsize field contains the PDU length, allowing the bridge to begin transmitting 802.6 segments before receiving the complete PDU.

For ISO protocols such as CLNP (NLPID 0x81), the NLPID is considered part of the protocol data and must not be stripped before passing to upper layers. For non-ISO protocols like IP (NLPID 0xCC), the NLPID is purely a demultiplexing value and not part of the protocol.

Non-canonical MAC destination addresses are used for encapsulated IEEE 802.5 and FDDI bridged frames (following RFC 1638 precedent), while canonical MAC destination addresses are used for all other bridging encapsulations (802.3, 802.4, 802.6).

The Common PDU Header and Trailer of an encapsulated 802.6 frame must not be simply copied to the outgoing 802.6 subnetwork, because the encapsulated BEtag value may conflict with the previous BEtag value transmitted by the egress bridge.

A compliant station must send and accept the NLPID-encapsulated version of protocols that have an assigned NLPID. It MAY accept a SNAP-encapsulated version of such protocols but is not required to, as those frames are noncompliant.

A Frame Relay network must support at least a 262-octet maximum frame size. A Frame Relay DTE must allow the maximum acceptable frame size to be configurable.

Because DLCIs have only local significance, ARP hardware addresses in transit are invalid at the destination. The receiving station must extract the correct Q.922 address from the Frame Relay header and place it in the source hardware address field of the ARP packet.

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 local, the local system shall reduce its maximum frame size to the remote value before generating the response XID.

In the LAN-modeled single virtual bridge port configuration, Frame Relay bridges must provide a mechanism to dynamically learn MAC-address-to-DLCI associations; bridged packets must conform to the Section 4.2 encapsulation to enable this learning.

IP data shall be encapsulated using the NLPID value 0xCC (indicating IP directly), not the SNAP form. This is more efficient (48 fewer bits) and consistent with IP encapsulation in X.25.

ip

Stations must be able to map more than one IP address in the same IP subnet (CIDR prefix) to a particular DLCI on a Frame Relay interface, to support proxy-ARP use cases such as remote-access servers.

ip

Upon receipt of an unsolicited (gratuitous) ARP request announcing a new IP-to-DLCI association, the receiving station must store the new association and remove any old existing association for that IP address from any other DLCI on the interface.

ip

Frame Relay bridges may be configured in LAN view (all VCs combined into one virtual bridge port, requiring flooding to each VC) or point-to-point view (each VC is a separate bridge port). When more than one virtual port exists within a remote bridge group, an extended Spanning Tree Algorithm (IEEE 802.1g) is required.

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

The NLPID (Network Level Protocol ID) field identifies the encapsulated protocol or encapsulation method. It is administered by ISO and ITU; values are defined in ISO/IEC TR 9577. A NLPID of 0x00 is invalid under Frame Relay encapsulation because it is indistinguishable from the pad field.

The pad field (0x00, single octet) aligns the data portion of the frame to a two-octet boundary. It is used when a SNAP header is present; when NLPID encapsulation is used directly, no pad is needed.

The Q.922 address field encodes the DLCI in the high-order bits along with C/R (Command/Response), FECN (Forward Explicit Congestion Notification), BECN (Backward Explicit Congestion Notification), DE (Discard Eligibility), and EA (Address Extension) bits. For ARP purposes, C/R, FECN, BECN, and DE are set to zero.

The Q.922 XID exchange allows negotiation of maximum frame size N201 (default 260 octets), retransmission timer T200 (default 1.5 s), and maximum outstanding I-frames K (3–40 depending on link speed). A K value of zero signals unwillingness to support acknowledged-mode operation.

A receiver must trust that the sender has correctly identified the encapsulated protocol; there is no mechanism to verify protocol identification in Frame Relay encapsulation.

security

ARP and RARP are used without authentication, making Frame Relay networks subject to the same known ARP security issues as other networks, including host impersonation. No additional security mechanisms have been added to ARP or RARP for use with Frame Relay.

security

A SNAP header consists of a 3-octet Organizationally Unique Identifier (OUI) followed by a 2-octet Protocol Identifier (PID). OUI 0x00-00-00 indicates that the PID is an Ethertype.

All protocols must encapsulate packets within a Q.922 Annex A frame consisting of: flag (0x7E), Q.922 Address (2–4 octets containing 10-bit DLCI), Control (UI = 0x03), optional pad (0x00), NLPID, Data, two-octet FCS, and closing flag (0x7E).

ip

ARP packets over Frame Relay are encapsulated with NLPID 0x80 (SNAP), pad 0x00, OUI 0x00-00-00, and PID 0x0806. The ARP hardware type (ar$hrd) assigned to Frame Relay is 15 decimal (0x000F); ar$hln is 2, 3, or 4 matching the Q.922 address length.

BPDU frames use NLPID 0x80 (SNAP), OUI 0x00-80-C2, and PID 0x00-0E for standard BPDUs (802.1d/802.1g) or PID 0x00-0F for Source Routing BPDUs. Unlike other bridged frames, no pad octet precedes the NLPID in the single-octet-per-line BPDU format.

Bridged 802.6 frames use PID 0x00-0B (no FCS variant only; CRC-32 presence is indicated by the CIB bit in the MAC frame header). The Common PDU Header (containing BAsize) and Trailer are included to enable pipelining at egress 802.6 bridges.

Bridged frames use NLPID 0x80 (SNAP), pad 0x00, OUI 0x00-80-C2 (IEEE 802.1), and a PID that identifies the MAC frame type and whether the original LAN FCS is preserved. PIDs with preserved FCS: 0x00-01 (802.3/Ethernet), 0x00-02 (802.4), 0x00-03 (802.5), 0x00-04 (FDDI); without FCS: 0x00-07 through 0x00-0B.

Routed frames for protocols without an assigned NLPID use NLPID 0x80 (SNAP), a pad octet 0x00, OUI 0x00-00-00, and the Ethertype as PID. Protocols with an assigned NLPID omit SNAP and pad, saving 48 bits.