Frame Relay Tutorial

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.

The PVC STATUS displays the status of the PVC. The DCE device creates and sends the report to the DTE devices. There are 4 statuses:

+ ACTIVE: the PVC is operational and can transmit data
+ INACTIVE: the connection from the local router to the switch is working, but the connection to the remote router is not available
+ DELETED: the PVC is not present and no LMI information is being received from the Frame Relay switch
+ STATIC: 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.

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).

Reference:http://www.9tut.com/frame-relay-tutorial