9.3 Policy-based management

In recent years the scale and complexity of internetworks and the huge amount of control information required to configure and maintain them have led to the requirement for an overall policy-based management architecture. This architecture must integrate many different facets of network operations, provide a consistent repository for control data, and provide timely responses to policy queries. Policy should be defined and controlled centrally and then translated automatically into specific system configuration parameters, ready for download to network systems and devices. The intention is to abstract much of the complexity of individual device configuration and operating systems from the network planner, so that more time can be spent optimizing the design, rather than on learning the intricacies of how a dozen or so different products work. Policy-based management is intended to significantly reduce the time, effort, and cost associated with deploying large internetworks and reduce the burden of maintenance and troubleshooting by ensuring that all systems in the network behave consistently. It turns out that there are several important areas of network operations that benefit from an overall policy model, including the following:

Quality of service (e.g., 802.1p, differentiated services, ToS)
Network security and VPN management (e.g., firewall policy, IPSec VPN policy, ACL management)
Traffic engineering and bandwidth allocation (e.g., routing policy, ACL management)
Routing policy [55]
Address management (e.g., DHCP policy, NAT policy)
Storage management (e.g., HSM policy)

Policy management characterizes the response of the network as a whole to specific traffic behavior, user behavior, application behavior, and system behavior. Policy should reflect the needs of an organization as whole, individual groups within the organization, and the way that an organization interfaces with the outside world. Policy management utilizes other facets of traditional management systems, such as configuration management, to effect those changes in behavior and be sufficiently granular to effect changes based on time of day and day of week.

9.3.1 Policy defined

Policy is a set of rules associated with services (such as security, bandwidth, etc.), where these rules define the criteria for obtaining those services. A rule comprises one or more conditions and actions, typically represented as a tuple:

IF <conditions> THEN <actions>

A rule, therefore, describes the conditions that must be met before the specified actions can be taken. For example, a high-level policy rule might be:

Rule: On the backbone, SAP traffic flows from HQ should get higher priority than those from remote offices.

We can break this down as:

CONDITION: If the traffic flows are identified as SAP and originate from the HQ network.
ACTION: Assign higher priority to these flows.

In practice policies can be complex and numerous; policies can be defined recursively, which means that a policy could contain other policies. A policy group is an aggregation of policy rules or an aggregation of policy groups.

Policy management services must be able to identify and resolve policy conflicts and must be flexible enough to support both static and dynamic operations (i.e., the ability to enforce policy rules loaded at system startup and the ability to enforce policy rules based on events). The IETF Policy Framework working group is addressing the need for a policy framework definition language, a policy architecture model, and policy terminology. Although much of the initial focus is on QoS policy, this work is generic in scope. The policy metamodel links high-level business requirements (e.g., such as those specified in an SLA), to low-level device implementation mechanisms (such as rules for access control or the configuration of queues to handle a particular service class). In Figure 9.13, master policy may reside on a dedicated policy server or a directory server (in some implementations it may even reside on the management console). Policy-enabled devices such as switches and routers typically cache policy locally to reduce latency in policy queries. Legacy devices must be configured directly from a standalone policy server. For high-availability applications a redundant policy server may be available.

click to expand
Figure 9.13: Policy management deployment.

9.3.2 Components of a policy management system

The basic components of a policy management system are as follows:

Policy console—to enable GUI or command-line access to policy functions (such as setting QoS policies)
Policy servers—to hold policy data at different sites
Policy repository—typically a Directory Service (LDAP) or RDBMS (such as Oracle or SQL Server) to provide centralized storage for policy profiles
Policy distribution protocols—used to download policy (SNMP, TFTP, COPS, CLI, etc.)

There are other so-called policy peripherals, which may be offered with a policy management system, including the following:

Policy proxy agents—to implement policies in network devices (e.g., a policy-enabled switch)
Integrated DHCP or WINS/NIS servers—for address allocation and management
Integrated security servers—for authentication or certificate management
Baselining tools—for checking that policy is effective by first characterizing the network
RMON probes—for remote performance monitoring

