- Business Environments
- High-Level Policies
- Low-Level Policies
- The Policy Management Tool
The Policy Management Tool
As must be apparent to you at this stage, the policies described in the section "High-Level Policies" and the policies described in the section "Low-Level Policies" of this chapter have very little in common. There exists a large gap between the business needs of an enterprise/ISP/ASP and the technologies that are required to satisfy them. Clearly you need to develop solutions that bridge the gap. One possible way to bridge this gap is by exploiting the IETF policy architecture and the policy definition framework.
Note - The policy definition framework is being done jointly within IETF as well as DMTF. Because it is network-centric, I will refer to it as the IETF architecture. The IETF does the bulk of the architecture, while the DMTF does the bulk of schema definition.
To recap the IETF policy architecture introduced in Chapter 1, it consists of four components: a policy management tool, a policy enforcement point (or the policy consumer), a policy decision point (or the policy target), and a policy server. The management tool populates the policy server, the policy decision point takes policies from the server to determine the configuration and interprets it, and the policy enforcement point enforces that decision.
One of the key components in the policy architecture (and the various scenarios just described) is the policy management tool. The policy management tool is the component that translates the specified requirements in terms of the business needs of the deployers into the detailed specifications needed for technology deployment. This section describes how such a policy management tool can be constructed. The rest of this book describes the various components of such a management tool in much more detail.
The purpose of the policy management tool is to take a high-level representation of the business goals or desired functions within the network and translate them into the appropriate configuration of the various devices in the network. The input is called the high-level policies, and the output of the tool is the low-level policies in the network. Such a tool is composed of the four basic functions shown in Figure 3.6:
){kind=link}
The graphical user interface is the means by which an administrator can input the high-level policies within the network. These policies are the ones that need to be enforced in the network, and the configuration of the network must be made conformant to these high-level policies.
The resource discovery component determines the topology of the network and the users and applications that are operational in the network. In order to generate the configuration for the various devices in the network, the capabilities and topology of the network must be known. For any moderately sized networked system, such topology and capabilities must be discovered automatically.
The policy transformation logic component is responsible for ensuring that the high-level policies that are specified by the network administrator are mutually consistent, correct, and feasible with the existing capacity and topology of the network. It also translates the high-level policies into low-level policies that can be distributed to the different devices in the network.
The configuration distributor is responsible for ensuring that the low-level policies are distributed to the various devices in the network. The distribution of the configuration can be done in a variety of ways, such as storing them in a repository from where different devices can retrieve them.
Figure 3.6
Policy Management Tool
In addition to these components, there needs to be an additional component that is responsible for monitoring the network state and ensuring that the policies are being satisfied by the various devices in the network. For performance SLA, such monitors take the form of the different SLA monitoring tools that are available in the marketplace. For security policies, such monitors take the form of different "watcher" products that are responsible for detecting intrusion and other abnormal behaviors in the network traffic.
The next sections discuss each of the modules in turn.
The Graphical User Interface Module
The graphical user interface module is the component of the policy tool that provides the look and feel of the policy management tool to the end-user. Its purpose is to allow an administrator to enter the high-level policies to the management system. The user interface is largely responsible for making the task of entering policy information simpler. The input from the user is generated into an internal representation of the high-level policies that are to be processed by the policy validation module.
The design of such a user interface must take into account the factors that affect the experience a user would have. In particular, the tool must provide appropriate help screens and useful diagnostics messages when exception conditions are encountered in the tool.
Two common ways of providing the user interface module are via a command-line interface or via a graphical user interface. The command-line interface is preferable when the management tool needs to interface with other automated programs. The graphical user interface is useful to interface with a human administrator. With the increasing emphasis on Web-oriented management, the user interface (in many instances) is implemented as a program that can be accessed via a browser. One way to achieve this goal is to implement the user interface as a Java applet. Other methods include creation of specific Web pages and server-side programs that let a user input the desired high-level policies.
The user interface is a very important component of any practical management tool. Many tool developers consider it the most important component of the management tool. However, for the goal of this book, which is to discuss the algorithms and applications of the policy architecture, the user interface module is just a way of obtaining high-level policies. The focus of this book is on processing high-level policies, so more attention is given to the other modules in the management tool. I will not discuss this module further in this book, but I want to reemphasize that this component is the one that can most dramatically affect a successful adoption of any tool for policy management.
The Resource Discovery Module
The first component of the policy management tool that I will discuss in detail in subsequent chapters (Chapter 5) is the resource discovery module. The purpose of this module is to obtain information about the different types of devices that are active within the network, their capabilities, and their characteristics that might affect policy generation and management.
The resource discovery module is needed in any practical policy management tool. The goal of policy management is to simplify the task of system/network administration. If this management must be done, the tool needs to maintain a current snapshot of the various PEPs and PDPs that are operational within the network. Because it is not possible for any administrator to correctly enter the topology and configuration of any moderately sized network manually, these characteristics must be discovered by the tool automatically.
Several of the resource discovery capabilities are included in many traditional systems management/network management tools. Such resource discovery capabilities include SNMP-based tools to collect network routing and topology information, as well as many inventory tools that can obtain a summary of all the applications that are installed and active on a server or a desktop. When a policy management tool is included as a component within a larger systems management/network management suite, it can leverage the capabilities of the existing tools in the suite.
I will discuss the issue of resource discovery in more detail in the next chapter.
The Policy Transformation Logic Module
The policy transformation logic module validates the information provided in the high-level policies and transforms them into the configuration of devices in the network. The logic furthermore ensures that the policies specified are mutually consistent and that they cover all aspects of interest to the network administrator.
The validation process must incorporate syntactical checks as well as semantic checks. The semantic validation of high-level policies consists of the following three types of checks:
Bounds checks. This validates that the values taken by any parameter in the policy specification are within specific constraints that are determined by the network administrator. For example, a network administrator should be able to specify that all response times in any defined class of service be less than 1000ms.
Relation checks. This validates that the value taken by any two parameters in the policy specification are within constraints that make sense. For example, two attributes of a class of service are response time and the duration over which the response time must be measured. The latter must be larger than the former, and the network administrator should be able to specify how large the response time should be.
Consistency checks. These checks ensure that each traffic flow is mapped onto exactly one service class, and that each service class is properly defined at all the interfaces. These checks are applied in the manner described next.
After validating that high-level policies are consistent and well-formed, the transformation logic translates them into technology specific low-level policies. These low-level policy definitions may be grouped so that only one set of policy information is generated for many boxes that need identical policy information. In general, boxes that play a similar role in the network (for example, access routers as opposed to core routers in network) are likely to have the same set of policy rules guiding their behavior.
Policy validation logic is discussed in more detail in Chapter 6, "Policy Validation and Translation Algorithms."
The Configuration Distributor Module
As soon as the low-level policies (which drive the configuration of different devices) are generated by the policy management tool, they need to be distributed to the different devices within the network. Several means of distributing devices are possible:
Populating a repository. The management tool can write the device configuration rules into a configured repository in the network. Individual servers and routers pull the policy information from the repository, use the policy information to generate their local box configuration and subsequently configure themselves. The preferred approach in IETF policy working group has been to define a LDAP directory with a standardized schema as such a repository. In this approach, the low-level policies are stored at the repository, and the configuration is generated individually by each of the participating devices.
Distributing configuration files. The management tool can translate the low level policies into the configuration files that would be needed at each device and copy them remotely over to the appropriate router and server. This approach works for all types of devices and does not require any specific software to be running at the device. However, the management tool must understand each type of device and the format of configuration file that can be used with it. The distribution mechanism is available in many systems management products. In this approach, the translation from low-level policies to box configuration is done by the management tool.
Command-line interfaces. Most routers permit remote administration by means of a telnet session and specific command lines. The QoS management tool can use automated scripts to specific routers and control the configuration of the router using commands specific to the router. As in the case of configuration files, the QoS management tool must translate the low level policy definition to the configuration scripts, and must understand the scripts that can be used for different types of routers.
Further details and a comparison of the different distribution approaches are discussed in Chapter 7, "Policy Distribution Mechanisms."