A week ago I grabbed one of the numerous techno-nerdic magazines on Nicky Erd's desk and leafed through it. My eyes caught this thing about something called frame relay, started to read and, of course, had a lot of trouble understanding the silly thing. From the title I would have thought this was about a relay contest, like in the Olympics, but where the runners would relay some sort of a frame to each other -- and I asked myself "What on earth would something like that have to do with data communications?"

Nicky looked over my shoulder and smirked. "Why, Norm, are you sick? Reading science?"

"Yeah," I said, "I must be! Sounds like Greek to me, though, which means I didn't completely lose my sanity!"

"Oh, that stuff is so simple," said N. Erd, "even you can understand it -- all you need is someone like me to explain it to you."

So, naive as I am, I ended up spending the rest of the day with N. Erd trying to teach me frame relay. I brought him to the verge of hysteria, but I think I got it. So here it is, folks, all I know about it.

A network based on frame relay is a wide area network (WAN) on steroids. Strong, fast, and without too much brain sophistication. N. Erd says "Frame relay is a switching and statistical multiplexing technology without the error control of the X.25, therefore being much faster. While X.25 is only implemented at speeds below 64 Kbps, frame relay is implemented up to T1 (24 times faster) and some carriers may implement it at T3 rates (672 times faster) - therefore it's sometime called fast packet." I quoted N. Erd because I may not get this right.

Let's see: X.25 is a packet switching technology -- you send data packets through an access line into the network cloud just like you send soap bubbles through a straw. Each packet is labeled with an identifier, called a logical channel number (LCN). This is nothing but a fancy name for an identifier of your session, and all your packets during this session will have the same LCN. Miraculously, all the packets with the same LCN are sent by the network via a permanent virtual circuit (PVC) or switched virtual circuit (SVC). A permanent circuit is like a leased one -- as long as you behave and pay your monthly bill, it's yours to keep and blow bubbles through it. With an SVC, on the other hand, you first have to make a call just like with your telephone, get connected, and then blow away. Only the network knows how one of those is built. At the end of the PVC or SVC, the bubbles are sucked through the end straw (just kidding) -- the packets are delivered through the other access line to the X.25 destination. And, of course, packets can go both ways ("full duplex" as N. Erd says).

The network provider charges for the access at both ends of the PVC or SVC - just like your subscription to your telephone service - and then bills you only for the amount of data packets you send (however, tariffs sometimes are full of surprises) - the cost per packet depending on the distance the packet travels. There is also a minimum charge per call. Charges, therefore, are not time-sensitive.

Every node of the network performs extensive error control and, if necessary, transmissions are retried several times. The end-nodes are also checking each packet thoroughly and sequencing them in the order in which they were transmitted. This is known as end-to-end error control. The end-to-end error control is done at the "packet level", while the node-to-node checking is done at "frame level" as N. Erd says -- making X.25 a tedious and slow but very thorough "bandwidth-on-demand up to a throughput class" technology (i.e., you cannot exceed a certain number of bits per second, but if you stay below that, as long as you don't send anything, you don't pay).

As opposed to this: leasing a circuit end-to-end would mean that you would have to pay monthly whether you send data or not.

The N. Erds of North America thought of an even better scheme: with today's mostly digital lines on our continent, networks don't need all these smarts, because bits are rarely gobbled by those lines. In addition, today's user devices are smart PCs and workstations with software like TCP/IP, perfectly capable of error detection and recovery. So, the standard committees' and forums' doctors prescribed the steroid treatment to be administered to the nodes of the network. They were to become faster, bigger and dumber, but maintaining the essential bandwidth-on-demand characteristics of the X.25.

They called the new technology frame relay. Here's how it works.

There is no more end-to-end packet level error control; only the node-to-node frame level error control is kept. Even here, without any error recovery through retransmission of frames -- frames received with errors are simply discarded.

