November/December 2001

Performance Monitoring Changes The Face Of The SLA

BY MICHAEL COMBS

Todays service level agreements (SLAs) arent making anyone happy. Customers who have suffered through service problems only to have to battle again for a credit wonder what the real value of an SLA is. And service providers, under pressure to keep costs down, are rightfully concerned about opening the door to new cash outflows. After years of SLA discussion and hype, why are we still facing this problem?

The fact that todays SLAs are not living up to their promises is even more disappointing given the current market conditions. Before customers can build new business models based on the availability of new network services, they need proof that those services are reliable. SLAs, when implemented correctly, help manage expectations for both parties, ultimately increasing customer satisfaction. Increased customer satisfaction and acceptance of new services are two benefits of SLAs that the market needs in order to sustain growth.

The root of the problem is in the double challenge of service level management and customer quality of service (QoS) management. Service level management has largely been focused on fault management. But in modern IP self-healing networks, performance management is becoming a more significant priority, even as it becomes a greater challenge due to network complexity and scale. Customer QoS management has not been as widely discussed but is central to customer satisfaction. It provides for timely reporting on customer commitments including SLAs and other relevant information such as orders completed on time, usage patterns, etc. To date, this reporting has been neither timely nor complete largely because tools for this have not been available.

SLA STATE OF THE UNION
The relevant portions of the SLA are the service level objectives, the service level indicators, the non-performance penalties, and the reporting. The basic service level objectives have been fairly well defined across the industry. But the challenges involved in monitoring the service level indicators make it difficult for service providers to detect and respond quickly to problems, to maintain a high level of quality of service and to deliver reports to customers. Until these limitations are overcome, service providers will be cautious when they negotiate SLAs.

Lets look at a couple of typical SLA problems: The metrics are often not directly related to the customers business backbone response time doesnt necessarily equate to the customers response time experience. But because of the difficulty in obtaining a true end-to-end latency metric, the backbone is used. A problem is defined as beginning when a customer opens a trouble ticket. (If a tree falls on your server, but nobody opens a trouble ticket on it, did it cause an outage?) Because neither the service provider nor the customer have real-time visibility into their service, this can significantly increase the duration of the service outage while reducing the amount of the credit the customer is eligible for. Even if the service provider does have immediate visibility into a network problem, theres no easy way to determine which customers will be impacted by it.

HOW PERFORMANCE MONITORING IMPROVES SLAs
A strong performance monitoring strategy can improve delivery against SLAs. When combined with a strategy for customer QoS management, these service improvements can be effectively communicated to customers. Even communicating service problems can improve customer satisfaction. Imagine a scenario where a customer service representative calls a customer to inform them that there is a performance problem and that service should be restored within the terms of the SLA before the customer was even aware there was a problem? This gives the IT manager the opportunity to proactively manage his organization and resources a welcome change.

In addition, a strong performance management/customer QoS solution can enhance the service level guarantees available. Duration parameters can be combined with thresholds to create premium offerings. Ninety-nine-percent packet delivery for the month can mask a seven-hour period where virtually no packets were delivered. Adding duration thresholds more accurately sets customer expectations while it creates new revenue opportunities for the service provider. Additional parameters of interest to the customer can be added to the SLA, such as the time to provision a new service, and the availability of a second resource (a server or network circuit) in standby mode as protection against failure of the primary resource. And because the service provider has immediate and proactive visibility into network performance, they can proactively communicate problems to their customers another value-added service and SLA parameter.

Fault management gives the network operations team real-time information about problems as they arise. This essential capability allows rapid reaction to issues, but doesnt provide any proactive assistance or in-depth insight into the nature of the problem. Performance management periodically gathers information from all monitored elements and retains it for historical reporting. These reports can be used to provide additional context when troubleshooting. Historical information can help differentiate between chronic problems and isolated events, simplify identification of congestion-related issues, and resolve borderline conditions. A fault management system would provide real-time notification each time the traffic rate crossed the alarm threshold, allowing the network operations team to take quick action. But historical performance reports from the performance management system would enable the network team to determine if these were isolated events or symptoms of a growing congestion problem.

