Frame Relay - The Protocol

Frame Relay is a packet switching protocol designed for high quality and high speed transmission line. It offers cost saving implementations, compared to other data transfer methods.
Frame Relay adds relay and routing functions to the data link layer (layer 2 of the OSI reference model). Some of the functions associated with packet transport, such as error correction, flow control, etc., are still formed, but on an end-to-end basis by the end-user devices, instead of by the network.

How does Frame Relay work ?

As described in the Protocol Architecture Diagram below, Application A initiates the communication process by sending a request for session establishment to the transport layer via the presentation and session layers. The transport layer forwards call control information through the ISDN via the D channel using Q.931 procedures. The signaling message is routed through the network and is used to define the virtual path and calls parameters that will be used during the data transfer stage.

Once the call is established, data is transferred through the network between applications A and B on a hop-by-hop basis by using the DLCI in the frame header and routing information at each node as determined during call setup. One of the characteristics of Frame Relay is that it minimizes the amount of processing performed on each frame by the network and allows for very fast transfer of information.

The Frame Structure:

Frame Relay's frame structure is essentially identical to that defined for Lap-D. The frame relay format can be distinguished from Lap-D by its absence of a control field.
Frames are constructed by encapsulating layer 2 messages (excluding the CRC and flags), with a two-byte header, a CRC, and a flag delimiter -  as shown here.

Each frame relay PDU consists of the following fields:

Flag Field :
The flag is used to perform high-level data link synchronization, which indicates the beginning and end of the frame with the unique pattern 01111110.
To ensure that the 01111110 pattern does not appear somewhere inside the frame, bit stuffing and destuffing procedures are used.

Address Field:

The address field can vary from 2 to 4 octets in size. One of the reasons why this field is variable is due to the fact that there is the possibility that 1024 (1022 if LMI (1023) is excluded) DLCI's may not be enough.

• DLCI - This function of the address field allows multiple connections to be carried over a single channel (multiplexed). and enables the network to route each frame on a hop-by-hop basis along a virtual path defined either at call setup or subscription time. It is used to identify the virtual connection so that the receiving end knows which  connection this frame belongs to. It should be pointed out that this DLCI has only local significance. Several virtual connections can be multiplexed over the same physical channel.
• The Command/Response bit (C/R) -  is used by higher end applications to manage end to end connections. It is not used at OSI level 2 (Frame Relay).
• EA bits - allow the address to be extended in size from 10 bits to 17 or 24 bits respectively. Thus the address field has built in scalability.
• Forward Explicit Congestion Notification (FECN) - is activated when the frame is switched onto a link where the Frame Relay interface has become congested. Thus the receiving device knows that the PVC is congested.
• Backward explicit Congestion Notification (BECN) -  is activated to tell the switch to engage in congestion avoidance where traffic is in the opposite direction of the received frame. i.e. user transmitted frames will encounter congestion. (for more information see Frame Relay Congestion Management).
• Discard Eligibility (DE) - is set to indicate that a certain frame should be dropped in preference to other frames without the bit set when and if the link becomes congested.

 
Information/Data Field - The information field contains actual data from applications that operate at higher levels of the OSI model. It can also be used for call controlling. The maximum number of data bytes that may be put in a frame is a system parameter. The actual maximum frame length may be negotiated at call set-up time. The standard specifies that the maximum information field size (to be supported by any network) is at least 262 octets. Since end-to-end protocols typically operate on the basis of larger information units, it is recommended that the network support the maximum value of at least 1600 octets, to avoid the need for segmentation and reassembling by end users.

Frame Check Sequence (FCS) - It is necessary to implement error detection at each switching node in order to avoid wasting bandwidth due to the transmission of error frames. The error detection mechanism used in frame relay is based on the Cyclic Redundancy Check (CRC).

There is no more end-to-end packet level error control; only the node-to-node frame level error control is kept. No error recovery through retransmission is performed  and frames received with errors are simply discarded

 

Link Management Interface -LMI :
An optional extension to the frame relay interface standards which ensures link management functions. This extension allows "keep-alive" messages, configuration information, and congestion status to be exchanged across the UNI between the access device and the network device. The LMI message begins with a DLCI of 1023 or a DLCI of 0 (according to the  LMI version used). This DLCI together with an unnumbered information frame type and protocol discriminator of 00001001 identifies it as an LMI frame. The frame includes a message type and some information elements (IEs) which carry the data itself
 

Error Checking & Handling

Frame Relay does not implement error correction. However, it does implement an error-checking mechanism known as the cyclic redundancy check (CRC). Typically Frame Relay is implemented on reliable network media and  error correction may be left to higher-layer protocols running on top of Frame Relay. That way, data integrity is not sacrificed.