In 1992, the carriers began to roll out a new service for data; Frame Relay. What is Frame Relay? Frame Relay is a simplified form of X.25. Data packets are routed to their destination based on header information. The major difference between Frame Relay and X.25 is that X.25 guarantees data integrity and network managed flow control. X.25 causes some network delay. Frame Relay switches packets end to end much faster, but there is no guarantee of data integrity. In Frame Relay, network buffering is kept at a minimum resulting in a few byte time delay versus several hundred milliseconds for X.25. One of the issues with Frame Relay is data integrity.
The network delivers frames, whether the CRC check matches or not. If the network is congested, frames can be discarded. It is key that a protocol such as SDLC, TCP/IP or IPX run above Frame Relay to handle error recovery. However, keep in mind that Frame Relay networks today are reliable, and the reality is that very few frames are discarded by the network. This is because most of the public frame relay networks are operating below design capacity. When you subscribe to a frame relay service, a line speed is ordered, 56 Kbps for example, and a Committed Information Rate, CIR. The CIR specifies how much of the bandwidth is guaranteed. In this example, 32 Kbps is the guaranteed bandwidth. 24 Kbps is available for burst rate above the 32 Kbps, if the network has capacity. If the network is congested, two forms of flow control can be used. The first is called Discard Eligible. There is a bit in the Frame Relay header that tells the network switches whether or not that frame can be discarded in the event of congestion. The DE bit is set by the network access equipment. This method is acceptable for TCP/IP traffic, but it is unacceptable for SNA applications. The other method of flow control is more sophisticated.
With this method, if the network becomes congested, a flow control message is sent to the Frame Relay CPE to slow down. The Frame Relay CPE sends back an acknowledgment and throttles back the network traffic until the congestion is alleviated. At that point the data flow resumes at the faster rate. This is known as Forward Explicit Congestion Notification, (FECN), and Backward Explicit Congestion Notification (BECN).
When a circuit is provisioned in a network. A permanent virtual circuit (PVC), is configured between endpoints. The endpoints are identified by Data Link Circuit Identifiers (DLCI's). In essence, the DLCI is the sites frame relay "phone number". Today, all of the circuits being sold are PVC's. Within the next 12-18 months, carriers will begin to make switched virtual circuits (SVC's) available. With the advent of SVC's, users will be able to make data calls in a similar fashion to a voice phone call. Frame Relay is capable of delivering many exciting advances for public data networking that are impossible in a leased line environment.
Frame Relay brought several benefits to the user community: built in redundancy, lower cost for higher performance and flexibility. Customers began to move their router traffic onto this new technology. However, early adopters of Frame Relay discovered that this new network was not a good fit for their SNA data. Response time became erratic and sessions were dropped or would time out. The problem turned out not to be with the Frame Relay network, but with the access equipment used to get the SNA and LAN traffic onto the network.
As users began to mix SNA and LAN traffic together across a single data backbone, severe performance problems began to surface with the SNA traffic. Most users were deploying branch office routers as the access product to combine these two networks. Because the routers were designed to handle large data flows of connectionless traffic, they had a difficult time giving the SNA terminal traffic the appropriate attention to guarantee consistent response times. These early experiences have given Frame Relay a "bum rap" when it comes to handling mission critical SNA traffic.
In the past 12 months a new breed of branch office communications devices have sprung up: Frame Relay Access Devices, FRADs. FRADs are designed with the goal of supporting multiple traffic types across a common frame relay connection. By providing the ability to prioritize bandwidth, SNA users receive adequate response times and the LAN traffic can share the same pipe. While many products exist in the FRAD arena, KMJ chose to represent the Netlink FRAD this year.
After reviewing many different FRAD vendors, what made Netlink stand apart from the crowd? For SNA shops to migrate to Frame Relay, network managers need assurances that the network will be reliable. Also, it is important that the FRAD be compatible with IBM Frame Relay implementation. If at all possible, the unit needs to provide some form of dial back up in the event the connection to the Frame Relay network is lost. With regards to SNA, Netlink performs local acknowledgment. Without local acknowledgment, installations run a high risk of losing SNA sessions because the needed acknowledgments must come from the other side of the network. IBM recently embraced Frame Relay as a sanctioned networking protocol. This standard is RFC 1490. RFC 1490 is a standard method of transporting data across a Frame Relay network. RFC 1490 includes support for the following protocols: SNA/SDLC, TCP/IP, IPX, NETBIOS, as well as an interoperable standard for bridging non-routable protocols, Virtual Bridging.
Dial restoral is imperative in any network supporting mission critical applications. In a Frame Relay network, the ability to dial around a failed Frame Relay local connection requires that the end point equipment recognize the down condition, establish a back up path, and resolve the address and wide area protocol issues.
