Frame Relay -- Summary
Network Consultants Handbook - Frame Relay
by Matthew Castelli
Frame Relay is a Layer 2 (data link) wide-area network (WAN) protocol that works at both Layer 1 (physical) and Layer 2 (data link) of the OSI model. Although Frame Relay services were initially designed to operate over ISDN service, the more common deployment today involves dedicated access to WAN resources.
Frame Relay networks are typically deployed as a cost-effective replacement for point-to-point private line, or leased line, services. Whereas point-to-point customers incur a monthly fee for local access and long-haul connections, Frame Relay customers incur the same monthly fee for local access, but only a fraction of the long-haul connection fee associated with point-to-point private line services.
Frame Relay was standardized by two standards bodies -- internationally by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) and domestically by ANSI (American National Standards Institute).
Frame Relay is a packet-switched technology, meaning that each network end user, or end node, will share backbone network resources, such as bandwidth. Connectivity between these end nodes is accomplished with the use of Frame Relay virtual circuits (VCs).
Frame Relay WAN service primarily comprises four functional components:
- Customer premise Frame Relay access device (FRAD).
- Local access loop to the service provider network.
- Frame Relay switch access port. Link Management Interface parameters are defined here.
- Frame Relay VC parameters to each end site.
DLCIs are of local significance, unless an agreement has been made with the network service provider to deploy global DLCIs. Local significance means that DLCIs are of use only to the local Frame Relay network device. Frame Relay DLCIs are analogous to an organizations telephone network utilizing speed-dial functions.
Two types of Frame Relay VCs exist:
- Permanent virtual circuits (PVCs) -- These are permanently established, requiring no call setup, and utilize DLCIs for endpoint addressing.
- Switched virtual circuits (SVCs) -- These are established as needed, requiring call setup procedures and utilizing X.121 or E.164 addresses for endpoint addressing.
Two types of congestion-notification mechanisms are implemented with Frame Relay:
- Forward explicit congestion notification (FECN) -- The FECN bit is set by a Frame Relay network to inform the Frame Relay networking device receiving the frame that congestion was experienced in the path from origination to destination. Frame relay network devices that receive frames with the FECN bit will act as directed by the upper-layer protocols in operation. The upper-layer protocols will initiate flow-control operations, depending on which upper-layer protocols are implemented. This flow-control action is typically the throttling back of data transmission, although some implementations can be designated to ignore the FECN bit and take no action.
- Backward explicit congestion notification (BECN) -- Much like the FECN bit, the BECN bit is set by a Frame Relay network to inform the DTE that is receiving the frame that congestion was experienced in the path traveling in the opposite direction of frames. The upper-layer protocols will initiate flow-control operations, depending on which upper-layer protocols are implemented. This flow-control action is typically the throttling back of data transmission, although some implementations can be designated to ignore the BECN bit and take no action.
- Committed information rate (CIR) -- This is the amount of bandwidth that will be delivered as best-effort across the Frame Relay backbone network.
- Discard eligibility (DE) -- This is a bit in the frame header that indicates whether that frame can be discarded if congestion is encountered during transmission.
- Virtual circuit identifier
- Data-link connection identifiers (DLCIs) for PVCs -- Although DLCI values can be 10, 16, or 23 bits in length, 10-bit DLCIs have become the de facto standard for Frame Relay WAN implementations.
- X.121/E.164 addressing for SVCs -- X.121 is a hierarchical addressing scheme that was originally designed to number X.25 DTEs. E.164 is a hierarchical global telecommunications numbering plan, similar to the North American Number Plan (NANP, 1-NPA-Nxx-xxxx).
Table 15-17: Summary of Network Topology Formulae
Note: N is the number of locations
|Fully meshed||[(N (N - 1)) / 2]|
|Partial-mesh||(Approximation) [N2 / (N - 1)]|
(Guideline) [((N (N - 1)) / 2) X (N - 1)]
|Hub-and-Spoke||[N - 1]|
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.
- TCP/IP Suite
- Novell IPX Suite
- IBM SNA Suite
- Voice over Frame Relay (VoFr)
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.