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.