COVER STORY

ISDN: PRIme For The Enterprise

by David Willis and Jeff Newman

If you need flexible, affordable remote access, you need ISDN. In fact, you may need a lot of it. But once it moves beyond a few point-to-point connections, should you consolidate service to a few high-capacity Primary Rate Interface (PRI) circuits to allow further growth? We brought ISDN PRI access routers into our labs to determine which units are up to the task.

We examined a range of products, each with a slightly different focus: general-p urpose routers that support PRI interfaces (ACC); ISDN routers for IP/IPX LAN internetworking (Shiva); bridges with IP routing capability (Gandalf); simple ISDN appliances for connecting LANs (Symplex); and high-capacity ISDN access switches supporting a broad range of connectivity options (Ascend). Common to all of these units is LAN-to-LAN internetworking capabilities, so we put that functionality to the test.

Cisco Systems could not provide an AS5200 in time for our testing, and it could not supply a currently shipping PRI router with a good feature match.

Ascend outclassed the pack in many respects. The MAX 4000 offers a broad range of interface types, excellent link compression, and overall it has great features and manageability. It's a bi t expensive for many applications and turned in only moderate performance with small IPX reads. We were also surprised and impressed by the Symplex DirectRoute DR-1/PRI unit. Best used in smaller environments where simple administration is a mus t, the DR-1 turned in unexpectedly high throughput numbers in our lab tests. The Shiva Integrator 500 turned in a respectable showing for its good link management.

Gandalf's XpressStack PRI bridge/router needs better IPX handling before we can recommend it, and ACC Amazon's text string interface makes the administrator work way too hard.

ISDN in Prime Time Why do you want to use ISDN anyway? It's widely available and it is the only option for rapidly switching circuits between destinations. Using common aggregation techniques such as Multilink PPP, you can establish a channel of 128 Kbps or more in a few seconds. ISDN also moves some of the intelligence of the public switched network into the user network. Information such as call type, calling number and so on comes over the D channel. Devices can then make intelligent routing decisions, delivering the call to the most appropriate service and location or giving call priority.

ISDN is available in just about any area, although you may have to ask for it in some locations (see availability chart, page 54). If your central office (CO) doesn't offer it, the telco can bring it over from another office that has the facility. In some areas, unlimited BRI service will cost as little as $100 per month. In others, usage fees might blow your budget: If you pay four cents a minute per B channel, a single weekend could cost you $307. Ouch.

To avoid high usage fees, smart routers like those we tested here will let you establish limits on connection time, with utilization thresholds for bringing additional B channels up and down. They'll also let you set filters on the packets that propagate across the links. When managing circuits, especially when you're charged for usage, you must avoid unnec essary connect time. You have to give special consideration to NetWare environments, where you see a barrage of administrative information propagated. We've covered the impact of SAPs, IPX watchdogs and SPX keep-alive messages before. How a router handles these things can have a major impact on the bottom line.

These Go to 11 A single ISDN PRI circuit will support 23 B channels-or 11 simultaneous BRI-connected sites-with one B channel to spare. How you manage the access into this (relatively) small pool of channels is the trick. Calls may get blocked because others are using the service. Good routers will use spoofing to trick devices into thinking a session is active, but that only goes so far. Channels need to be kept free for actual data traffic, or sessions will get lost.

A common trick used to manage access is to break the PRI trunk line into two hunt groups, or channel clusters. The first (larger) hunt group supplies one B channel; this allows a larger number of users to get a single B call. The second hunt group delivers the second B channel if one is available. In this way, more users get a minimal level of access and aren't starved out by a few hungry users with 2B connections. Alas, this approach w ill not work if your CO uses a Northern Telecom DMS switch, which will only return a busy signal when the entire trunk is full, not when just the hunt group is busy. A software update this year should add this capability, however.

Fortunately, provisioning PRI circuits and setting up equipment on the interface is quite easy. If you're familiar with T1, you know most of it already. For the connection, you'll specify a line encoding mechanism, most often B8ZS; a frame type, frequently Extended Super Frame (ESF); next, you'll identify the synchronous clock source (in our case, sourced at carrier's network); a SPID; and a directory number-and you're in business.

