SLAs Meet Managed VPNs - continued

How Are Targets Measured and Enforced?
Methods for measurement vary, depending upon the type of service and SLA targets. GTE Internetworking contracts a third party, Inverse Network Technology, to monitor VPN Advantage remote access availability. According to Aliber, "They dial into about 500 modems per month (a fairly large sample size) to monitor performance. Results are compared to customer SLAs. If SLAs are not met, we proactively apply credit to customer's next bill."

For UUsecure VPN Direct, a site-to-site VPN service, SLA enforcement involves three layers.

1. Probe software on each CPE router—a Lucent Access Point—performs a ping-like function between itself and other CPE routers, depending upon topology. In spoke-and-hub networks, CPE will ping the hub; in fully-meshed networks, CPE will ping all other sites. Probes are repeated every 2 1/2 minutes. "This interval is configurable: We find 2 1/2 minutes to be good compromise," says Bregman.
2. Poller software at the VPN NOC gathers availability, latency, and packet loss probe results at just under 10 hour intervals, based on CPE storage capacity. The poller uses SNMPv3 to pull results from the CPE to ensure that the measurement source is authenticated.
3. A back-end system stores summarized probe results using Sybase. Monthly reports are distributed to the account team for review. The account team makes reports available to customers, along with any necessary service credits.

According to Bregman, "The CPE router also send traps to the VPN NOC if latency and availability thresholds are reached so that proactive measures can be taken by UUNET to find and fix the problem." This kind of early warning system is essential: The provider must manage ongoing performance in order to meet SLA targets.

But even if one site is down for an hour—more than 0.1 percent of the month—the SLA can still be met. Measurements are averaged over the entire month and all eligible customer sites. For UUNET, eligible sites are those with a sustained use level less than or equal to 50 percent of the total dedicated connection capacity. If sustained use exceeds 50 percent during two consecutive months, the customer must order a capacity upgrade within a 30 day period or the site will become ineligible for latency and availability guarantees.

What Remedies Are Provided When SLAs Are Not Met?
Proactive service credits are used to compensate customers for VPN SLA non-compliance. According to Aliber, "Our requirements analysis has shown that reactive credits can be messy, and we want to make this process as painless as possible." But proactive credits are not yet available across all GTE Internetworking offerings. "Our dial offering is reactive, but if you tunnel VPN over dial, the credit becomes proactive," says Aliber. "GTE is definitely moving toward credit consistency across offerings, but needs to put in place back-end systems to make this happen across the board."

While UUNET also provides proactive credits, Bregman says "Our belief—borne out by customer feedback—is that the size of credits and how they are received is not as important as the fact that we offer them. Credits are a measure of UUNET's commitment to achieving agreed levels of service. Clearly they don't compensate for loss of revenue associated with downtime for mission-critical applications."

In fact, the monthly fee for a single dedicated connection is probably quite small when compared to the business impact of an outage, particularly for site-to-site VPNs that provide corporate backbone network connectivity. Should ISPs offer larger service credits? "I see this as an insurance question more than a service credit issue," says Aliber. "If you're in a high risk business, you take an insurance policy out to compensate for disasters. Service premiums would have to be set very high to issue credits commensurate with loss of use for customers that would be affected, and I don't see market interest in paying these kinds of premiums."

What About Security Level Agreements?
Given that managed VPNs are a security service, customers may also request security level agreements. Such agreements are just starting to emerge, and targets are not as clear-cut to measure. Security level agreements may define physical steps taken to safeguard equipment and data, resistance to certain types of threats, or the reliability of intrusion detection and response systems. For example, Intermedia guarantees that Secure Managed Firewall log files are archived off-site nightly for safe-keeping.

But, according to GTE's Aliber, there are legal and financial issues that must be addressed before security level agreements can be offered. "Quantifying security level agreements is difficult. For example, maybe a customer wants a guarantee against DDOS attacks. But we don't control every system that might be involved in a DDOS attack. We can only exert controls over our own real estate, and can't guarantee against attacks that exploit customer-controlled resources."

Challenges that Impede SLA Deployment
I asked Aliber and Bregman to comment on the technology hurdles an ISP must face when offering SLAs for managed VPN services.

"SLAs are inherently challenging," says Bregman. "There are so many small pieces that make up a product that measuring performance can be like eating soup with a slotted spoon. There are two challenges: How can we measure end-user experience accurately and meaningfully? And how can we manage SLAs across the backbone?"

The latter issue is addressed today by building out the backbone in anticipation of need—classic over-engineering. "The problem with this approach is that it is expensive, and there's always the chance that usage will catch up with you," says Bregman. "We're looking to improve our ability to exert quality of service across the backbone, first with class-based queuing at the network edge, then moving into the core network."

If managing SLAs across your own backbone can be difficult, what happens when more than one ISP backbone is involved? According to Aliber, a study of Fortune 500 companies shows an average of 2.3 ISPs per company. This implies that traffic generated by large customers may well transit from one ISP's backbone to another. "Local loop measurement is easy, but it's not end-to-end quality of service," says Aliber. "What happens once the loop enters the network cloud? What happens when you have to peer into someone else's network? As a provider, how can you deal with that—unless you get an SLA from the other ISP."

Future Directions For VPN SLAs
On the horizon, UUNET sees customer requirements for SLAs associated with packet loss. "We are measuring and looking at packet loss now, and are likely to add packet loss levels to our SLAs in the near future," says Bregman. Excessive packet loss can be an indication of poor application performance and end-user experience, even when latency targets are being met.

UUNET also expects to turn up "Extranet-like" VPN services with several large customers. These Extranets will employ spoke-and-hub topology, with the hub centrally owned by the customer and CPE routers owned by suppliers and business partners. According to Bregman, "In this type of network, we're being asked to break out SLAs—currently averaged over all site-to-site tunnels—into point-to-point SLAs (individual hub-to-spoke SLAs)."

Both Bregman and Aliber say that the next big step will be incorporating end-to-end quality-of-service into VPN SLAs. QoS is the ability to effectively prioritize one traffic stream over another and to manage individual stream service characteristics. "Customers are asking for this, and our CPE router provides some capabilities to do this at the network edge," says Bregman. "But there are still backbone issues to be considered, and we are working within a larger MCI WorldCom initiative to address extending QoS across the backbone."

return to the top of this article

—End