INTERNET-DRAFT Fran Reichmeyer Expires: June 2000 IP Highway Document: draft-reichmeyer-polterm-terminology-00.txt Dan Grossman Motorola John Strassner Cisco Matthew Condell BBN Technologies A Common Terminology for Policy Management Thursday, March 09, 2000, 10:52 PM 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 This memo defines a common vocabulary for describing concepts and components related to policy management. It is intended to be used to align terminology and concepts in architecture and framework documents that either address policy management or which specify components and services that are subject to policy management. Reichmeyer, et. al. Expires: September 2000 [Page 1] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 Table of Contents 1. Introduction.....................................................3 2. Terms for Describing Approaches to Policy........................4 2.1. Policy......................................................4 2.2. Policy Management...........................................4 2.3. Policy Administration.......................................4 2.4. Policy Management Area......................................4 2.5. Policy Domain...............................................5 2.6. Meta-policy.................................................5 2.6.1. Introduction..............................................5 2.6.2. Definition................................................6 3. Terms describing Policy-based Network Management Models..........6 3.1. Introduction................................................6 3.2. Outsourced Policy...........................................6 3.3. Provisioned Policy..........................................6 3.4. Interactive Policy..........................................6 4. Policy Abstraction and Scoping...................................7 4.1. Introduction................................................7 4.2. Levels of abstraction.......................................7 4.2.1. Administrator-defined policy..............................7 4.2.2. Device-independent policy.................................8 4.2.3. Device-dependent policy...................................8 4.3. Scoping with Roles..........................................8 5. Terms Concerning Modeling and Representation of Policy...........8 5.1. Information Model...........................................8 5.2. Data Model..................................................9 5.3. Schema......................................................9 5.4. Composition of policies.....................................9 5.4.1. Policy Group..............................................9 5.4.2. Policy Rule...............................................9 5.4.3. Policy Condition..........................................9 5.4.4. Policy Action.............................................9 5.5. Policy Meta-data...........................................10 6. Terms for Describing Policy Functions...........................10 6.1. Introduction...............................................10 6.2. Policy Storage and Retrieval...............................10 6.3. Policy Conversion..........................................10 6.4. Policy Discovery...........................................11 6.5. Policy Resolution..........................................11 6.6. Policy Translation.........................................11 6.7. Policy Control.............................................11 6.7.1. Policy Conflict..........................................11 6.7.2. Policy Conflict Resolution...............................12 6.7.3. Policy Satisfiability....................................12 6.7.4. Policy Feasibility.......................................12 6.8. Policy Decorreltation......................................12 7. Terms for describing Functional Elements and Policy Topologies..12 7.1. Introduction...............................................12 7.2. Policy Administrator.......................................13 7.3. Policy Repository..........................................13 Reichmeyer, et. al. September 2000 [Page 2] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 8. Terms Describing Interactions Between Policy Components.........13 8.1. Access Protocol(s).........................................13 8.2. Policy Requests............................................13 8.3. Policy Decisions...........................................13 8.4. Policy Evaluation..........................................13 8.5. Policy Enforcement.........................................14 8.6. Policy Monitoring..........................................14 8.7. Policy Feedback............................................14 9. Terms describing specific policies..............................14 9.1. Introduction...............................................14 9.2. Terms related to Service Levels............................14 9.2.1. Service Level Agreement (SLA)............................15 9.2.2. Service Level Specification (SLS)........................15 9.3. Terms related to security policies.........................15 10. Security Considerations........................................15 11. Author's Addresses.............................................15 12. References.....................................................16 13. Full Copyright Statement.......................................16 1. Introduction A policy management framework must be realized to provision and configure operational policies related to services and network operations. Performance objectives (such as those addressed by the Intserv and Diffserv frameworks) and security are examples of service aspects which may have policies associated with them. Policies may also apply to network operations, e.g., for managing policies for monitoring. It is highly desirable that such a policy management framework be as common as possible, so as to allow policies for any operational area to be expressed in a uniform manner. This has been the subject of activities in several IETF working groups. This memo defines a common vocabulary for describing concepts and components related to policy management. It does not describe an architecture or framework. Instead, it is intended to be used by various IETF working groups to align their terminology and concepts in architecture and framework documents which either address policy management or which specify components and services that are subject to policy management. This memo is a product of the Policy Terminology (POLTERM) BOF. Reichmeyer, et. al. September 2000 [Page 3] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 2. Terms for Describing Approaches to Policy 2.1. Policy A policy is formally defined as an aggregation of policy rules. Each policy rule is comprised of a set of conditions and a corresponding set of actions. The conditions define when the policy rule is applicable. Once a policy rule is so activated, one or more actions contained by that policy rule may then be executed. These actions are associated with either meeting or not meeting the set of conditions specified in the policy rule. Policies can contain policies. This notion of hierarchy is crucial, as it enables complex policies to be built from a set of simpler policies, thereby simplifying their management. It also enables reuse of policy building blocks (policy rules, conditions and actions). Policy Representation in the Policy Framework WG Specific examples of policy representation can be found in the Policy Framework Architecture [ref] 2.2. Policy Management Policy management is the area of network management that deals with the control of policies within a network, including installing and deleting policy rules at network devices and monitoring network performance related to the installed policy. Policy management is concerned with the overall behavior of the network, i.e. end-to-end or edge-to-edge, and controls policy based on the ability to provide consistent and predictable network services across the entire network, not just on a device-by-device basis. 2.3. Policy Administration Policy administration is the function that creates, modifies and deletes policies, typically based on human input. 2.4. Policy Management Area A Policy Management Area is an area of networking that deploys policy and policy management for the purpose of controlling various aspects of the network, network resources, and access to them by the applications and users of the network. Examples include Security, Diffserv, etc. Distinct Policy Management Areas may be represented by the interfaces presented by policy management systems, but this separation does not extend to the underlying data models and information that will be required to implement policies. Reichmeyer, et. al. September 2000 [Page 4] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 2.5. Policy Domain A policy domain is a collection of objects that have been explicitly grouped together in order to administratively share the same policies. Domains can be nested, in order to reflect hierarchical semantics. Examples are organizational structures, subnets, and a grouping of policies that supply (for example) increasing freedom and/or privileges at lower and lower levels. A domain does not encapsulate the objects it contains; rather, it holds references to objects that it contains. A domain is thus very similar in concept to a directory or folder in a file system. Domains can be nested within domains. Note, however, that a nested domain is not necessarily a subset of the parent domain, because an object in the nested domain may not be a direct member of its parent domain. Policy domains provide a convenient abstraction for specifying policy for individual objects within a large system. Policy domains separate the policy from the entities that the policy affects. This enables the domain membership to be changed without having to change the policy, and vice-versa. It also provides the flexibility to add and remove objects from a policy domain without changing the definition of the policy itself. 2.6. Meta-policy 2.6.1. Introduction The concept of a policy is expressible in different ways for different consumers of the policy. For example, a system administrator might want to express a policy that configures network elements in business terms. That same policy must therefore be translated into a form that enables devices supporting this business rules to be configured. This is conceptually the same policy, but there are two distinctly different representations of that policy that must be related to each other. This is because the goal of policy is to relate the management aspects (e.g., business rules) of the policy to actions executed in a device. At each level of abstraction, there is a universal set of all possible policies (e.g., different variations of queuing mechanisms). However, a policy element might elect to support only a subset of the universal set. By selecting such a subset, it in effect makes a policy decision that constrains other policy decisions. Reichmeyer, et. al. September 2000 [Page 5] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 2.6.2. Definition A meta-policy is a policy that defines how policies are made, or how to build other policies. Note, this is not to be confused with policy meta-data (see section 5). 3. Terms describing Policy-based Network Management Models 3.1. Introduction Three models for policy management are identified in the sections below. These three models represent different ways of expressing the implementation and execution of policies. Primarily, the network services and resources that are being managed dictate network policies and the method used to access them by the users of the network. 3.2. Outsourced Policy An outsourced policy model implements policy by having some components of the policy framework rely upon other components of that same framework to perform policy-related decisions. This model locates the policy decision-making function in a component separate from the device where the policy is executed. An outsourced policy model is a client-server model. There is a well defined, real-time interaction between components in an outsourced policy model. 3.3. Provisioned Policy A provisioned policy model implements policy by configuring devices that execute policy prior to the events that will prompt decisions. Configuration is pushed to the device, e.g., based on time of day or at initial booting of the device. The focus of the provisioned policy model is on the distribution of configuration information. Events received use downloaded (pre-provisioned) mechanisms to implement policy; thus, there is no real-time interaction between systems in this model. There is a well-defined interaction between components, but the interaction does not necessarily occur on a real-time basis. 3.4. Interactive Policy An interactive policy model implements policy by installing policy expressions within appropriate components of the system. This includes complete and self-contained expression of policy data and rules that defines interaction between a process and its constituent components. The focus is not on distribution of policy rules and data, but rather on naming and being able to refer unambiguously and in a consistent, uniform manner to the Reichmeyer, et. al. September 2000 [Page 6] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 information required by the process responsible for implementing the given policy. Interaction between components is defined on a system-specific basis. For example, the network in the general case consists of a variety of different devices, each of which has different capabilities. This means that their specific configuration may vary device to device, but their overall handling of traffic (as a simple example) should be conceptually as uniform as possible. So in general there needs to be an interactive communication between the policy server making the decision and the set of devices that it controls that are implementing the decision. 4. Policy Abstraction and Scoping 4.1. Introduction Policy can be expressed using different levels of abstractions. Roles provide a way to scope policy, at the various levels of abstraction, to portions of the network where they apply. A policy is expressed as a set of related policies at different levels of abstraction. This is because the goal of policy is to relate the management aspects (e.g., business rules) of the policy to actions executed in a device. For example, high-level policies that describe how the network should treat different types of traffic may be expressed in a way that is independent of any one particular way of configuring a device. Yet, we still need to develop policies at a lower level that are used to configure specific devices that actually condition the traffic according to these business rules. This relation exists to enable different network vendors and different types of devices to be provisioned in a common way. So, we need to translate between the different representations of policies in a common and consistent way. Three levels of abstraction have been identified. 4.2. Levels of abstraction 4.2.1. Administrator-defined policy An administrator-defined policy is a policy that is expressed in human-oriented terms of rules which convey organizational or operational goals, independent of any of the details of how or where the policy will be implemented. For example, the Sales Organization runs a different set of applications compared to the Engineering Organization, and requires different conditioning of their traffic compared to that of the Engineering Organization. Reichmeyer, et. al. September 2000 [Page 7] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 4.2.2. Device-independent policy A device-independent policy is a policy that is expressed in terms of rules that describe conditions and actions to be taken by a device in a generic (i.e., implementation-independent) fashion. For example, multiple device-dependent policies could be derived from a single device-independent policy. The single device-independent policy could be described in terms of using various DiffServ Code Points to designate different conditioning for different service classes. This device-independent policy specifies different conditioning to be implemented for different traffic types independent of the type of device that is implementing the traffic. 4.2.3. Device-dependent policy A device-dependent policy is a policy that is expressed in terms of rules that describe the conditions and actions to be taken by a specific device in terms that are particular to a given implementation. Continuing the example used in "device-independent policy," a set of device-dependent policies are defined that express how different devices are configured to express the conditioning defined in the single device-independent policy. Each device-dependent policy implements the same traffic conditioning instructions as specified by the device-independent policy, but in a device-specific way. 4.3. Scoping with Roles Roles define groups of devices (or device interfaces) that want to share the same configuration of policy. For many policy rules, policy roles enable a more efficient implementation of policy. For example, roles can be used to identify a set of policies in a policy repository that are specific to what needs to be accomplished (e.g., find all edge frame relay policies and download them). However, for other types of policies, policy role mechanisms are insufficient. This is primarily because they by themselves are not sufficient to specify the mechanism that they are being used to control (e.g., the above example says nothing about configuring different queues in an interface) to scope them. 5. Terms Concerning Modeling and Representation of Policy 5.1. Information Model An information model is a representation of the entities in a managed environment and the way that they interact with each other. Reichmeyer, et. al. September 2000 [Page 8] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 It is independent of any specific repository, application, protocol, or platform. A set of data models can be derived from an information model. 5.2. Data Model A data model represents a mapping of the contents of an information model into a form that is specific to a particular type of repository. By binding to a repository, protocol and schema are also bound. However, it should be noted that additional platform- and application-specific mappings may be required. 5.3. Schema A schema is a collection of data models that are each bound to the same type of repository. 5.4. Composition of policies Policies are composed of four primary components, or building blocks. These are: policy group, policy rule, policy condition, and policy action. They are briefly defined here. For more complete definition and description of the relationships, see [ref]. 5.4.1. Policy Group A policy group is a group of policies or policy rules. 5.4.2. Policy Rule A policy rule is a set of conditions and a corresponding set of actions. 5.4.3. Policy Condition A policy condition defines the criteria for when a policy rule is to be enforced, that is, when the policy action associated with the policy rule is to be taken. 5.4.4. Policy Action A policy action defines what is to be done to enforce a policy rule when the conditions of the policy rule are met. Reichmeyer, et. al. September 2000 [Page 9] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 5.5. Policy Meta-data Policy meta-data is a set of data that describes the semantics of a specific policy. For example, meta-data could be used to describe additional semantics that should be associated with a given attribute in a data or information model. Note, this should not be confused with a meta-policy (see section 2). 6. Terms for Describing Policy Functions 6.1. Introduction Policy elements can be described in terms of the functions that they perform. This section defines the basic functions deployed in a policy management system. No assumptions are made regarding the physical elements of the system that implement these functions. 6.2. Policy Storage and Retrieval Policies and policy rules must be stored and retrieved from storage, as part of the policy management process. This allows for consistent and predictable application of policy across a network. Storage and retrieval can be implemented with different types of storage technologies (e.g. directories and relational databases), which in turn define the type of protocol(s) that is (are) used to access the policy data. Details on the different technologies, protocols, and the impact of using one versus another, is beyond the scope of this draft. 6.3. Policy Conversion Policy conversion transforms policy information from a representation used in one part of the policy system to another one used elsewhere in the system. For example, a proxy policy server might convert PIB data (received from a policy server) to CLI format used to talk to its clients. Policy conversion is a syntactical transform between representations at the same level of abstraction. Reichmeyer, et. al. September 2000 [Page 10] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 6.4. Policy Discovery In order to insure a communication can proceed between policy domains, a policy decision may depend upon knowledge of the policies of all policy domains that will affect the communication. Each policy domain will have to 'discover' the policies of the other domains in order to make the correct policy decisions. 6.5. Policy Resolution Often misnamed policy negotiation, though no real negotiation takes place. When presented with policies from multiple policy domains, through which a communication must pass, it is necessary to find a common policy supported by all the domains. If no such policy exists, then the communication cannot be completed. 6.6. Policy Translation Policy translation transforms a policy from a level of abstraction used in one part of the policy system to another level of abstraction used elsewhere; e.g., a user name gets 'translated' to an IP address. This is a semantic transform from a policy element at one level of abstraction to another. 6.7. Policy Control Policy control deals with the processing of policy and policy rules, the installation, deletion, and monitoring of policy in the network. Before a new policy can be installed in the network, it must be verified by the policy management system that it will not conflict with other existing policy in the network, and that it can be executed correctly. 6.7.1. Policy Conflict A policy conflict occurs when the conditions of two or more policies can be simultaneously satisfied, but the actions of at least one of the policies can not be simultaneously executed. This implies several things: - one or more policy rules of each of the policies is satisfied by the same request - each condition of each of the conflicting policy rules is satisfied by the same request - one or more actions specified by one policy conflict with one or more actions specified by the other policy Reichmeyer, et. al. September 2000 [Page 11] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 6.7.2. Policy Conflict Resolution Policy conflicts can be resolved in a number of different ways. The simplest is to change the conditions and/or actions of one of the policies so that it no longer conflicts with the other policies. However, if the policies must remain inherently conflicting, then there are a number of ways to resolve the conflict on an individual event basis, including the following: - apply a "match-first" criteria, wherein conflicts are resolved by matching the first policy that is found - apply a priority order criteria, wherein conflicts are resolved by finding all policy rules which match a given event and selecting only the rule with the highest priority - use additional meta-data to determine which rule or rules should be applied. 6.7.3. Policy Satisfiability Policy satisfiability refers to determining if a policy can execute successfully or not. For example, a policy might result in reserving bandwidth of 10Mb. However, if only 8 Mb of bandwidth are available, then even though the conditions of the policy are satisfied, it can not be successfully executed, because enough resources do not exist. 6.7.4. Policy Feasibility Policy feasibility refers to determining if a given policy can execute safely. This not only means that the policy itself can execute correctly, but that the execution of that policy will not adversely affect other policies that are already deployed. 6.8. Policy Decorreltation 7. Terms for describing Functional Elements and Policy Topologies 7.1. Introduction Policies are managed and implemented in functional elements, which correspond to real devices. Functional elements perform one or more functions. Functional elements are not limited to routers and Reichmeyer, et. al. September 2000 [Page 12] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 switches. For example, host systems and firewalls can also be considered functional elements in a policy framework. 7.2. Policy Administrator A policy administrator is a functional entity thatà performs policy administration function. 7.3. Policy Repository A policy repository is a specific type of data store that is used to store policies and policy data. A mapping is required from the repository-independent information model that describes a policy to a repository-specific implementation of that policy. In general, a set of mappings may be made -one for each type of repository. For example, an auxiliary class is a concept that is specific to directories. A mapping for a directory may use auxiliary classes, whereas a mapping to a relational database can not use auxiliary classes. Note that different vendor implementations of the same type of repository may still require an additional mapping from a common data model. For example, you might have a directory data model, and then x additional mappings to account for the differences in how vendors implement the access protocol and specific mechanisms, such as auxiliary classes. 8. Terms Describing Interactions Between Policy Components 8.1. Access Protocol(s) 8.2. Policy Requests 8.3. Policy Decisions A policy decision is the abstraction of activating and evaluating one or more policy rules. Each policy rule is interpreted in the context of a specific request (implied or explicit) for accessing and/or using one or more resources. It connotes taking one or more pre-determined actions based on whether or not a given set of policy conditions were satisfied. 8.4. Policy Evaluation Policy evaluation is the determination of whether or not the entity or set of entities that is being controlled by the policy is in a desired policy state. Reichmeyer, et. al. September 2000 [Page 13] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 8.5. Policy Enforcement Policy enforcement is the action of placing the entity or set of entities that is under policy control in a desired policy state using a set of management commands. For example, when this definition is applied to network elements, these management commands change the configuration of the device(s) using one or more mechanisms. Enforcement is carried out in the context of a policy rule. 8.6. Policy Monitoring Policy monitoring is an on-going active or passive examination of the entity or set of entities that are under policy control. Policy monitoring is done for one or more of the following reasons: 1) to ensure that clients are receiving the services that they have contracted for 2) to monitor statistics as part of checking the health of the entity that is under policy control 3) to monitor statistics as part of checking whether policies that are currently in use are being satisfied 4) to ensure that clients of a given set of policies are not abusing their privileges 8.7. Policy Feedback Closed loop feedback is important to policy networks. This ensures that implementing a policy does not put the system that is under policy control into an unstable state. It can be in the form of acknowledgments to decisions, verification of accounting records, and many other forms. 9. Terms describing specific policies 9.1. Introduction In some cases, terminology is defined to describe sets of policies related to one or more areas to which policy management is applied. 9.2. Terms related to Service Levels One important application of policy is in management of service level commitments by a service provider to a service user. This may be in the context of a commercial relationship between a service provider and a service user which are two separate entities (e.g., an ISP and a subscriber) or which are two entities within Reichmeyer, et. al. September 2000 [Page 14] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 the same organization (e.g., an IT organization and a functional department). 9.2.1. Service Level Agreement (SLA) A service level agreement (SLA) is a service contract between a service user and a service provider that specifies the service a user should receive for all or a portion of their traffic. An SLA includes considerations of a business or contractual nature. Note: This term is a generalization of the term as used in Diffserv. 9.2.2. Service Level Specification (SLS) A Service Level Specification (SLS) is a set of parameters and their values which together define the service offered to a traffic stream by a domain. An SLS is that part of an SLA that is implementable as one or more policies. Note: This term is a generalization of the term as used in Diffserv. Also, the term Service Level Objective (SLO) is also used. 9.3. Terms related to security policies 10. Security Considerations Security considerations are addressed in the appropriate architecture and framework documents. 11. Author's Addresses Francis Reichmeyer IPHighway, Inc. 400 Kelby Street Fort Lee, NJ 07024 Phone: +1 201 665 8714 Email: franr@iphighway.com Dan Grossman Reichmeyer, et. al. September 2000 [Page 15] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 Motorola Inc. 20 Cabot Blvd. Mansfield, MA 02048 Phone: +1 508 261 5312 Email: dan@dma.isg.mot.com John Strassner Cisco Systems 170 West Tasman Drive, Bldg 15 San Jose, CA 95134 Phone: +1 408 527 1069 Email: johns@cisco.com Matthew Condell BBN Technologies 10 Moulton St. Cambridge, MA 02138 Phone: +1 617 873 6203 Email: mcondell@bbn.com 12. References 13. Full Copyright Statement Copyright (C) The Internet Society (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 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. Reichmeyer, et. al. September 2000 [Page 16] Internet Draft draft-reichmeyer-polterm-terminology-00.txt March 2000 The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Reichmeyer, et. al. September 2000 [Page 17]