It wasn’t so long ago that calling a telco to order frame-relay circuits was the only feasible way to securely connect remote offices to headquarters. The typical frame-relay network consists of T1 and fractional T1 circuits connected via a frame switch located in a telco CO (central office), with all these circuits aggregated on a central circuit in the corporate datacenter. The recurring fees are costly, leaving IT directors little choice but to severely limit the bandwidth to remote sites. If 128Kbps circuits can do the job, albeit slowly, then up they go.
In the late 1990s, when many of these networks were built, they weren’t expected to carry e-mail traffic or support rich applications. When the only traffic on the wire consisted of terminal sessions to an AS/400, maybe 128Kbps really did fit the bill. Now, of course, the playing field is much different, but the prices are not. Today, it’s not uncommon to find a frame-relay network of reasonable size and geographic spread priced at $30,000 per month. For overseas sites, the prices increase exponentially.
Fortunately, there are a number of ways to reduce costs on your WAN. And frame relay has significant competition. A number of new technologies have emerged that can breathe new life into your WAN and potentially save you a bundle in the process.
Let’s make a deal
If frame is your game, contract negotiations are one key to controlling costs. Frame-relay carriers will often drop their pricing if the CIR (committed information rate) on each leg of the network is low. The CIR determines the absolute minimum bandwidth available on a circuit, regardless of its rated bandwidth. If a 512Kbps link carries a 256Kbps CIR, the carrier cannot be held liable for bandwidth levels below 256Kbps, even if it has significantly oversubscribed the frame-relay switch.
A low CIR level can sweeten the deal on a frame-relay circuit by slightly reducing monthly costs. Unfortunately, many contracts are signed with CIRs in place that would render the network effectively inoperable. Some contracts are signed with a 0Kbps CIR, which essentially allows the carrier to drop the network at any time.
Another way to reduce costs is to sign a long-term contract. But all too often, corporations sign long-term agreements only to find they can’t easily escape them when better offers abound. Fortunately, there are myriad technical solutions available today that can provide a solid WAN infrastructure without the cost headaches of frame relay.
The darling of the WAN these days is MPLS (multiprotocol label switching). At its essence, MPLS is a managed, nonencrypted network of traditional T1 or fractional T1 service between sites. But MPLS providers encapsulate the traffic from these links and tunnel it to other sites on the network, switching packets at higher layers than they would for traditional WANs. Because MPLS networks require only local-loop access to the provider’s POP (point of presence) and are then switched and routed through the provider’s network, more bandwidth is available at lower cost.
Desmond Fuller, IT director at iBiquity Digital, is in the process of moving his WAN through its third iteration. Fuller migrated to ATM from frame relay a few years ago to better support VoIP and videoconferencing. Now the stage is set for a move to MPLS.
“We were never able to fully realize the performance we needed for seamless videoconferencing and VoIP phone calls,” Fuller says. “Part of that was the hub-and-spoke design of the ATM network, so our remote offices couldn’t directly talk to each other. With MPLS, we can guarantee QoS end-to-end for the entire network, … and the branch offices have seamless communication to each other. For what we were paying for 1.5Mbps ATM lines for each office, we were able to upgrade to 4.5Mbps.”
There are downsides to the MPLS approach. Traditional frame-relay networks provide only layer 2 connectivity. Routers on either end of the circuit have a clear path to each other and take responsibility for packet transmission at layers 3 through 7. With MPLS, traffic is routed through the carrier’s network using virtual routing frameworks. In essence, all traffic for a given network is encapsulated, making the network seem private even though its traffic is flowing across public links. As a result, routing issues on the carrier’s side quickly translate into connectivity problems on the MPLS network.
Steve LaPointe, director of information systems at specialty materials manufacturer FiberMark, recently completed a migration from frame relay to MPLS on FiberMark’s seven-site WAN. Overall, he says, it’s been a great success. But it hasn’t been a bed of roses.
According to LaPointe, “The cost comparison showed us that by migrating to a MPLS network, we could double, and in some cases triple, the bandwidth at all of our locations, while reducing our monthly network spending by more than 60 percent,” LaPointe says. “Once we saw the numbers, making the decision was easy.” But he adds, “We do see more downtime due to planned maintenance windows on the new network. Although this was unexpected, it has not been a problem.”
Making the most of it
If switching to MPLS isn’t feasible, alternatives are available to improve the performance of traditional frame-relay networks. The key is not to throw more bandwidth at the problem but to make the most out of the bandwidth available.
When positioned at one or both ends of a WAN link, WAN compression appliances watch for frequently requested data on the wire and store that data to a local disk. Thus, when similar data is requested by several clients on the local network, the appliance will intercept each request and substitute locally cached data, resulting in much faster access. RiverBed Technology’s Steelhead product is a good example of this type of solution. Alternatively, rather than caching data, WAN compression engines compress all data flowing across low-bandwidth pipes, reducing transmission overhead.
And then there’s QoS. Managing QoS calls for packet-shaping appliances, which provide a management interface that displays current traffic on the wire. Administrators can then prioritize those packets, ensuring that mission-critical applications always take precedence. For example, if the bulk of traffic seen on a WAN is HTTP and e-mail but the company runs on Oracle, then guaranteeing bandwidth for Oracle will result in snappier application performance, even if Web sites may take longer to render.
Packeteer is the current leader in QoS appliances and has recently moved into the compression market as well. Packeteer’s compression technology, termed PacketShaper Xpress, incorporates the features found in the PacketShaper but adds the benefit of data compression.
Not all WAN bandwidth problems can be traced to legitimate usage. Too often, costly WAN upgrades are implemented unnecessarily. In many cases, the true culprit of poor WAN performance is poor application performance, poor network design, or simply carrying more noise than signal.
For instance, an edge site with many users can certainly be set up to have clients authenticate to a central directory server, but file sharing might best be handled locally to reduce the traffic between sites.
The same tenet can apply to other applications, such as e-mail. Although adding servers to remote sites adds administrative overhead, it’s often much cheaper than increasing bandwidth to provide the same services from a central location. Also, reducing the number of fat client/server applications can have a positive effect on the network, as Web-based applications typically use less bandwidth.
Remote desktop and application delivery is another method for reducing network costs.
Citrix has held the crown in this space since its inception, although Microsoft’s RDP (Remote Desktop Protocol) has been gaining popularity. By investing in a Citrix server farm at the datacenter and providing only thin clients to edge sites, the WAN bandwidth necessary to serve a single office will be much lower than in a traditional configuration.
Mark Flieger, senior vice president of network services at Occupational Health + Rehabilitation, knows this scenario well. OH+R’s network is almost completely driven by Citrix, with dozens of remote sites running only thin-client workstations. The WAN is built on frame relay over ATM, but judicious use of a Packeteer PacketShaper makes the most available bandwidth.
“While Citrix ICA [Independent Computing Architecture] traffic is very bandwidth-efficient, it is also latency-sensitive,” Flieger says. “Therefore, we use a PacketShaper to ensure WAN QoS. Although it took us a while to create a bandwidth QoS model that works well for us, we are now very pleased with overall WAN performance and cost avoidance.”
There are caveats to the Citrix approach, however. Obviously, if the WAN link goes down, the remote office is disconnected from all its applications and cannot function. Also, the amount of bandwidth available can significantly increase the time required to print local documents, as the print server is on the other side of the WAN with all the other applications. Fortunately, Citrix has been incorporating printing bandwidth management in its more recent MetaFrame products.
Finding your way
Another alternative to the traditional WAN is a do-it-yourself approach using IPSec VPNs. If all remote sites qualify for broadband connectivity, or if the price of a T1 or fractional T1 to a remote site is reasonable, it’s possible to build a fully meshed VPN architecture to connect every site using standard Internet links (see "Metro networks go wide").
This method has the dual benefits of being cost-effective and generally fast. But it also suffers from the vagaries of the Internet. With no SLA for timely packet delivery from site to site, Internet outages and slow ISP interconnects can have an impact. Also, without centralized management, each site becomes somewhat of an island.
If you’re lucky enough to find a common carrier that can provide bandwidth to multiple sites, however, then this is very likely to be the most cost-effective and reliable approach. Site-to-site VPN traffic will never leave the carrier’s backbone network, so a site 200 miles away might actually be no more than three hops away.
As always, decisions made regarding the network foundation will have a significant impact on every subsequent initiative. Holding out for the bargain-basement WAN will feel great on the day the deal is signed, but it can leave everyone hanging when the network fails to perform or fails altogether. It’s important never to underestimate the cost associated with solid long-haul networks. But it’s also important not to lose sight of the next technology that will allow you to do more with less.