Policy Working Group Ken Owens Internet Draft Vijay Jadhwani Expiration Date: September 2000 Tellabs Operations, Inc. Hugh Mahon Hewlett-Packard March 2000 Policy Management Scalability draft-owens-policy-scalability-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract Policy Management System (PMS) scalability and resource utilization are important aspects of Policy. Policy management requires centralized management. Scalability factors into the requirements since a centralized management system is not practical if it doesn't scale well to fit the management needs of the environment. The objectives for providing PMS scalability and resource utilization are provided in this draft. Owens et. al. Expires September 2000 1 Internet Draft draft-owens-policy-scalability-00.txt March, 2000 Table of Contents Page Abstract 1 1. Introduction 2 2. Organization 2 2.1 Policy Storage 3 2.2 Policy Partitioning 3 2.3 Policy Topology 6 3. Policy Resource Allocation 7 3.1 Workload Balancing 7 4. Database Management 8 4.1 Logging 8 4.2 Statistics 8 4.3 Policy Database Query Support 8 4.4 Policy Database Backup and Restoration 8 5. Security Considerations 8 6. Acknowledgements 8 7. References 8 8. AuthorsÆ Addresses 9 1. Introduction Key requirements for the Policy Management System (PMS) are scalability, performance, and good resource utilization. Policy management requires centralized management. Scalability factors into the requirements since a centralized management system is not practical if it doesn't scale well to fit the management needs of the environment. The objectives for providing PMS scalability include: ¸ Enforcing policies at numerous locations ¸ Managing large numbers of nodes at which policy is deployed ¸ Enabling policy management across multiple domains Achieving these objectives may be accomplished by allowing ¸ Organizational database functionality ¸ Hierarchical policy management 2. Organization Policy data must be organized in a manner that will not constrain the storage of policies or the topology of the PMS or network. The objectives for policy organization include: ¸ Providing a manageable partitioning of policy rules and schemas ¸ Nesting of policy schemas to represent a hierarchy of policies Owens et. al. Expires September 2000 2 Internet Draft draft-owens-policy-scalability-00.txt March, 2000 ¸ Providing secondary policy servers to scale PMS deployment to support a large number of agents ¸ Supporting fault tolerance in the PMS architecture to allow consoles, agents, and secondary servers to fail over to back-up servers Achieving these objectives may be accomplished by allowing ¸ Creation of a partitioning of policy conditions, actions, and groups in a manner that aids in the development and management of a hierarchy of policy rules and schemas ¸ Designing a manageable hierarchy of Policy Repositories organized in a manner that aids in the identification, location, and enforcement of Policy Actions ¸ Support of hierarchical policy based management domains that support organizational, political, or geographic boundaries ¸ Enhance repository and efficient messaging services between repositories to boost performance 2.1 Policy Storage The amount of policy data being managed could be as large as 5,000 policies in a repository. The organization of policy data should be based on the partitioning of the policy data and the hierarchical design of the policy network. The exact partitioning of policy data and the hierarchical design of the policy network are outside the scope of this draft. However, to ensure scalability, policy data manageability, and interoperability of the PMS systems, the partitioning of policy data and the hierarchical design of the policy network are critical design decisions. In this draft we present considerations for the organizations of policy data based on the partitioning of the policy data and the hierarchical design of the policy network. Whatever the partitioning of the policy data or the hierarchical design of the policy network, both aspects are critical to enable scalability and maintainability of policy. Policy Maintainability is a key consideration due to the ability to query/search for policies in a database of 5,000 policies. Determining a way to organize the policy information and store the policy information based on the partitioning and the PMS topology to enable policy scalability and maintainability. 2.2 Policy Partitioning In basic terminology, policy information consists of conditions and corresponding actions. In Policy, conditions and actions are called Policy Schemas. Weather these are standalone conditions and actions or groups of conditions and actions is an implementation detail. These conditions and actions could either be part of a standardized schema Owens et. al. Expires September 2000 3 Internet Draft draft-owens-policy-scalability-00.txt March, 2000 (for example QoS Schema) or a proprietary schema (for example Company X Admission Control Schema). The considerations for defining standardized Policy Schema's that are contained in the PMS are provided in this section. The Policy Framework Core Information Model -- Version 1 Specification [4] defines the following policy rules: ¸ Motivational Policies: Targeted at whether or how a policy's goal is accomplished. Configuration and Usage Policies are specific kinds of Motivational Policies. ¸ Configuration Policies: Define the default (or generic) setup of a managed entity (for example, a network service). ¸ Installation Policies: Define what can and cannot be put on a system or component, as well as the configuration of the mechanisms that perform the install. Installation policies typically represent specific administrative permissions, and can also represent dependencies between different components (e.g., to complete the installation of component, components B and C must be previously successfully installed or uninstalled). ¸ Error and Event Policies: For example, if a device fails between 8am and 9pm, call the system administrator, otherwise call the Help Desk. ¸ Usage Policies: Control the selection and configuration of entities based on specific "usage" data. Configuration Policies can be modified or simply re-applied by Usage Policies. Examples of Usage Policies include upgrading network forwarding services after a user is verified to be a member of a "gold" service group, or reconfiguring a printer to be able to handle the next job in its queue. ¸ Security Policies: Deal with verifying that the client is actually who the client purports to be, permitting or denying access to resources, selecting and applying appropriate authentication mechanisms, and performing accounting and auditing of resources. ¸ Service Policies: Characterize network and other services (not use them). For example, all wide-area backbone interfaces shall use a specific type of queuing. Service policies describe services available in the network. Usage policies describe the particular binding of a client of the network to services available in the network. The authors agree with the partition described in [4] and plan to abstract from this partitioning. Instead of policy rules, the authors like to use policy schemas. The Policy Schema's could be partitioned into the following schemas Policy Management Schemas (PMgtS), Policy Directory Schemas (PDS), and Policy Enforcement Schemas (PES). Note: All Policy information at this level will conform to this partitioning regardless of whether it is proprietary or not. Owens et. al. Expires September 2000 4 Internet Draft draft-owens-policy-scalability-00.txt March, 2000 The PMgtS contains the conditions and actions for configuration and monitoring of performance, detection of faults, accounting, security, and distribution of policies. For example, the motivational, configuration, error and event, and security policies defined in [4]. The PDS contains the conditions and actions for defining policy rules and groups, for defining conditions and actions, for defining user and network resources, and for defining global setting of thresholds and weights. For example, Usage and service policies defined in [4]. The PES contains the conditions and actions for defining local setting of thresholds and weights, enforcement of performance parameters (I.e. QoS parameters), enforcement of attributes and constraints associated with the user resources, and enforcement of the PMgtS and PES. For example, the installation, usage, and service policies defined in [4]. The PMS partitioning is displayed below: +----------------------+ | Policy Mgmt System | +----------------------+ | | V +----------------------+ | Policy Schemas | +----------------------+ | | +---------------------+----+----------------------+ | | | +---------------+ +----------------------+ +------------------+ |Pol Mgmt Schema| | Pol Directory Schema | | Pol Enforcement | +---------------+ +----------------------+ +------------------+ | | | | | | V V V +---------------+ +--------------------+ +------------------+ | Configuration | | Policy Rules | | Local Settings | | Performance | | Policy Groups | | PmgtS and PDS | | Fault | | Policy Conditions | | Parameter | | Accounting | | Policy Actions | | Enforcement | | Security | | Network Resources | +------------------+ | Distribution | | Local Resources | +---------------+ | Global Settings | +--------------------+ Owens et. al. Expires September 2000 5 Internet Draft draft-owens-policy-scalability-00.txt March, 2000 2.3 Policy Topology A policy network uses policy to control which state a policy device should be in or is allowed to be in at any given time. Policy is applied using a set of policy rules. Each policy rule consists of a set of conditions and a corresponding set of actions. Policy rules may be aggregated into policy groups called schemas. These schemas may then be nested, to represent a hierarchy of policies. The key requirement for policy topology is to realize how many concurrent reads and write access requests there are in each database. This is the basic information that is needed to design the database topology. An assumption for policy databases are that they have replicas on multiple servers and a low degree of replication is needed because data changes only occasionally. Two considerations that are key in deciding the policy database topology are: ¸ Restrict the number of resources for whom entries will be made in the policy database ¸ Restrict the number of concurrent transactions The hierarchical design of the policy network basically has a master or lead node (processor). This node oversees everything that occurs on the network. The master node may delegate some amount of the control of the network to subordinate nodes, which may either perform the control or again delegate. At the bottom levels of this network are the policy targets. In order for the policy targets to communicate over the network that must follow the directions of the controlling nodes. Define master responsibilities The PMS topology consists of a two-tier hierarchy, Global and Local. The Global tier contains the policy repositories and policy consumers' information that is global to the PMS and the Local tier contains the policy repositories and policy targets information that the local elements contain. Each tier could consist of multiple levels of hierarchy. An example of a PMS topology is shown below. +--------------------------+ | Global PMS (GPMS) Master | | (Global canonical store) | +--------------------------+ | | +-----------+-----------+---------------+ | | | | | | V V V +-------+ +-------+ +-------+ Owens et. al. Expires September 2000 6 Internet Draft draft-owens-policy-scalability-00.txt March, 2000 | GPMS | | GPMS | ... | GPMS | +-------+ +-------+ +-------+ | V +-------------------------+ | Local PMS (LPMS) Master | +-------------------------+ | | +--------+---------+-----------------+ | | | | | | V V V +-----------+ +-----------+ +-----------+ | LPMS | | LPMS | ... | LPMS | +-----------+ +-----------+ +-----------+ | | +---------+-----+-------------+ | | | | | | V V V +---------+ +---------+ +---------+ | Policy | | Policy | ... | Policy | | Target | | Target | | Target | +---------+ +---------+ +---------+ 3. Policy Resource Allocation Before creating policy databases and replicas, consider how frequently users access the database and evaluate the need for data availability. For heavily used databases, it may be desirable create more than one replica and locate these on the most reliable servers In general, the more replicas of a database, the more accessible the data. Creating too many replicas, however, can add unnecessary maintenance overhead and therefore impact the performance. As part of planning for the PMS implementation, the planner or designer must balance user requirements for data availability and server workload. 3.1 Workload balancing A key aspect of scalability is the ability to distribute the workload across a PMS in a way that maximizes the resource utilization. To measure workload, the PMS monitors its own workload. This is measured by the PMS monitoring the average response time of a representative set of server operations initiated by the PDP. The PMS master also polls all the other servers in the hierarchy to determine their workload. Owens et. al. Expires September 2000 7 Internet Draft draft-owens-policy-scalability-00.txt March, 2000 4. Database Management 4.1 Logging All PMS entities SHALL maintain a log of all events. These logs SHOULD be stored in nonvolatile memory for 24 hours in configurable units of 1 or 8 hour intervals. There should be a function to auto archive the PMS entries for 7 days. 4.2 Statistics The PMS's SHALL provide statistics commands at the console and store statistics reports in the database. These reports SHOULD be stored in nonvolatile memory for 24 hours in configurable units of 1 or 8 hour intervals. There should be a function to auto archive the PMS statistics reports for 7 days. 4.3 Policy Database Query Support The PMS SHALL support database queries within the context of policy configuration, management, and definition. The frequency with which database queries need to be supported is an open issue. 4.4 Policy Database Backup and Restoration Memory backup and restoration features enable an entity to recover from the loss of data. The PMS SHALL provide automatic memory backup capabilities to copy working data into nonvolatile memory. The PMS SHALL have at least one nonvolatile memory for backup purposes. 5. Security Considerations This document raises no new security issues for any of the protocols discussed herein. 6. Acknowledgements 7. References 1. Mahon, H., Bernet, Y., Herzog, S., and Schnizlein,J. "Requirements for a Policy Management System", Work in Progress, Internet Draft , September, 2000. 2. Stevens, M., Weiss, W., Mahon, H., Moore, B., Strassner, J., Walters, G., Westerinen, A., Wheller, J., " QoS Policy Framework Architecture", Owens et. al. Expires September 2000 8 Internet Draft draft-owens-policy-scalability-00.txt March, 2000 Work in Progress, Internet Draft , September 1999. 3. Reichmeyer, F., Stevens, M., "A Unified Terminology for Policy Based Networking", Work in Progress, Internet Draft , October 2000. 4. Moore, B., Ellesson, E., Strassner, J., " Policy Framework Core Information Model -- Version 1 Specification", Work in Progress, Internet Draft , January, 2000. 8. AuthorsÆ Addresses Ken Owens Vijay Jadhwani Tellabs Operations, Inc. Tellabs Operations, Inc. 1106 Fourth Street 4951 Indiana Avenue St. Louis, MO 63126 Lisle, IL 60532 Phone: +1 314 918 1579 Phone: +1 630 378 7129 Email: Ken.Owens@tellabs.com Email: Vijay.Jadhwani@tellabs.com Hugh Mahon Hewlett-Packard Co. 3404 East Harmony Road, MS A2 Fort Collins, CO 80528-9599 Phone: +1 970 898 2487 EMail: hugh_mahon@hp.com Full Copyright Statement "Copyright (C) The Internet Society (March 2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the Owens et. al. Expires September 2000 9 Internet Draft draft-owens-policy-scalability-00.txt March, 2000 copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Owens et. al. Expires September 2000 10 Internet Draft draft-owens-policy-scalability-00.txt March, 2000