While the PVC is a point-to-point logical path between two customer routers, there are many physical and logical components that work together to create the illusion of a single logical path. Each router needs a physical access link from the router to the nearest Frame Relay switch. The provider needs to have some kind of physical network between those switches as well. In addition, the provider has to somehow provision those virtual circuits in order to make sure frames sent from one end of a VC 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. The basic Frame Relay protocol format used for carrying user data frames is also used to carry LMI messages. However, LMI messages are sent in frame distinguished by a special LMI-specific DLCI usually set to 1023.

Two LMI message types have been defined that flow between the router acting as DTE and the Frame Relay switch acting as DCE. The Status-enquiry messages are sent from the router to the switch and allow the router to ask about the status of network. The Status messages are sent from the switch to the router responding to status-enquiry messages. In fact, the Frame Relay switch sends two types of messages: a status message every 10 seconds and a full status message instead of a status message every 60 seconds. The full status message containc all the information about known DLCIs and their state. The LMI status-enquiry messages are sent every 10 seconds from the router to the switch while the router responds with the status message. These periodic LMI messages also serve as keepalives for both the router and the switch.   LMI status messages act as a keepalive between the DTE and DCE. If the access link is having a problem, these keepalives will be missed and link problem will be detected. In addition to performing a keepalive function between the DTE and DCE, LMI status messages also signal if a PVC is active or inactive. Every PVC is predefined by the Frame Relay service provider, but its status can change due to network conditions like failure of trunk links in the provider network. An access link may be up and and running and keepalives may be present but one or more VCs may still be down. The reason is that a VC is an end-to-end logical connection that involves not only the access links at the two ends but also spans the core of the provider network. The router needs to know that which VCs are functional and which are not. The router learns this information as well from the Frame Relay switch through LMI status messages.

In addition to the common features like keepalives, LMI has several optional features defined as LMI extensions. We will briefly introduce two LMI extensions related to global addressing and multicasting. The basic Frame Relay specification supports DLCI values that are only locally significant. For example, the DLCI value used on the access link between a router and Frame Relay switch is significant only on the access link and does not in any way identifies the router globally. This DLCI value cannot serve as an address for the router due to its local significance. In other words, Frame Relay addresses do not exist and hence cannot be discovered by usual address resolution methods. Therefore, static maps must be created to tell a router which DLCI to use to reach a remote router. The global addressing extension solves this problem by allowing DLCI values that are globally significant and hence can serve as addresses of individual end routers. The Frame Relay network with global addressing looks much like a LAN to the end routers that can use global addresses (DLCIs) as Frame Relay addresses similar to MAC addresses used in a LAN.

The multicasting extension defines multicasting as another optional LMI feature. There is a series of four reserved DLCI values (1019 to 1022) that represent multicast groups. The frames sent by a device using one of these reserved DLCIs are replicated by the network and sent to all destinations in the group. The LMI extension for multicasting also defines LMI messages to notify devices of the presence, addition, and deletion of multicast groups.

Cisco routers have three options for different variations of LMI protocols: Cisco, ITU, and ANSI. These LMI options have their differences and are incompatible with each other. For LMI to work correctly, both the DTE and DCE devices across an access link must use the same LMI type.

LMI configuration is pretty straightforward. Most of the time, we are good with the default LMI setting. This default setting uses something known as LMI autosense, in which router simply figures out on its own which LMI type the Frame Relay switch is using. You can just let the router autosense the LMI and never bother manually configuring it on the router. However, if you choose to configure the LMI type manually, it will automatically disable the autosense featue. Table 12-2 lists the three LMI types, the standrd document, and the keyword used in the Cisco IOS Software frame-relay lmi-type interface configuration mode command.

Table 12-4 LMI Types

LMI Type Standard Document Cisco IOS Keyword
Cisco Proprietary cisco
ANSI T1.617 Annex D ansi
ITU Q.933 Annex A q933a