When considering PRI service, compare it to other alternatives. ISDN doesn't use concentrated channels very eff iciently. Circuit switching frequently wastes bandwidth and reduces your remote fan-out capacity (your ability to handle large numbers of remote users concurrently). In large networks, it can be impractical to install enoug h physical circuits to avoid blocked calls. In these environments, packet switching via IP or frame relay will make better use of available circuits, but often at the expense of end-to-end latency.

Packet networks are also frequently billed on a flat rate, making budgeting easier and lessening the economic impact of an improperly tuned network. With ISDN, in addition to local usage fees, your long-haul carrier may charge a premium, typically 5 percent to 15 percent extra for data calls, as compared to analog POTS long distance fees.

Ascend MAX 4000

We weren't too surprised that Ascend has delivered a superior product in the MAX 4000, given its lock on the tough Internet Service Provider (ISP) market, and the fact that its lower-end products have done well in previous tests. Ascend understands ISDN and bandwidth management and supports industry standards.

But th is is a powerhouse of an ISDN access router! And it is an excellent choice for supporting a large number of circuit-switched users, whether they're doing ISDN/analog dial-up or LAN interconnection. It can be used as a terminal server, a bridge or a router. It supports the most important security and accounting mechanisms. When it comes to features and capacity, the MAX screams.

Unfortunately, your CFO may scream back: The unit costs two to four times as much as others-but we would expect that, given its capacity. In smaller environments, the Pipeline 400 T1/E1 is a more affordable option with similar capabilities.

As a general access switch, the MAX 4000 can direct calls coming over the PRI to its internal V.34 analog modems (available as an option) or to digital service for remote ISDN users. Using I SDN signaling techniques, the call's destination is automatically determined and routed to the appropriate service.

Setting up the unit is fairly straightforward. Consoles can ei ther be Telnet sessions, direct serial port connections or a special palmtop unit that's available at additional cost. Like other Ascend routers, the MAX uses a text-based nested menu system for navigating. Available options change as you select modes. For example, if bridging is not turned on, special IPX handling options that only apply to bridging are not available. Details like this help avoid configuration mistakes.

It was easy to monitor channel use, line utilization and other service parameters. The console screen is continually updated when active. The unit offers a number of WAN service diagnostics, including automatic bit error rate testing. ISDN Cause codes are revealed to help debug connection problems. Its major limitation is that of display real estate: There's only so much data a text-based monochrome console can provide.

Like all of the units, a connection profile is created for each remote site. Here, you configure various parameters specific to a site: the directory num ber, link layer options, routing/bridging options, utilization thresholds, and so on.

The MAX is clearly designed to support IP as the primary protocol, and it provides merely adequate IPX support. You have to enter server SAP and network RIP filters by hand, and they're not automatically discovered and presented like they are with Gandalf's XpressStack. Only a single frame type can be routed via IPX. Small IPX reads-like those issued by many e-mail programs-produced lackluster performance over the Ascend link. We used an Ascend Pipeline 50 as the remote BRI router and found the combination delivered superior compression and good performance in the IP and large IPX file transfer tests.

Shiva Integrator 500

The Shiva In tegrator 500 is a relatively new offering from Shiva, but it's not a new product. It was formerly part of Spider System's SpiderIntegrator line, which Shiv a acquired last year. The 500 offers a strong feature set, particularly in the areas of NetWare-aware management and minimizing network usage costs.

Architecturally, it's a solid unit-built on the Intel i960, with 8-MB RAM. However, the unit we tested stored setup information on a standard floppy diskette. That's handy for backing up the configuration, but makes it prone to failures in environmentally hostile areas. According to Shiva, the unit will soon be using Flash RAM for this storage.

The 500 turned in some of the fastest connect times, ranging from 1.5 seconds to 3.5 seconds, including CHAP authentication. In other performance tests, however, Shiva trailed the pack. Compression ratios hovered around 3.4:1 for highly compressible files, versus Ascend's 6.4:1 (Stac) or Symplex's 5.1:1 (Symplex proprietary).

Shiva has put a lot of attention in minimizing connect time by focusing on the full complement of NetWare optimization techniques: It spoofs IPX watchdog, SPX probes a nd NetWare serialization packets, and features triggered RIP and SAP, which allows only RIP and SAP information to pass across the link when it has something new to say.