Traditionally, fault and performance management solutions have displayed information in real-time consoles and in reports for consumption by network operations. In worst-case scenarios, there may be a separate console for each monitored vendors equipment, supplied by the equipment vendor. Obviously, a different approach is required to deliver reports to the service providers customers.

REPORTING TO THE CUSTOMER
Trouble ticketing, fault, and performance monitoring solutions will evolve to deliver reports over the Web directly to the service providers customers. This helps address the customer QoS management issue, but brings new challenges:

• Scalability. How many customers can access reports simultaneously (on Monday morning)?
• Real time. Performance information must be current in order to help customers quickly respond to issues.
• Integrated view. Trouble tickets, fault, and performance information are closely related and need to be correlated in reports. If nothing else, customers will expect a single user interface.
• Data retention. Customers will need access to their information for several billing periods to give them time to review performance against their SLA commitments.
• Data integrity. Reporting issues and occasional errors could be tolerated when the audience was the internal network operations team. For example, they knew that the network was okay but data collection was temporarily interrupted when the customer was moved to a new circuit. But customers wont have the same inside knowledge and may not have the same patience to make sense of confusing and erroneous reports.

The reality of SLAs, from the service provider and from the customers perspectives, has fallen far short of the promise. Both service providers and their customers will eventually benefit from solid service and SLAs. But in order to deliver true SLAs, service providers must first bring a new focus on performance management and its companion customer QoS management.

Michael Combs is director of product marketing for Quallaby Corporation. Quallaby provides telecommunications software that enables service providers to derive maximum revenue from their network infrastructure while improving customer satisfaction. The companys PROVISO software imports and integrates OSS data in an Oracle-based data mart for SLA business modeling, so that network performance is associated to the services and service levels deployed per subscriber. Contact Quallaby at www.quallaby.com.

[ Return To The November/December 2001 Table Of Contents ]

BY CRAIG WARREN

Carriers and service providers deploying VoIP networks are recognizing the need to protect the infrastructure from hackers and denial of service (DoS) attacks. After all, VoIP networks are IP-based networks just like the public Internet, and weve seen how vulnerable the Internet is to such disruptions. The attacks demonstrate just how easy it is to gain access to Internet-connected servers and steal, damage, or corrupt their contents. When carriers and service providers deploy VoIP networks, they will have to take precautions or suffer the fate of eBay, Amazon.com, and others security breaches, lost business, and all.

The old saying about an ounce of prevention applies here. The best time to mount a defense is when attacks happen. But few carriers, other than the IP purists building next-generation networks from scratch, really understand the problem. Most companies wait until they experience a security breach before taking action. Many of them dont know that new VoIP security solutions are available today. Whats more, standards are taking shape that will provide more choices and lower prices.

The Internet was designed for data. In its current state, it cannot replicate the public switched telephone network (PSTN). Its just not as reliable. And VoIP networks have been limited experiments. They cant yet boast the reliability that 100 years of refinement have given the current telephone network.

Some VoIP service providers use the public Internet to carry voice packets while other carriers wouldnt think of using it because of its poor voice quality. But voice quality could be the least of their problems. The same operating systems and underlying computer hardware that power the World Wide Web are used in VoIP infrastructure. Most application servers, location servers, proxy servers, softswitches, and gatekeepers used in VoIP networks are open system platforms with their own inherent vulnerabilities. Like those on the public Internet, these systems are susceptible to the same attacks, vulnerable to the same security breaches, and are sitting ducks unless the proper precautions are taken.