The frame format is very simple. There are two octets (groups of eight bits each) that contain the address and control of the frame relay frame, then the 'payload' (as N. Erd calls it) containing the data carried by the frame, then an error control group of 32 bits which N. Erd calls the Cyclic Redundancy Check (CRC). And all this is sealed between two identical octets called flags made of 6 ones and 2 zeros.

The stuff that's in the two control bytes and makes Frame Relay tick is named by some engineer that doesn't speak English at all -- only Engineerish.

First, there are these 10 bits that make up a number called data link connection identifier (DCLI). A DLCI is exactly what the LCN (logical channel number) used to be in X.25, but it has to have a new name so us lowly normal people have to pay fat fees to instructors that teach us what a DLCI is. I guess the parent of the DLCI was not the same nerd as the parent of the LCN!

When subscribing to a frame relay service, today one gets a PVC only (although SVC standards were written, no SVC service is provided yet). A PVC is a patched end-to-end connection through the carrier's network that has attributes. One attribute is a DLCI number at each switch port. (DLCI numbers change through the network, from switch to switch, for the same PVC. They have only local significance for each port.) DLCIs are actually buffer numbers for the traveling packets over the PVC. A DLCI is a 10-bit number, and with 10 bits, one can write 1,024 possible combinations (says N. Erd and I believe him). That means each switch port may serve up to 1,024 PVCs. However, some DLCIs are reserved for special purposes.

At each end of the PVC, the customer may place a computer port or a multiplexor, but most likely a LAN bridge/router. The routing addresses (for example, IP) associated with each bridge/router would have to be mapped to the assigned DLCIs at each end of the PVC. For the routing purpose, the PVC becomes a data link and therefore N. Erd says that Frame Relay works at "link layer," or layer 2.

