The four FRADs we evaluated in our latest DATA Comm Lab Test proved to be solid frame relay performers. Each box can respond to network congestion by throttling back throughput to minimize frame loss. In general, the FRADs we tested did a good job of prioritizing traffic so that mission-critical data gets through no matter what network conditions exist. These products also offer several different options for encapsulating SNA traffic into frame relay frames, which gives them the flexibility to handle a range of SNA scenarios.
Given all these positives, at this point FRADs are a clear winner over branch- office routers when it comes to connecting smaller sites to corporate frame relay networks. When we put branch-office routers to the frame relay test last month, we uncovered across-the-board problems with congestion control and prioritization (see Branch-Office Routers: No Match for Frame Relay). This time out, we ran the exact same battery of tests on FRADs and came away with much better results.
The FRAD advantage over branch- office routers goes beyond performance. As part of our evaluation, we created a request for proposal (RFP) and asked the router and FRAD vendors participating in our tests to cost out three different frame relay installations (see "Frame Relay Economics, Part Two"). For a network comprising 500 branch sites, the average cost cited by FRAD vendors.for equip- ment and services was nearly 20 percent lower than the average price quote from router vendors.
FRADs do have a couple of potential weak spots that prospective buyers need to keep in mind. Like frame relay switches, FRADs work primarily at the data link layer, which means they don't necessarily offer routing of network-layer protocols. The good news, however, is that three of the four products we tested can route IP and IPX traffic. Another FRAD caveat is spotty support for the Internet Engineering Task Force's Request for Comment 1490 (RFC 1490), a specification that defines a method for transporting multiprotocol traffic over frame relay. Of the 15 FRAD vendors we invited to participate in this test, only four were able to supply products that comply with RFC 1490 for handling SNA and LAN traffic. The weak support for RFC 1490 surprised us, given the spec's well-deserved reputation for encapsulating all kinds of traffic with a minimum of overhead.
Those concerns aside, all of the four products we tested are worth a closer look (see the table). Two of the four performed well enough to merit Tester's Choice awards. The Omnilinx 4000 from Netlink Inc. (Framingham, Mass.) and the Framenode 400 from Sync Research Inc. (Irvine, Calif.) both posted exceptional showings in our congestion and prioritization tests. The other two products we tested-the IEN 1000 from Hypercom Inc. (Phoenix) and the 6520 MPRouter from Motorola Information Systems Group (Mansfield, Mass.)-offer data compression, a feature not found on the Netlink or Sync boxes.
However, neither the IEN 1000 nor the 6520 MPRouter used RFC 1490 encapsulation to handle SNA traffic in our test configuration; instead, both deployed proprietary encapsulation methods. Both vendors pointed out that they do use RFC 1490 encapsulation when handling synchronous data link control (SDLC) traffic, which is commonly found in SNA environments.
The most obvious criterion for judging frame relay equipment is price-and as we found in our RFP evaluation, FRADs come out ahead of branch-office routers on this count. The other key criteria-and the performance features we tested-are the ability to respond to congestion conditions in the frame relay network and to prioritize traffic to give mission-critical data the best shot at available bandwidth and to keep delay-sensitive SNA sessions up and running.
Congestion control is especially important since frame relay networks offer only minimal safeguards against congestion. With frame relay services, customers pay for a committed information rate (CIR), which designates the theoretical minimum amount of bandwidth available for a given installation. Customers can use bandwidth above the CIR as it's needed-provided the extra bandwidth is available. But if the network becomes congested, frame relay switches may respond by discarding frames.
Carriers guard against frame loss by overprovisioning their networks. However, there's no guarantee that frame relay networks will always have ample capacity. As more users sign on for frame relay services, the chances grow that networks will suffer from some congestion.
Frame relay switches can't force access devices to throttle back on frame transmissions, but they do alert those devices when congestion occurs. These alerts come in the form of forward or backward explicit congestion notification (FECN or BECN) bits set in frames handled by the switch. When traffic gets heavy, frame relay switches mark frames with FECN or BECN bits to notify access devices that the network is getting congested. It's then up to the access gear to react to those indicators.
Three of the four FRADs we tested throttle back traffic to the CIR with FECN or BECN bits set. The one exception, Hypercom's IEN 1000, deals with congestion through a CIR management feature usually found only on frame relay switches. Netlink's Omnilinx 4000 and Sync Research's Framenode 400 offer even more sophisticated controls-they allow net managers to configure not just the CIR but also burst-rate parameters.
Other prioritization schemes, like the one deployed by Sync Research, also allow net managers to define an "urgent" queue, from which traffic is always transmitted first, regardless of the priorities set for other protocols.
Frame relay headers also contain a crude form of prioritization-a discard eligibility (DE) bit. Frames that have their DE bits set are eligible to be dropped if congestion occurs. All the FRADs we tested except Hypercom's allow net managers to flag low-priority traffic as eligible for discard. However, setting DE bits in some frames doesn't ensure that other frames will make it through a congested network. That's because an intermediate switch in the network can set DE bits on all frames above the CIR that pass through it if congestion becomes extreme.
For handling SNA traffic, the major concerns are ensuring session integrity and making the most of available bandwidth. All four FRADs we tested handle SNA with source route bridging (SRB), treating the frame relay cloud as one virtual ring.
But we found some critical differences in the way FRADs deal with SNA. Only two of the products we evaluated- the Netlink Omnilinx 4000 and the Sync Research Framenode 400-perforrn local acknowledgment of SNA LLC (Logical Link Control) keep-alive frames. Without local acknowledgment, installations run a higher risk of losing SNA sessions, because the needed acknowledgments must come from the other side of the wide-area link. What's more, sending acknowledgment frames across the WAN link means throughput is lower, end-to-end latency is higher, and less bandwidth is available for user data.
All the FRADs we tested can encapsulate SNA traffic directly into RFC 1490 frames. However, the Hypercom and Motorola ISG devices do RFC 1490 encapsulation only when front-end processors (FEPS) are attached directly to the frame relay network, and cluster controllers or end-stations use SDLC headers. That's a common configuration for legacy networks, but it rules out the use of RFC 1490 encapsulation when the SNA session partners all reside on token ring LANs-as in our test bed.
For sites where the SNA session partners reside on a IAN, a FRAD must be able to encapsulate frames with an LLC2 header rather than an SDLC header. (In fact, RFC 1490 uses an LLC2 header when transporting frames across the wide area.) The FRADs from Netlink and Sync Research go either way, encapsulating SDLC or LLC2 traffic into RFC 1490 format. For our configuration, the Hypercom and Motorola ISG devices used proprietary frame relay encapsulation techniques- and not RFC 1490-for LLC2 traffic.
We simulated a multiswitch frame relay network by using an external cable to link internal PVCs (permanent virtual circuits) on an STDX 3000 frame relay switch from Cascade Communications Corp. (Westford, Mass.). The external cable created a backbone PVC with a port speed of Tl (1.536 Mbit/s).
In the congestion tests, we used SNA 3270 terminal traffic as the primary data stream-a good indicator of congestion handling because of SNA:s inherent sensitivity to delay. To generate enough traffic to fill a 64-kbit/s pipe in one session, we used one physical unit (PU) running an IND$FILE file transfer over SNA. A baseline measurement of this file transfer on a single ring showed throughput of more than 80 kbit/s-more than enough to fill a 64-kbit/s PVC.
To simulate congestion, we generated background traffic-in this case, IP packets from a frame generator-through a pair of routers connected over separate PVCS. Both the SNA and background traffic had to traverse the Ti backbone link in the Cascade switch. Because both streams traversed the same backbone link, each could conceivably burst into the other's available bandwidth. Notably, though, neither CIR should have been affected. The CIRs for SNA and IP added up to Tl.
Throughput for all products took a nosedive under congested conditions, with no FRAD able to use the full 64 kbit/s available for SNA; the best performer of the lot was Netlink's Omnilinx 4000, which moved traffic at 47 kbit/s.
However, these results aren't as dire as they appear, for two reasons. First, congestion occurred at the Cascade switch, not at the FRADS. The switch congestion caused frames to be delayed, and thus reduced end-to-end throughput. In no case did a FRAD discard data in our tests; indeed, all the FRADs did was pass along traffic at rates already below the CIR.
Second, the FRAD results are significantly better than those we obtained in our branch-office router tests. The average throughput for all routers we tested was 26.64 kbit/s; for FRADS, the average was 32.25 kbit/s.
We left it up to the FRAD vendors to determine how to transport each protocol and how many PVCs to use. Not surprisingly, all vendors used source route bridging for the unroutable SNA traffic, and all except Hypercom provided local acknowledgment of LLC2 polls. Hypercom, Motorola, and Netlink configured their FRADs to route the IP and IPX traffic; Sync Research used SRB for these protocols because its Framenode 400 doesn't offer network-layer routing. All vendors except Motorola ISG used one PVC.
As with the congestion results, the numbers posted by FRADs in the prioritization tests were substantially better than the results we found in our tests of branch office routers (see Figure 2). No FRAD caused an application or session to time out, which was a problem in the router tests. And only one FRAD-Hypercom's IEN 1000-failed to deliver more SNA bandwidth than TCP/IP c;r IPX traffic. The Sync Research and Netlink FRADs actually came within striking distance of our 60/20/20 targets for SNA, IP, and IPX traffic.
Sync Research's Framenode 400 came closest to meeting our prioritization goals across all protocols. Thanks to its extensive user-definable priority queues, the Framenode 400 produced a 43/11/14 mix for SNA, IP, and IPX, respectively. However, Sync's aggregate throughput was only 43 kbit/s for all three protocols- more than 20 kbit/s less than Netlink's FRAD could deliver. After reviewing the test results, Sync said a slightly different configuration would have yielded higher SNA throughput. Time constraints pre- vented us from verifying this.
Netlink's Omnilinx 4000 came closest to hitting the 60 percent target for SNA, allocating 51 percent of the pipe to that protocol. The Omnilinx also did something no other product in this test or the branch-office router could do-it filled the 64-kbit/s pipe with all three protocols. Netlink accomplished this by terminating the LLC2 sessions at each FRAD and increasing the window size across the frame relay network. On the downside, the Omnilinx allocated 41 percent of its bandwidth to TCP/IP, leaving IPX traffic with just 7 percent of the pipe.
Motorola ISG's 6520 MPRouter delivered a mix of roughly 40/20/20 for SNA, IP, and IPX. That's a fair showing, but it took three PVCs rather than one to accomplish these results. Results weren't as close with one PVC, although no sessions were lost. 'Me trade-off for using multiple PVCs is higher service costs, since carriers generally base their frame relay charges on the number of PVCs used. The 6520 does perform data compression, which means lower-speed (and less costly) PVCs could be used; however, we didn't evaluate compression in our tests.
The only FRAD that didn't allocate more bandwidth to SNA was Hypercom's IEN 1000, which ended up delivering much more bandwidth to IP traffic than either SNA or IPX. Hypercom says its prioritization scheme works by the frame, rather than by the byte. That put the IEN 1000 at a disadvantage in our configuration, which used 290-byte SNA frames and 1,500-byte IP frames.