Frame Relay Forum, a vendor consortium, also defines several Frame Relay specifications,
many of which have been added to the standards body's documents. Table 8-10 lists the most
important of these specifications.
used with Frame Relay; Cisco expects CCNAs to master the differences. The LMI is a
definition of the messages used between the DTE (for example, a router) and the DCE (for
example, the Frame Relay switch owned by the service provider). The encapsulation defines the
headers used, in addition to the basic Frame Relay header, for transporting the frame from DTE
to DTE. The switch and its connected router care about using the same LMI; the switch does
not care about the encapsulation.
is slightly different and therefore not compatible with the other two. For instance, the Cisco and
ANSI Q.933-A LMIs call for use of DLCI 1023 for LMI messages, whereas T1.617-D calls for
DLCI 0. Some of the messages have different fields in their information elements. The DTE
simply needs to know which of the two (DLCI 1023 or DLCI 0) to use; it must match the one
used by the switch.
supported by the IOS in version 11.2, so there is no need to code the LMI type. If desired, the
LMI type can be configured, but this disables the autosense feature. One LMI type exists per
serial interface because the LMI controls the single physical access link, which is connected to
a single switch.
message, which signals whether a PVC is up or down. Even though each PVC is predefined, its
status can change. As with all LMI messages, status enquiry messages flow between the switch
(DCE) and the DTE. For instance, a routing protocol reacts when a PVC is down, signaling that
routes over that PVC are lost.
LAPF header/trailer
(originated in RFC 1490/2427)