SLA savvy, 09/27/99

By JULIE BORT
Network World, 09/27/99

True or false: A service-level agreement is a distinct type of legal document in which service providers stipulate their commitments and also their penance. Answer: False. Truth be told, "SLA " is just a new-age term for the age-old telecom contract.

"There's nothing special about an SLA. It's a legal contract like any other," says David Simpson, founding partner in Young, Harlick, Wilson and Simpson, a San Francisco law firm that specializes in telecom contracts.

So why coin a phrase?

In years past, carriers wrote the contracts, and network executives simply signed them. Today, net execs have taken the upper hand, negotiating hard for pricing, performance and penalties. Enter the need for tools for verifying that carriers meet the terms of these contracts, and for a jazzy new name for the agreements themselves. After all, without a nifty buzzword, how else would vendors be able to sell these new tools?

Cynicism aside, drafting a contract and verifying that you're getting what you've paid for are real and valid expenditures of time and money. Today's service contracts - or SLAs, to keep with the buzz - are hugely complex. An SLA stipulates the delivery of numerous service levels and spells out penalties for shortfalls. But only the best SLAs are negotiated well enough to lock a provider into the promises made by its salespeople.

"An SLA is, in effect, pricing. You ask for a certain commitment for a certain price," says Ellen Van Cleve, datacom director for a Fortune 500 company and a vice president of the Communications Managers Association (CMA). "You must clarify what that means and how it's measured. "

SLAs cover an assortment of data services: frame relay, leased lines, Internet access, Web hosting and outsourcing. While each one of these has its own set of contractual gotchas, experts say that several guidelines apply to all SLAs.

The best way to understand SLAs is to break them into two pieces: negotiating the technology agreement and verifying that promises made are promises kept. Within each of these areas, experienced SLA negotiators offer these tips for a winning deal.

Tip No. 1: Figure out what it's worth.

Define exactly what your needs are and how much they are worth. End-user perception is a good guideline for determining your needs, says Jason Czaplewski, network systems analyst for Shands Hospital, a Gainesville, Fla., institution that runs a statewide WAN composed of frame relay, leased lines, T-1s and fractional T-1s, plus ISDN.

"If, at less than 99%, users start complaining the network is always down, we need to contract for 99% [of successful frame transmissions]," he says.

In other words, "quantify from a business perspective what your real requirements are. Then you can deal with determining your system requirements," says Lightsey Wallace, principal of Lightsey Enterprises, a datacom quality consultant in Fairfax Station, Va., and a leader of a TeleManagement Forum QoS/SLA working group.

Still, you can assume some numbers. For instance, Wallace finds that a typical SLA requirement for T-1 and frame relay service should be 99.93% availability, which is 60 seconds of disrupted service in 24 hours. But beware - carriers can trickily coat this statistic in the term "mean time to restore (MTTR). " Availability expressed as MTTR is a trap because, by definition, it's an average.

If you've negotiated for a MTTR of 60 seconds per 24-hour period (thinking you've gotten 99.93% availability), that doesn't automatically mean no more than 31 minutes of downtime per month. The service provider could have 10 minutes of downtime 15 days out of the month, and two-second outages every other day in the month, and still average less than one minute of downtime per day.

Availability and MTTR therefore need to be coupled with a maximum time to restore, a specific length the network can be down for a specified period, expressed as a daily or, perhaps, monthly figure. Specifying a MTTR of 60 seconds and a maximum time to restore of 31 minutes per month would be more in your favor.

Other well-accepted statistics include three hours per month scheduled downtime for maintenance, and a network mean time between failures of two hours (again coupled with a maximum time between failures that jibes with your negotiated availability).

Performance should be in user-satisfaction terms. One accepted standard is the "three-second response," Wallace says. That is, the reply from the application should take no longer then three seconds to respond once the user hits the Enter key. For real-time networks, such as those used by financial traders, a subsecond response is required.

The guideline for a value that indicates a service provider has defaulted on its SLA should be the old "three strikes you're out " rule. If you report three to five trouble tickets on the same service area point (SAP) - meaning, a piece of equipment or circuit - and the service provider can't resolve the problem, the trouble ticket should be escalated to a "vendor meet," Wallace says. At this level, all vendors involved meet to fix the problem. Three vendor meets on the same SAP, even if for different problems, should nullify the contract.

Pricing remains the trickiest part. Like a car dealer, a carrier is not going to reveal the deals it made with others. Unfortunately, many users keep negotiated prices close to their vests, as well. Yet pressure is mounting for service providers to create tiered service - say, Gold, Silver and Bronze levels - and publish the pricing for each. ISPs might lead the way.

Tip No. 2: Know how the carrier net is designed.

Don't impose service levels; design for what is offered, Wallace says. The truth is, no matter what a service provider promises, it can only give you what its network is capable of. By contracting only for what a service provider can provide realistically, a network executive can then implement measures to ensure availability via redundancy and fail-safes, for example.

Good guidelines for what a service provider should present as reasonable network capabilities can be found on a handful of Web sites that publish performance metrics. For example, check out UUNET's monthly latency statistics or AT&T's IP Network Status Site. At its site, AT&T serves up real-time backbone statistics as well as target and achieved statistics for the prior month. In August, for example, AT&T reported that it hit 51 msec for delay; 0.11% packet loss; 99.9% availability and 98% modem connection success rates.

The difficulty is getting service providers to offer apples-to-apples statistics on network reliability. To help you make comparisons, ensure that network descriptions clearly define what is measured, where it is measured, the time period over which measurements are taken and time of day.

Of utmost importance is how a service provider measures traffic that traverses backbones, as this area is laden with strife for users and is least likely to be covered by an SLA (see next tip). For instance, in the AT&T example cited earlier, the target performance was between city pairs on its backbone, not end-to-end measurements.

SLA validation tool maker VisualNetworks offers an SLA template that was produced by TeleChoice, a consulting firm in Owasso, Okla. Available by registering at the company's site, the template includes the following advice on end-to-end performance: The average end-to-end round trip delay for each permanent virtual circuit should be 110 msec for a T-1, 140 msec for 256K bit/sec and 230 msec for 56/64K bit/sec.