If IP is used, then the question for a sending router becomes "which DLCI at the entry node should I use to send this packet to this IP address at the exit node?" The answer is provided in most cases through a pre-configured static table; however, ARP-ing can also be used if the routers are built to work that way (see Internet's RFCs 1294 and 1490).

The other attribute one buys when subscribing to a frame relay service is a committed information rate (CIR) which is showing how much one can indulge in sending packets. Sometimes N. Erds can be funny. With Frame Relay, they invented a thing called "leaky bucket algorithm." Leaky Bucket kind of reminds me of early childhood. Algorithm is definitely nerdic. You see, when buying a CIR, one is getting a timed buffer (bucket) in each switch port along the PVC. This bucket has two dimensions: a diameter measured in seconds called committed time (abbreviated Tc) and a height called committed burst (Bc) measured in megabytes or kiloframes. The committed information rate CIR = Bc/Tc.

One can only send Bc frames or less during every Tc period.

In each frame header there is a bit called discard eligibility (DE) which, when set to one (1), makes that frame eligible for discard. The frames below CIR (those that fit in the bucket) are not eligible for discard (DE = 0).

The power of Frame Relay consists in a second bucket: its diameter is also Tc. Its height is typically equal to Bc and is known as excess burst (BE).

A customer having bought a CIR can burst for free over Bc by Be frames, every Tc! (Nerd alert ... )

The only caution is that the network will only make a best effort to send the frames in the second bucket -- they will be discarded if congestion is experienced. That information is at risk! After all, there's no such thing as a free lunch. Buying a CIR reserves bandwidth, but it's like leasing a pipe: when not used the money still goes to the carrier. One can today buy CIR = 0, thus putting all frames at risk, but paying only for what one uses.

Now, why is N. Erd's bucket leaky? Is he ill? He says no! He says that every Tc, some little piece of software turns on a faucet and frees the CIR buffer for another round of Bc frames. Then he laughs like after a great joke!

So -- the only things a frame relay node does are:

• Check if the CRC is good, i.e., the DLCI is correct (DLCI is routing information -- and one would not want somebody's frames to end up in the wrong hands!)
• Check if the frames are within the CIR for that PVC -- if not, set DE = 1
• Check if congestion exists (output buffer filled beyond some threshold). If it does, and if this frame has DE set, discard the frame. Otherwise queue the frame in the output buffer to be sent to the next network node.

I asked N. Erd, "Who sets the DE bit?" He answered that if a customer subscribes to a high quality of service (QOS), the customer may set the DE so certain important applications can be protected (the routers would do that).

If normal QOS is subscribed for, then the carrier switch counts frames and sets DE = 1 to any frame above CIR.

What if a node experiences congestion? How is that controlled (beyond throwing out discard eligible frames)? The answer is in one of the following two methods of congestion control: Explicit Congestion Notification (ECN) and Consolidated Link Layer Management (CLLM) Message.

In the frame header, there are two bits named FECN and BECN (reminds me of Heckel and Jeckel): Forward and Backward Explicit Congestion Notification.

A node that decides it's congested on a PVC, sets FECN from 0 to 1 on all frames sent forward in the direction that congestion is seen for that PVC.

If there are frames for that PVC going back toward the source, BECN is set from 0 to 1 by the node that experienced congestion in the opposite direction.

This is supposed to let the router that sends too many packets know that there is congestion and have that router stop transmission until the condition is reversed.

BECN is a direct notification. FECN is an indirect one (through the other router at the opposite end) which somehow is supposed to send a mysterious message to the offending router making that one stop transmission.

The truth is that most routers do not respond to FECN, some do to BECN, but only to the extent that their buffers allow the frames to accumulate. Eventually, if the CIR is not the right size, even the most potent router will overflow and data will be lost (after all, it's not the router that creates frames and congestion, but the stations on the attached LAN). If there are no frames sent over the PVC because congestion brought it to a complete halt, then FECN and BECN don't work at all.

This is why ANSI decided that DLCI 1023 should be reserved for a 'consolidated' message that reports to the router all congested DLCIs over all PVCs. They called this process consolidated link layer management (CLLM).

How do a frame relay network node and a router signal to each other about what's new or what's wrong? They do so via a link management interface protocol with a status inquiry from the router and a status response from the network, or simply with an unsolicited status message from the network.

This protocol is used over the User to Network Interface (UNI) or Network to Network Interface (NNI). The status messages basically say what DLCI have been added or dropped and which ones became congested since the last poll.

The silly buggers from ANSI and the Frame Relay Forum (an association of users, manufacturers and carriers) are at odds as to which DLCI ought to be used for LMI. The forum wanted 1023 but ANSI, who has already recommended CLLM to be run over 1023, said that LMI should be run over DLCI 0 and described their LMI variant under a standard called Annex D to Frame Relay Standards. T1.606 - service description, T1.618 - core aspects and T1.617 - access signaling are ANSI Frame Relay standards, while the corresponding international standards (TSS) are I.233, Q.922 and Q.933.

N. Erd tells me to tell you that frame relay uses zero bit insertion and deletion (ZBID) to avoid flag-like appearances within the data field of the frame, just like in a protocol called HDLC. I think you had enough of this nonsense and will tell you some other time about HDLC.

Access to frame relay services is offered by most significant carriers in USA and Canada over T1 or fractional T1 lines, or over ISDN connections. The near future may see T3 and SONET access as well as switched virtual circuits (SVCs).

A customer may realize very large savings by using frame relay instead of leased line services to interconnect LANs.

LANs are statistical in nature (therefore, almost unpredictable), the bridges and routers transmitting random variable length packets. A technology like frame relay offers bandwidth on demand up to twice the CIR and adds very little overhead (6 octets) to large packets.

What frame relay cannot do very well is voice or video transmission -- because that kind of traffic requires synchronization and fixed short delays from switch to switch. Frames are variable in size and, therefore, packets carrying a voice message over the same links shared by data packets would be suffering variable delays through a node. However, several vendors offer equipment that overcome these limitations, making frame relay even more useful as a WAN backbone technology.

So long,
Norm Al