Frame Relay

Introduction to Frame Relay

Early connections between corporate offices in different cities often used X.25, a reliable but complex protocol. X.25 was designed for noisy, error-prone analog telephone lines. It used extensive error checking and flow control at every hop between network nodes. This improved tolerance of link errors, but also increased processing overhead on newer digital networks. Frame Relay assumed a lower error rate on digital links, so it reduced functions performed in switches and left recovery to end devices.

Frame Relay was developed in response to this problem. It is a simplified packet-switching technology for high-quality digital circuits. It reduces functions performed inside the network, leaving error detection and any recovery to end devices such as routers. Its main task is fast frame forwarding. This made it useful for building Wide Area Networks (WANs) in the 1990s and 2000s, especially where link quality reduced the need for extensive per-hop recovery. Q.922 specifies the frame-mode bearer data-link service and the fields used by that service.

Virtual circuits

Unlike datagram packet switching, where successive packets may take different routes, Frame Relay is a connection-oriented technology. The provider establishes logical forwarding state for a service before user data is sent. This does not reserve one physical wire for the customer. This logical path is called a Virtual Circuit (VC).

For example, a switch can receive a frame with DLCI 100 on one interface, look up its local mapping, and send it with DLCI 200 on another interface. The next switch can use another value. Frames belonging to the same VC follow these mappings even though the identifier changes between segments.

Identifying virtual circuits: DLCI

Each virtual circuit is identified by a Data Link Connection Identifier (DLCI). In the basic Q.922 format, DLCI occupies 10 bits in the frame header. The ranges have different uses: 16-511 are a user-data option, 512-991 identify logical link and user information, and 992-1007 are for layer-2 management. Thus, 16-1007 is not a single universal user-data range. DLCI is a locally significant identifier. On a given interface, its value selects an output port and may be changed before forwarding.

PVCs and SVCs

Frame Relay supports two types of virtual circuits. Link-layer signaling procedures can communicate their configuration and status:

Frame Relay frame structure

The simplified frame structure limits processing overhead in switches. The Frame Relay format is related to HDLC framing and contains a flag, header, data, and a check sequence. The basic header is 2 bytes, while address extensions can make it longer. Bit stuffing keeps the flag pattern from being confused with data, and the FCS covers the fields used for error detection.

• Flag (1 byte): Marks the beginning and end of a frame with the bit pattern 01111110.
• Header (2-4 bytes): Contains fields that identify the circuit and report congestion:
  • DLCI (10 bits): The virtual circuit identifier, as explained above. Its value selects a local forwarding entry on the interface.
  • FECN (Forward Explicit Congestion Notification, 1 bit): A switch may set the bit in a frame traveling in the same direction as the congested traffic to inform the destination about conditions on the path.
  • BECN (Backward Explicit Congestion Notification, 1 bit): A switch may set the bit in a frame traveling in the opposite direction to inform the source about congestion.
  • DE (Discard Eligibility, 1 bit): Marks a frame as eligible for discard. During congestion, the frame may be discarded, but DE does not define an absolute discard order.
• Data/Payload (Variable): This field carries the actual user data, typically an IP packet from the Network Layer. Its size is variable.
• Frame Check Sequence (FCS) (2 bytes): A 16-bit CRC value used to detect errors in the frame. If the calculated FCS differs from the received value, the receiver discards the corrupted frame. The FCS detects corruption on the link; it does not identify the cause of the error. Frame Relay detects errors, while retransmission and recovery are left to higher-layer protocols.

Service parameters: CIR and excess transmission

A Frame Relay service specifies traffic parameters for a virtual circuit. The main parameters are CIR and limits for data sent above the committed amount during a measurement interval. In the contract notation, Bc describes the committed amount, Be the excess amount, and Tc the measurement interval.

• Committed Information Rate (CIR):

  CIR is the agreed transmission rate, while Bc is the amount of committed data that the network supports during the measurement interval. For Bc and CIR, the relation is often written as Tc = Bc/CIR. It does not mean dedicated capacity available at every instant or a guarantee for each individual frame.

• Excess Burst Size (EBS or Be):

  Statistical multiplexing leaves capacity that is temporarily unused by other circuits. Be limits the excess amount sent above Bc during Tc, and delivery depends on available network capacity. In the standard model, Tc is derived from Bc and CIR, but it is not necessarily a repeating time slot. Excess data can be delivered when capacity is available, yet the contract gives it less protection under congestion.

• The Discard Eligibility (DE) Bit:

  Frames above the committed traffic profile may be marked with DE by an edge device. The mark tells switches that this traffic has less protection. During congestion, the network may discard these frames to release resources for other traffic. DE is a two-level priority indication, so it does not require every DE-marked frame to be discarded first.

Congestion signaling: FECN and BECN

Frame Relay uses shared resources, so a simultaneous increase in traffic can fill switch buffers. The FECN and BECN bits in the header report congestion in two directions.

• Forward Explicit Congestion Notification (FECN):

  A switch may set FECN in frames traveling in the same direction as the congested traffic. The destination then receives information about conditions on the path and may use it to trigger rate reduction in a higher layer.

• Backward Explicit Congestion Notification (BECN):

  A switch may set BECN in frames traveling in the opposite direction to inform the source about congestion. A router may then reduce its sending rate. The bit reports network conditions and does not prove that a particular source caused the congestion.

FECN and BECN form a simple feedback path for congestion information. The network and end devices can react to changing traffic conditions without performing error recovery at every hop.

Local Management Interface (LMI)

The user router, called DTE, and the provider switch, called DCE (Data Communications Equipment), exchange messages to manage the link state. The Local Management Interface (LMI) provides this management function.

LMI is a keepalive and status-reporting mechanism. In one example configuration, the router sends a status inquiry to the switch regularly, for example every 10 seconds. The interval depends on the variant and configuration. A status inquiry and its reply can also carry sequence information for monitoring the exchange. The response may contain:

• A list of all PVCs configured on that physical link.
• The status of each PVC (e.g., Active, Inactive, Deleted).

This lets the router detect which VCs are available and react when an active circuit changes state. Common variants include Cisco, ANSI, and an ITU-T variant associated with Q.933. Message details and status scope depend on the signaling version.