610 W Hubbard, Suite 125
Coeur d'Alene, ID 83814
Customer Support
|
610 W Hubbard, Suite 125 |
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. .
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.
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, viola, the data has reached its destination.
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.
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.
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 guaranty. 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"...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.
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.
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 your area, you're generally buying a shorter line. You're only buying half a line because Imbris 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 to Imbris. In fact, with frame relay, you can connect to Imbris from hundreds of miles away for perhaps the same price as a local connection, so your choices 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 the entire circuit as well) that is shorter (so if there are distance sensitive charges it will be less). You also don't have to buy a CSU/DSU for Imbris as well as your own, so your start-up costs should be less as well.
That explains why the monthly line charges are less, but Imbris sells 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. Imbris 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, Imbris 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. Imbris saves money, real estate and has a much cleaner, easy to manage operation with frame relay.
Back to Imbris Frame Relay page