The frame relay UN

Frame relay is an extension of the link access procedure for the D channel (LAP-D) and it is based on the core functions of ITU-T’s recommendation Q.9221 (Q.992 core). (LAP- D has a similar format to LAP-B, which is a subset of HDLC). LAP-D was chosen because virtually every data protocol, such as SNA, X.25, TCP/IP, and DECnet, can be easily made to conform to it. Thus, frame relay is compatible with a variety of higher layer protocols. Layer 4 Layer 3 Q.922 core Phy Phy Backbone protocol Frame Relay access device Frame Relay network device Frame Relay UNI Q.922 core

Figure 3.4: The protocol stack for the frame relay UNI

Information

Header FCS Flag

1 byte 2 bytes !!! 2 bytes 1 byte Flag

DLCI C/

R EA DLCI FECN BECN DE EA

1 byte 1 byte

Figure 3.5: The structure of the frame relay frame

Frame relay is a standardized user-network interface (UNI) protocol which defines the interaction between frame relay access devices (FRAD), such as routers, bridges, and other control devices, and a nodal processor which is known as the frame relay network device. Frame relay does not define how the nodal processors are interconnected. An example of the location of frame relay UNIs is given in figure 3.3

The protocol stack is shown in figure 3.4. The structure of the frame is shown in figure 3.5. The following fields have been defined:

Flag: As in HDLC, a flag consisting of the bit pattern 01111110 is used as a delimiter. Bit stuffing is used to avoid duplication of the bit pattern inside the frame.

Data link connection identifier (DLCI): Frame relay is a connection-oriented protocol. That is, a virtual connection has to be established between the sender and the receiver before data can be transferred. The 10-bit DLCI field is used to identify a virtual connection, as explained below.

Command/response (C/R): 1-bit field used to carry application-specific information. It is carried transparently by the network.

Forward explicit congestion notification (FECN): 1-bit field used for congestion control, as explained in section 3.5.

Backward explicit congestion notification (BECN): 1-bit field used for congestion control, as explained in section 3.5.

Discard eligibility (DE): 1-bit field used for congestion control. The use of this bit is explained in section 3.5.

Address extension (EA): The basic header of frame relay is two bytes. It can be extended to 3 or 4 bytes so that to support DLCIs with more than 10 bits. The 1-bit EA field is used to indicate whether the current byte in the header is the last one. For instance, in a 2 byte header, EA will be set to 0 in the first byte, and to 1 in the second byte.

FCS: This field contains the frame check sequence obtained using the pattern x16_+x12_+x5_+1.

The length of the information field has to be an integer number of bytes before bit- stuffing, with a minimum size of 1 byte. The frame relay Forum recommends a defaulted maximum value of 1600 bytes, and ANSI recommends up to 4,096 bytes.

Frame relay is an extremely simple protocol. The receiver checks the integrity of each frame using the FCS. The frame is discarded if it is found to be in error. If no errors are found, the frame’s DLCI is looked up in a table. The frame is discarded if its DLCI number is not found in the table. Otherwise, the frame is relayed towards its destination. Valid frames can also be discarded in order to alleviate congestion. When a frame is discarded, the end-devices are not notified. A discarded frame will eventually be noted by

the destination end-device, which will then request the sending end-device to retransmit the frame. This re-transmission procedure is not part of the frame relay protocol, and it should be done by a higher-level protocol.

DLCI: Data link connection identifier

All DLCIs have local significance. That is, they are only used to identify a virtual circuit connection between a frame relay access device and the nodal frame relay network device. The same number can be used for another connection at another UNI. This concept of using locally significant connection identifiers is also found in X.25 and in ATM networks.

In the example given in figure 3.6, there are two connections between end-devices A and B, and end-devices A and C, shown by a solid line. The connection between A and B is identified by DLCI=25 on A’s UNI and by DLCI=20 on B’s UNI. The connection between A and C is identified by DLCI=122 on A’s UNI and by DLCI=134 on C’s UNI. If A wants to send a frame to B, then it will populate the frame’s DLCI field with the number 25. The frame relay network will deliver the frame to B with the DLCI field set to 20. Likewise, if B wants to transmit a frame to A, it will populates the frame's DLCI field with the number 20, which will be delivered to A with a DLCI equal to 25.

Frame relay connections can be permanent virtual connections (PVC) or switched virtual connections (SVC). PVCs are set-up administratively using network management procedures, whereas SVCs are set up on demand using the ITU-T Q.933 signalling protocol.

To C: DLCI=122 To B: DLCI=25 DLCI=20 To A: To A: DLCI=134 Frame relay network Device C Device A Device B

Figure 3.6: An example of DLCI addressing