Policy console

Policy rules are created, edited, and viewed at the central policy console, with changes sent to the policy repository. The policy console is also responsible for other functions, such as checking for possible conflicts between policy rules. The interface is typically an object-oriented GUI (although some vendors have implemented a text-oriented CLI). The user typically creates or modifies a set of policy profiles that characterize the behavior of systems. For example:

The default security policy could be defined for a class of device called PerimeterFirewalls.
The default QoS policy could be defined for a class of device called EnterpriseRouters. This would define how these devices should treat different types of traffic in order to meet specified QoS requirements.
The default routing policy could be defined for a class of device called BackboneRouters.

Policy repository

A policy repository is a dedicated server that is responsible for policy storage and retrieval. Policy must be centralized for consistency, and in large, multi-vendor internetworks it is essential to use a standardized vendor-independent format for storing policy profiles. The IETF Policy Framework working group defines a core information model and schema [56]. The policy core schema is based on LDAP [57] and comprises 13 classes, including policyGroup, policyRule, policyCondition, and policyAction. There must be standardized mechanisms to distribute policy information to clients; currently this can take several forms, as follows:

A centralized Directory Server, such as an LDAP Server, Microsoft's Active Directory Service (ADS), or Novell's Novell Directory Service (NDS)
A standard Relational Database Management System (RDBMS), such as SQL Server, Oracle, or Sybase
A highly optimized proprietary database format

In practice there are examples of all three types of implementation in commercial products, including hybrid combinations; the prime concerns for implementers are performance, scalability, and flexibility. For example, policy rules for different service levels could be stored in directories as LDAP schema and be downloaded to devices that implement policy (such as hosts, routers, firewalls, policy servers, or proxies) via LDAP. The Directory-Enabled Networks (DEN) initiative is also of great interest for policy management systems, so much so that the DEN standards have been incorporated into Distributed Management Task Force (DMTF) and Common Information Model (CIM).

Policy server

The policy server (referred to as the Policy Decision Point [PDP]) makes decisions based on the policy rules it retrieves from the policy repository. The policy server can also retrieve information from other entities (such as authentication server or SNMP agents). The policy server can also translate abstract rules into low-level vendor-specific rules. The policy server is responsible for communicating policy to client systems (such as switches, routers, and firewalls). One policy server can manage multiple policy clients in the same administrative domain.

Policy servers can be implemented as standalone systems (e.g., as software running on a Windows NT, Solaris, or UNIX platform), or they can be embedded within networking systems (such as switches and routers). To improve scalability, some vendors take a two-tiered approach (rather like the Manager-of-Managers concept introduced earlier) that uses a server manager to download policies to a number of standalone servers. For high-availability applications, systems may be deployed with redundant policy servers. To improve performance policy may be cached inside policy-enabled devices such as switches and routers. This operates rather like caching systems, except that the content of interest here is policy. Any requests for policy not in the cache must be forwarded to a policy server, and cached policy must be synchronized regularly to avoid inconsistencies. If the policy server is also embedded in the same system, the policy request will be resolved locally, and the embedded policy server must fetch policy from the central policy repository.

Policy clients

Policy clients (referred to as the Policy Enforcement Points [PEPs]) represent the physical execution point for policies (e.g., a router, switch, or firewall). As indicated previously, the separation of PDP and PEP functions is a logical distinction; both functions are often implemented in the same network device. Once policy has been communicated and accepted, it is up to the client device to enforce policy according to its individual functional capabilities. For example, in response to a QoS policy, a router could use internal scheduling mechanisms and admission control features to meet policy requirements. Note that the main prioritization schemes associated with policy manipulation in commercial products today include 802.1p, Differentiated Services, and ToS.

Policy distribution

Policy needs to be fetched from the central policy repository and held on policy servers. Policy also needs to be communicated between policy servers and policy clients (such as a router or switch). This requires some form of messaging protocol. Unfortunately, there is a huge installed base of equipment that is not policy enabled, so there is no universally accepted way to achieve this.