Furthermore, Shiva's Tariff Management feature makes use of the actual cost of the circuit to determine routing methods. For example, suppose ISDN usage is not metered at night but is expensive during the day. A flat-rate leased line might provide access during the day for LAN routing, then be shifted over for host file transfers at night. Meanwhile, evening LAN traffic is routed over the ISDN link.

Initial setup is fairly straightforward. The install command walks you through the basic configuration details: defining circuits, associating protocols to those circuits and determining a route and service advertisement strategy. The documentation clearly presents the tradeoffs in u sing RIP/SAP, triggered RIP/SAP or single or multiple static routes. WAN diagnostics are available, including basic loopback tests, but the unit does not offer the breadth of tests and reports available on the Ascend routers.

The Integrator 500 supports only the most common line encoding and framing formats-B8ZS and ESF-which are what the majority of PRI lines will use. Still, it may be possible to find PRI built on older T1 facilities that do not support these formats.

Router management is hampered by a text-string-based interface. Shiva has done a better job than ACC by keeping the context of the command current-in a way, nesting menus on the command line by remembering your last command-but it is still cumbersome to use. Only basic syntax-level help is available.

The unit also falls down in its support for Multilink PPP. It can combine channels between like devices, but only using its own algorithm. It can support PPP links from remote ISDN LAN cards, but you can't get a 2B connection when using someone else's equipment. For our testing, we used a Shiva Integrator 100, a single BRI router, on the remote side.

Once Shiva addresses the MP and interface issues-and it promises to soon-this will be a good solution for LAN-to-LAN internetworking in IPX and IP environments.

Symplex DirectRoute DR-1/PRI

ISDN routers are expensive, require extensive knowledge to set up and need constant monitoring and attention. There's no way you're going to install a router remotely unless you've got a bright and patient person onsite to help you.

Wrong. The Symplex DirectRoute family of ISDN routers are inexpensive, and Homer Simpson could install them. Faster than you can say "Doh!" you're routing packets between destinations, and getting respectable performance too. We had done little more than plugged in the DR-1/PRI and its companion BRI unit and were getting ready to start debugging when we said, "Hey, there are our servers! And our Pings are working too!" (Network Com puting lab rats get excited about the simplest things).

And simple it isperhaps too simple for some. It doesn't provide much access to the nitty-gritty of protocol configuration, and, for example, does not allow a forced shutdown of a given call from the console. PPP is available as an interoperability option, but most link management features are only available between Symplex units. There is not a great deal of diagnostic information available if you get into trouble, except for one handy bit of data: the initial call packet. The router stores the packet that caused the current connection to go up, and with a little analysis you can decode what caused it-say, a poorly filtered SAP broadcast. We didn't find this feature in any other ISDN router.

The DirectRoute uses a simple text-based menu structure that's easy to understand. Call status and network statistics are dynamically updated. Loopback tests are graphically displayed using simple ASCII characters, making a fairly sophisticated concept easy to grasp.

The Symplex software focuses heavily on containing communications costs and allows for line usage caps to be set by call, day or month. Via action tables, you can block calls at certain times of the day, or require calls to originate from a certain source. It's not as sophisticated as Shiva Integrator 500, where a bandwidth source can shift based on link cost, but it puts the network manager firmly in control of communications expenses.

In small internetworks, the unit is nearly automatic in its discovery of available services. The idea is to simply point the router to a given destination, where the units exchange service information and build a simple routing table from it. After the basic table is built, future service exchanges are similar to triggered RIP and SAP, as offered on the Shiva Integrator 500, but you cannot fine tune them as well as you can with the Sh iva unit.

For larger networks, however, you'll still need to set up static route tables- a process Symplex could make easier. Autodiscovery will find its maximum of servers and networks: 500 and 245, respectively. There's no way to purge the tables and rediscover networks (except by rebooting), nor is it possible to take a currently discovered network and service and make a static route out of it.

Our lab networks quickly filled all the available tables, so we had to make static entries by hand, and the DirectRoute didn't make it easy. We had to manually look up NetWare server internal network numbers and MAC addresses, and then enter them as remote networks and routers, respectively, which may not be obvious to many.

