by Arthur Cooper
Frame Relay is a technology that grew from an existing protocol and the need to improve upon it. The need in this case was to provide cheap, reliable network services for Local Area Network (LAN) users who need to pass data back and forth between other LANs that they do business with on a daily basis. This data passing between LANs is where Wide Area Networking (WAN) technology comes into play. In order to understand the background of Frame Relay technology, it's necessary to take a trip down the path of network history and the creation of the X.25 protocol.
The history of data networks begins in the 1960s in the United States. At that time, most computer systems were standalone behemoths that had no reason to interact with other computers. The U.S. government created the Defense Advanced Research Projects Agency (DARPA), which was mandated to fund projects concerning the development of emerging technologies. One idea was to connect dissimilar computer systems to each other to simplify the task of sharing data between those systems. Scientists involved with DARPA began to look at creating a standard protocol to be used between computer systems. In 1969, using four network switches or nodes, the first internetwork (network of networks) became a reality. This network was called the Advanced Research Projects Agency Network (ARPANET), and it was the seed that created today's modern Internet system. Frame Relay grew out of this technology.
The ARPANET was responsible for the creation of a new internetwork protocol. This protocol was called ARPANET 1822, but it soon became known as X.25 (a standard name assigned by the International Telegraph and Telephone Consultative Committee [CCITT]).
X.25 was the original packet-switching scheme that grew from the old ARPANET 1822 protocol. Several factors were present in those days that are no longer a problem today. Those factors were the driving forces that made X.25 look and act the way it did. The first factor is the lack of sophistication of the computers themselves. By today's standards, these systems were anything but sophisticated. IBM's biggest and most popular machine in those days was the old IBM 360 series mainframe.
The 360 was a staple among businesses that could afford computers, and it was a marvel in its day. However, the personal computers (PCs) of today hold more computing power in their small, desktop-sized cases than the old 360 computers did. All of the programs running on these old mainframes were simply used for data manipulation and storage of some type. The computers themselves were not smart enough, or capable enough, to screen the data being fed to them for accuracy.
Computer programmers and operators needed to ensure that error-free data was being put into these computers. The phrase "garbage-in-garbage-out," or GIGO, was formulated at that time. GIGO meant simply that you could not expect a computer to know if the data being fed to it was useful or full of errors. If the data being fed to it was indeed "garbage," the computer would still attempt to process the data as it normally would. The results of the processing would, of course, be of no value, and the computer itself could not be faulted for producing garbage from garbage.
The second factor that drove X.25's development was the quality of telephone lines and connections. The entire Public Switched Telephone Network (PSTN) was composed of mostly copper wire between switch points, and the old Frequency Division Multiplex (FDM) microwave radio systems that carried telephone signals over greater distances were prone to thermal noise and other variations in signal quality due to the equipment itself or the atmosphere these microwave signals traveled through.
These two factors, unsophisticated computer systems and poor quality telephone lines, together make up a formula for failure if X.25 is not capable of rising above them. The scientists on the ARPANET understood these two factors very well, and they decided to ensure that the protocol developed for their network could overcome these two obstacles.
The ARPANET 1822 protocol was the result of their labor, and it did compensate for unsophisticated computers by ensuring error-free delivery of data. X.25 performed error-checking at many levels and stops along the network's path. All of this was built into X.25 at a time when no real protocol layers or standards had been developed.
Now that you know the history of X.25, let's compare X.25 and Frame Relay (FR) technology.
Although X.25 was the father of almost all modern network protocols, it adheres well to the OSI standard in that it uses the first three layers of the reference model. Figure 17.1 shows the X.25 layers.
FIGURE 17.1. X.25 layers of the OSI model.
These three layers are called the physical, data, and network layers. Neat things are happening at each layer, as you will see later on, but the important thing to know is that X.25 uses these three layers at all times, and error checking occurs at each layer.
X.25 actually encompasses three protocols. There is one at each layer of operation, as shown in Figure 17.2.
FIGURE 17.2. X.25 layers and their respective protocols.
At the lowest layer of X.25, the layer at which there is a physical connection between a User-to-Network Interface (UNI) and the X.25 network itself, the actual protocol used that describes how the user and network tie together is called the X.21 or X.21bis protocol. X.21 is popular in Europe, whereas X.21bis is used in the United States. This protocol describes the actual physical data connection between the UNI and the network.
At the data or data link layer, X.25 uses a protocol known as Link Access Procedure Balanced (LAPB). Briefly, this is a software protocol that performs the function of decoding frames or collections of bits of information. These frames are collections of bits of information that the transmitting and receiving UNIs are trying to get passed through the network.
At the highest layer of X.25, the Network or packet layer, X.25 uses a protocol known widely as the Packet Layer Protocol (PLP). This protocol ensures that the frames from the second level are assembled into packets that can then be transmitted from one end of a network to the other.
Now that you have seen what X.25 is all about, what is Frame Relay? Frame Relay is simply the latest variation on the old X.25 scheme. The CCITT originally came up with the idea of using Frame Relay on Integrated Service Digital Network (ISDN) circuits. The ISDN circuits in use today are either a 2B & D arrangement or a 23B & D arrangement. The 2B & D uses 2 B, or bearer, channels that are 64Kbps circuits. The D, or delta, channel is a 16Kbps circuit used for signaling. The 23B & D is the same, except that there are actually 23 64Kbps circuits available.
When the CCITT came up with the original scheme for Frame Relay, they were not too sure how popular it would be, so they originally designed it to be used on the D, or delta, channel of an ISDN circuit. As you can see, 16Kbps is not a lot of bandwidth, so this idea was scrapped rather quickly. If you take a look at Figure 17.3, you will see that Frame Relay uses only the first two layers of the OSI Reference Model.
FIGURE 17.3. Frame Relay layers of the OSI model.
The lowest layer, the physical layer, describes the connection between the UNI and the Frame Relay network. The second layer shows the data, or data link layer, and this layer is used by Frame Relay for a few needed items to be discussed later. The interesting thing to note, however, is that Frame Relay has no need for the third layer as X.25 did. Frame Relay eliminates this layer completely.
Frame Relay technology makes a few assumptions about the environment it is operating within. First, it assumes that the computer systems being connected together by Frame Relay networks are by their nature intelligent devices. Second, it assumes that the telephone circuits carrying the data within a Frame Relay network are of above average, if not near-perfect, quality.
Examine these assumptions individually. As you know, today's modern computer systems do not in any way resemble the old mainframe systems in use during X.25's heyday. In fact, on most LANs today, the systems in use are powerful, sophisticated PCs with sophisticated operating systems and hardware. Why did X.25 have to assume computers were not too smart? If it did not, and it allowed error-ridden data to enter the computer after it had passed through the network, the computers in those days would simply have accepted and processed the data as if nothing was wrong.
Today's computer systems and LAN servers are smart enough to recognize garbage when it is being fed to them. If data being sent to a computer is incorrect, it is usually the function of the higher level peer processes in the programs themselves to recognize the bad data and request new data from the device, person, or computer providing the data. Frame Relay technology is counting on this ability to ferret out and ignore bad data.
The second assumption made by Frame Relay is also a valid and arguable one. Telephone circuits and networks have become extremely sophisticated and reliable in the past five to ten years. With the advent of modern fiber connections and extremely fast and reliable switching technology, line problems are really a thing of the past when dealing with data circuits and connections through the public telephone network.
Here's a quick comparison of X.25 and Frame Relay at each layer. Figure 17.4 provides a side-by-side look at the two technologies and their associated layers.
FIGURE 17.4. Comparison of X.25 and Frame Relay layers.
X.25 uses the physical layer through the implementation of the X.21 protocol discussed earlier. Frame Relay uses the physical layer in many different ways. In most cases, it will be a UNI such as a bridge or a router.
X.25 uses the data, or data link, layer with a protocol known as LAPB. This is a software-driven protocol that adds a lot of overhead to the data transmission taking place in the network. Frame Relay uses only a group of two octets (8 bits) at this level. This adds very little overhead to the transmission taking place.
Now look at the third level used by X.25. At the network, or packet, level, X.25 uses a device known as an X.25 Packet Assembler/Disassembler (PAD) to put all of the data into packet form. These packets, or bundles, of data contain all of the information to be transmitted through the network, but there are also overhead bits of information added by X.25 at this layer. These overhead bits include a section of bits known as the logical channel number (LCN). This number is then used by the distant end node of the X.25 network in order to identify what packets go where when receiving a sequence of packets.
It should be obvious to you now that Frame Relay is not even using this third layer at all. With that in mind, the following section discusses why Frame Relay is the logical choice for network managers to use when getting data from one place to another over wide distances.
Before moving into a discussion of the actual workings of Frame Relay technology, consider why Frame Relay is really a smart move to make when designing a WAN/LAN interface. In this author's opinion, the two major factors to consider when making any sort of networking choice are speed and cost. With that in mind and referring once again to Figure 17.4, take a look at the speed issue of X.25 technology. As you know, there is a lot of error checking and addition of redundant bits going on at the three levels of X.25 technology.
At the physical layer, the X.21 protocol does some Cyclic Redundancy Checking (CRC) of the data being passed back and forth, and this process takes time. At the data, or data link, level, X.25 uses LAPB in order to compile the data into frames. LAPB adds an enormous amount of overhead bits of information needed for general frame housekeeping as well as error detection. Even the addition of 2 bits/frame over the course of a large data transmission will slow down the transmission tremendously.
As the data approaches the network, or packet, layer, X.25 stuffs in a multitude of information as it performs the compilation of frames into what are known as packets. Bits are added to ensure that adequate error detection is performed at the packet level; bits are added to number, or sequence, the packets of a single transmission; and bits are even used to signal the fact that a packet was received in error. Again, all of these additional bits will slow the transmission down a lot.
How does speed relate to Frame Relay? At the physical layer, Frame Relay technology is usually a bridge or router connected to the user's LAN. There are many different physical protocols in use at this level, and Frame Relay technology does not specify a particular one to be used. Therefore, the fastest method of coupling a LAN with a bridge/router that serves as the Frame Relay network interface should, and could, be used.
At the data, or data link, layer, Frame Relay uses only a 2-octet field to pass its information from one end of the network to the other. What these two octets include is discussed later in this chapter, but for the purpose of this discussion, please note the small amount of information Frame Relay includes in the frames it assembles. Don't forget that Frame Relay does not even use the third layer.
Figure 17.5 compares the frames of X.25 and Frame Relay at Level 2, the data layer, of the OSI Reference Model.
FIGURE 17.5. X.25 and Frame Relay frame comparison at Level 2 of the OSI Reference Model.
Notice the larger amount of information X.25 must place in all of its frames. Now, remember that Frame Relay has finished its job at this point as far as organizing and compiling frames is concerned. X.25 will be adding more bits and overhead information at Level 3, the network layer, of the OSI reference model. You can see why Frame Relay is really a speedier alternative to X.25.
The second determining factor for a network choice is cost. When Frame Relay became popular in the early 1990s, there were many companies who wanted to lead the pack and grab all of the Frame Relay customers they could.
One of the recognized leaders of the pack was a company called Williams Telecommunications (WILTEL) of Oklahoma. WILTEL prided itself on being one of the largest resellers of telephone and data bandwidth to America, but it actually was, and remains pretty much so today, a collection of leased fiber connections from coast to coast. WILTEL did not own a large portion of its network in the early 1990s, but they were still able to provide excellent coverage throughout the United States. They were able to do this by leasing Right of Ways from the various railroad corporations traversing the United States. For that reason, they decided to come up with a Frame Relay network and pricing package known as WILPAK.
The only problem with this was that Frame Relay was in its infancy, and none of the major network companies including AT&T, MCI, as well as Sprint and others were too sure how it should be priced and sold. Today, most companies are clear on where the tariffs of pricing Frame Relay are concerned. In other words, most companies feel they can charge based on the committed information rate. In earlier days, many companies were not sure how to "explain and package" their pricing in terms the layman could understand. However, there are still some pretty difficult-to-understand and/or strange Frame Relay pricing schemes.
The moral of this story is that Frame Relay is a pay-as-you-use technology. X.25 was used primarily over expensive leased lines. Also, there was no system in place to look at the actual bandwidth being used, so X.25 lines were almost always never used to full capacity. Even when the ARPANET switched to a per/packet billing scheme for its major users, it was not very cost-effective. Frame Relay connections can be had quite cheaply today.
That's really it in a nutshell. X.25 is slower and in some, if not all, cases more expensive than Frame Relay. With that in mind, it makes more sense to go with a Frame Relay network connection between LANs if at all possible.
Frame Relay also has its problems. The next section of this chapter discusses the actual workings of Frame Relay step by step, including frame relay's limitations.
Frame Relay is not difficult to understand, and for the purposes of this chapter, we shall make every attempt to use layman's terms and concepts. Frame Relay is a wide area network (WAN) technology. It also happens to be a rather fast operating technology. X.25 is almost always used at speeds below 64Kbps, but Frame Relay is being used today at T-1 and even T-3 speeds.
NOTE: T-1 uses a 1.544Mbps data rate, and T-3 uses rates up to approximately 45Mbps.
With speeds such as this, it is easy to see why Frame Relay is sometimes referred to as Fast Packet technology.
Remember that X.25 was a packet technology that used logical channel numbers to get packets to the right addressee. X.25 did so by using Switched Virtual Circuits (SVC) and Permanent Virtual Circuits (PVC). X.25 was, and is, a full-duplex operation. This means that data is going back and forth in each direction on the network. The way X.25 got these packets delivered properly was through the use of end-to-end error and packet control. This was accomplished by the third layer used by X.25.
This layer, the network layer, ensured that if a message contained 500 packets, each packet was numbered 1-500 in sequence. At the receiving end of the transmission, the X.25 node on the network would be charged with the task of reassembling the packets in the correct order. If any of the packets did not arrive in sequence, the X.25 node would have to wait for the proper packet to arrive in order to pass the entire message on to the network computer requesting the transmission.
However, if any of the packets arrived with errors, the X.25 node would have to request a retransmission of errored packets from the node that originated the data transmission in the first place. This sounds good, but remember, this discussion covers factors that will eat up time during a data transmission. If the X.25 nodes are involved with error checking and retransmission requests as well as packet reassembly, then the transmission will be slowed down tremendously.
Frame Relay does none of this. First of all, Frame Relay does not use LCNs in order to assign packets to a destination address. Frame Relay uses a Data Link Connection Identifier (DLCI), which is covered later. The other nice thing about Frame Relay is that it also does no end-to-end error and packet control at the third layer. All it does do is some error checking at the frame, or second, level of the OSI Reference Model. At the data layer, Frame Relay does some simple error checking, and if a frame is full of errors, it does not ask for the frame to be retransmitted by the distant end. Rather, it simply discards the frame as no good, and goes on about its business of receiving and transmitting frames.
You may be wondering how frames can simply be tossed away after being determined to be laden with an error or errors. The answer relates to the sophistication levels of today's modern computers. Computers today can recognize and identify the fact that a frame was missing from the transmission. At that point, the request will be passed back through the Frame Relay network to the originator requesting the frame be sent again.
Frame Relay is also full-duplex, and there is indeed two-way transmission of frames from each end to the other. However, when the request is transmitted back to the originator to retransmit the frame that was apparently discarded by the Frame Relay network due to errors, it will look like any other frame to the Frame Relay network. In other words, the Frame Relay network does not get involved with the content of the frames being transmitted over it as deeply as X.25 did.
Frame Relay networks simply monitor the error checking information at the second level, and if there are errors, the network discards the errored frame or frames. This is not a big problem today, as the networks in use that carry Frame Relay transmissions are extremely stable and reliable. In all actuality, very few frames are discarded due to errors in today's modern Frame Relay networks. A much larger portion of frames are discarded due to traffic demands.
The frame format used by Frame Relay at Level 2 of the OSI model is shown in Figure 17.6.
FIGURE 17.6. Frame Relay frame structure at OSI Level 2.
It's quite simple and makes a lot of sense. There are two octets used by Frame Relay at this point. These octets contain the information needed by the Frame Relay network to know where the frames are to be sent along the Frame Relay network structure. There is also some controlling information present. The first ten bits of these octets make up the DLCI.
The DLCI refers to the actual number assigned on the Frame Relay network to the user's port or system. When buying Frame Relay service from a vendor today, the circuit the vendor provides will determine what numbers are used as DLCIs at your location. If you are using the ten bits just mentioned, there is a possibility of 1,024 address combinations.
NOTE: The 1,024 combinations are created by forming a binary number between 0 and 1023 by using the 10 DLCI bits. 1111111111 would be 1023, and 0000000000 would equal zero. 0000000001 would equal one, 0000000010 would equal two, and so on.
Most of the vendors providing Frame Relay services today will use numbers between 16 and 1007 for DLCI address numbers.
Assume that you have a router connected to a Frame Relay circuit provided by a vendor. On this router, there are four ports in use. The vendor may decide that port one will be assigned a DLCI of 16, port two will be assigned a DLCI of 17, and so on for the remaining two ports. In this example, there would be four DLCIs assigned to your Frame Relay termination point.
At the other end of the Frame Relay network, there is obviously a system that will be communicating with your end through the network. Assume that it is another router with eight ports in use. The vendor may decide to reuse the DLCIs of 16, 17, 18, and 19 for the first four ports of this termination. Therefore, the last ports could be called 20, 21, 22, and 23. This would complete the eight port addresses.
How can the numbers 16 through 19 be reused? At the first termination point, the router would not be involved in sending frames to itself, so anything numbered as 16 coming in from its local ports would be sent to the first port at the other end of the Frame Relay connection.
This example may seem simple, but it explains the point that while the numbers 16 through 1007 are available on most DLCI configurations, the numbers may be used over again at each user location. The DLCI number 0 is reserved for call signaling by the Frame Relay network. Also, 1-15 and 1008-1022 are reserved at present and are not being used in most Frame Relay arrangements. DLCI address 1023 will be discussed later in this chapter.
The next logical question concerns itself with how a user of Frame Relay services is able to get data destined for a distant user or LAN to the right place. Within the routers and bridges themselves, there are static routing tables. In Frame Relay, most of today's users are connecting LANs together through Frame Relay technology. These LANs are almost always using a TCP/IP address scheme of sorts. Without going into a broad discussion of how IP addresses are created, let it suffice to say that each LAN will have a unique IP address.
It is the information concerning the IP address and their respective DLCI numbers that is entered into the static routing tables of routers and bridges that are in turn connected to Frame Relay networks. So, going back to the last example, if the LAN on DLCI port 16 at this end has an IP address of 207.102.88.1, the tables in the distant end's router or bridge will know that anything coming in addressed to 207.102.88.1 should be sent to DLCI 16 at this end.
Now, with that discussion behind you, take a look at the concept of Committed Information Rate (CIR) and how it relates to Frame Relay.
The committed information rate, CIR, is the concept driving Frame Relay services and their pricing. When you purchase connectivity between your LANs from a Frame Relay vendor, they are going to help you establish a CIR rate to work with. This rate actually refers to the amount of frames you can blast down the Frame Relay pipe at any given time.
Figure 17.7 shows two pails of water. Believe it or not, Frame Relay technology uses an algorithm referred to as the leaky bucket algorithm. What this algorithm states is simple. When you purchase Frame Relay bandwidth at a certain CIR rate, you are assigned a timed buffer in each switch of the network along your frame relay's circuit path. Consider these buffers to be buckets of water, and the width of the buckets can be called the time or T1 The height of the buckets can be called committed burst or B1. By using these two symbols, you can see that the CIR rate would be equal to: CIR = B1 / T1.
Here's what this equation is saying. If the burst of data you are transmitting is small enough to be divided equally by the time of the buckets, or buffers, within each switch along the Frame Relay network, the data will be transmitted with no discarding of frames. In simpler terms, if you have been given a CIR rate of 64Kbps, and you transmit a burst of 56Kbps, this will divide by the time (T1) which is actually a 1, and it will equal, of course, 56Kbps. Because this is smaller than the CIR rate you have been given, this burst of data should move through all of the switches in the Frame Relay network without any frames being discarded.
FIGURE 17.7. Frame relay's bucket algorithm.
Why is this math even needed? When you buy a Frame Relay circuit with a CIR rate of 64 or 128Kbps, you are gambling that your data may actually hover close to that figure at all times. Further, you are gambling that your data will want more bandwidth than that on several occasions. Now let's take the math a step further and explain the so-called leaky bucket.
Whenever a customer's CIR rate has been surpassed at any switch within the Frame Relay network, there is a bit called the Discard Eligibility (DE) bit (refer to Figure 17.6) that will be set to a 1 in all of the frames above the CIR. As these frames move through the network, they may get discarded if traffic is heavy and the switch is in a position to meet the CIR rate only. The neat thing about Frame Relay is the so-called second, or leaky, bucket. This is used whenever a customer's frames have exceeded the CIR rate, and the DE bit has been set to 1.
This second bucket, the leaky bucket, is what makes Frame Relay so attractive. I will also refer to its width as T1. However, I will refer to its height as B2 for Bursts exceeding the CIR rate. This second bucket, or buffer, within the switches on a Frame Relay network will almost always be equal to the size of the first bucket. In other words, a CIR rate of 128Kbps would perhaps be able to accept bursts up to 256Kbps by filling the second bucket with data during T1, but once again, if the demands of the network are great, the second bucket, the leaky one, may have no height at all. If this is the case, then all frames above the CIR of 128Kbps will have the DE bit set to 1 and will most likely get discarded by the switch setting the DE bit to 1 or the next switch along the network path.
Believe it or not, you can actually buy Frame Relay circuits today with a CIR rate of zero, but this will, of course, put all of the data you are putting on the network at risk. LANs are bursty by nature, and it behooves today's LAN administrators and network managers to attempt to determine the highest rates their LANs may need during the busy traffic periods of the average day. When using Frame Relay services, it makes sense to try a higher rate first and then lower the CIR rate after a trial period. If the lower CIR works, it may need to come lower still, but lowering the CIR can also be risky.
If a vendor's network has very little traffic on it when you first purchased your service, you may actually be exceeding your CIR on a regular basis without even realizing it. If this is the case, and you lower the CIR you require at the same time the network incurs more traffic, you may well create a monster. This monster will be the continual discarding of frames by the network. Each end of your Frame Relay connection will be in crisis as it attempts to request the discarded frames, and you could actually go dead in the water if it continues.
For this reason and many others, it's important to work closely with your Frame Relay vendor to ensure that the CIR rate you are paying for is cheap for you and profitable for your vendor. It's this marriage of cheap service combined with profitability for vendors that has made Frame Relay so attractive.
Another area of Frame Relay that warrants explanation concerns the idea of node or traffic congestion. You have already learned how Frame Relay beats X.25 in terms of cost and speed, but there is one killer of Frame Relay services. That killer is congestion within the network itself. Frame Relay uses two methods of controlling and, hopefully, eliminating congestion.
The first method is called Explicit Congestion Notification (ECN). This method is used by the switches or nodes in a Frame Relay network to notify the User-to-Network Interfaces of congestion. Most UNIs are routers or bridges, so this notification is seen by the user's router or bridge. Refer to Figure 17.6, and you will notice there are two fields called FECN and BECN. These are called Forward Explicit Congestion Notification (FECN) and Backward Explicit Congestion Notification (BECN). Each of these fields is one bit in length, and the way they are used is as follows.
If a node along the path in the Frame Relay network realizes there is some congestion being experienced for frames being transmitted to a specific DLCI, the node will set the FECN bit to a 1 for all frames heading to that DLCI address. It is hoped that the UNI connected to the DLCI at the other end will see these FECN bits set to 1 and will attempt to communicate with the UNI at the originating DLCI and slow things down a bit.
At the same time, if any frames are seen going back toward the originator of the frames bound for the congested DLCI, the BECN bit will be set to a 1 on those frames. By doing so, the node is trying to tell the originator of frames bound for the congested DLCI that there is indeed congestion on the network. If a user's UNI sees the BECN bit set high to a 1, the UNI will know there is congestion going to the other end's DLCI, and hopefully the UNI will slow transmission to this congested site a bit.
There are a few things that will make ECN useless. If the routers or bridges that comprise the user's UNI do not even recognize or process the FECN and BECN bits, then there is no use in using this method. Likewise, if a user has completely surpassed the CIR rate for the Frame Relay connection in question, it is possible that traffic will simply halt and go dead in the water. If this occurs, naturally the ECN bits, both forward and backward, would be of no value.
For those reasons as well as others, another congestion control method is being used in some Frame Relay networks today. It is called Consolidated Link Layer Management (CLLM). This is used between the routers and nodes that comprise Frame Relay networks. It generally uses the DLCI address of 1023. The routers and nodes communicate via an established protocol called Link Management Interface (LMI) protocol.
There has been a lot of discussion lately as to where LMI should be sent and used, but most Frame Relay networks are using DLCI address 1023 to pass this information between nodes and UNIs. Some newer networks are using DLCI 0, but it really does not matter which address is used as long as the LMI data gets where it needs to be.
LMI will provide status messages to the UNI and node points along a Frame Relay network. These messages will contain information about what DLCIs are currently in use on the network, which ones are congested at present, and in which direction(s) the congestion is being experienced. No doubt future systems will put LMI to greater use than it is currently being used.
Frame Relay will no doubt be around for the next several years. For most users of X.25 network services, it is a simple task to upgrade to a Frame Relay network arrangement. A simple change of software in a user's router or bridge can make the transition from an X.25 to a Frame Relay-based service seem invisible to the users of the connected LANs. If these software changes are implemented simultaneously with a change of vendor to one who can provide Frame Relay services, the cost savings can be extremely large.
Frame Relay will provide users of network services a cheap, speedy, and reliable alternative to X.25 and other older network technologies. Some people have called Frame Relay simply a stop-gap on the way to Asynchronous Transfer Mode (ATM) technology. Although that statement may hold some truth, Frame Relay is proving itself to be anything but a stop-gap. As pricing becomes more uniform between different vendors, there will be less confusion about the CIR rate and how to determine monthly costs associated with Frame Relay. In fact, for most designers of enterprise TCP/IP networks, Frame Relay is the WAN technology of choice today.
© Copyright, Macmillan Computer Publishing. All rights reserved.