When you’re first learning about Frame Relay, it’s often easy to confuse the LMI and the encapsulations used with Frame Relay.  The LMI is a definition of the messages used between the DTE (router) and the DCE (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 (DTE) care about the encapsulation.

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

* They perform a keepalive function between the DTE and the DCE.  If the access link has a problem, the absence of keepalive messages implies that the link is down.

* They 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: 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.  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.

Today’s most popular option is to use the default LMI setting.  This setting 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, the router disables the autosense feature.

Set the LMI type with: frame-relay lmi-type option interface subcommand.

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.

The LAPF header and trailer do not provide all the fields typically needed by routers.  In particular, a Protocol Type field.  Each data-link header needs a field to 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 Cisco uses for HDLC.

* RFC 1490 (which has later superseded 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 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.

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 should agree on 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.