The World Famous Frame Relay FAQ, written by X.25 and Frame Relay Software Pioneer Dennis Baasch in 1997.
What is Frame Relay?
So what's all this hullaballoo about Frame Relay? Is it some powerful new networking concept that's going to revolutionize Western World communications? Or is it just another networking protocol? Or just another masters project that somehow caught on?
One thing that's certain about frame relay is that its widely misunderstood. In fact, its so misunderstood that many people who could benefit most from it are avoiding it like the plague. As a Frame Relay vendor this worries us a great deal. So we'll offer this tutorial with hopes of generating some interest.
Its Cheap, Right?
This is the only thing that most people agree about when referring to frame relay, and its not even accurate. A better term to use it that its cost-effective. There's a big difference. If you want to be a stickler, OK, its cheap. But understanding why its cheap is the key to understanding its power. Before you can understand why its inexpensive, you have to know something about how it works.
How Does it Work?
Frame relay is a networking protocol, which means that unlike a point-to-point private line, there's a network switch in-between your location and to whoever you're connecting. Actually, you get a private line to a node on the frame relay network, and the remote location gets a private line to a near-by frame relay node. When you send traffic over your line, the network gets it to the remote location by routing it through the frame relay network. Then the data is passed to the remote location's line and, voila, the data has reached its destination.
What's a DLCI?
A DLCI is a channel number (the technical term is "data link connection identifier") which is attached to data frames to tell the network how to route the data. Frame relay is "statistically multiplexed", which means that only one frame can be transmitted at a time but many logical connections can co-exist on a single physical line. The DLCI allows the data to be logically tied to one of the connections so that once it gets to the network it knows where to send it.
What is LMI?
LMI is one of those really bad terms that means "Line Management Interface". Its a bad term for 2 reasons, one because its more of a protocol than an interface, and the second is that one of the two most widely used versions of LMI is referred to as LMI. More about this later. Basically, LMI is a keep-alive mechanism that periodically gives the end user some status information about his connections. Every 10 seconds or so, the end user polls the network, either requesting a dumb sequenced response or channel status information. The network should respond with the requested information; if it doesn't then the user will consider the connection to be "down" (actually, it takes more than one failure to bring the line down as its possible that a frame was lost due to noise). When the network responds with a "FULL STATUS" response, it includes status information about DLCIs that are allocated to that line. The user can use this information to determine whether its logical connections are able to pass data.
The Truth About CIR
You've heard people talk about CIR. but what does it mean? The acronym itself stands for "Committed Information Rate", which really doesn't seem that difficult to understand. But there seems to be widespread misinterpretation of this concept, so we'll attempt to straighten the whole thing out. You'll hear terms like "burst rate" and "bursting above your CIR", but these terms are really quite misleading and were devised by engineers who figured that most people wouldn't understand network engineering concepts so they tried to put it in layman's terms. In reality, you're always "bursting" to your line speed because frame relay is an HDLC protocol and there's no other way to make it work.
HDLC is a synchronous protocol (which means that the data is "synchronized" to a clock) which sends data with a standardized framing and checksum technique. When a frame is transmitted, the data must be contiguous, that is, there cannot be any "gaps" between bytes of data. So if you're transmitting 1000 bytes of data you can't send 500, and then hang out for a while, and then send the rest. It has to go out as one, big chunk. Its a lot like a train. Either all of the cars make it to the station or none of them do; they're not independent units. The frame relay term "bursting over your CIR" comes into play because there is no way to slow down the data, or to change the length of the chunk, once you start transmitting. And, contrary to popular belief, you cannot change the clock speed on the line. So if you happen to send too much data because your data chunk is larger than the allotment, you've bursted over your CIR. Then, you may ask, what is CIR?
CIR is the "worst-case" throughput that the frame relay network provider attempts to guarantee. If you're talking about cars on a highway, its like the state guaranteeing you that you'll always be able to go 40MPH. Like the state, the frame relay network provider can't guarantee that you'll always be able to transmit at the CIR (take the case where everyone on the network happens to be transmitting at once), but they can over a reasonable time span (usually over a span of seconds). Basically, the network backbone is "engineered" to handle reasonable loads, such as the number of lanes in a highway. Given a certain amount of traffic, the data should flow through the backbone without delay. At times, when unusually heavy traffic exists, you have what they call congestion.
Congestion
"Congestion"...now there's a big word. What is congestion? Congestion is when there is more aggregate data in the network than there is bandwidth. How can that happen, you say? Well, its like ten roads that turn into a four lane highway. Most of the time you just zip in, no problem. But whenever you've got more than four guys trying to get on the highway at once someone has to slow down. If no-one slows down you have a crash.
Now the problem with frame relay is that there is no slowing down. If you have a 56kbs line then you always transmit your data at 56kbs, because that's the clock speed and that's the way it works. You can't change the clock speed like you slow down a car. So when there's congestion, how do you avoid a crash? Well you've basically got two choices. When the network determines that a congestion event is close to a reality, it sends a notification bit in the data which tells the frame relay device (lets call it a router) that it really ought to slow down. The only way that it can slow down is to delay sending the next frame (it could abort the current frame, but that would be a pretty stinky way to do it). The big question is how long to wait...well there's a complicated formula for determining this that's basically horse-nonsense, so lets just say you wait a little while. Logically, you should delay enough so that you slow down to your CIR, but if your CIR is 0 this is pretty difficult. When you send data, you check to see if you're getting any more congestion bits, and if not, you can just start pummeling data onto the line again.
If you can't slow down (because your router doesn't support such concepts), then your risk of crashing is increased. Of course data doesn't crash, but you can think of it as a policeman standing at the previously mentioned ten road to four lane intersection with a phaser gun. When he sees that a crash is imminent, he zaps one of the cars with his phaser, making it disappear forever. Frame relay networks call this a "discard". When there is too much data, some of the data gets discarded. But how does the network decide which data gets discarded? Now we're back to CIR. Once you've reached your guaranteed throughput, the network will consider additional data to have high discard potential and will set the DE (discard enable) bit in the frame. So when a congestion event occurs, the excess frames are discarded first. In our highway example, there might be a guy standing on the side of each of the ten roads counting cars. Say that ten cars per minute are allowed. When more than ten cars go by in a particular minute interval, he launches tomatoes at the excess car's windshields for the duration of the interval. When the cars reach the intersection, the policeman will try to zap the tomatoed vehicles first. If the highway (network) is engineered properly, all of the non-tomatoed cars (or non-DE bit enabled frames) should be able to pass without a problem.
User Priority Control
In the case where certain traffic is more important than others, the end user (or router) can set the DE bit to tell the network that the data isn't very important. In the highway example, there may be a family in two separate cars, with the husband in the lead and the wife and kids behind. Even though the husband is first, he might smash a tomato on his own windshield in an effort to say "take me first".
Not many routers can do this, mainly because ISO says that networking layers aren't supposed to know about "content" and that applications aren't supposed to know about over what medium the data is transported. There's also a question of how do you prioritize data on a 0 CIR link when (theoretically) all of your data is transmitted over your CIR. These issues, unfortunately, are well beyond the scope of this FAQ.
Making the Connection
When you get a frame relay connection, you have to connect your router or host to the network, usually by connecting the router's V.35 port to a CSU/DSU with a cable. Assuming that your DDS or T1 line is working properly, your frame relay device will begin to send "STATUS ENQUIRY" frames to the switch as part of the line management protocol. In the US, there are two accepted "standards" for this protocol, one is referred to an "ANSI ANNEX-D" and the other is referred to, regrettably, as "LMI". When you send the switch a STATUS ENQUIRY, the switch responds with a STATUS message in return. Occasionally, the router will ask for "full status" information, and when these messages are sent the switch will respond with information about all of the DLCIs that are currently allocated on the line. Using a debugging mechanism (the hdebug or ifhdlc utilities with our product), you should be able to look at the information that the switch is sending and determine if the frame relay network provider has your line configured properly. DLCIs are marked "ACTIVE" if there is a valid connection set up for that particular DLCI. If you do not get an ACTIVE response from the switch, then the frame relay network provider probably does not have the connection set up properly.
Once you have successfully received a response from the switch, the link is considered to be "up" and you are ready to pass data on the "active" DLCIs.
So, Why is it Inexpensive?
Ah, the bottom line. Well, there are essentially 2 reasons why frame relay is less expensive than private lines. The negativists will tell you that its because you get lower throughput, but that's not the reason and not necessarily accurate, either. One reason, at least initially, is that you're really only buying half a line, and depending on how well deployed frame relay is in you area, you're generally buying a shorter line. You're only buying half a line because your provider probably has an existing T1 (or multiple T1s), and is simply selling you bandwidth (a DLCI) on the line. Another piece of this is that you're only buying a line to the nearest frame relay switch, which may be much closer than your provider. In fact, with frame relay, you can connect to a provider hundreds of miles away for perhaps the same price as a local provider, so your choices of providers are greatly expanded as well. The result of all of this is that when you pay your monthly charge you're only paying for one end of a private line (with a dedicated point-to-point connection you pay for your provider's circuit as well) that is shorter (so if there are distance sensitive charges it will be less). You also don't have to buy your provider a CSU/DSU, so your start-up costs should be less as well.
That explains why the monthly line charges are less, but some providers sell service for a lot less via frame relay, so the line charge alone can't be the only component. So what's the secret? Well, the secret has to do with the equipment economies associated with frame relay. Your provider can service 40 or more 56k customers over a single T1 circuit, which means that a dual T1 router can service a whole lot of customers. With private line service, a provider would need either a couple of real big expensive routers or a whole bunch of smaller ones, as well as a room full of CSU/DSUs. Your provider saves money, real estate and has a much cleaner, easy to manage operation with frame relay. This also implies that a little guy can be a big vendor with frame relay. Little guys have less overhead than big guys, and that results in lower costs and greater competition.
Cir and Bandwidth Limiting
Now all this stuff about CIR and bursting and such can be pretty confusing, and we've noticed that even many of the people who consider themselves experts have no clue how it works, but there is a pretty simple situation which it seems that most router vendors are largely ignoring. It has to do with a "hub" frame relay connection, which is usually the case where you have a central site with a T1 and several or many remote locations connected to the frame relay network at lower speeds. As explained before, each remote location is connected to the hub location with a DLCI, and all of the DLCIs are aggregated on a single T1, all of which is just fine and dandy. The issue is that each PVC has its own CIR that cannot exceed the speed of its individual line. So, for example suppose you have a location connected to the frame relay network with a 56kbs line and a 56k CIR. What most people fail to realize is that the T1 side of the connection ALSO has a 56k CIR. The problem is that the T1 side will always transmit data at full T1 speeds, and the 56k CIR can easily be viotated with reasonably small bursts of activity.What can (and often does) happen, it that the router on the T1 side of the connection will violate the 56k CIR and DE bits will be set in the location's incoming data, which of course represents a potential network discard. Since the location has a full CIR (56k for a 56k line), this condition is highly unexpected.
The solution the the above problem is what we call "bandwidth limiting". Our router can limit the traffic on a particular DLCI to match the bandwidth of the remote location to avoid this problem. It also prevents the frame relay network switch from getting more data than it can physically forward. You can actually set the bandwidth limit to any value (ie 48kbs) in the case that you need to allocate bandwidth usage different from the physical topology. All in all, its a neat little feature and at the time of this writing no one else has it, which makes us feel good even if hardly anyone knows how to use it!
About Frame Relay Routers and FRADs
Now that you know everything there is to know about frame relay, choosing a frame relay router for yourself should be fairly simple. Well, of course it isn't easy, because everyone says that their product is the best and that it can do anything you want it to do. A simple rule of thumb is that you want to get the most bang for your buck, even if you have a low speed line. Every frame that you transmit is affected by the speed of your router (even if its a millisecond or two), and those tiny little latencies add up fast, particularly when you may be transmitting millions of bytes per day. In addition, you never know what you'll be doing next year, so get something that isn't going to become a lawn ornament when technology changes a tad. Be optimistic, get something that will grow with the marketplace.
You really want a router with "congestion management", but this is a pretty tough call for the layman. If congestion management is implemented improperly (like according to the "standard" algorithm), the router will actually inhibit your throughput and will have a negative impact. You want a router with a more sophisticated, adaptive algorithm so that it can adjust to specific network situations on a demand basis. ET/R1500-T and the ET/R1500-H use such an algorithm.
Don't ever buy a converter (or a raw FRAD) unless you have to; they are generally slow and serve very little purpose unless you have some archaic piece of equipment that can't be upgraded. Anyone who tells you that "need a FRAD" (instead of a router) to connect to the internet or to pass TCP/IP or Novell traffic is either selling them or knows nothing about frame relay.
Of course the best way is to talk to the vendor on the phone and get your own impression. Now that you know some of the lingo, you may be able to determine when a salesman is giving you a snow job. If you can't get to anyone in the company who seems to know anything about frame relay, then you probably won't be able to get to anyone when you need support, either.