Understanding Frame Relay

In simple terms, Frame Relay is a packet-switched network. A "frame", in the context of Frame
Relay, is a packet of data.
When a data stream enters a Frame Relay network it is broken into frames and each frame is sent across the network to the destination point. The frames contain header information which tells the intervening network nodes where to route them, and which output port to use.
At any one time an individual link in a Frame Relay network is carrying frames from many different sources en route to many different destinations. This frame mixing or multiplexing is one of the keys to Frame Relay’s advantages - it offers benefits over leased lines in terms of performance, cost-saving, manageability and resilience.

Comparisons
It’s worth comparing traditional point-to-point links with Frame Relay links in order to discuss the differences between the two methods.
A traditional leased line is a point-to-point link. You pay for the line irrespective of whether there is traffic on it. Consequently the line cost fficiency, its cost per unit of data sent, can vary. When an organisation has multiple locations then connecting them together using leased lines can become very expensive.
With leased lines, each message has to complete before the next message can travel along the line. This can cause response time problems at sending/receiving terminals and PCs. For example, a 3270 terminal may be slow to respond to a transaction request sent via SNA over a leased line. With Frame Relay the frames from one data source can be intermingled with those from another.
Because a Frame Relay line can carry more data it is often more cost-effective than leased lines. Users have reported substantial cost savings, 20 to 30%, for example, as a result of substituting
a Frame Relay network for a leased line network.

Reliability
With leased lines there is significant management overhead on the customer. Also Frame Relay networks can route frames around failed links or nodes. Leased lines cannot, and users of them often have to have dial-up lines available as backups. Frame Relay is reliable enough that these backups can be dispensed with, saving both cost and management overhead. Frame Relay networks can be reconfigured quite quickly so that, for example, a backup data centre can be used. This kind of reconfiguration would be impossible with leased lines.

Network Description
A user will typically have a private line to a node on a Frame Relay network. Line speed is fixed, and will be somewhere in the range of 56 Kbps to 2 Mbps depending on the service that has been purchased.
The network itself is composed of lines connecting nodes (also known as switches). The receiving location also has a private line to a Frame Relay node.
A permanent virtual circuit, or PVC, is defined to link the sending and receiving end points. The circuit is bi-directional. Frames are routed across the network from sender to receiver using header information which is added to the incoming data stream.
Note that it may be possible to have switched access to Frame Relay by, for example, dialling up an access point on the Frame Relay network over an ISDN interface. Data then flows from the user across an ISDN network and then into the Frame Relay network. Each logical connection from a site via ISDN uses a single ISDN channel; they cannot be multiplexed into one ISDN channel.
This may be a cost-effective way of connecting remote sites with low data traffic rates to a Frame Relay network.
All the nodes have entry and exit ports and a particular route through the network involves each node know ing which exit ports to use for frames in a message. Each frame has a data
link connection identifier - DLCI -which is used by the nodes to choose the right exit port. A DLCI is not constant across the network. It is of only local significance to a Frame Relay node. The routing tables in each node for a PVC take care of alternately reading and assigning DLCI values in frame headers before they send the frame on to the next node.
When PVCs are first defined mis-installation of DLCI numbers can be a common error that prevents proper message transmission and receipt. The FRAD Data enters a Frame Relay network by passing through a FRAD, which is either a Frame Relay Access Device or Frame Relay Assembler/Disassembler depending on who you speak to. Either way, a FRAD is typically a router.
The FRAD breaks the data stream down into sections (frames), adds the header information and a check digit at the end, and sends the frames across the network. At the exit point of the network the frames are reassembled into a continuous data stream once more.
Each frame contains 5 bytes of header information. This header size is constant irrespective of how large the frame is. The larger the frame, the lower the overhead and the more efficient
Frame Relay is at turning theoretical bandwidth into available bandwidth.
A Frame Relay node takes no interest in user data within a frame at all. It looks for a flag that starts a frame, the header, and then for a check digit that marks the end of the user data.
Frames can be of variable size. Each one is transmitted as a stand-alone entity. If it gets corrupted en route through the network it is dropped. There is no frame error checking and recovery within the network. That is the responsibility of software that uses the network. Thus Frame Relay requires a virtually error-free transmission system for this approach to be enable.

Renting Space
A telcomms company (telco to those in the industry) will take a leased line, a T1, for example, and sell you Frame Relay bandwidth on it. So you are, in effect, using only part of the T1 line.
There may be 40 or more customers each with their own Frame Relay bandwidth on the line. Frames are statistically multiplexed on it. The telco is sharing lines and nodes between many customers. This is one reason why a 56 Kbps Frame Relay network is cheaper than a 56 Kbps
leased line.

