Frame Relay Tutorial

September 7th, 2011Go to comments

Let’s start this article with the question: Why do we need Frame Relay?

Let’s take a simple example. Suppose you are working in a big company and your company has just
expanded to two new locations. The main site is connected to two branch offices, named Branch 1 &
Branch 2 and your boss wants these two branches can communicate with the main site. The most
simple solution is to connect them directly (called a leased line) as shown below:

To connect to these two branches, the main site router, HeadQuarter, requires two serial interfaces
which a router can provide. But what happens when the company expands to 10 branches, 50
branches? For each point-to-point line, HeadQuarter needs a separate physical serial interface (and
maybe a separate CSU/DSU if it is not integrated into the WAN card). As you can imagine, it will need
many routers with many interfaces and lots of rack space for the routers and CSU/DSUs. Maybe we
should use another solution for this problem? Luckily, Frame Relay can do it!

By using Frame Relay we only need one serial interface at the HeadQuarter to connect to all branches.
This is also true when we expand to 10 or 50 branches. Moreover, the cost is much lesser than using
leased-lines.

Frame Relay is a high-performance WAN protocol that operates at the physical and data link layers of
the OSI reference model. It offers lower-cost data transfer when compared to typical point-to-point
applications, by using virtual connections within the frame relay network and by combining those
connections into a single physical connection at each location. Frame relay providers use a frame relay
switch to route the data on each virtual circuit to the appropriate destination.

Maybe these terminologies of Frame Relay are difficult to understand so we will explain them in more
detail in this article.

DCE & DTE

The first concept in Frame Relay you must grasp is about DTE & DCE:

+ Data terminal equipment (DTE), which is actually the user device and the logical Frame-relay end-
system
+ Data communication equipment (DCE, also called data circuit-terminating equipment), which
consists of modem and packet switch

In general, the routers are considered DTE, and the Frame Relay switches are DCE. The purpose of
DCE equipment is to provide clocking and switching services in a network. In our example,
HeadQuarter, Branch 1 & Branch 2 are DTEs while Frame Relay switches are DCEs.

Virtual Circuits

The logical connection through the Frame Relay network between two DTEs is called a virtual circuit
(VC). The term “virtual” here means that the two DTEs are not connected directly but through a
network. For example, the HeadQuarter & Branch 1 (or Branch 2) can communicate with each other
as if they were directly connected but in fact they are connected through a Frame Relay network with
many Frame Relay switches between them.

There are two types of VCs

+ switched virtual circuits (SVCs): are temporary connections that are only used when there is
sporadic data transfer between DTE devices across the Frame Relay network. SVC is set up
dynamically when needed. SVC connections require call setup and termination for each connection.
+ permanent virtual circuits (PVCs): A predefined VC. A PVC can be equated to a leased line in
concept.

Nowadays most service providers offer PVC service only to save additional costs for signaling and
billing procedures.

In this part we will continue to discuss about other important Frame Relay parameters

DLCI

Although the above picture shows two VCs from the HeadQuarter but do you remember that the
HeadQuarter only has only one serial interface? So how can it know which branch it should send the
frame to?

Frame-relay uses data-link connection identifiers (DLCIs) to build up logical circuits. The identifiers
have local meaning only, that means that their values are unique per router, but not necessarily in the
other routers. For example, there is only one DLCI of 23 representing for the connection from
HeadQuarter to Branch 1 and only one DLCI of 51 from HeadQuarter to Branch 2. Branch 1 can use
the same DLCI of 23 to represent the connection from it to HeadQuarter. Of course it can use other
DLCIs as well because DLCIs are just local significant.
By including a DLCI number in the Frame Relay header, HeadQuarter can communicate with both
Branch 1 and Branch 2 over the same physical circuit.

DLCI values typically are assigned by the Frame Relay service provider (for example, the telephone
company). In Frame Relay, DLCI is a 10-bit field.

Before DLCI can be used to route traffic, it must be associated with the IP address of its remote
router. For example, suppose that:

+ HeadQuarter’s IP address is 9.9.9.9

+ Branch 1′s IP address is 1.1.1.1 
+ Branch 2′s IP address is 2.2.2.2

