Controlling your service network

Feb 11, 2002 12:00 PM

The communications industry's last five years have been a flurry of activity--including a torrent of spending followed almost immediately by a financial retreat from the same, over-saturated market space. Companies that have survived the recent drying up period repeat the mantra, "Grow the business without growing expenses." Succeeding in this framework requires focusing on investments that improve operational efficiencies and deliver bottom-line ROI. What challenges and strategies exist for achieving the right kind of growth in an environment wary of infrastructure expansion?

The problem

The network is a purpose-built utility designed to generate service revenue for the provider and allow the business to grow. The service offered is basic connectivity with added-value features. Providers are able to offer several flavors of connectivity, including private line, VPN, TLS, VoIP and Internet access. Some added-value features include usage-based billing, flexible service-scheduling options, service granularity, application/user sensitive service configuration, service assurance and monitoring.

Network services are quantified by two classes of metrics. The first one is session level metrics. Call-blocking probability is the most widely used of these, and it describes the unhappiness of users who cannot gain access to the service. For example, a busy signal in the telephony world indicates that an admission control mechanism has blocked a customer's service request because the resources in the network aren't sufficient to support the request. To improve this metric and eliminate the busy signal, the network designer must re-size the network, keeping in mind the intensity of the overall traffic demand. To achieve this, the operator might be tempted to admit all calls. However, if resources are not there to support all service requests, service degradation will occur. Users will be happy because there is no request blocking, but they will be displeased with the service quality. This leads us to the second class of metrics--data level metrics.

In a packet-based system, data level metrics describe the treatment a packet receives as it traverses the network. These metrics typically include packet loss, delay and delay jitter. It is quite feasible to guarantee excellent packet level service by deploying a conservative admission control system. Such a design would allow only a few requests to be admitted into the network. Admitted requests would have plenty resources and excellent data level service. On the other hand, many service requests would be blocked, resulting in a cacophony of busy signals and customer complaints. On top of that, the network would be seriously underused.

The paradox of these two metrics points out the importance of fine-tuning the network parameters that can achieve both high network utilization and customer satisfaction. The goal of the service network control system is to allow the service provider to balance these two objectives.

Given most carrier business models, the two obvious strategies for extracting value from the network are to increase service revenue (by increasing customer retention and offering added-value services) and to decrease operational costs (through operational efficiencies). A key requirement in both cases is service network control--a level of business and technology control based on a holistic understanding of both service and network resources. In today's marketplace, this level of control is imperative.

Now is a good time to introduce a few definitions before exploring the possible strategies of service network control. For the purpose of this discussion, let's define "control" as a set of actions executed on a system with the intent of bringing the system from the current state into the desired state. In the context of the service network, the control entity must be able to:

• Get the current state of the network

• Semantically interpret the state of the system and identify the required control action to bring it into the desired state

• Implement the control actions.

Why is the service network control a difficult problem to solve?

There are three main reasons why gaining control of the network is such a complicated enterprise. The first of these is that getting the network state is very difficult. No tools or protocols currently exist that provide a consistent logical topology and resource model in a multi-vendor, multi-technology environment. Therefore, making a control decision that has networkwide implications becomes a very complex task.

Current networks consist of devices that exploit different capabilities, use different technologies and come from different vendors. Even within a single vendor's product line, it is possible to find many different platforms and software images because vendors like to optimize each product. As providers usually implement network services over multiple devices, the process of service activation becomes fairly excruciating--getting the state of the system ends up requiring a sophisticated (i.e., expensive) workforce that understands all the technical peculiarities of a very diversified environment. The human operator is inserted into the control loop and all too frequently becomes the bottleneck.

The second difficulty is that implementing a network service means piecing together a solution with complex interactions between multiple technologies (for example, one possible solution for delivering end-to-end QoS creates interactions between DiffServ and MPLS). In most cases, implemented policies are tuned and validated manually, so they cannot respond to changing needs.

Third, executing the control actions requires complex translations from desired behavior into device configuration data. Once again, this requires a knowledgeable, expensive workforce.

And the situation will only get worse. The number of networks, and the bandwidth demands within them, is increasing rapidly, while providers continue to introduce new technologies into the core and at the edge of the network. As the network gets even larger and more complex, the pressure for change is beginning to mount.

How is this problem solved today?

Today, the logical network state is obtained by having an "expert user" interpret the raw configuration files from diverse set of network elements. For networkwide configuration, large amounts of data are consolidated from different sources. Given the different formats, semantics and granularity of these, the task is difficult if not impossible. This inability to semantically interpret the state of the network means that service activation suffers from a lack of network awareness. At the same time, network optimization suffers from the lack of service awareness. Even when off-line tools are used to generate control actions, the logical network state must be translated in the format used by the off-line tools. This is difficult, time consuming and expensive because it requires a workforce to activate the services manually--and that's how errors creep in. Finally, when the intensity of requests is high enough, human reaction time becomes a bottleneck. The overall effect is that the service network control timescale becomes prohibitively large.

To make things worse, the size of a network, the number of users and the service complexity create a very dynamic environment. One look at the large control timescale shows that most of the time, the network is far from its "sweet spot." Taking all of these woes, complexities and opportunities together, it's easy to see the need for a new strategy.

What is the right strategy?

The good news is that the basic mechanisms used to provide network services and optimize network resource utilization have been around for a while. A partial list of these mechanisms includes traffic conditioning, bandwidth management, traffic engineering and admission control. The parameters for these mechanisms are well-defined. What has been subject to constant change are the implementations and the protocols used for setting the mechanisms' parameters. Experience implies that it is possible to define a unified, logical, multi-vendor, multi-technology information model that describes the network, services, and users as well as the relationships between them. Such an information model can also capture device capabilities and constraints to enable coherent control of devices with disparate functionality. The information model enables integration and allows the plug-and-play use of best-of-breed devices and commercial off-the-shelf software components. The service provider is armed with a holistic set of data that reveals how specific network elements are being used to support specific revenue-generating services.

A service network control system using a component based architecture offers service providers the ability to meet future requirements through rapid evolution. Components of the architecture are loosely coupled in the sense that they run independently and can be added or removed without affecting the behavior of other components. Business models can be untangled from the service network control infrastructure and implemented as workflows that network operators can alter without having to re-code anything. Such greater flexibility and component reuse translates directly into superior operational efficiency and reduced time to market.

With service network control in place, the human workforce can focus on what they do well, and computers can do the rest. The presence of a semantically rich state of the network allows the development of applications that perform complex translations and implement algorithms that operate on this state. The carrier can then use that data to make intelligent decisions from both the business and technology perspective. Through policies and workflow designs, human operators can express the objectives that drive the behavior of the system. Removing human intervention shortens the control timescale, which ensures that the system is much closer to the desired state most of the time.

By adopting this strategy, providers can offer services on top of multi-vendor, multi-technology networks. The presence of semantically rich information model decouples the service provider's development cycles from the development cycles of network element vendors. New services can be developed quickly without re-engineering the whole physical network. A common information model provides consistent physical, logical, and service views of the network and manages the relationships between these different views as well. This eliminates the need to understand, correlate and manipulate multiple vendor-specific and technology-specific management systems. A unified logical view allows network operators to capture and use correlation between multiple technologies to provide optimized service delivery.

Given the current state of the carrier services market, the focus is now on minimizing costs and maximizing profits. Service network control has emerged as a key requirement to achieve that objective. The bottom line is this: carriers can't control their business without controlling their service network.

Aleksandar Ratkovic is CTO of CPLANE Inc., and can be reached at sasha@cplane.com.

Visit CPLANE Inc. online.