Putting the Symplex devices up against the Ascend MAX 4000 is a bit like matching, say, Mike Tyson against the Terminator. The Ascend definitely has more firepower, but the Symplex DirectRoute family held its own, even in performance tests. While call setup times are considerably slower than other routers, it turned in excellent scores, making the Symplex Direc tRoute DR-1/PRI a great value. In our tests, we used a Symplex DirectRoute RO-1 for the remote BRI router.

Gandalf XpressStack PRI

We brought in the Gandalf Xpress line of PRI bridges at the recommendation of several RBOCs that have standardized on the equipment for their own internal use. The XpressStack PRI offers a single PRI on the WAN side and one Ethernet port for the LAN. You can get higher densities through the XpressWay Central modular concentration chassis.

The XpressStack PRI is used as either a bridge or an IP router, but it can't do both at the same time. As an IP router, it offers average performance. Call setup times were slower than we expected for such a high-powered unit. We left Gandalf's IPX bridging results in the performance charts, but don't attempt to compare these to the IPX routing performance of the other devices. Bridging is inherently simpler to implement and often d elivers faster numbers.

Managing bridges over usage-sensitive links is not q uite as simple, however. You'll spend more time setting up MAC filters than you need to. Granted, the XpressStack makes pretty simple work of setting up filters, and does a fine job of tuning links for NetWare, but we can't see it being used heavily in mixed IP and IPX environments. If you want to use NetWare over ISDN, buy an IPX router.

There is a lot of horsepower in this unit; it boasts three Intel i960 processors and 8-MB RAM. You can determine a lot by simply looking at the box: 10 alarm and status conditions are visible via the front panel LEDs, once you understand how to read them.

The VT100 console interface, available via direct connection or Telnet, is easy to understand. The console gives good network status, performance and diagnostic information. By the time you read this, Gandalf expects to have a simple Windows-based interface for the unit (one is available with the LANLine 5242I BRI unit we used during our tests).

Gandalf features a unique IPX server SAP learn ing mode, and XpressStack was the easiest unit on which to configure SAP filtering. Unfortunately, you have to disable the Administrative State of the unit in order to learn SAPs. Once the unit has captured them, you can easily filter them or even split them into SAP groups if you wish to classify the SAPs by service, location or some other designation. Still, we can't recommend the unit in NetWare environments.

The unit is best managed from an SNMP management platform. Traps can be set for such alarms as attempted connections from "blacklisted" sites, or when a site exceeds its maximum daily connect time.

ACC Amazon

The Amazon is a general-purpose router with a rich feature set that also handles ISDN PRI, so it qualified for our review. ACC also sells the Amazon ISDN PRI POP (at a list price of $7,995), which initially supports a single T1/PRI and Ethernet, from which you can expand. We like the f lexibility of expandable modules, but the Amazon needs a simpler interfac e and more attention to link optimization before we can recommend it for ISDN routing.

ACC routers use a verbose configuration language that may threaten you with carpal tunnel syndrome before you get everything typed in. Fortunately, the unit supports TFTP download, so once you're familiar with the units you can create your own templates and use a text editor to customize for each location. However, this is an archaic method of dealing with the complex problem of managing router configurations.

We understand routers very well, and don't think asking for a decent interface is wimping out. When under pressure to fix a problem, we might not remember if it's "show IP route table" or "display IP route table" or "display IP route entries." A few wrong attempts, and the most satisfying option is to hurl the box out onto the street, preferably to land far below on the salesperson that sold it to us. It's inexcusable not to provide basic input validation by using me nus. We already learned Unix, thank you very much, and don't want to learn another string-based operating system for each new network device. Please, good interfaces make everybody's life easier.

Now, back to our regularly scheduled programming. Setting up the WAN interface involved mapping a dial port call address (a remote location record) to a physical port address, associating network protocols and then grouping dial port addresses into multilink groups for channel aggregation. It was essentially the same process as with other units, but it took longer to conceptualize, as the hierarchy of physical interfaces, circuits and protocols wasn't obvious.

