Frame Relay

Overview

Frame relay forwards data elements between source and destination without applying any internal error detection or correction. This is in direct contrast to X.25 networks that expend considerable overhead providing these facilities (Implementing, pg 3). This allows frame relay services to make more efficient use of bandwidth by reducing overhead. This is achieved by reducing the delay associated with each node in the network (Implementing, pg 4). The frame relay standard places responsibility for error recover and flow control on the user. This is necessitated by eliminating OSI level 3 functionality from the standard (Implementing, page 7). The resulting connection resembles a data line from the user's perspective. Another way that frame relay makes more efficient use of bandwidth is through statistical multiplexing. The improved efficiency can be illustrated through a comparison to fixed multiplexing schemes in T1 service. Studies have found that actual circuit use may be as low or lower than 50% (Implementing, page 6). Frame relay can either make this resource available or halve the bandwidth required to support the same data transmission needs (Implementing, page 6).

Services

This is an evolution compared to traditional packet switching communication specified in X.25 standards.

• Aims at reducing network delays, equipment costs and efficient bandwidth utilization.
• Accomodates applications such as wide area interconnection of LANs at 56kps and 1.544 Mbps.
• Service Providers: AT&T, PacBell, BT North America, MCI, Network Services, US Sprint, Wiltel

Cost

1. Access charges
2. DSU/CSU costs
3. Internetworking Customer Premise Equipment (CPE) costs
4. per-Virtual Circuit pricing
5. aggregate Committed Information Rate (CIR) pricing

Frame Relay Technology

A less common type of FR implementation is one that utilizes Switched Virtual Circuits (SVCs).  A SVC provides on-demand connections between two locations within a FR network.  When a SVC is used, the subscriber can connect to any other subscriber site with the SVC capability.  Virtual circuits define paths through the network but do not give those paths space on the wires until information of some sort is passed along them.  Each virtual circuit utilizes Data Link Connection Identifiers (DLCIs) to uniquely identify each network path.

All communication over a FR network is indirect.  One computer talks to a switch, which may then talk to another switch before reaching another computer on the network.  FR technology does not provide error correction.  It relies on higher-level protocols (i.e., TCP/IP) to correct errors, allowing faster network speeds with less overhead and responsibility for the service providers.

FR is less expensive than other types of high-speed data transfer technologies, due to the shared facilities that lead to shared costs.  Because this technology entails sharing resources, FR introduces the possibility that all users may try to use the same resource at the same time.  If this occurs, the physical bandwidth of the FR cloud can become overloaded and result in lost packets.  FR service provider pricing schemes vary greatly and are always negotiable.  The four basic pricing elements are:

• The CIR--The CIR is typically priced relative to its speed.  One would choose a CIR speed that is lower than the access line speed.
• The port charge--The port charge allows access to the FR cloud.  Port charges are also based on speed.  The port speed selected typically matches your access line speed.
• The access line--Access lines are the customer's local loops.  They are the lines from the customer's site to the FR Point-of-Presence (POP).  Access lines are priced relative to their speed and distance to the nearest POP.
• The CPE--The customer must decide whether to purchase CPE or lease it from the service provider.

FR technology continues to evolve, with advances that support the requirements of delay-sensitive traffic such as voice, video, high-speed connections (i.e., DS-3), and Frame Relay/Asychronous Transfer Mode (ATM) inter-workings.  Vendors are now offering Quality-Of-Service architectures, for FR switches for public networks and CPE, which allow carriers to deliver on their service level agreements.  FR users must decide whether to purchase their own Customer Premise Equipment (CPE) or pay to use the service provider's equipment.  CPE, typically composed of a router and a Channel Service Unit/Data Service Unit (CSU/DSU), is the electronics that translate the FR protocols to those of your local network.

Numerous FR services for SVCs are now coming to market.  SVCs are particularly appropriate for supporting seldom or intermittently used applications that need bandwidth-on-demand, including video- conferencing, voice, and bulk file transfer.  With all of the advantages and applications, FR will continue to be an important wide area technology for well into the future.  Worldwide market revenue for FR services approached $4 billion in 1997 and is expected to reach $10 billion in 2000. 

Why frame relay?