THE IMPORTANCE OF VoIP SECURITY
Backbone carriers and service providers have found that IP voice traffic has its own particular set of characteristics that render data security solutions inadequate. Theyve asked vendors to develop new products to protect their next-generation IP networks and expect them to actively support standards. Of course, they still need to preserve voice quality, too. Carriers and service providers establish peering relationships by interconnecting their networks. Carriers collocate and connect directly through LAN interfaces, while others connect over a WAN through routers. For all practical purposes, interconnected networks become one larger network, each side inheriting the strengths and weaknesses of the other. Just like the weakest link in a chain, the combined network becomes just as vulnerable as the weakest network. Carriers and service providers are thus looking for ways to protect their networks at the peering points.

In order to have a viable service, carriers and service providers must deploy secure, reliable, real-time communications. Failure to implement security solutions will make VoIP networks susceptible to outages and slowdowns that could result in lost revenue, reputation, and customer confidence. One way to avoid this problem is to install a firewall system that can handle the real-time demands of IP telephony and multimedia applications. Such a device must meet two requirements:

• It must have a firewall policy that allows one host to send packets to another host, from one port to another; and
• It must allow call control (signaling elements) to control the firewall.

HOW IT WOULD WORK
One solution is to design a system that would use high-speed, stateless, packet-filtering technology that allows policy provisioning while enabling signaling elements to have control over the firewall. This system would resemble an IETF proposal that describes a decomposed model for providing firewall and network address translation (NAT) functions under application control.

In an IP telephony network, special consideration must be given to signaling elements, which are responsible for locating the called party and for arbitrating call setup and teardown messages. Under the decomposed model endorsed by the IETF, these signaling elements control the firewall.

When a signaling element observes that an authorized call is being set up between two endpoints, it can glean the relevant IP addresses and port numbers from those messages to create policy for the firewall, or for multiple firewalls. When the call is torn down, the same (or another) signaling element can remove the policy from the firewall. The result: The firewall remains closed until a call is set up.

When a call is set up, policy within each firewall is modified by the IP telephony network element(s) to allow the media packets for that telephone call to flow through them. As each new call is set up, policy is created to match, and as each call is torn down, policy is removed. At any given instant, the firewall allows only the media for existing, authorized calls to pass through it. No other traffic passes and, subsequently, there are no attacks.

Of course, some static policy is necessary to allow signaling traffic to pass through the firewall, as well as to allow other potentially essential network traffic. This sort of policy must be site-specific and supported by the system.

ANATOMY OF A VOIP FIREWALL
The system purpose-built to perform the firewall and NAT functions would consist of specialized hardware and software in order to achieve high performance and low latency. Software-based firewalls are too slow and inject too much delay. ASIC-based hardware firewalls are fast, but not flexible enough to be controlled by the application. Whats needed is the right combination of hardware for speed and software for flexibility.

One or more packet processing cards and a single management card (printed circuit cards mounted in a chassis) would comprise the hardware elements. Each packet processing card separates a protected (secure) network, from an unprotected, or open one. Each processing card provides firewalling and NAT services to the path connecting the open and secure networks. The only management and control path to the processing cards is via the management cards Ethernet interface. As a result, the processing cards are invisible to the networks to which they are attached, and the interface is non-addressable. The management card provides the control interface to the signaling element. The signaling element provisions the firewall, opening and closing media ports. Voice packets crossing the network interface undergo dynamic NAT to move media on and off the IP network to the appropriate endpoints.

The best VoIP security solution for carriers and service providers is a firewall/dynamic NAT solution that scales to meet requirements for capacity and performance. It must be designed specifically for the multimedia traffic used by carrier-class IP telephony services. Its firewall control protocol must give the IP network call signaling elements control of the firewall and its policies, and support fail-over and redundant configurations to ensure high availability. Such capabilities will enable secure, real-time communications. They are the essential services that will help transform the Internet into the new public telephone network.

Craig Warren is corporate evangelist and co-founder of Minneapolis-based Aravox Technologies. Aravoxs network services platform enables secure, real-time communications for carriers, access providers, and managed service providers deploying Voice-over-IP networks. For more information, visit Aravoxs Web site at www.aravox.com.

[ Return To The November/December 2001 Table Of Contents ]