6.2 Frame Relay
Frame Relay is a connection-oriented, Layer 2 WAN connection technology. It operates at speeds from 56 Kbps 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.
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.
6.2.1 Local Management Interface (LMI)
The Local Management Interface (LMI) is a set of enhancements to the original Frame Relay specification and includes global addressing, virtual-circuit status messages, and multicasting. It 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.
There are three types of LMI implementations. The LMI type can be set per serial interface with the following command:
frame-relay lmi-type {ansi | cisco | q933a}
Cisco routers perform autosensing of the LMI type with IOS 11.2 or higher. Thus, the lmi-type command does not need to be configured on routers running newer code.
6.2.2 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.
| Committed Information Rate (CIR) |
|---|
| CIR guarantees bandwidth to a maximum limit, although the user traffic can burst to higher rates, if the provider's frame relay network is underutilized. The CIR is defined in two ways, depending on the Frame Relay provider's implementation. The CIR is either the maximum speed that the Frame Relay provider transfers information for each PVC, or it is the average rate (in bps) at which the network guarantees to transfer data over a defined period of time. |
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.
6.2.3 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. 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 superseded 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.
6.2.4 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.
6.2.5 Frame Relay Frame Format
Frame Relay uses Link Bytes: 8 16 Variable 16 8
Access Procedure for Frame Relay (LAPF) for frame format. LAPF is another variation of the HDLC frame format. The LAPF has no control frame, no flow control, and no error control. It also does not use Bits: 8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
sequence numbers. The Frame Relay LAPF Frame Format
The 10-bit DLCI provides the PVC identifier, which has local significance between the router and the Frame Relay switch. The C/R bit is not used. The Extended Address (EA) bit extends the address field an additional 2 bytes. There are two EA bits in a 16-bit address field. The eighth bit of every byte in the address field indicates the extended address. If the bit is set to 0, the containing byte is not the last byte of the address. Implementations that use the nonextended DLCI addresses set the first EA bit to 0 and the second EA bit to 1. The control field has the FECN bit, the BECN bit, and the DE bit.
6.2.6 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 (InARP) to dynamically configure the DLCI and discover neighboring routers across the cloud by mapping remote protocol addresses to local DLCI numbers. InARP is enabled by default. You can configure InARP by using the frame-relay inverse-arp command, and you can erase InARP mappings by using use the clear frame-relay inarp command.
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.
6.2.6.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.
6.2.6.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.
6.2.6.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. 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.
6.2.6.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.
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.
6.2.6.5 Congestion Control
Frame Relay has few control and error mechanisms as compared with X.25. There are four methods that Frame Relay uses to reduce congestion and errors in the network. These are:
Forward explicit congestion notification (FECN), which is a bit that is set in the frame that reaches a switch that is experiencing congestion. The next upstream router receives the frame with the FECN bit and allows the upper-layer protocols to determine what to do about the congestion. Sometimes, the FENC bit is ignored.
Backward explicit congestion notification (BECN), which functions similar to FECN bits, but the BECN bit is set by the switch on frames heading in the opposite direction of frames experiencing congestion. It is set on frames heading back to the source of the traffic. Depending on the implementation, a flow-control scheme can be used or the BECN can be ignored.
DE bit, which marks frames that are eligible to be discarded if the Frame Relay switch becomes congested. The Frame Relay network marks all frames in excess of the CIR as discard eligible. The router can attempt to influence which packets are discarded by marking the frames as discard eligible before they enter the Frame Relay network. The router can be configured to mark frames based on traffic type or other parameters.
Frame Relay Error checking, which is performed by means of a cyclic redundancy check (CRC).
This is error checking and not error correction. The upper-layer protocol is responsible to correct errors or re-send packets.
6.2.6.6 Frame Relay Traffic Shaping (FRTS)
FRTS allows for the management of congestion in Frame Relay networks. FRTS-enabled routers use received BECN information as input to manage the outbound traffic. FRTS is enabled on the major interface, and traffic classes are defined in global configuration. A traffic class is applied to each subinterface as it applies.
You can use FRTS for rate enforcement on an individual VC by configuring the peak transmission rate, to dynamically throttle traffic on a VC when BECNs are received, or for enhanced queuing support by enabling custom or priority queuing on a VC.
There are a number of commands that you can use to configure FRTS on a Frame Relay network. These include:
frame-relay traffic-shaping, which enables traffic shaping for all VCs defined on an interface.
frame-relay class map-class-name, which specifies the map class that is applied to the interface or subinterface. If this command is applied to a main interface, all the VCs on the interface's subinterfaces inherit the map class's properties.
map-class frame-relay map-class-name, defines the properties for the FRTS.
frame-relay traffic-rate average [peak], which defines the traffic rate for the VC.
frame-relay adaptive-shaping {been | foresight}, which enables dynamic traffic shaping based on received BECNs or ForeSight. ForeSight is a Cisco proprietary traffic control mechanism. This command replaces frame-relay becn-response-enable.
frame-relay custom-queue-list list-number, which defines a custom queue list number to apply to the VC.
frame-relay priority-group list-number, which defines a priority group number to apply to the VC to enable priority queuing. It applies the priority list that was defined at the global configuration level.
6.2.6.7 Frame Relay Compression
With Cisco routers, you can configure payload compression on point-to-point or multipoint interfaces. You can use either the Stacker method or FRF.9 with the Stacker method. The Stacker method uses an encoded dictionary to replace a stream of characters with codes. The symbols represented by the codes are stored in memory in a dictionary style list.
Implementation FRF.9 of the Frame Relay Forum provides standards-based compression on Frame Relay, therefore providing multivendor interoperability. FRF.9 uses higher compression ratios, which allows more data to be compressed, thus providing faster transmission.
To enable Stacker compression on point-to-point subinterfaces, use the frame-relay payload-compress packet-by-packet command.
To enable Stacker compression on multipoint subinterfaces, use the frame-relay map protocol protocol-address dlci payload-compress packet-by-packet command.
To enable FRF.9 compression on a point-to-point subinterface, use the frame-relay payload-compress frf9 stac command.
To enable FRF.9 compression on multipoint subinterfaces, use the frame-relay map protocol protocol-address dlci payload-compress frf9 stac command.
6.2.7 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. 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.