Network Computingwww.networkcomputing.com

One of the best reasons to invest in policy-based management is that it frees up your experts. They can create policy-configuration applications that can be used by less experienced IS staff. An architecture for an SNMP-based policy-configuration application and its interaction with managed elements or agents is shown in "An SNMP-Enabled Policy System," on page 102. Setting up policy-based management involves four major steps:

1. Inputs to the management system are made. The system can be driven from other business systems and given policies at high levels of abstraction, such as assigning a certain amount of bandwidth to customers that have paid a premium. Through this interface or other expert CLI-like alternatives, network engineers can put into the system definitions of what good means. This is where the experts can input differences among vendors, functions, operating environments and so on. Without the ability to have policies effectively provide for such differences, policy management is not likely to be achieved.

2. In the data-mapping part of the policy system, the high-level business policies are mapped to specific expressions for distribution to the managed elements in the network. Several components get mapped:

   >>  Roles -- These attributes will be assigned to elements such as interfaces in the network. A specific security policy might be applied only to interfaces that are exposed to external customers. In this case, the policy might be to disallow certain management operations or accept file-transfer traffic to specific networks.

   >>  Schedules -- Policies are subparts of a larger operational strategy. During business hours, one set of utilization parameters might apply; during nonbusiness hours, another might apply. The snmpconf work enables managed elements to execute schedules coordinated by the manager. In cases where the network elements have limited resources, the schedule changes can be sent down to the managed elements as needed.

   >>  Filters -- These components are used to determine which parts of the system are to have the policy applied. In some cases, roles will have been applied to interfaces. In other cases, it may be possible to take advantage of the large amount of SNMP-based instrumentation available and select items by MIB attribute, such as interface speed or operational status.

   >>  Actions -- The managed system executes these commands on the elements that are selected for a policy based on the filter. In the simplest case, this might be to turn off an interface or to set dozens of default values on hundreds of elements. This is where you can realize enormous efficiency gains over a standard CLI- or traditional SNMP-based system.

   With just one or two simple set operations, the roles, filters, actions and schedules can be downloaded to a system for local execution.

3. All the information -- such as which systems are in the network, security details, system status, utilization, and capabilities of the managed system -- comes together in this step. Since SNMP has easy access to much of this information, it can make far better policy decisions than other systems. Without this, systems have to manipulate SNMP or use other information to derive utilization, state and so on. For example, if a management system has collected performance statistics over time, it might check this data before allowing configuration operations that, while correct, could cause problems in one or two days if the configured systems were at or near capacity. The new configuration could exceed available capacity during a peak demand time.

4. The last step involves the managed elements themselves. "MIB Module Structure" (left) shows a traditional view of a manager and many managed systems. The snmpconf architecture is not limited to this deployment paradigm. All five functions can be included in a single system or distributed among managers and managed systems.

MIB Module Structure Click here to enlarge

The central focus of the snmpconf work is the policy MIB module. It contains the tables that are used to hold the information sent down to it from the management applications. These tables have several functions:

• They assign attributes to system elements, such as interfaces. The policy agent uses this information to decide to which elements it should apply the policy.

• They map the selected elements to specific policies, enabling the association of utilization and faults with policies; this is crucial to making good policy decisions.

• They show the system's types of elements -- such as Ethernet interfaces and Web servers -- and their capabilities. With this information, a manager can reduce the likelihood of sending policies to a system that cannot implement them.

• They control the time and the order in which policies are evaluated on the system. This gives operators the ability to have one policy override another based on a user-defined precedence value.

  At the heart of the policy module are two objects, pmPolicyFilter and pmPolicyAction, which contain expressions for the filter. The pmPolicyAction contains an expression with the commands the system will perform on elements that match the filter expression. The expression language will be familiar to those experienced in PERL, since it is a selected subset of PERL and adjusted for this environment.

  The policy module can be thought of as the brains of the managed system, and the mechanism-, implementation- and instance-specific MIB modules are the arms and legs. The other MIB modules carry out the instructions of the pmPolicyAction object, which uses local mechanisms for efficient setting of MIB objects.

  The snmpconf working group does not require the creation of mechanism- or implementation-specific modules for a policy-enabled system to function. The policy module can act directly on instance-specific MIB modules, the only kind that currently exist. The snmpconf working group is creating a mechanism-specific MIB module for DiffServ, and others are under discussion.

  One purpose of these higher-level modules is to make it easier to write pmPolicyAction objects. The mechanism- and implementation-specific MIB modules carry the defaults that are applied to the instance-specific MIB objects. These mechanism- and implementation-specific objects can be set by any SNMP-based management application. Mechanism- and implementation-specific objects and their values need not be contained in the pmPolicyAction, only the pointer to the rows of the tables that contain these defaults. This flexibility allows for future expansion of higher-level modules while preserving current investment in implementations and making the incremental addition of policy capabilities possible.

  These modules also make visible the defaults stamped on every instance selected by the pmPolicyFilter. This facility can serve as an important debugging capability in the future.

  To appreciate this system's gain in efficiency, imagine a small network with 20 routers, each of which has 10 interfaces. If 10 parameters are to be set in common for each interface, that could translate into as many as 100 commands for each router, or 2,000 for this one configuration operation in this small network. Using the snmpconf policy-based approach, you could reduce this number to as few as one SNMP set operation for each router. This set would contain the information necessary to select the interfaces to which you would apply the templates, with details about what the default values should be.

  As IP networks become more complex, basic SNMP counter and per-box management control based on character interfaces to one box at a time will no longer scale. The inclusion of the levels of abstraction in new systems addresses many of the concerns people have about much of the existing SNMP-based management software. It makes third-party development of new features less costly, because some of the details of the variability from one system to the next will not be visible.

  This work also offers an excellent platform for a new generation of service-level monitoring and real-time fault and performance tools that can use the network and other resources far more efficiently. Data will be moved at a higher level of abstraction more often, resulting in far less data.

  Let's face it -- at many sites, systems-management packages are nothing but shelfware. The snmpconf work has great potential for ending this situation and moving SNMP systems-management software away from being a simple checklist item that no one really cares about to being truly useful. If the users support the standard, the vendors will come. For more detail on the snmpconf working group, see www.ietf.org/html.charters/snmpconf-charter.html.

  Jon Saperia, co-chair of the IETF SNMP Configuration Working Group, is co-author of several recent Internet drafts in the area of policy and configuration management. He is also the founder of JDS Consulting. Send your comments on this article to him at saperia@jdscons.com.