Then the HeadQuarter will need to map Branch 1 IP address to DLCI 23 & map Branch 2 IP address to
DLCI 51. After that it can encapsulate data inside a Frame Relay frame with an appropriate DLCI
number and send to the destination. The mapping of DLCIs to Layer 3 addresses can be handled
manually or dynamically.

* Manually (static): the administrators can statically assign a DLCI to the remote IP address by the
following statement:

Router(config-if)#frame-relay map protocol dlci [broadcast]

For example HeadQuarter can assign DLCIs of 23 & 51 to Branch 1 & Branch 2 with these commands:

HeadQuarter(config-if)#frame-relay map ip 1.1.1.1 23 broadcast

HeadQuarter(config-if)#frame-relay map ip 2.2.2.2 51 broadcast

We should use the “broadcast” keyword here because by default split-horizon will prevent routing
updates from being sent back on the same interface it received. For example, if Branch 1 sends an
update to HeadQuarter then HeadQuarter can’t send that update to Branch 2 because they are
received and sent on the same interface. By using the “broadcast” keyword, we are telling the
HeadQuarter to send a copy of any broadcast or multicast packet received on that interface to the
virtual circuit specified by the DLCI value in the “frame-relay map” statement. In fact the copied
packet will be sent via unicast (not broadcast) so sometimes it is called “pseudo-broadcast”.

Note: “frame-relay interface-dlci” command can be used to statically assign (bind) a DLCI number to a
physical interface.

Note: In fact, we need to run a routing protocol (like OSPF, EIGRP or RIP…) to make different
networks see each other

* Dynamic: the router can send an Inverse ARP request to the other end of the PVC for its Layer 2
address. In short, Inverse ARP will attempt to learn its neighboring devices IP addresses and
automatically create a dynamic map table. By default, physical interfaces have Inverse ARP enabled.

We will take an example of how Inverse ARP works with the topology above. At the beginning, all
routers are not configured with static mapping and HeadQuarter has not learned the IP addresses of
Branch 1 & 2 yet. It only has 2 DLCI values on s0/0 interface (23 & 51). Now it needs to find out who
are attached to these DLCIs so it sends an Inverse ARP Request on s0/0 interface. Notice that the
router will send Inverse ARP Request out on every DLCI associated with the interface.

In the Inverse ARP Request, HeadQuarter also includes its IP 9.9.9.9. When Branch 1 & 2 receive this
request, they send back an Inverse ARP Reply with their own IP addresses.

Now all the routers have a pair of DLCI & IP address of the router at the other end so data can be
forwarded to the right destination.
In this example you can see that each router has a DLCI first (Layer 2) and it needs to find out the IP
address (Layer 3). This process is opposite of the ARP process (ARP translates Layer 3 address to
Layer 2 address) so it is called Inverse ARP.

After the Inverse ARP process completes, we can use the “show frame-relay map” to check. The word
“dynamic” indicates the mapping was learned through Inverse ARP (the output below is not related to
the above topology):

By default, routers send Inverse ARP messages on all active DLCIs every 60 seconds.

Another thing you should notice is when you supply a static map (via “frame-relay map” command),
Inverse ARP is automatically disabled for the specified protocol on the specified DLCI.

In the last part we will mainly learn about LMI, which is the signaling protocol of Frame Relay

LMI

Local Management Interface (LMI) is a signaling standard protocol used between your router (DTE)
and the first Frame Relay switch. The LMI is responsible for managing the connection and maintaining
the status of your PVC.

LMI includes:
+A keepalive mechanism, which verifies that data is flowing 
+A multicast mechanism, which provides the network server (router) with its local DLCI.
+A status mechanism, which provides PVC statuses on the DLCIs known to the switch

In our example, when HeadQuarter is configured with Frame Relay, it sends an LMI Status Inquiry
message to the DCE. The response from the DCE might be a small Hello message or a full status
report about the PVCs in use containing details of all the VCs configured (DLCI 23 & 51). By default,
LMI messages are sent out every 10 seconds.

The four possible PVC states are as follows:

