Policy Product Examples

Two examples illustrate established policy products. One is from Cisco Systems; the other is from MetaSolv Software.

Cisco QoS Policy Manager

The QoS Policy Manager (QPM) from Cisco Systems is an example of a maturing policy system; it has been in the market long enough to be tested in real production environments.

QPM has a scalable architecture with a set of distributed policy servers supporting its classifiers and enforcers. Cisco might package classifiers and enforcers in the same network device, or it can use separate elements. QPM is designed to manage the configuration of devices to deliver specified service quality.

The QPM console functions as the interface to the rest of the system. The console is also used for policy management functions. Policies are stored on a policy server that replicates the policy information to a distributed set of policy servers. This provides high scalability and fault tolerance.

Other policy management functions include the following:

• Periodic comparison of the device configuration against the policy definitions stored in the repository

• The provision of a series of web-based reports for administrators

• The tracking of distribution status

• The maintenance of a detailed log of device configuration and policy changes

• The use of an alarm to distribute new policy information

• The use of incremental configuration updates, saving time and bandwidth

The repository is a directory accessed through the Lightweight Directory Access Protocol (LDAP). LDAP establishes a client/server connection before transporting requests from the client. LDAP is the common-access mechanism, leaving the choice of the actual repository schema open. The repository could be an object-oriented database, an SQL database, or even a flat file.

QPM uses several policy-distribution mechanisms to support its push-delivery model. Cisco will continue to support Simple Network Management Protocol (SNMP) devices, but it sees Common Open Policy Services (COPS) as its strategic future direction. Distributed servers can be placed close to concentrations of policy elements to avoid backbone congestion and to speed policy updates to the components.

COPS

COPS is an emerging Internet standard for interactions between a policy client (the Policy Enforcement Point [PEP]) and a policy server (the Policy Decision Point [PDP]). It supports both models for distributing policy information. The pull model is used when the PEP initiates requests, updates, and deletes to the PDP, which returns a decision for each request. The push model is also available, enabling the PDP to push new information to a PEP, or delete old information.

COPS uses reliable communication between the PEP and the PDP. Because secured policy exchanges are essential, COPS uses message-level security for message integrity, authentication, and replay protection. Other security mechanisms, such as IPSec, can also be used.

Messages between the PDP and PEP contain self-identifying objects relating to each request or response. Examples include client type, interfaces, errors, decisions, and timers.

COPS offers higher reliability than earlier connectionless protocols, such as SNMP. It also imposes the burden on the PEP and PDP to keep the connection active with heartbeat traffic that also adds more network loading.

Cisco provides special engines that use Network Based Application Recognition (NBAR) to inspect each incoming packet and classify it according to the specified policy. Enforcers are also built into most Cisco devices.

QPM has all the components for a policy-based management system oriented toward element-management policies. It has Cisco devices with the capabilities to classify traffic and apply a range of enforcement policies. Figure 7-1 shows an example of the use of QPM to handle an SLA. Among the SLA specifications are descriptions of service classes, services, and metrics.

Figure 7-1. Using QPM and an SLA to Configure a Policy System

Under the SLA in Figure 7-1, there are two branches: the left branch sets up the classification and enforcement functions while the right branch handles instrumentation. With the left branch, the SLA defines the service classes, such as streaming, interactive, or transactional, that are covered by the agreement. The next stage is defining the membership of each service or application and defining which service class applies.

This information is then enhanced with the definition of the relative priorities for each service class. Applications are identified by criteria such as the information in the communications packet. This information is used to configure the NBAR functional module so that it recognizes each application and appends the appropriate information to each packet it processes.

Information can also be loaded into other devices that act as enforcers for the policy system. For example, edge devices can have rate and admission control functions that are activated for each type of application/service flow.

The metrics are handled on the right branch of Figure 7-1. They are specified for each class and service in the SLA. A solution such as QPM takes these metrics and configures the instrumentation system accordingly. Instrumentation can be found in devices, desktops, servers, and stand-alone collectors and aggregators. Both passive and active instrumentation are configured to capture the metrics and report them to a management server.

Some of these steps require some manual translation today. Future SLAs can be constructed as XML documents, providing an electronic input for QPM. More of the process can be automated, adding more value by reducing staff labor and errors.

Orchestream Service Activator

In contrast to QPM, MetaSolv Software's Orchestream Service Activator is positioned as a multi-vendor policy solution for configuring a larger variety of elements. A brief overview shows similarities to QPM in many aspects.

The Service Activator system consists of a central server and a set of distributed agents that uses vendor-specific device drivers to control a number of network elements. Policy information is distributed with COPS or with SNMP.

Device drivers convert requests for services and policies into device- and vendor-specific configurations without needing scripts or templates. For example, Service Activator automatically determines the following:

• Which devices are affected by the policies

• Which protocol is used when updating device configurations

• The exact commands that are issued to the device

This frees administrators to concentrate on more important management tasks. Orchestream Service Activator further simplifies the process with a discovery function that enables it to create a topology model with information about the capabilities of each device.

Constant monitoring tracks any unauthorized configuration changes, and Service Activator restores the appropriate policy information.