Section 7.2: Frame Relay

Frame Relay is a connection-oriented, Layer 2 WAN connection technology. It operates at speeds from 56 kpbs to 45 Mbps. It is very flexible and offers a wide array of deployment options. Frame Relay operates by statistically multiplexing multiple data streams over a single physical link. Each data stream is known as a virtual circuit (VC). Frame Relay VCs come in two types: Permanent Virtual Circuits (PVCs) and Switched Virtual Circuits (SVCs).

Each VC is tagged with an identifier to keep it unique. The identifier, known as a Data Link Connection Identifier (DLCI), is determined on a per-leg basis during the transmission. It must be unique and agreed upon by two adjacent Frame Relay devices. As long as the two agree, the value can be any valid number, and the number does not have to be the same end to end. Valid DLCI numbers are 16-1007. For DLCI purposes, 0-15 and 1008-1023 are reserved. The DLCI also defines the logical connection between the Frame Relay (FR) switch and the customer premises equipment (CPE).

Frame Relay devices fall into two possible roles, data terminal equipment (DTE) or data circuitterminating equipment (DCE). The DTE/DCE relationship is a Layer 2 (data link) layer relationship. DTE and DCE relationships are normally electrical. The DTE/DCE relationship at Layer 1 is independent of that at Layer 2.

DTEs are generally considered to be terminating equipment for a specific network and are located at the customer premises.
DCEs are carrier-owned internetworking devices. DCE equipment provides clocking and switching services in a network; they are the devices that actually transmit data through the WAN. In most cases, the devices are packet switches.

