Frame Relay for ICND Exam

Foundation Topics

Frame Relay Protocols

If you're using both books, in Chapter 4, "Fundamentals of WANs," of CCNA INTRO Exam Certification Guide, you read about the basics of Frame Relay. This chapter begins with a brief review of those concepts, and then it dives into the details of Frame Relay protocols and concepts. This chapter ends with coverage of Frame Relay configuration.

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 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 11-1 outlines the basic physical topology and related terminology in a Frame Relay network.

Figure 11-1 Frame Relay Components

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

Whereas Figure 11-1 shows the physical connectivity at each connection to the Frame Relay network, Figure 11-2 shows the logical, or virtual, end-to-end connectivity associated with a virtual circuit (VC).

Figure 11-2 Frame Relay PVC Concepts

The logical communications path between each pair of DTEs is a VC. The trio of parallel lines in the figure represents a single VC; this book uses a different line style to make sure you notice the line easily. Typically, the service provider preconfigures all the required details of a VC; predefined VCs are called permanent virtual circuits (PVCs).

Routers use the data-link connection identifier (DLCI) as the Frame Relay address, which identifies the VC over which the frame should travel. So, in Figure 11-2, when R1 needs to forward a packet to R2, it 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 so that the provider's Frame Relay switches correctly forward the frame to R2.

Table 11-2 lists the components shown in Figure 11-1 and some associated terms. After the tables, the most important features of Frame Relay are described in further detail.

Table 11-2 Frame Relay Terms and Concepts

Frame Relay Standards

