Appendix H. Understanding Frame Relay Concepts
This chapter covers the following exam topics:
WAN Technologies
Identify Different WAN Technologies
Frame Relay
This appendix is from Chapter 13 of Cisco CCNA Routing and Switching ICND2 200-101 Official Cert Guide, which is the previous edition of this book. Although the ICND2 exam objectives do not explicitly reference the content covered here, the skills and concepts covered are important to have a solid understanding of as a future IT professional. All references to other content in this appendix refer to Cisco CCNA Routing and Switching ICND2 200-101 Official Cert Guide and not this book.
Frame Relay was at one time 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, as discussed back in Chapter 7, “Virtual Private Networks,” and Ethernet WANs, as introduced in the ICND1 book. 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.
Although many companies choose other WAN options today, Frame Relay still has uses. Some companies still use it as a core WAN technology. It can also be used to connect to MPLS and Internet VPNs. So, Frame Relay will be an important networking topic for some time.
This chapter describes Frame Relay protocol details, with Chapter 14, “Implementing Frame Relay,” discussing how to configure Frame Relay. The first section of this chapter focuses on the basics of Frame Relay, including a lot of new terminology. The second section examines Frame Relay data link addressing. This topic requires some attention because Frame Relay addresses are needed for both router configuration and troubleshooting. The last major section of this chapter examines some network layer concerns when using Frame Relay.
Foundation Topics
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.
Figure H-1 outlines the basic physical topology and related terminology in a Frame Relay network.
Figure H-1 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 Local Management Interface (LMI) protocol. The routers are considered DTE, and the Frame Relay switches are data communications equipment (DCE).
Note
The terms DCE and DTE have different meanings in different contexts. Here, with a Frame Relay service, the roles are as described in the previous paragraph. On a physical leased line, the DCE provides Layer 1 clocking, and the DTE receives and reacts to the DCE’s clock signal. These are two different (and accepted) uses of the same two terms.
Figure H-1 shows the physical connectivity at each connection to the Frame Relay network, and Figure H-2 shows the logical, or virtual, end-to-end connectivity associated with a virtual circuit (VC).
The logical communications path between each pair of DTEs is a VC. The dashed line in the figure represents a single VC; this book uses a thick dashed line style to make sure that you notice the line easily. The service provider usually preconfigures all the required details of a VC; predefined VCs are called permanent virtual circuits (PVC).
Routers use the data link connection identifier (DLCI) as the Frame Relay address; it identifies the VC over which the frame should travel. So, in Figure H-2, 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.
Table H-1 lists the components shown in Figures H-1 and H-2 and some associated terms. After the table, the most important features of Frame Relay are described in further detail.
The definitions for Frame Relay are contained in documents from the International Telecommunications Union (ITU) and the American National Standards Institute (ANSI). Originally, back in the 1990s, the Frame Relay Forum, a vendor consortium, defined many of the original specifications. Over time, the ITU and ANSI picked up many of the forum’s standards.
Now that you have heard some of the big ideas and key terms from Frame Relay, the next few topics go into more depth about the core functions within Frame Relay: virtual circuits, the LMI protocol, framing, and Frame Relay addressing.
Virtual Circuits
Frame Relay provides significant advantages over simply using point-to-point leased lines. The primary advantage has to do with VCs. Consider Figure H-3, which shows a typical Frame Relay network with three sites.
A VC defines a logical path between two Frame Relay DTEs. The term virtual circuit describes the concept well. It acts like a point-to-point circuit, enabling the sending of 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.
Not only does a single customer router share its access link among many VCs, many customers share the same Frame Relay network. Originally, people with leased-line networks were reluctant to migrate to Frame Relay because they would be competing with other Frame Relay customers for the provider’s capacity inside the cloud. To address these fears, Frame Relay uses a concept of a committed information rate (CIR). Each VC has a CIR, which is a guarantee by the provider that a particular VC gets at least that much bandwidth. So, you can migrate from a leased line to Frame Relay, getting a CIR of at least as much bandwidth as you previously had with your leased line.
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).
Frame Relay and other multiaccess WAN technologies have an even bigger cost advantage with larger enterprise WANs. For instance, imagine an organization with 100 sites, with one router at each site. To connect each pair of routers with a leased line, that company would need 4950 leased lines! And besides that, each router would need 99 serial interfaces. With Frame Relay, each router could use one serial interface and one access link into the Frame Relay cloud, for a total of 100 access links. Then, the Frame Relay provider could create a PVC between each pair of routers (a total of 4950 VCs). The Frame Relay solution requires a lot fewer actual physical links, and you would need only one serial interface on each router.
Service providers can build their Frame Relay networks more cost-effectively than for leased lines. As you would expect, that makes it less expensive for the Frame Relay customer as well. For connecting many WAN sites, Frame Relay is simply more cost-effective than leased lines.
When the Frame Relay network is engineered, the design might not include a VC between each pair of sites. Figure H-3 includes PVCs between each pair of sites; this is called a full-mesh Frame Relay network. When not all pairs have a direct PVC, it is called a partial-mesh network. Figure H-4 shows the same network as Figure H-3, but this time with a partial mesh and only two PVCs. This is typical when R1 is at the main site and R2 and R3 are at remote offices that rarely need to communicate directly.
The partial mesh has some advantages and disadvantages compared to a full mesh. Partial-mesh designs save money compared to full-mesh designs because the provider charges per VC. The downside is that traffic from R2’s site to R3’s site must go to R1 first and then be forwarded. If that is a small amount of traffic, it is a small price to pay. If it is a lot of traffic, a full mesh is probably worth the extra money because traffic going between two remote sites would have to cross R1’s access link twice.
LMI and Encapsulation Types
While the PVC gives two customer routers a logical means to send frames to one another, Frame Relay has many physical and logical components that have to work together to make those 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.
Interestingly, due to historical reasons, Cisco routers have three options for different variations of LMI protocols: Cisco, ITU, and ANSI. 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. Today’s 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. If you choose to configure the LMI type, the router disables the autosense feature. Table H-2 outlines the three LMI types, their origin, and the keyword used in the Cisco IOS software frame-relay lmi-type interface subcommand.
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 header and trailer are defined by Frame Relay (or more specifically, the Link Access Procedure Frame Bearer Services [LAPF] specification, ITU Q.922-A). The sparse LAPF framing provides error detection with an FCS in the trailer, a DLCI field (discussed in detail later in this chapter), plus a few other header fields. Figure H-5 diagrams the frame.
However, 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, Figure H-5 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 is using only the LAPF header, DTEs (including routers) cannot support multiprotocol 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 H-5. It includes a 2-byte Protocol Type field, with values matching the same field Cisco uses for HDLC.
RFC 1490 (and later 2427), Multiprotocol Interconnect over Frame Relay, defined the second solution. RFC 1490 was written to ensure multivendor 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.
Figure H-6 outlines these two alternatives.
Routers should agree on the encapsulation used; the switches do not care. However, each VC can use a different encapsulation. In the configuration, the encapsulation created by Cisco is called cisco, and the other one is called ietf.
Now that you have a broad understanding of Frame Relay concepts and terminology, the next section takes a much closer look at Frame Relay DLCIs.
Frame Relay Addressing
At a basic conceptual level, Frame Relay addresses, called data link connection identifiers (DLCI), have some similarity with the more familiar MAC and IP addresses. All these addresses exist as binary values, but they all have some more convenient format: hex for MAC addresses, dotted decimal for IP, and decimal for DLCIs. Frame Relay defines the DLCI as a 10-bit value, written in decimal, with the low- and high-end values usually reserved. (The specific range does not matter much because the service provider assigns the values, but they usually range from around 17 to a little less than 1000.)
When you dig deeper, particularly into how DLCIs impact the forwarding of Frame Relay frames, the similarities to MAC and IP addressing fades, and stark differences appear. This section focuses on that forwarding logic, first discussing the idea that Frame Relay addresses actually identify one end of a PVC. Following that, the discussion turns to the forwarding logic used inside the Frame Relay cloud.
Frame Relay Local Addressing
The service provider assigns each PVC two local DLCI values: one on one end of the PVC, and one for the other end. The term local DLCI has several different origins, but you can think of the word local as emphasizing the fact that from a router’s perspective, the local DLCI is the DLCI used on the local end of the PVC where the router sits. Figure H-7 shows the idea.
In this example, the PVC between routers A and B has two DLCIs assigned by the provider. Router A’s end uses local DLCI 41 to identify the PVC, and router B’s end uses DLCI 40 to identify the same PVC. Similarly, the PVC between routers A and C, as usual, has two local DLCIs assigned, one on each end. In this case, router A’s end uses 42, and router C’s end uses 40.
The service provider could have used any DLCI values within the range of legal values, with one exception:
The local DLCIs on a single access link must be unique among all PVCs that use one physical Frame Relay access link, because Frame Relay DLCIs are locally significant.
Because the provider chooses the DLCIs, the enterprise network engineer does not need to worry about avoiding making the wrong choice for DLCI value. For the sake of understanding the technology, know that on each physical access link from one router to the Frame Relay network, the DLCI values must be unique. In Figure H-7, the provider has defined two PVCs that cross router A’s one Frame Relay access link: one with local DLCI 41, and one with local DLCI 42. If another PVC were added, connected to router A, the provider just could not use 41 or 42 as the local DLCI on router A’s access link.
The local router only sees or knows the local DLCI. When you configure a router, you configure only the local DLCI value, not the DLCI on the other end of the PVC. Likewise, show commands list only local DLCI values.
Frame Forwarding with One DLCI Field
The most significant difference between the two other popular addresses in CCNA Routing and Switching (MAC and IP) versus DLCIs relates to the whole forwarding process. The Ethernet header includes both a source and destination MAC address, and the IP header includes a source and destination IP address. However, the Frame Relay header lists only one DLCI field, and it does not identify a source or a destination, but the PVC.
To get an idea of how the provider forwards a Frame Relay frame, consider the fact that the provider knows the local DLCI used on both ends of the PVC, plus the access links that connect to those routers. For instance, in Figure H-8, the provider knows that a PVC exists between router A and router B. They know it uses local DLCI 41 on the router A side. And they know it uses DLCI 40 on the router B side. Keeping that in mind, take a look at Figure H-8, which shows what happens when router A sends a frame to router B.
The figure shows three major steps. First, router A decides to send a frame over the PVC connected to router B. From router A’s perspective, A knows that PVC only as the PVC with local DLCI 41, so A sends a frame with DLCI 41 in the header. At Step 2, the service provider does a lot. They look at the information they know about this PVC, forward the frame over toward router B, and they change the DLCI to 40. At Step 3, when the frame arrives at router B, it has a DLCI value of 40. Router B correctly thinks that the frame arrived over the PVC from router A, because router B’s only knowledge of that PVC is that it is the PVC whose local DLCI (on router B’s end) is 40.
Note that when A sent the frame, A used its local DLCI value (41), and when B received the frame, B saw its local DLCI (40).
To complete the process, think about a packet sent by router B back toward router A. Again, the routers only know local DLCI values, so as shown in Figure H-9, B sends the frame with DLCI 40, which identifies the A-to-B PVC; the cloud changes the DLCI to 41; and router A receives the frame with DLCI 41 in it.
The same idea happens on each and every PVC. Earlier, Figure H-7 introduced two PVCs, including an A-to-C PVC, with local DLCIs 42 (A side) and 40 (C side). Figure H-10 shows the local DLCIs in two different frame flows: first from A to C, and then from C back to A.
This figure does not point out the cloud’s action of swapping the DLCI values, but the action still takes place. At Step 1, router A forwards a frame, with DLCI 42. At Step 2, when it exits the cloud toward router C, it has been changed to use DLCI 40, router C’s local DLCI for this PVC. Similarly, at Step 3, router C sends a frame, with local DLCI 40. The cloud changes the DLCI to 42, so that when it exits the cloud toward router A at Step 4, the frame lists router A’s local DLCI, which is 42.
Network Layer Addressing with Frame Relay
Frame Relay networks have both similarities and differences as compared to LAN and point-to-point WAN links. These differences introduce some additional considerations for passing Layer 3 packets across a Frame Relay network. In particular, Frame Relay gives us three different options for assigning subnets and IP addresses on Frame Relay interfaces:
One subnet containing all Frame Relay DTEs
One subnet per VC
A hybrid of the first two options
This section examines the three main options for IP addressing over Frame Relay.
Frame Relay Layer 3 Addressing: One Subnet Containing All Frame Relay DTEs
Figure H-11 shows the first alternative, which is to use a single subnet for the Frame Relay network. This figure shows a fully meshed Frame Relay network because the single-subnet option is usually used when a full mesh of VCs exists. In a full mesh, each router has a VC to every other router, meaning that each router can send frames directly to every other router. This more closely resembles how a LAN works. So, a single subnet can be used for all the routers’ Frame Relay interfaces, as configured on the routers’ serial interfaces. Table H-3 summarizes the addresses used in Figure H-11.
The single-subnet alternative is straightforward, and it conserves your IP address space. It also looks like what you are used to with LANs, which makes it easier to conceptualize. Unfortunately, most companies build partial-mesh Frame Relay networks, and the single-subnet option has some deficiencies when the network is a partial mesh.
Frame Relay Layer 3 Addressing: One Subnet Per VC
The second IP addressing alternative, having a single subnet for each VC, works better with a partially meshed Frame Relay network, as shown in Figure H-12. Boston cannot forward frames directly to Charlotte because no VC is defined between the two. This is a more typical Frame Relay network because most organizations with many sites tend to group applications on servers at a few centralized locations and most of the traffic is between each remote site and those servers.
The single-subnet-per-VC subnetting design uses the same logic as a set of point-to-point links. Using multiple subnets instead of one larger subnet does waste some IP addresses. However, using a single subnet in the partial-mesh design of Figure H-12 introduces several problems with routing protocols because not all routers in the subnet can send messages directly to each other. Partial-mesh designs work better with a single-subnet-per-VC approach.
Table H-4 shows the IP addresses for the partially meshed Frame Relay network shown in Figure H-12.
Cisco IOS software has a configuration feature called subinterfaces that creates a logical subdivision of a physical interface. Subinterfaces allow the Atlanta router to have three IP addresses associated with its serial 0/1/1 physical interface by configuring three separate subinterfaces. A router can treat each subinterface, and the VC associated with it, as if it were a point-to-point serial link. Each of the three subinterfaces of serial 0/1/1 on Atlanta would be assigned a different IP address from Table H-5. (Example 14-8 in Chapter 14 shows Atlanta’s configuration to match the address in Table H-5, including the subinterfaces of S0/1/1.)
Note
The example uses IP address prefixes of /24 to keep the math simple. In production networks, point-to-point subinterfaces usually use a prefix of /30 (mask 255.255.255.252) because that allows for only two valid IP addresses—the exact number needed on a point-to-point subinterface. Of course, using different masks in the same network means that your routing protocol must also support VLSM.
Frame Relay Layer 3 Addressing: Hybrid Approach
The third alternative for Layer 3 addressing is a hybrid of the first two alternatives. Consider Figure H-13, which shows a trio of routers with VCs between each of them, and two other VCs to remote sites.
Two options exist for Layer 3 addressing in this case. The first is to treat each VC as a separate Layer 3 group. In this case, five subnets are needed for the Frame Relay network. However, Routers A, B, and C create a smaller full mesh among each other. This allows Routers A, B, and C to use one subnet. The other two VCs—one between Routers A and D and one between Routers A and E—are treated as two separate Layer 3 groups. The result is a total of three subnets.
To accomplish either style of Layer 3 addressing in this third and final case, subinterfaces are used. Point-to-point subinterfaces are used when a single VC is considered to be all that is in the group—for instance, between routers A and D and between routers A and E. Multipoint subinterfaces are used when more than two routers are considered to be in the same group—for instance, with routers A, B, and C.
Multipoint subinterfaces logically terminate more than one VC. In fact, the name multipoint implies the function, because more than one remote site can be reached via a VC associated with a multipoint subinterface.
Table H-5 summarizes the addresses and subinterfaces that are used in Figure H-13.
What will you see in a real network? Most of the time, point-to-point subinterfaces are used with a single subnet per PVC. However, you should understand all options for the CCNA exams.
Note
Chapter 14 provides full configurations for all three cases illustrated in Figures H-11, H-12, and H-13.
Exam Preparation Tasks
Review All the Key Topics
Review the most important topics from this chapter, noted with the Key Topic icon. Table H-6 lists these key topics and where each is discussed.
Table H-6 Key Topics for Appendix H
Definitions of Key Terms
After your first reading of the chapter, try to define these key terms, but do not be concerned about getting them all correct at that time. Chapter 22 directs you in how to use these terms for late-stage preparation for the exam.
committed information rate (CIR)
data link connection identifier (DLCI)
Local Management Interface (LMI)
nonbroadcast multiaccess (NBMA)