Frame Relay -- Summary - Page 3

 By Cisco Press
Page 3 of 3   |  Back to Page 1
Print Article

Local Management Interface (LMI) is a set of enhancements to the basic Frame Relay specification. LMI includes support for keepalive mechanisms, verifying the flow of data; multicast mechanisms, providing the network server with local and multicast DLCI information; global addressing, giving DLCIs global rather than local significance; and status mechanisms, providing ongoing status reports on the switch-known DLCIs.

Three types of LMI are found in Frame Relay network implementations:

  • ANSI T1.617 (Annex D) -- The maximum number of connections (PVCs) supported is limited to 976. LMI type ANSI T1.627 (Annex D) uses DLCI 0 to carry local (link) management information.
  • ITU-T Q.933 (Annex A) -- Like LMI type Annex-D, the maximum number of connections (PVCs) supported is limited to 976. LMI type ITU-T Q.933 (Annex A) also uses DLCI 0 to carry local (link) management information.
  • LMI (Original) -- The maximum number of connections (PVCs) supported is limited to 992. LMI type LMI uses DLCI 1023 to carry local (link) management information.
Frame Relay is a versatile transport mechanism, traditionally supporting four networking applications:
  • TCP/IP Suite
  • Novell IPX Suite
  • IBM SNA Suite
  • Voice over Frame Relay (VoFr)
Internet Protocol (IP) is a best-effort delivery protocol, relying on the transmission-control mechanisms (packet acknowledgement and sequencing) that are supported by TCP. IP datagrams, or packets, are routed from source to destination based on the address information found in the packet header. IP traffic is typically bursty in nature, making it an ideal network-layer protocol for Frame Relay WANs.

Novell IPX implementations over Frame Relay are similar to IP network implementation. Whereas a TCP/IP implementation would require the mapping of Layer 3 IP addresses to a DLCI, Novell IPX implementations require the mapping of the Layer 3 IPX addresses to a DLCI. Special consideration needs to be made with IPX over Frame Relay implementations regarding the impact of Novell RIP and SAP message traffic to a Frame Relay internetwork.

Migration of a legacy SNA network from a point-to-point infrastructure to a more economical and manageable Frame Relay infrastructure is attractive; however, some challenges exist when SNA traffic is sent across Frame Relay connections. IBM SNA was designed to operate across reliable communication links that support predictable response times. The challenge that arises with Frame Relay network implementations is that Frame Relay service tends to have unpredictable and variable response times, for which SNA was not designed to interoperate or able to manage within its traditional design.

Voice over Frame Relay (VoFr) has recently enjoyed the general acceptance of any efficient and cost-effective technology. In the traditional plain old telephone service (POTS) network, a conventional (with no compression) voice call is encoded, as defined by the ITU pulse code modulation (PCM) standard, and utilizes 64 kbps of bandwidth. Several compression methods have been developed and deployed that reduce the bandwidth required by a voice call to as little as 4 kbps, thereby allowing more voice calls to be carried over a single Frame Relay serial interface (or subinterface PVC).

That concludes our serialization of Chapter 15 from Cisco Press' Network Consultants Handbook.

This article was originally published on Feb 14, 2002
Get the Latest Scoop with Networking Update Newsletter