The definitions for Frame Relay are contained in documents from the International Telecommunications Union (ITU) and the American National Standards Institute (ANSI). The Frame Relay Forum (http://www.frforum.com), a vendor consortium, also defines several Frame Relay specifications, many of which predate the original ITU and ANSI specifications, with the ITU and ANSI picking up many of the forum's standards. Table 11-3 lists the most important of these specifications.

Table 11-3 Frame Relay Protocol Specifications

Virtual Circuits

Frame Relay provides significant advantages over simply using point-to-point leased lines. The primary advantage has to do with virtual circuits. Consider Figure 11-3, which is a typical Frame Relay network with three sites.

Figure 11-3 Typical Frame Relay Network with Three Sites

A virtual circuit 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, providing the ability to send data between two endpoints over a WAN. There is no physical circuit directly between the two endpoints, so it's 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. R1 has only one physical access link to the Frame Relay network.

VCs share the access link and the Frame Relay network. For example, both VCs terminating at R1 use the same access link. In fact, 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 customers for the provider's capacity inside the cloud. To address these fears, Frame Relay is designed with the 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.

Interestingly, even with a three-site network, it's probably less expensive to use Frame Relay than to use point-to-point links. Imagine an organization with 100 sites that needs any-to-any connectivity. How many leased lines are required? 4950! And besides that, the organization would need 99 serial interfaces per router if it used point-to-point leased lines. With Frame Relay, an organization could have 100 access links to local Frame Relay switches, one per router, and have 4950 VCs running over them. That 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 to the Frame Relay customer as well. For connecting many WAN sites, Frame Relay is simply more cost-effective than leased lines.

Two types of VCs are allowed—permanent (PVC) and switched (SVC). PVCs are predefined by the provider; SVCs are created dynamically. PVCs are by far the more popular of the two.

When the Frame Relay network is engineered, the design might not include a PVC between each pair of sites. Figure 11-3 includes PVCs between each pair of sites, which is called a full-mesh Frame Relay network. When not all pairs have a direct PVC, it is called a partial-mesh network. Figure 11-4 shows the same network as Figure 11-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.

Figure 11-4 Typical Partial-Mesh Frame Relay Network

The partial mesh has some advantages and disadvantages when compared to a full mesh. The primary advantage is that partial mesh is cheaper, 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's a small amount of traffic, it's a small price to pay. If it's a lot of traffic, a full mesh is probably worth the extra money.

One conceptual hurdle with PVCs is that there is typically a single access link across which multiple PVCs flow. For example, consider Figure 11-4 from R1's perspective. Server1 sends a packet to Larry. It comes across the Ethernet. R1 gets it and matches Larry's routing table, which tells him to send the packet out Serial0, which is R1's access link. He encapsulates the packet in a Frame Relay header and trailer and then sends it. Which PVC does it use? The Frame Relay switch should forward it to R2, but why does it?

Frame Relay uses an address to differentiate one PVC from another. This address is called a data-link connection identifier (DLCI). The name is descriptive: The address is for an OSI Layer 2 (data link) protocol, and it identifies a VC, which is sometimes called a virtual connection. So, in this example, R1 uses the DLCI that identifies the PVC to R2, so the provider forwards the frame correctly over the PVC to R2. To send frames to R3, R1 uses the DLCI that identifies the VC for R3. DLCIs and how they work are covered in more detail later in this chapter.

LMI and Encapsulation Types

When you're first learning about Frame Relay, it's often easy to confuse the LMI and the encapsulation used with Frame Relay. The LMI is a definition of the messages used between the DTE (for example, a router) and the DCE (for example, the Frame Relay switch owned by the service provider). The encapsulation defines the headers used by a DTE to communicate some information to the DTE on the other end of a VC. The switch and its connected router care about using the same LMI; the switch does not care about the encapsulation. The endpoint routers (DTEs) do care about the encapsulation.

The most important LMI message relating to topics on the exam is the LMI status inquiry message. Status messages perform two key functions:

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

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

Three LMI protocol options are available in Cisco IOS software: Cisco, ITU, and ANSI. Each LMI option is slightly different 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.

The differences between LMI types are subtle. For example, the Cisco LMI calls for the use of DLCI 1023, whereas ANSI T1.617-D and ITU Q.933-A specify DLCI 0. Some of the messages have different fields in their headers. The DTE simply needs to know which of the three LMIs to use so that it can use the same one as the local switch.

Configuring the LMI type is easy. Today's most popular option is to use the default LMI setting, which 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, it disables the autosense feature.

Table 11-4 outlines the three LMI types, their origin, and the keyword used in the Cisco IOS software frame-relay lmi-type interface subcommand.

Table 11-4 Frame Relay LMI Types

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 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, as well as the DLCI, DE, FECN, and BECN fields in the header (which are discussed later). Figure 11-5 diagrams the frame.

Figure 11-5 LAPF Header

However, the LAPF header and trailer do not provide all the fields typically needed by routers. In particular, Figure 11-5 does not show a Protocol Type field. As discussed in Chapters 3, "Virtual LANs and Trunking," and 4, "IP Addressing and Subnetting," a field in the data-link header must 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 11-5. It includes a 2-byte Protocol Type field, with values matching the same field used for HDLC by Cisco.

• RFC 1490 (which was later superceded by RFC 2427—you should know both numbers), "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 n a Protocol Type field as well as many other options. ITU and ANSI later incorporated RFC 1490 headers into their Q.933 Annex E and T1.617 Annex F specifications, respectively.

Figure 11-6 outlines these two alternatives.

Figure 11-6 Cisco and RFC 1490/2427 Encapsulation

DTEs use and react to the fields specified by these two types of encapsulation, but Frame Relay switches ignore these fields. Because the frames flow from DTE to DTE, both DTEs must agree to the encapsulation used. The switches don't 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.

DLCI Addressing Details

So far, you know some basic information about Frame Relay. First, the routers (DTEs) connect to the Frame Relay switches (DCEs) over an access link, which is a leased line between the router and the switch. The logical path between a pair of DTEs is called a virtual circuit (VC). Most networks use permanent virtual circuits (PVCs) instead of switched virtual circuits (SVCs), and the data-link connection identifier (DLCI) addresses or identifies each individual PVC. The LMI protocol manages the access link, and the LMI type must match between the router and the local switch. Finally, the routers on either end of each VC must agree on the style of encapsulation used. Both encapsulation types include a Protocol Type field, which identifies the header that follows the Frame Relay header.

DLCIs can be both simple and confusing. It was just stated that the DLCI identifies a VC, so when multiple VCs use the same access link, the Frame Relay switches know how to forward the frames to the correct remote sites. You could know just that, look at the configuration examples later in this chapter, and probably learn to create new configurations. However, a closer look at DLCIs shows how they really work. This is important for actually understanding the configurations you create. If you want to get a deeper understanding, read on. If you prefer to get the basics right now and fill in more details later, you might want to jump ahead to the "Frame Relay Configuration" section.

Frame Relay addressing and switching define how to deliver frames across a Frame Relay network. Because a router uses a single access link that has many VCs connecting it to many routers, there must be something to identify each of the remote routers—in other words, an address. The DLCI is the Frame Relay address.

DLCIs work slightly differently from the other data-link addresses covered on the CCNA exams. This difference is mainly because of the use of the DLCI and the fact that the header has a single DLCI field, not both Source and Destination DLCI fields.

A few characteristics of DLCIs are important to understand before getting into their use. Frame Relay DLCIs are locally significant; this means that the addresses need to be unique only on the local access link. A popular analogy that explains local addressing is that there can be only a single street address of 2000 Pennsylvania Avenue, Washington, DC, but there can be a 2000 Pennsylvania Avenue in every town in the United States. Likewise, DLCIs must be unique on each access link, but the same DLCI numbers can be used on every access link in your network. For example, in Figure 11-7, notice that DLCI 40 is used on two access links to describe two different PVCs. No conflict exists, because DLCI 40 is used on two different access links.

Local addressing, which is the common term for the fact that DLCIs are locally significant, is a fact. It is how Frame Relay works. Simply put, a single access link cannot use the same DLCI to represent multiple VCs on the same access link. Otherwise, the Frame Relay switch would not know how to forward frames correctly. For instance, in Figure 11-7, R1 must use different DLCI values for the PVCs on its local access link (41 and 42 in this instance).

Figure 11-7 Frame Relay Addressing with Router A Sending to Routers B and C

Most people get confused about DLCIs the first time they think about the local significance of DLCIs and the existence of only a single DLCI field in the Frame Relay header. Global addressing solves this problem by making DLCI addressing look like LAN addressing in concept. Global addressing is simply a way of choosing DLCI numbers when planning a Frame Relay network so that working with DLCIs is much easier. Because local addressing is a fact, global addressing does not change these rules. Global addressing just makes DLCI assignment more obvious—as soon as you get used to it.

Here's how global addressing works: The service provider hands out a planning spreadsheet and a diagram. Figure 11-8 is an example of such a diagram, with the global DLCIs shown.

Figure 11-8 Frame Relay Global DLCIs

Global addressing is planned as shown in Figure 11-8, with the DLCIs placed in Frame Relay frames as shown in Figure 11-9. For example, Router A uses DLCI 41 when sending a frame to Router B, because Router B's global DLCI is 41. Likewise, Router A uses DLCI 42 when sending frames over the VC to Router C. The nice thing is that global addressing is much more logical to most people, because it works like a LAN, with a single MAC address for each device. On a LAN, if the MAC addresses are MAC-A, MAC-B, and MAC-C for the three routers, Router A uses destination address MAC-B when sending frames to Router B and MAC-C as the destination to reach Router C. Likewise, with global DLCIs 40, 41, and 42 used for Routers A, B, and C, respectively, the same concept applies. Because DLCIs address VCs, the logic is something like this when Router A sends a frame to Router B: "Hey, local switch! When you get this frame, send it over the VC that we agreed to number with DLCI 41." Figure 11-9 outlines this example.

Figure 11-9 Frame Relay Global Addressing from the Sender's Perspective

Router A sends frames with DLCI 41, and they reach the local switch. The local switch sees the DLCI field and forwards the frame through the Frame Relay network until it reaches the switch connected to Router B. Then Router B's local switch forwards the frame out the access link to Router B. The same process happens between Router A and Router C when Router A uses DLCI 42. The beauty of global addressing is that you think of each router as having an address, like LAN addressing. If you want to send a frame to someone, you put his or her DLCI in the header, and the network delivers the frame to the correct DTE.

The final key to global addressing is that the Frame Relay switches actually change the DLCI value before delivering the frame. Did you notice that Figure 11-9 shows a different DLCI value as the frames are received by Routers B and C? For example, Router A sends a frame to Router B, and Router A puts DLCI 41 in the frame. The last switch changes the field to DLCI 40 before forwarding it to Router B. The result is that when Routers B and C receive their frames, the DLCI value is actually the sender's DLCI. Why? Well, when Router B receives the frame, because the DLCI is 40, it knows that the frame came in on the PVC between itself and Router A. In general, the following are true:

• The sender treats the DLCI field as a destination address, using the destination's global DLCI in the header.

• The receiver thinks of the DLCI field as the source address, because it contains the global DLCI of the frame's sender.

Figure 11-9 describes what happens in a typical Frame Relay network. Service providers supply a planning spreadsheet and diagrams with global DLCIs listed. Table 11-5 gives you an organized view of what DLCIs are used in Figure 11-9.

Table 11-5 DLCI Swapping in the Frame Relay Cloud of Figure 11-9

Global addressing makes DLCI addressing more intuitive to most people. It also makes router configuration more straightforward and lets you add new sites more conveniently. For instance, examine Figure 11-10, which adds Routers D and E to Figure 11-9's network. The service provider simply states that global DLCIs 43 and 44 are used for these two routers. If these two routers also have only one PVC to Router A, all the DLCI planning is complete. You know that Router D and Router E use DLCI 40 to reach Router A and that Router A uses DLCI 43 to reach Router D and DLCI 44 to reach Router E.

Figure 11-10 Adding Frame Relay Sites: Global Addressing

The remaining examples in this chapter use global addressing in any planning diagrams unless otherwise stated. One practical way to determine whether the diagram lists the local DLCIs or the global DLCI convention is this: If two VCs terminate at the same DTE, and a single DLCI is shown, it probably represents the global DLCI convention. If one DLCI is shown per VC, local DLCI addressing is depicted.

Network Layer Concerns with Frame Relay

Most of the important Frame Relay concepts have been covered. First, the routers (DTEs) connect to the Frame Relay switches (DCEs) over an access link, which is a leased line between the router and the switch. The LMI protocol is used to manage the access link, and the LMI type must match between the router and the local switch. The routers agree to the style of encapsulation used. The single DLCI field in the Frame Relay header identifies the VC used to deliver the frame. The DLCI is used like a destination address when the frame is being sent and like a source address as the frame is received. The switches actually swap the DLCI in transit.

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. You need to concern yourself with a couple of key issues relating to Layer 3 flows over Frame Relay:

• Choices for Layer 3 addresses on Frame Relay interfaces

• Broadcast handling

The following sections cover these issues in depth.

Layer 3 Addressing with Frame Relay

Cisco's Frame Relay implementation defines 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

Frame Relay Layer 3 Addressing: One Subnet Containing All Frame Relay DTEs

Figure 11-11 shows the first alternative, which is to use a single subnet for the Frame Relay network. The figure shows a fully meshed Frame Relay network because the single-subnet option is typically 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—which more closely equates to 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 11-6 summarizes the addresses used in Figure 11-11.

Figure 11-11 Full Mesh with IP Addresses

Table 11-6 IP Addresses with No Subinterfaces

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, the single-subnet-per-VC alternative, works better with a partially meshed Frame Relay network, as shown in Figure 11-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.

Figure 11-12 Partial Mesh with IP Addresses

The single-subnet-per-VC alternative matches the logic behind a set of point-to-point links. Using multiple subnets instead of one larger subnet wastes some IP addresses, but it overcomes some issues with distance vector routing protocols.

Table 11-7 shows the IP addresses for the partially meshed Frame Relay network shown in Figure 11-12.

Table 11-7 IP Addresses with Point-to-Point Subinterfaces

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 Serial0 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 Serial0 on Atlanta would be assigned a different IP address from Table 11-7. (Sample configurations appear in the next section.)

Frame Relay Layer 3 Addressing: Hybrid Approach

The third alternative of Layer 3 addressing is a hybrid of the first two alternatives. Consider Figure 11-13, which shows a trio of routers with VCs between each of them, as well as two other VCs to remote sites.

Figure 11-13 Hybrid of Full and Partial Mesh

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 between 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 11-8 summarizes the addresses and subinterfaces that are used in Figure 11-13.

Table 11-8 IP Addresses with Point-to-Point and Multipoint Subinterfaces

What will you see in a real network? Most of the time, point-to-point subinterfaces are used, with a single subnet per PVC.

The later section "Frame Relay Configuration" provides full configurations for all three cases illustrated in Figures 11-11, 11-12, and 11-13.

Broadcast Handling

After contending with Layer 3 addressing over Frame Relay, the next consideration is how to deal with Layer 3 broadcasts. Frame Relay can send copies of a broadcast over all VCs, but there is no equivalent to LAN broadcasts. In other words, no capability exists for a Frame Relay DTE to send a single frame into the Frame Relay network and have that frame replicated and delivered across multiple VCs to multiple destinations. However, routers need to send broadcasts for several features to work. In particular, routing protocol updates are often broadcasts.

The solution to the Frame Relay broadcast dilemma has two parts. First, Cisco IOS software sends copies of the broadcasts across each VC, assuming that you have configured the router to forward these necessary broadcasts. If there are only a few VCs, this is not a big problem. However, if hundreds of VCs terminate in one router, for each broadcast, hundreds of copies could be sent.

As the second part of the solution, the router tries to minimize the impact of the first part of the solution. The router places these broadcasts in a different output queue than the one for user traffic so that the user does not experience a large spike in delay each time a broadcast is replicated and sent over every VC. Cisco IOS software can also be configured to limit the amount of bandwidth that is used for these replicated broadcasts.

Although such scalability issues are more likely to appear on the CCNP Routing exam, a short example shows the significance of broadcast overhead. If a router knows 1000 routes, uses RIP, and has 50 VCs, 1.072 MB of RIP updates is sent every 30 seconds. That averages out to 285 kbps. (The math is as follows: 536-byte RIP packets, with 25 routes in each packet, for 40 packets per update, with copies sent over 50 VCs. 536 * 40 * 50 = 1.072 MB per update interval. 1.072 * 8 / 30 seconds = 285 kbps.) That's a lot of overhead!

Knowing how to tell the router to forward these broadcasts to each VC is covered in the section "Frame Relay Configuration." The issues that relate to dealing with the volume of these updates are more likely a topic for the CCNP and CCIE exams.

Frame Relay Service Interworking

Inside a service provider's Frame Relay network, the provider can use any kind of gear it wants to create the Frame Relay network. One large vendor many years ago built its Frame Relay network with a bunch of Cisco routers! But today, most well-established Frame Relay networks use Asynchronous Transfer Mode (ATM) in the core of their Frame Relay networks.

ATM works similarly to Frame Relay, but it has many features that make it much more robust than Frame Relay. For instance, ATM uses virtual connections (VCs), which provide the same function as Frame Relay VCs. However, ATM differs in that it segments all frames into 53-byte-long cells before transmitting them across the ATM network, and it reassembles them at the other side of the network. ATM also has significantly better quality of service (QoS) features, which lets the service provider better control the use of its core networks.

Service providers can use ATM to build the core of their Frame Relay networks. This concept is depicted in Figure 11-14.

The Frame Relay Forum and other standards bodies use the term service interworking to refer to the use of ATM between the two Frame Relay switches. In Figure 11-14, you see that the two routers use Frame Relay to communicate with the provider. You normally think of the internals of the Frame Relay network as being hidden from the customer. Often, inside the service provider network, ATM is used between the Frame Relay switches at the edges of the network.

Figure 11-14 FRF.5 Service Interworking

The Frame Relay Forum defined a specification about how Frame Relay switches interoperate using ATM in a Frame Relay Forum document called FRF.5. FRF.5 defines how a Frame Relay switch can convert from a Frame Relay VC to an ATM VC and back to a Frame Relay VC. The end result is totally transparent to the two routers.

A second variation of service interworking was defined by the Frame Relay Forum in document FRF.8. FRF.8 service interworking defines how two routers communicate when one router is connected to a Frame Relay network and the other is connected to an ATM network. ATM services can be used for WAN connectivity, much like Frame Relay. So, with FRF.8, a service provider can sell VCs to its customers, with some endpoints connected via Frame Relay and some with ATM. FRF.8 defines how to convert between the ATM and Frame Relay sides of the networks, as shown in Figure 11-15.

For the exam, you should remember the basic idea behind service interworking, and the two types—FRF.5 and FRF.8.

Figure 11-15 FRF.8 Service