+ Active state: Indicates that the connection is active and that routers can exchange data. 
+ Inactive state: Indicates that the local connection to the Frame Relay switch is working, but the
remote router connection to the Frame Relay switch is not working. 
+ Deleted state: Indicates that no LMI is being received from the Frame Relay switch, or that there
is no service between the customer router and Frame Relay switch.
+ Static state: the Local Management Interface (LMI) mechanism on the interface is disabled (by
using the “no keepalive” command). This status is rarely seen so it is ignored in some books.

We can use the “show frame-relay lmi” to display LMI statistics of Frame Relay on enabled interfaces
of the router. The output shows the LMI type used by the Frame Relay interface and the counters for
the LMI status exchange sequence, including errors such as LMI timeouts.

Cisco routers support the following three LMI types:

* Cisco: LMI type de?ned jointly by Cisco, StrataCom, Northern Telecom (Nortel), and Digital
Equipment Corporation
* ANSI: ANSI T1.617 Annex D
* Q.933A: ITU-T Q.933 Annex A

Notice that three types of LMI are not compatible with each others so the LMI type must match
between the provider Frame Relay switch and the customer DTE device.

From Cisco IOS Release 11.2, the router attempts to automatically detect the type of LMI used by the
provider switch.

Note: LMI is required for Inverse ARP to function because it needs to know that the PVC is up before
sending out Inverse ARP Request.

Now you learn most of Frame Relay mentioned in CCNA, some other Frame Relay’s characteristics you
should know are mentioned below.

Other Frame Relay characteristics

+ Frame Relay provides no error recovery mechanism. It only provides CRC error detection.
+ Unlike with LANs, you cannot send a data link layer broadcast over Frame Relay. Therefore, Frame
Relay networks are called nonbroadcast multiaccess (NBMA) networks.
+ Depending on the bandwidth needed for each virtual connection, the customer can order a circuit
with a guaranteed amount of bandwidth. This amount is the Committed Information Rate (CIR).
CIR defines how much bandwidth the customer is “guaranteed” during normal network operation.
+ Any data transmitted above this purchased rate (CIR) is available for discard by the network if the
network doesn’t have available bandwidth.
+ If the Frame relay switch begins to experience congestion, it sends the upstream site (to the
source) a Backward explicit congestion notification (BECN) and the downstream site (to the
destination) a Forward explicit congestion notification (FECN).
+ There are two Frame Relay encapsulation types: the Cisco encapsulation and the IETF Frame
Relay encapsulation, which is in conformance with RFC 1490 and RFC 2427. The former is often
used to connect two Cisco routers while the latter is used to connect a Cisco router to a non-Cisco
router.

+ Frame Relay does not define the way the data is transmitted within the service provider’s network
once the traffic reaches the provider’s switch. So the providers can use Frame Relay, ATM or PPP…
inside their networks.

Layer 2 Encapsulation Protocols

Besides Frame Relay there are other Layer 2 Encapsulation Protocols that you can implement instead:

High-Level Data Link Control (HDLC): The default encapsulation type for Cisco routers on point-to-
point dedicated links and circuit-switched connections. HDLC is a Cisco proprietary protocol.
Point-to-Point Protocol (PPP): Provides connections between devices over several types of physical
interfaces, such as asynchronous serial, High-Speed Serial Interface (HSS1), ISDN, and synchronous.
PPP works with many network layer protocols, including IP and IPX. PPP can use either Password
Authentication Protocol (PAP) or Challenge Handshake Authentication Protocol (CHAP) for
authentication.
X.25/Link Access Procedure, Balanced (LAPB): Defines connections between DTE and DCE for
remote terminal access. LAPB is a data link layer protocol specified by X.25.
Asynchronous Transfer Mode (ATM): International standard for cell relay using fixed-length (53-
byte) cells for multiple service types. Fixed-length cells allow hardware processing, which greatly
reduces transit delays. ATM takes advantage of high-speed transmission media such as E3, T3, and
Synchronous Optical Network (SONET).

If you want to learn how to configure Frame Relay in GNS3, please read my Frame Relay Lab in GNS3
tutorial.