rame Relay is a data protocol. To be specific, it's a network access protocol, which means that it takes other protocols, like Synchronous Data Link Control (SDLC), Internet Protocol (IP), IPX (Novell's version of IP), et al, and envelopes them with Frame Relay headers and trailers for protocol and network consistency. This means that dissimilar "native" protocols, like, again, SDLC, IP, and IPX, can share the same network without incompatibility, irreconcilable differences and big ticket communications link costs.
The Frame Relay protocol has been specially designed to transport large and variable amounts of data at "reasonably high speeds" very efficiently. The "reasonably high speeds" translate to multiples of 56 Kbps (just think, a few years ago, 56 Kbps was the high speed).
Like its X.25 cousin, Frame Relay has adopted some really great network ideologies: Variable-sized packets (up to 4,096 bytes); Bandwidth-on-demand capabilities; Any-to-any connectivity; and Statistical multiplexing. Add to that some Frame Relay-specific inner network efficiencies which minimize overhead and supervisory data exchange, and you've got one multi-purpose protocol that handles the idiosyncrasies of both Local Area Networks (LANs) and serial traffic with ease.
As processing and communications technologies evolved (and improved), the demand for a new network standard increased. So what changed? Well, nearly everything that was anything to networking!
Frame Relay provides a global, standard multipurpose (serial and LAN) protocol network. And its incredible efficiencies also reduce end-to-end transit delay for better data throughput (read: improved response time). But there's more ...
Frame Relay also allows data to "burst" (transmit) beyond its specified data rate; meaning that your anticipated and unanticipated "blips" of increased data traffic are efficiently handled without impact to your other traffic.
Furthermore, when compared with other terrestrial offerings, Frame Relay comes in as the winner (in most cases) in the direct "bandwidth / performance -versus- cost" war. Finally, Frame Relay is one of the migration paths to the high bandwidth transport architecture of the future, namely Broadband Integrated Services Digital Network (BISDN) / Asynchronous Transfer Mode (ATM). That's a transfer rate of at least 52 Mbps!
The first premise is that Frame Relay thinks everybody else is smarter. It rightly realizes its place in the food chain as just a network access mechanism, and the end points (a.k.a. your communicating devices) are the real brains behind the organization. All the big decisions, like re-transmission, error-checking, and flow control, are made by your devices (terminal, PC, host computer), and Frame Relay blindly (or at least near-sightedly) accepts it all.
Other than a pretty basic frame verification, Frame Relay blithely ignores higher level error determination, sure in the knowledge that, if something was wrong, the receiving device would initiate its own request, back through the network, for a re-transmission. If something does happen, and an error occurs, Frame Relay simply discards the data. So you see how important clean digital links are!
Frame Relay's approach to life (and data) is clearly black and white. You're either good or you're bad. At each point within the Frame Relay network (access devices and switches included), a determination is made as to whether the data frame is correct. This is accomplished through the Frame Check Sequence (FCS) byte on the Frame Relay packet. If your data passes this verification at all Frame points, then it will be received at "the other end". If, however, line problems, or whatever, create an error, and the Frame Check Sequence verification fails, then Frame Relay will throw the data into the trash. That's why digital links and Frame Relay are such perfect partners; digital's line errors are low, compared to analog, and the chances of Frame Relay throwing away data due to this problem are nil.
Well, that's really dependent upon your FRAD. But to name a few, SDLC, IP, IPX, BSC 3270, BSC 3780, ASCII/Asynchronous are just a few of the protocols that, through the use of FRADs, have access to the Frame Relay network.
In addition, inner-FRAD protocols provide protocol uniformity and consistency if you have more than one type of protocol accessing the Frame Relay network from the same site. A protocol you'll hear a lot about is RFC 1490, which provides multi-protocol support for both legacy and LAN-type protocols for Frame Relay access. In essence, it's a common envelope for a variety of end-user protocols to the Frame Relay network. Annex G also provides similar multi-protocol support for legacy-type protocols for Frame Relay access. Like its cousin RFC 1490, it's a common envelope for diverse end-user legacy protocols to the Frame Relay network.
A FRAD is a Frame Relay Access Device, and its main purpose is to take native protocols like IP, SDLC, Bisync, Async, et al and "frame" them with Frame Relay headers and trailers. The FRAD is usually co-positioned with the terminating devices and is usually an end-user/client responsibility.
Where applicable, the FRAD also has the responsibility of "spoofing" or providing local emulation to its connecting devices. Spoofing fakes out the connected device into thinking that it's talking directly to its termination point, like a host computer. This saves needless supervisory / polling traffic that would, otherwise, crisscross the network with great and hideous frequency.
A FRAD can be a separate device or it could be integrated into the terminating device, like a router, controller or PC.
NO! Frame Relay is a NETWORK ACCESS protocol, which means that it provides the 'ramp' to some other bulk transport protocol, such as Cell Relay / ATM (Asynchronous Transfer Mode), or networked IP, etc. Graphically speaking, the native protocol (such as IP or SDLC) enters the FRAD, which turns it into Frame Relay, which hits a Network Node, which turns it into a transport protocol! Huh? Well, in this case, pictures do speak louder than words! [See diagram.]
Frame Relay is supposed to handle my "anticipated and unanticipated" traffic blips - or data increases. How does it do that?
Frame Relay has the capability of assigning, on a temporary basis, more than you've been allocated, thus, allowing those "blips of traffic" an almost free passage. More importantly, your business, during those peak times, doesn't suffer from poor response time.
Well, the problem / challenge in doing that is when the Frame Relay network becomes congested (due to lots of traffic from a variety of sources), the Frame relay network starts trashing data, particularly the data getting that "free ride". And, remember the reason you require the 'free ride': lots more traffic = greater applications access = peak period = more business. Can you afford to lose transactions during those times?
When you select an information rate - or Committed Information Rate / CIR in Frame Relay-ese, it's almost your guarantee that even when times get tough (network congestion), your data will be transmitted at this minimum rate and NOT be trashed! Granted, sometimes congestion will be real bad, and all data will be dumped, but that's a pretty severe situation that shouldn't happen, particularly with the over-configured networks / links in today's carrier offerings.
Under normal circumstances, when your communicating devices transmit and receive data equivalent to your transmit / receive CIR, and no severe network congestion exists, your data will reach the appropriate end point without unnecessary heartache. If, however, an unanticipated 'blip' of data traffic occurs, and there's bandwidth available, your Frame Relay network assigns the additional bandwidth to accommodate your increase in traffic. It also marks that additional traffic with a Discard Eligibility - or DE , which suggests that if things get hot and the network becomes congested, this data can be discarded or trashed, without malice or forethought. But for the purposes of argument, let's say the network is not congested and your data reaches your end-point without any problem.
If and when the network becomes congested, that "blip" of traffic, which is currently enjoying a free ride - but is also marked with a DE - comes under the scrutiny of the network node. The network node verifies the congestion situation and your DE - say good-bye to your data. At this point, it's up to your remote devices to sort out the re-transmission jumble caused by this trashing.
We could go into great more detail, but this just about represents the "need-to-know" for Frame Relay. The bottom line is that Frame Relay offers you enhanced accessibility, bandwidth availability, applications insensitivity, cost savings, and an evolution path necessary for your processing environment. So, go on, get a network quote today!
For the expanded and complete Frame Relay Primer, please send your request to