Frame Relay
Packet-switched WAN technology with virtual circuits and congestion control.
Introduction: A Smarter, Faster WAN Technology
Imagine the early days of connecting corporate offices across different cities. The primary technology available was X.25, a reliable but notoriously slow and complex protocol. X.25 was designed for an era of noisy, error-prone analog telephone lines. It operated on the principle of "trust nothing," incorporating extensive error checking and flow control at every single hop between network nodes. This made it very robust, but also incredibly inefficient on the cleaner, more reliable digital networks that began emerging.
Frame Relay was developed as the answer to this problem. It is a streamlined, efficient technology designed specifically for modern, high-quality digital circuits. It operates on the principle of "trust the network," moving the responsibility for error correction to the end devices (like routers) and focusing on one primary job: switching frames as fast as possible. This made it a far more efficient and cost-effective solution for building Wide Area Networks (WANs) in the 1990s and 2000s.
The Core Concept: Virtual Circuits
Unlike the public internet where each data packet might take a different path to its destination, Frame Relay is a connection-oriented technology. This means it establishes a fixed path for data to travel through the provider's network before any user data is sent. This pre-determined path is called a .
Think of it like this: sending a packet on the internet is like mailing a letter where each letter finds its own way. Frame Relay is more like a train system: before the train departs, a specific route from City A to City B is established. All wagons of that train will follow that exact same track.
Identifying Virtual Circuits: The DLCI
Each virtual circuit is identified by a . The DLCI is a 10-bit number (from 16 to 991 for user data) included in the header of every Frame Relay frame. It's important to understand that the DLCI is a locally significant identifier. It's like the platform number for a train: the train arriving at Platform 5 in New York might be the same one that departs from Platform 2 in Chicago. The platform number only has meaning at that specific station. Similarly, the DLCI value tells the Frame Relay switch which output port to send the frame to, and the value may be changed by the switch before forwarding it.
PVCs vs. SVCs
Frame Relay supports two types of virtual circuits:
Permanent Virtual Circuits (PVCs)
This is the most common type. A PVC is a static, pre-configured connection that is "always on." It's established manually by the network provider and remains active as long as the service is subscribed. This is ideal for stable connections between fixed locations, such as connecting two corporate offices.
Switched Virtual Circuits (SVCs)
An SVC is a temporary, on-demand connection. It is set up dynamically when data needs to be sent and torn down when the transmission is complete, much like a telephone call. While more flexible, SVCs were less commonly implemented by providers due to their complexity.
The Anatomy of a Frame Relay Frame
The beauty of Frame Relay lies in its simplified frame structure, which minimizes processing overhead at each switch. It's a stripped-down version of the HDLC frame.
- Flag (1 byte): Marks the beginning and end of the frame with the unique bit pattern
01111110. - Header (2-4 bytes): The control center of the frame. It contains:
- DLCI (10 bits): The virtual circuit identifier, as explained above.
- FECN (Forward Explicit Congestion Notification - 1 bit): A bit set by a switch to inform the destination device that there is congestion on the path ahead.
- BECN (Backward Explicit Congestion Notification - 1 bit): A bit set by a switch to inform the source device that there is congestion on the path.
- DE (Discard Eligibility - 1 bit): A bit that marks the frame as "low priority." If the network becomes congested, frames with the DE bit set will be discarded first.
- 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 for error detection. If the receiver calculates a different FCS, it knows the frame was corrupted during transit and discards it. Crucially, Frame Relay only detects errors; it does not perform retransmissions. Error recovery is left to higher-layer protocols.
The Service Contract: CIR and Bursting
When a customer buys a Frame Relay service, they sign a contract with the provider that defines the performance characteristics of their virtual circuits. The key parameters are CIR and the ability to burst.
- :
This is the guaranteed minimum bandwidth that the provider allocates to a virtual circuit. The customer can transmit data up to this rate at any time. Think of this as your own dedicated lane on a highway: it's always available for you.
- :
Frame Relay's advantage is its statistical multiplexing. The provider knows that not all customers will use their full CIR all the time. This leaves spare capacity in the network. The EBS allows a customer to "burst" above their guaranteed CIR and temporarily use this spare capacity, as long as it's available. This is like being allowed to use the shoulder of the highway when traffic is light.
What happens when you burst above your CIR? The router at the edge of the network sets the DE bit to '1' on those excess frames. This tells the network switches: "This frame is part of a burst and is not guaranteed. If you encounter congestion, you can discard this frame first to relieve pressure." This mechanism protects the guaranteed CIR traffic of all customers.
Congestion Management: The FECN and BECN Bits
Since Frame Relay is a shared network, congestion can occur if too many users try to send data at once. Frame Relay has a simple but effective mechanism to manage this using the FECN and BECN bits in the frame header.
- Forward Explicit Congestion Notification (FECN):
When a Frame Relay switch in the provider's network starts to experience congestion (its buffers are filling up), it sets the FECN bit to '1' on all frames passing through it in the direction of the congestion. This is like a traffic sign on a highway warning drivers, "Congestion ahead!" When the destination device receives frames with the FECN bit set, it knows there is a problem on the path. This information can be passed to higher-layer protocols to slow down their transmission rate.
- Backward Explicit Congestion Notification (BECN):
The same congested switch also sets the BECN bit to '1' on all frames traveling in the opposite direction, back towards the source devices that are causing the congestion. This is a more direct way of communicating the problem. When the source router receives frames with the BECN bit set, it gets a clear signal: "Slow down! You are causing congestion!" In response, a well-behaved router should reduce its sending rate to help alleviate the problem.
Together, FECN and BECN provide a feedback loop that allows the network and end devices to dynamically react to changing traffic conditions without the heavy overhead of older protocols.
The Local Management Interface (LMI)
One final piece of the puzzle is how the user's router (the DTE, or Data Terminal Equipment) and the provider's Frame Relay switch (the DCE, or Data Circuit-terminating Equipment) communicate with each other to manage the connection. This is handled by the Local Management Interface (LMI) protocol.
LMI is a "keepalive" and status-reporting mechanism. On a regular basis (e.g., every 10 seconds), the router sends an LMI status inquiry to the switch. The switch responds with a status reply that contains vital information, such as:
- A list of all PVCs configured on that physical link.
- The status of each PVC (e.g., Active, Inactive, Deleted).
This allows the router to automatically detect which VCs are available for use and to be notified if a previously active circuit goes down. There are three main variants of LMI: Cisco (the original proprietary version), ANSI, and ITU-T (Q.933a).