CIR
A user commits to deliver data to a PVC at a Committed Information Rate (CIR), which is expressed as bits per second. There could be two 28 Kbps CIR PVCs defined over a single 56
Kbps interface to the network. Since data has to be submitted at the line speed, 56 Kbps for example, the CIR is an average over a period of a few seconds. If you under-submit it doesn’t
matter. If you over-submit (called "bursting over your CIR"), excess frames may be discarded if the network gets congested.
When you’re renting Frame Relay lines, you need to discuss CIR figures with the company to ensure that the line can cope with the amount of traffic you intend to throw at it. Congestion occurs when more data is attempting to cross the network than it can handle. When this is detected a congestion bit is added to a frame header to tell the sending FRAD it ought to slow down. It will then keep frames in its buffers until it stops receiving congestion bits.
If buffer space fills up, or there is none, then frames are discarded. The network knows the CIR for a sender and discards frames that have had a Discard-Enable (DE) bit set in their
header meaning that they represent a frame in excess of the sender’s CIR.
Some FRADs can set the DE bit to signal that the frame is low priority. Thus senders can divide messages into normal and low priority groups.

UNI
The UNI is the User Network Interface and defines what user devices need to do to initiate, operate and receive Frame Relay transmissions.

The PVC
When a location or device is given access to an existing Frame Relay network it means wiring in the access port and then configuring a permanent virtual circuit - PVC. A unique PVC connects each of the user’s sending nodes with each of their receiving nodes. Each PVC is defined by DLCIs with routing tables that designate the entry and exit ports on a node in the network.
The PVC is ready to use whenever data needs to be sent. This keeps call latency low. Automatic Re-routing If a node or line in a Frame Relay network goes down, the network is automatically reconfigured to route around the failed component. This is a matter of re-setting routing tables in each node on the network so that PVCs are redefined.

SVC
The Frame Relay specification defines Switched Virtual Circuits -SVCs - as well as PVCs. A calling device would request a connection to a destination device using internationally-recognized X.121 or E.164 numbering plans. SVC services may be cheaper than PVC services in circumstances where there is a low traffic rate or low connection rate. Also SVC services
mean that users don’t have to pre-configure and manage PVCs and can get additional bandwidth on demand.
This is useful where networks are in a state of flux. When an SVC is set up, any encapsulation procedures needed are agreed during the setup. The CIR is also agreed at that time. Note that Multicasting is only available over PVCs, not SVCs.

LMI
When there is no data passing across from the network to a user the network is polled every 10 seconds or so and should return a "keep alive" message signifying that the link is operational. This polling is part of the Line Management Interface - LMI. The link will be assumed to be down if a certain number of keep alive failures occurs. This allows noise on the line to be accommodated.

Frame Relay Forum
In 1991, 42 Frame Relay suppliers formed the Frame Relay Forum. There are now over 300 members and it has proved to be a very effective body in advancing market take-up of Frame
Relay technology.
The Forum has three subgroups which work to develop forum proposals. The Market Development and Education Committee aims to stimulate interest in the technology and its
benefits as well as serving as a user group. Multivendor issues are the concern of the Interoperability and Testing Committee.
The Technical Committee addresses technical issues to encourage interoperability and developments of Frame Relay technology. There are four main areas of activity: User Network
Interfaces (UNI), Network-to-Network Interface (NNI), Multicast Service and Multiprotocol Encapsulation Procedures. The committee develops UNI standards and conformance tests for
vendors to check their products and services. Items in the standard may be mandatory, highly desirable or not critical. Transferring data between network nodes belonging to different Frame
Relay vendors is where the NNI issues surface. A user may use Frame Relay services from two or more carriers with each carrier providing a segment of that user’s Frame Relay network.
Whole PVCs are broken down into PVC segments provided by each carrier. The sum of the segments makes up a complete PVC. The committee decides what each network has to do to
support such interoperability. A peerto-peer interface operates between the carriers providing each network segment.
When a network detects that a User Network Interface or NNI is inoperative, each network notifies the adjacent network via the NNI that the PVC is inactive. The PVC status change is propagated through the adjacent networks to the remote users. The NNI also covers congestion management principles and CIR coordination between the network providers. Ideally a
user should see and receive the same service from a multi-carrier Frame Relay network as from a single carrier network. This is what the committee is working towards. Multicasting, a supplementary Frame Relay service, is the facility to accept a frame at a UNI and broadcast
the frame to multiple destinations. In One-Way multicasting, nodes in the Frame Relay network have an extra PVC. Frames transmitted on this PVC will be delivered to all the neighbouring
nodes. This is helpful for management traffic like routing table updates.
Two-Way multicasting allows a single point or "root" to multicast data units to a specified group of users. Frames transmitted by the root are seen by all group members. Frames transmitted
by group members are delivered only to the root. This is useful for remote learning applications.
With N-Way multicasting frames transmitted by any group member are seen by all group members. This is useful for conferencing situations. Multicasting destinations may be on one
network or multiple networks.