Most vendors today use SNMP and LDAP to distribute policy to clients. SNMP is not viewed as a long-term solution due to its weak security, connectionless deployment, and its inefficiency for bulk data transfers. LDAP also has similar limitations; however, only embedded-server vendors tend to use it for fetching policy profiles from the central policy repository (i.e., the less time-critical part of policy distribution). Several vendors have reverse engineered Cisco's IOS Command-Line Interface (CLI), enabling configuration commands to be fed directly into Cisco hardware over Telnet. Vendors are also showing increased interest in a relatively new IETF protocol called Common Open Policy Service (COPS), developed initially for QoS policy distribution between policy servers and policy clients and optimized for high performance. We will briefly review COPS here.

Common Open Policy Service (COPS) protocol

Common Open Policy Service (COPS) is a simple client/server query-response protocol. It was initially designed to support policy control over QoS signaling protocols, although the model is extensible so that other policy clients can be supported in the future. COPS requires that at least one policy server exists in each administrative domain; it is used to exchange policy information between the policy server (PDP) and its clients (PEPs). The COPS protocol is reliable, utilizing a single persistent TCP connection between the PEP and a remote PDP (the PDP listens on a well-known TCP port, 3288). All COPS messages include a common eight-byte header, incorporating a one-byte OpCode. Current operations include the following:

Request (REQ)
Decision (DEC)
Report State (RPT)
Delete Request State (DRQ)
Synchronize State Req (SSQ)
Client-Open (OPN)
Client-Accept (CAT)
Client-Close (CC)
Keep-Alive (KA)
Synchronize Complete (SSC)

COPS makes no assumptions about the methods used by the policy server; all it requires is that the server returns decisions to policy requests. The basic model for interaction between a policy server and its clients is compatible with the framework document for policy-based admission control [58]. For further information on COPS, the interested reader is referred to [59]. Reference [60] discusses COPS applications with RSVP.

9.3.3 Design and implementation issues

While all of this sounds great in theory, unfortunately, given the major discontinuities in multivendor networks, the task of integrating all of this functionality into a seamless architecture is far from easy. It is important to note that the physical implementation of the policy server can significantly affect scalability, cost, and performance, as follows:

Standalone servers reduce the number of policy profiles, since with the embedded approach each client maintains its own profile. However, standalone servers have finite resources and can distribute policy to only a finite number of network devices before they become a bottleneck. The number of devices capable of being managed by a policy server varies widely, with estimates ranging between 5 and 500. A two-tier architecture is advisable for very large networks. Another problem with standalone managers is that they are often run on general-purpose platforms. These platforms may not be sufficiently rugged for nonstop operations. During outages policy may be unavailable even though the client switch or router continues to operate.
Embedded servers are claimed to scale better and provide higher availability. With the embedded approach each switch or router is loaded with its own policy server, and client-to-server overheads are greatly reduced and do not impact on the network. Embedded servers do, however, require more resources (processor and memory), which increase the platform price. This could increase the cost of a design significantly if many hundreds of systems are involved.

Standalone managers are useful in the interim, since they enable network planners to apply policy to legacy networking equipment (e.g., routers and LAN switches that either cannot be upgraded or do not have sufficient memory or processing capacity to run policy code). For the foreseeable future, policy managers will require a mixture of standard and proprietary methods to work in large, multivendor networks. There is also a substantial installed base of legacy equipment that does not support new standards, such as Differentiated Services and COPS, and possibly never will.

For the interested reader, [61] provides some excellent background information on policy, the applications of directories, and middleware in policy-based management.

Vendors

Examples of vendors of policy managers and embedded policy servers include Orchestream, Xedia, Check Point, Cabletron, Cisco, IBM, HP/ Intel, Lucent, Extreme Networks, Fore Systems, 3Com, Xylan, Aponet, Class Data Systems, Packeteer, IP Highway, and Newbridge Networks.