Frame Relay (FR) has quietly become known as the most efficient and cost-effective way to link remote sites together on a corporate network. FR has done so without the incredible hype that has surrounded the more high-profile technology known as Asynchronous Transfer Mode (ATM). CTR's report, Evaluating Frame Relay Technology for Your Organization, discusses the background, development, and functioning of FR and explains how FR fits into a corporate networking environment.

The report includes extensive information on new FR features such as international availability and the complicated new issue of tariffing FR services. The report analyzes the use of FR for voice and videoconferencing -- two applications of great interest to corporate information systems (IS) managers. FR network design, implementation, and management issues are reviewed in detail.

The report compares FR with other established and emerging technologies such as the Internet, private TCP/IP router networks, high-speed SONET leased lines, ATM, and SMDS.

FR is considered by many to be the first international standard for data communications. In fact, FR is quickly becoming known as the best way to build international networks of any kind, from SNA to TCP/IP.

Other mature and well-known international standards have had real problems when implemented across national borders, especially from the United States to Europe. The report explains why FR is a corporate network solution that has the potential to offer great cost savings, reliability, and efficiency to organizations worldwide.

How does frame relay work?

FR technology is not new; the report explains how FR developed and explores FR's roots in the X.25 public packet switched data network standard. The chapter traces the changes to local area networks (LANs), SNA networks, bridging, and routing that have made FR an attractive choice for internetworking today.

The report describes how the components of a FR network must work together. Key concepts such as PVCs and SVCs as they apply to users of FR services are detailed. The CIR and over-subscription -- two other major FR concepts -- are also discussed.

The report takes an in-depth look at the use of FR for SNA networks. Special attention is paid to IBM support for FR in the IBM SNA product family. The future of SNA is briefly discussed, and integrating LAN and SNA traffic over a FR network is explored.

The report also evaluates the use of FR as a possible transport vehicle for corporate voice and video applications. Although FR began as a data-only service, the need for businesses to support multimedia on the same network is real and immediate. This chapter explores the use of FR for voice, video, and data services ("broadband" services) and discusses several product offerings for making this possible.

Dealing with frame relay service providers

Evaluating Frame Relay Technology for Your Organization positions FR as a public network service, in contrast to the recent practice of building private corporate networks. The short- and long-term benefits of FR networks are examined.

The report deals with the connection of customer premise equipment to FR networks and evaluates the primary FR service providers. Possible speeds and technologies for linking the service provider's FR network are discussed. The FR switch-to-switch interface is explored, and the Network-to-Network Interface (NNI) is introduced to cover the situation where several FR network services must be linked over long distances.

The report provides a case study of a company which replaces a leased-line private network with a FR public service offering. Project goals are detailed in addition to a step-by-step analysis of the network design, pilot, and CIR choices.

Frame relay network management

Evaluating Frame Relay Technology for Your Organization addresses the crucial role of network management in a FR network. Because FR networks are essentially public data services, organizations accustomed to managing their own leased-line networks must adjust to the public nature of FR. This chapter deals with these issues and the use of the simple network management protocol (SNMP) as the common ground for private and public FR network management.

The report provides a series of checklists which can be used to determine if FR is the correct solution for a corporate network. The lists will help to evaluate carrier FR services and measure the progress of FR network installation.

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, the network via a permanent virtual circuit (PVC) or switched virtual circuit (SVC) sends all the packets with the same LCN. A permanent circuit is like a leased one -- as long as you behave and pay your monthly bill. The circuit is yours to keep and blow bubbles through it. With a 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).

Figure 1: PVC Frame Relay vs. Leased Circuit

The network provider charges for the access at both ends of the PVC or SVC - just like your subscription to your telephone service. The provider 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 those lines rarely gobble bits. 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.

Figure 2: Frame Relay Frame Structure and Header Format

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!

Figure 3: DLCIs, CIR, and Buffers

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.

Figure 4: DLCI Usage

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).

Figure 5: Congestion Notification

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!

Figure 6: What a Frame Relay Node Does

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.

Figure 7: Leaky Bucket Metering

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).

Figure 8: Annex D and LMI

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 overcomes these limitations, making frame relay even more useful as a WAN backbone technology.

Comments? Questions? Problems? Contact Us
Copyright © 1999 Networking Engineering and Transmission Services
1103, 11^th Floor, Park Avenue
PECHS # 6, Shahra-e-Faisal
Karachi.