LAN Connections
When Frame Relay is used to interconnect LANs then the LAN traffic (Ethernet or Token Ring, for example) is encapsulated in the frames so that there is no logical break in the LAN structure; the interconnected LANs seem to be a single one. Multiprotocol Encapsulation Procedures describe the methods used to do this. They cover other protocols as well and also include
bridging and routing between LANs. SNA And Frame Relay SNA is another packet switching
protocol developed from broadband ISDN. SNA links may well have used leased 9.6 Kbps lines, either point-topoint or multidropped. Frame Relay will provide much more speed than this. It will also support multiple protocols which the SNA links cannot. As IBM sites have added PCs on LANs and Unix systems with TCP/IP to its SNA 3270, LU6.2 etc networks, Frame Relay is an attractive option for carrying these multiple protocols. Without it, multiple SNA lines have to be
installed.
IBM has ensured that its SNA products support Frame Relay and supports all SNA topologies across Frame Relay networks. For example, in 1994 IBM released a new version of its Network Control Protocol, NCP 7.1, that allowed SNA networks to fully utilise Frame Relay. Also PS/2s running OS/2 can have RoutExpander/2 software and Wide Area Concentrator - WAC - hardware which enables them to access a Frame Relay network and function as a gateway for a mall site. AIX RS/6000s can be connected to a mainframe host via a Token Ring LAN and Frame Relay rather than by SNA links between the mainframe and the Unix box. The same goes for terminals and mainframes.

ATM And Frame Relay
Both Frame Relay and ATM evolved from the broadband ISDN standards developed in the 1980s. The essential difference is ATM’s fixed length cell size versus Frame Relay’s variable length frames. ATM has a fixed 53-byte cell size. That means the header overhead is constant. If cells are not filled with data then the header overhead as a percentage of network traffic grows. Thus ATM may be less efficient than Frame Relay when the data load factor in cells is low.
Many analysts think that Frame Relay and ATM will co-exist with an eventual trend for ATM to capture the backbone traffic and Frame Relay becoming a submitting route to an ATM backbone. ATM may spread to desktop devices where its ability to cope well with delay-sensitive traffic like multimedia make it suitable. In general, it is thought that Frame Relay transfers data more efficiently up to 56 Kbps with ATM being better at higher rates.
The Frame Relay Forum, together with the ATM Forum, has defined a Frame Relay/ATM Network Interworking Implementation Agreement to cover this area. They have also been
working on Frame Relay-to-ATM protocol conversion.

Voice And Frame Relay
Voice traffic is very sensitive to delay. If a voice input stream is broken up into frames which are sent one after the other across a network and reassembled at the other end, the listener should hear normal telephone speech. However, if there are intervals between the frames then the speech becomes disjointed with pauses between sections. The sections may not be at word or sentence boundaries which lowers the perceived quality still further. Frame Relay’s inability to prioritise frames effectively doesn’t help and neither does the use of DE bit setting on frames above the CIR. You just cannot discard voice frames. Thus Frame Relay has been considered unsuitable for voice traffic.
However, there are moves to enable voice traffic to be sent over Frame Relay. The forum’s technical committee is working on a framework for a Voice Over Frame Relay implementation.
Some vendors, like Scitec, have voice solutions ready today. The committee is also working on data compression which should help further and make Frame Relay more suitable for multimedia traffic. Voice-capable FRADS chop big frames up into small ones using ATM
segmentation and re-assembly (SAR) techniques. This stops large frames delaying voice frames and hence the network. This combination handles retransmission of data if errors occur. It is a perfect fit for Frame Relay. lowering voice transmission quality. Integrating voice and data on a Frame Relay network can be effective for companies with international links. Voice calls between countries are expensive and carrying voice over Frame Relay can save millions of dollars annually.

X.25 And Frame Relay
In Europe, X.25 lines have been popular for LAN-to-LAN and SNA connections. Frame Relay offers lower call latency, faster performance and cheaper line cost. It also has a lower data overhead per message. In X.25 the network handles error detection and retransmission. Frame
Relay networks let the user do this. For example, with the TCP/IP protocol, TCP establishes robust transport-level connections across a network and IP, a lower level protocol in the ISO scheme of things, carries data packets across the network. This combination handles retransmission of data if errors occur. It is a perfect fit for Frame Relay.