Local Management Interface (LMI) is the means by which Frame Relay edge devices maintain keepalive messages. The Frame Relay switch is responsible for maintaining the status of the CPE device(s) to which it is attached. LMI is the communication by which the switch monitors status. LMI implements a keepalive mechanism that verifies connectivity between DCE and DTE and the fact that data can flow. A LMI multicast capability, in conjunction with an LMI multicast addressing mechanism, enables attached devices to learn local DLCIs as well as provide global, rather than local, significance to those DLCIs. Finally, LMI provides a status indicator that is constantly exchanged between router and switch. The LMI setting is configurable.

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. Frame Relay networks are multiaccess networks, which means that more than two devices can attach to the network, similar to LANs. However, unlike LANs, you cannot send a data link layer broadcast over Frame Relay. Therefore, Frame Relay networks are called nonbroadcast multi-access (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.

7.2.1: Virtual Circuits

Frame Relay provides significant advantages over simply using point-to-point leased lines. The primary advantage has to do with virtual circuits (VCs) which define a logical path between two Frame Relay DTEs. The VC acts like a point-to-point circuit, providing the ability to send data between two endpoints over a WAN. However, there is no physical circuit directly between the two endpoints. VCs share the access link and the Frame Relay network. Each VC has a committed information rate (CIR), which is a guarantee by the provider that a particular VC gets at least that much bandwidth. Service providers can build their Frame Relay networks more cost-effectively than for leased lines. Therefore, Frame Relay is more cost-effective than leased lines for connecting many WAN sites.

Two types of VCs are allowed-permanent (PVC) and switched (SVC). PVCs are predefined by the provider, while SVCs are created dynamically. A Frame Relay network which includes PVCs between each pair of sites is called a full mesh Frame Relay network. In such a network, any two sites are connected by a PVC. When not all pairs have a direct PVC, it is called a partial mesh network. In such networks packets must be forwarded through other sites when packets are to be transmitted between two sites that are not directly connected by a PVC. This is the major disadvantage of partial mesh networks, however, partial mesh networks are cheaper because the provider charges per VC.

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. DCLI addressing is discussed in more detail in Section 7.2.3 below. (SVC)

7.2.2: LMI and Encapsulation Types

The LMI is a definition of the messages used between the DTE and the DCE. 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.

There are three LMI protocol options are available in Cisco IOS software:

Cisco LMI, which is a Cisco propriety solution and uses DLCI 1023;
ANSI LMI, which is also known as Annex D and uses DLCI 0; and
Q933a, which is defined by the ITU and is also known as Annex A.

Although the difference between these three LMI protocol options is slight; they are incompatible with one another. Therefore both the DTE and DCE on each end of an access link must use the same LMI standard.

Configuring the LMI type is easy and includes a default LMI setting, which uses the LMI autosense feature, in which the router figures out which LMI type the switch is using. If you choose to configure the LMI type, it disables the autosense feature. You can use the frame-relay { cisco | ansi | itu } interface subcommand to configure LMI type.

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.

However, the LAPF header and trailer do not identify the type of protocol, which is needed by routers. As discussed in Section 2 and Section 3, 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. It includes a 2-byte Protocol Type field, with values matching the same field used for HDLC by Cisco.
RFC 1490, which was superceded by RFC 2427, 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. ITU and ANSI later incorporated RFC 1490 headers into their Q.933 Annex E and T1.617 Annex F specifications, respectively.

DTEs use and react to the fields specified by these two specifications, but Frame Relay switches ignore them. In the configuration, the encapsulation created by Cisco is called cisco, and the other is called ietf.

7.2.3: DLCI Addressing

The DLCI is an addressing mechanism used to identify a VC so that when multiple VCs use the same access link the Frame Relay switches know how to forward the frames to the correct remote sites. Two important features of the DLCI are:

The Frame Relay headers, which have a single DLCI field, not both Source and Destination DLCI fields; and
The local significance of the DLCI, which means that the addresses need to be unique only on the local access link. This is called local addressing.

Because there is only a single DLCI field in the Frame Relay header, Global addressing can be used, making DLCI addressing look like LAN addressing in concept. Global addressing is a way of choosing DLCI numbers when planning a Frame Relay network so that working with DLCIs is much easier.

7.2.4: Frame Relay Configuration

In many cases, the configuration of Frame Relay can be as simple as setting the encapsulation and putting an IP address on the interface. This enables inverse-ARP to dynamically configure the DLCI and discover neighboring routers across the cloud. Although basic functionality can be achieved in this manner, more complex procedures are necessary for hub and spoke subinterface configurations dealing with point-to-multipoint implementations. The configuration of Frame Relay can be accomplished in a four steps, and entails determining the interface to be configured, configuring Frame Relay encapsulation, configuring protocol specific parameters, and configure Frame Relay characteristics.

7.2.4.1: Determining the Interface

The interface that interfaces the Frame Relay network is the one that should be configured. Once the interface has been selected, you should change to the appropriate interface configuration mode in the router. You should decide whether subinterfaces should be implemented. For a single point-to-point implementation, it might not be necessary to use subinterfaces; however, this implementation does not scale. If future sites are planned, it is best to use subinterfaces from the beginning.

To create a subinterface, use the following command to change to the desired interface:

interface interface_type interface_number.subinterface_number

For example, to create subinterface 1 on Serial 0, use the command interface serial 0.1. You must also determine the nature, or cast type, of the subinterface to be created, i.e., decide whether the subinterface will act as a point-to-point connection or a point-to-multipoint connection. If not specified, the subinterface defaults to a multipoint connection. To specify the cast type, add the keywords point-to-point or multipoint to the end of the previous command.

7.2.4.2: Configuring Frame Relay Encapsulation

To enable Frame Relay on the interface, issue the encapsulation frame relay command. The encapsulation of the interface determines the way it should act because each encapsulation is technology-specific. The encapsulation specified at this point dictates the Layer 2 framing characteristics of the packet passed to this specific interface from Layer 3. Once the Layer 2 framing is established, the resulting frame can be passed down to the physical layer for transmission.

7.2.4.3: Configuring Protocol-Specific Parameters

For each protocol to be passed across the Frame Relay connection, you must configure appropriate addressing. This addressing must be planned in advance. For point-to-point connections, each individual circuit should have its own subnetwork addressing and two available host addresses. For IP, each subinterface is assigned a separate and unique IP subnet. For IPX, each subinterface must have a unique IPX network number, and so on. As with any other addressing scheme, each side of the link must have a unique host address. For point-to-multipoint connections, each subinterface also must have unique addressing. However, a point-to-multipoint connection can connect to multiple remote sites. Thus, all sites sharing the point-to-multipoint connection are members of the same subnetwork, no matter the number of connections or the protocol. The cast type of the interface also dictates the manner in which DLCIs are assigned to the Frame Relay interface. The next section covers this topic in detail.

7.2.4.4: Configuring Frame Relay Characteristics

You must define specific parameters for Frame Relay operation. The parameters include LMI and DLCI configuration. If you use a pre 11.2 release of IOS Software, you must specify the LMI type that is being implemented. The Frame Relay service provider, or service provider, should provide the LMI information. For IOS Software Release 11.2 and later, you need not configure the LMI type. To disable LMI completely, use the no keepalive command to cease to transmit and receive LMI. However, keepalives must also be disabled at the switch.

You can now configure address mapping, if necessary. In the case of point-to-point connections, mapping of protocol addresses to DLCIs is dynamic and requires no intervention. However, if point-to-multipoint connections are in use, manual mapping is necessary. Mapping is the same from protocol to protocol and uses the frame-relay map protocol next_hop dlci [ broadcast ][ ietf | cisco ] command.

Protocols supported in the frame-relay map command include IP, IPX, AppleTalk, CLNS, DECnet, XNS, and Vines. The next_hop argument in the command represents the next hop logical address for the router on the remote end of the connection. The dlci argument represents the local DLCI, not that of the remote end. The broadcast keyword specifies that routing updates traverse the network through this circuit. The final option in the command specifies which Frame Relay implementation to utilize in communications with the remote router. When communicating with a Cisco device on the remote side, the default value (cisco) can be utilized. However, when communicating with non-Cisco gear on the remote end, it can be necessary to specify that the IETF implementation of Frame Relay be used.

7.2.4.5: Verifying Frame Relay Configuration

The most useful method of verifying the Frame Relay configurations is through the use of the show and debug commands. Some of the more useful show and debug commands are:

show frame-relay pvc is useful for viewing the status of statically or dynamically defined PVCs. The output for each PVC is detailed. The output also gives information on each circuit that specifies the receipt or transmission of FECN/BECN packets. FECN and BECN deal with congestion in the Frame Relay network, so obviously, a low number is preferable. The output also details the number of discard eligible (DE) packets received for which a low number is better.
show frame-relay lmi allows you to check the status of individual PVCs and to monitor the communication status between the router and the switch. This command show shows the number of LMI messages sent and received across the link between the router and the switch router. The LMI type can be specified differently for each interface, so the type is specified in the output. This command also shows the LMI input/output information.
debug frame-relay lmi is probably the most useful tool in verifying and troubleshooting Frame Relay problems. This command makes it possible to watch the real-time communication between the router and the switch. Each request sent from the router to the switch is noted, and the counter is incremented by 1 with each request. LMIs sent from the switch to the router by the service provider are noted and also are incremented by 1 with each request. As long as both numbers are greater than 0, the router should be functioning normally at Layers 1 and 3.
show frame-relay map is used to view the DLCI mappings that have been created. They can be static or dynamic and are noted as such in the command output.