Once we spent the time to learn the commands for the Amazon, laid out the configuration in a long planning session, mapped the right protocol parameters to the right physical and logical interfaces, then got it all typed in and verified, we were able to get the box to perform fairly well. It turned in exceptional call setup times and top- notch IPX performance.

As a general-purpose router, ACC supports a broad range of interface types and has software for a variety of WAN protocols such as frame relay, X.25 or SMDS. A cornerstone of the ACC router line is its Express Queuing software, which monitors conversations between host pairs and interleaves traffic between them in such a way that low-priority traffic doesn't get starved out while high-priority receives consistent service.

ACC has put less emphasis on managing WAN port utilization than others, and doesn't yet support the full range of NetWare spoofing options. We couldn't set ISDN connection limits for remote sites like we could with several others. NetWare serialization packets, sent between servers periodically to make sure you're not pirating NetWare and SPX keep-alives, which keep peer units in an SPX conversation aware of the other side's status, don't get spoofed across a wide area link. In our testing, we used an ACC Congo router on the remote office's BRI li nk. n

David Willis can be reached at dwillis@nwc.com.
Jeff Newman can be reached at jnewman@nwc.com.

How We Tested PRI ISDN Access Routers

We set up a test network to mimic connectivity with a small remote office. By hanging the PRI units off of our busy corporate network, we were able to keep the central router busy examining IP and IPX RIPs, IPX SAPs and a variety of network protocols generated by hundreds of networks and servers.

On the remote side, we placed a single DOS/Windows 3.1 workstation running NetWare VLMs and TGV TCP/IP. We allowed as much RIP and SAP traffic to traverse the links as the devices would allow. When units such as Symplex's placed limits on the number of networks and servers that could be advertised, we used the maximum allowable limit.

We used remote units from the same vendor that supplied the PRI router, and used the vendor's preferred performance enhancing fe atures-such as compression and channel aggrega tion, even if they were proprietary.

All tests were run at least three times, and any wildly varying results were discarded (to avoid variances due to network traffic). All file transfers used new source and target subdirectories to minimize any caching effects. The average re- sults are displayed in the figures.

IP Test: FTP sends and receives of an approximately 1-MB highly compressible text file. FTP sends and receives of an approximately 1-MB compressed (.ZIP) file.

IPX tests: IPX 6-byte reads, averaged over three one-minute periods, using PERFORM3.EXE. IPX 1,500-byte reads, averaged over three one-minute periods, using PERFORM3.EXE.

Call Setup Test: 2B channel call setup times using 56-byte ICMP Pings to an idle host. Edges of the bars represent the first response received and the last packet received before achieving stable Ping response. Numbers are adjusted to reflect the gap between request packets and the normal Ping latency.

Ordering ISDN PRI Service? Hold The Phone

PRI is still unavailable in many areas, and can be quite expensive-as much as four times T1 rates. The good news, however, is that you may not need PRI at all, but just a simple T1 circuit. If you don't care about routing a mix of voice and data calls over a single pipe, but just want to connect to a large number of remote ISDN users, you can dedicate a T1, or several channels on a T1, to serving that function. If the access router is smart enough, it can take a switched call over the T1 from a remote ISDN user, and even provide channel aggregation capabilities (MP or BACP, for instance) for incoming circuits.

To be fair, there are a few more negatives with switched access into T1 (non-PRI) facilities. Calls will be limited to 56 Kbps each and Calling Line ID (CLID) capabilities may be lost. Setup times will take an additional two to four seconds-but it's still much better than analog modems, and does not increase overall networ k synchronization time by a gr eat percentage.

This communication happens through the magic of the carrier's Signaling System 7 (SS7) network. A remote ISDN device that accesses the D chan-nel for signaling purposes is only communicating with the local switch-these messages don't (necessarily) get routed end to end. Once in the network, the signaling effectively takes place over a separate network than that which actually bears the user's data. From the ISDN side of the network, the switch receives Q.931 messages from the user for call setup. The remote switch can then provide the necessary signaling within the T1 channel receiving the call.

Of the units we tested, only the Ascend router supported switched access into T1. While many routers support dedicated channels over T1, few have added this type of switched capability. Vendors are now scrambling to add the required DTMF circuitry to their hardware in order to support remote BRI consolidation without PRI.

May 15, 1996