Once, Frame Relay was the most popular WAN technology used in computer networks. Today, Frame Relay has become less popular, being replaced by several other WAN options. These include the virtual private network (VPN) technology. In addition, many enterprises use Multiprotocol Label Switching (MPLS) VPNs, which follow the same basic service model as Frame Relay, usually offered by the same Frame Relay providers but with significant technical advantages.
Frame Relay Overview
Frame Relay networks provide more features and benefits than simple point-to-point WAN links but to do that, Frame Relay protocols are more detailed. For example, Frame Relay networks are multiaccess networks, which means that more than two devices can attach to the network, similar to LANs. Unlike with LANs, you cannot send a data link layer broadcast over Frame Relay.
Therefore, Frame Relay networks are called nonbroadcast multiaccess (NBMA) networks. Also, because Frame Relay is multiaccess, it requires the use of an address that identifies to which remote router each frame is addressed.
The above figure shows the most basic components of a Frame Relay network. A leased line is installed between the router and a nearby Frame Relay switch; this link is called the access link. To ensure that the link is working, the device outside the Frame Relay network, called the data terminal equipment (DTE), exchanges regular messages with the Frame Relay switch. These keepalive messages, along with other messages, are defined by the Frame Relay’s Local Management Interface (LMI) protocol . The routers are considered DTE, and the Frame Relay switches are data communications equipment (DCE).
Data Link Connection Identifier (DLCI)
Routers use the data link connection identifier (DLCI) as the Frame Relay address; it identifies the Virtual circuit (VC) over which the frame should travel. So, in figure above, when R1 needs to forward a packet to R2, R1 encapsulates the Layer 3 packet into a Frame Relay header and trailer and then sends the frame. The Frame Relay header includes the correct DLCI, identifying the PVC connecting R1 to R2, so that the provider’s Frame Relay switches correctly forward the frame to R2.
The table below lists the components and some associated terms. After the table, the most important features of Frame Relay are described in further detail.
Virtual Circuits (VC)
A VC defines a logical path between two Frame Relay data communications equipments (DCE). It acts like a point-to-point circuit which enables sending the data between two endpoints over a WAN. There is no physical circuit directly between the two endpoints, so it is virtual. For example, R1 terminates two VCs—one whose other endpoint is R2, and one whose other endpoint is R3. R1 can send traffic directly to either of the other two routers by sending it over the appropriate VC.
VCs share the access link and the Frame Relay network. For example, both VCs terminating at R1 use the same access link. R1 can send one Frame Relay frame to R2, and then another frame to R3, sending both over the same physical access link.
One big advantage of Frame Relay over leased lines is that Frame Relay provides connectivity to each site, with only a single access link between each router and the Frame Relay provider. Interestingly, even with a three-site network, it’s probably less expensive to use Frame Relay than to use point-to-point links because the access links tend to be relatively short, to some nearby Frame Relay provider point of presence (PoP).
LMI and Encapsulation Types in Frame Relay
Frame Relay has many physical and logical components that have to work together to make PVCs work. Physically, each router needs a physical access link from the router to some Frame Relay switch. The provider has to create some kind of physical network between those switches, as well. In addition, the provider has to do some work so that the frames sent over one PVC arrive at the correct destination.
Frame Relay uses the Local Management Interface (LMI) protocol to manage each physical access link and the PVCs that use that link. These LMI messages flow between the DTE (for example, a router) and the DCE (for example, the Frame Relay switch owned by the service provider).
The most important LMI message relating to topics on the exam is the LMI status inquiry message. LMI status messages perform two key functions:
- They perform a keepalive function between the DTE and DCE. If the access link has a problem, the absence of keepalive messages implies that the link is down.
- They signal whether a PVC is active or inactive. Even though each PVC is predefined, its status can change. An access link might be up, but one or more VCs could be down. The router needs to know which VCs are up and which are down. It learns that information from the switch using LMI status messages.
The table below outlines the three LMI types, their origin, and the keyword used in the Cisco IOS software frame-relay lmi-type interface subcommand .
Each LMI option differs slightly and therefore is incompatible with the other two. As long as both the DTE and DCE on each end of an access link use the same LMI standard, LMI works fine. Configuring the LMI type is easy. The most popular option is to use the default LMI setting. This setting uses the LMI autosense feature, in which the router simply figures out which LMI type the switch is using. So, you can simply let the router autosense the LMI and never bother coding the LMI type.
Frame Relay Encapsulation and Framing
A Frame Relay-connected router encapsulates each Layer 3 packet inside a Frame Relay header and trailer before it is sent out an access link.
The sparse LAPF framing provides error detection with an FCS in the trailer, a DLCI field, plus a few other header fields. The front figure illustrates LAPF framing.
Routers actually use a longer header than just the standard LAPF header because the standard header does not provide all the fields usually needed by routers. In particular, the above figure does not show a Protocol Type field. Each data link header needs a field to define the type of packet that follows the data link header. If Frame Relay only use LAPF header, routers cannot forward the traffic because there is no way to identify the type of protocol in the Information field.
Two solutions were created to compensate for the lack of a Protocol Type field in the standard Frame Relay header:
- Cisco and three other companies created an additional header, which comes between the LAPF header and the Layer 3 packet shown in Figure 13-5. It includes a 2-byte Protocol Type field, with values matching the same field Cisco uses for HDLC.
- RFC 1490, Multi-protocol Interconnect over Frame Relay, defined the second solution. This standard was written to ensure multi-vendor interoperability between Frame Relay DTEs. This RFC defines a similar header, also placed between the LAPF header and Layer 3 packet, and includes a Protocol Type field as well as many other options.