Internet Engineering Task Force John Strassner INTERNET DRAFT Cisco Systems 26 February 1999 Ed Ellesson IBM Terminology for describing network policy and services draft-strassner-policy-terms-01.txt Status of 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 obsoleted 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. Abstract Recent work in the IETF has led to multiple protocols which support the classification of packets for the purposes of treating certain classes or flows of packets in a particular way compared to other packets. The successful wide-scale deployment of these protocols depends on the ability to administer and distribute consistent policy information to the multiple devices in the network which perform the classification and packet conditioning or treatment. As a result, there is a clear need to develop a scalable framework for policy administration and distribution that will enable interoperability among multiple devices and device types that must work together to achieve a consistent implementation of policy. Unfortunately, terms like "policy" and "service" are not currently defined in sufficient detail as to enable the definition, specification, and implementation of policy servers and how policy is recognized and enforced at the device level. At present, both "policy" and "service" (as well as other related terms) are overloaded with multiple (often conflicting) meanings. This makes communication about policy in general and specifically policy-based networking cumbersome and difficult. This document defines a set of terms that the Internet community can use to exchange ideas on how policy creation, administration, management, and distribution could work among policy servers and multiple device types. Strassner and Ellesson Expires 5 March 1999 [Page 1]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 Definition of Key Word Usage The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [TERMS]. These words will be capitalized to ensure that their intent in this context is easily discernible. Table of Contents Status of this memo 1 Abstract 1 Definition of Key Word Usage 2 Table of Contents 2 1. Introduction and Motivation 4 2. Previously Defined Terminology 4 3. Areas of Terminology Conflict 8 4. Policy Mental Model 8 4.1 General Policy Architecture 8 4.2 How Policy Decisions Are Made 10 4.3 What Is A Policy (In General Terms) 10 4.4 Real-World Requirements of Policy 11 4.5 Policy Components 11 4.6 Policy-Based Applications And Network Policy 11 4.7 Difference Between Policy And Service 12 4.8 Need For Canonical Representation Of Policy 12 5. Policy Terminology 13 5.1 Policy 13 5.2 Policy Rule 13 5.3 Policy Condition 13 5.4 Policy Action 14 5.5 Policy Decision 14 5.6 Policy Behavior 14 5.7 Policy State 14 5.8 Policy Conflict 15 5.9 Service Level Agreement 15 5.10 Service Level Objective 15 5.11 Policy Event 16 5.12 Policy Evaluation 16 5.13 Policy Enforcement 16 5.14 Policy Policing 16 5.15 Policy Agent 16 5.16 Policy-Driven Service 16 5.17 Policy Audit 17 5.18 Policy Consistency Checking 17 5.19 Policy Discrepancy 17 5.20 Policy Mechanism 17 5.21 Policy Verification 17 5.22 Policy Restoration 17 6. Policy Example 17 Strassner and Ellesson Expires 5 March 1999 [Page 2]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 Table of Contents (continued) 7. Terminology For Implementing Policy GUIs 19 7.1 Types Of Policies 19 7.2 How A Policy Is Used - Service And Usage Policies 19 7.3 How A Policy Is Triggered - Static vs. Dynamic Policies 19 7.3.1 Static Policies 19 7.3.2 Dynamic Policies 19 7.4 Classifying Policies Based On Attributes 20 7.5 Policy Triggers 20 8. Security Considerations 20 9. Acknowledgements 21 10. References 21 11. Authors' Addresses 21 Strassner and Ellesson Expires 5 March 1999 [Page 3]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 1. Introduction and Motivation Recent work in the IETF has led to protocols which support the classification of packets for the purposes of treating certain classes or flows of packets in a particular way compared to other packets. The purpose of such classification may include preferential queuing or dropping, admitting or denying access, or encrypting the packet's payload, to cite just a few examples. Protocols that explicitly support some or all of these functions include COPS, RADIUS, RSVP, IntServ, DiffServ, ISSLL, DSSLL, and IPSEC. The successful wide-scale deployment these and other protocols depends on the ability for the administrator of a network domain to administer and distribute consistent policy information to the multiple devices in the network which perform the classification and packet conditioning or treatment. Protocols that could be used for the distribution of the policy include LDAP, COPS, SNMP, and TELNET/CLI. The multiple types of devices that must work in concert across even a single domain to achieve the desired policy can include hosts (clients and servers), routers, switches, firewalls, bandwidth brokers, subnet bandwidth managers, network access servers, and policy servers, to name just a few. As a result, there is a clear need to develop a scalable framework for policy administration and distribution that will allow interoperability among the multiple devices and device types that must work together to achieve a consistent implementation of the network administrator's policy. Unfortunately, terms like "policy" and "service" are not currently defined in sufficient detail as to enable the definition, specification, and implementation of policy servers and how policy is recognized and enforced at the device level. At present, both "policy" and "service" (as well as other related terms) are overloaded with multiple (often conflicting) meanings. This makes communication about policy in general and specifically policy-based networking cumbersome and difficult. This document defines a set of terms that the Internet community can use to exchange ideas on how policy creation, administration, management, and distribution could work among policy servers and multiple device types. 2. Previously Defined Terminology The following terms have been previously defined in other Internet Drafts and are used in this draft to better define policy and policy- based networking terms. Definitions taken from RFC2474 (Definition of the DS Field): Classifier: an entity which selects packets based on the content of packet headers according to defined rules. Strassner and Ellesson Expires 5 March 1999 [Page 4]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 Differentiated Services Boundary: the edge of a DS domain, where classifiers and traffic conditioners are likely to be deployed. A differentiated services boundary can be further sub-divided into ingress and egress nodes, where the ingress/egress nodes are the downstream/upstream nodes of a boundary link in a given traffic direction. A differentiated services boundary may be co-located with a host, subject to local policy. Differentiated Services Domain: a contiguous portion of the Internet over which a consistent set of differentiated services policies are administered in a coordinated fashion. A differentiated services domain can represent different administrative domains or autonomous systems, different trust regions, different network technologies (e.g., cell/frame), hosts and routers, etc. Differentiated Services Field: the IPv4 header TOS octet or the IPv6 Traffic Class octet when interpreted in conformance with the definition given in this document (RFC2474). Mechanism: The implementation of one or more per-hop behaviors according to a particular algorithm. Per-hop Behavior (PHB): a description of the externally observable forwarding treatment applied at a differentiated services-compliant node to a behavior aggregate. Traffic Conditioning: control functions that can be applied to a behavior aggregate, application flow, or other operationally useful subset of traffic, e.g., routing updates. These MAY include metering, policing, shaping, and packet marking. Traffic conditioning is used to enforce agreements between domains and to condition traffic to receive a differentiated service within a domain by marking packets with the appropriate codepoint in the DS field and by monitoring and altering the temporal characteristics of the aggregate where necessary. Traffic Conditioner: an entity that performs traffic conditioning functions and which MAY contain meters, policers, shapers, and markers. Traffic conditioners are typically deployed in DS boundary nodes (i.e., not in interior nodes of a DS domain). Service: a description of the overall treatment of (a subset of) a customer's traffic across a particular domain, across a set of interconnected DS domains, or end-to-end. Service descriptions are covered by administrative policy and services are constructed by applying traffic conditioning to create behavior aggregates which experience a known PHB at each node within the DS domain. Multiple services can be supported by a single per-hop behavior used in concert with a range of traffic conditioners. Strassner and Ellesson Expires 5 March 1999 [Page 5]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 Definitions taken from RFC2475 (Differentiated Services Architecture): - Differentiated Services (DS): a paradigm for providing quality- of-service (QoS) in the Internet by employing a small, well-defined set of building blocks from which a variety of services may be built. - DS-capable: capable of implementing differentiated services as described in this architecture; usually used in reference to a domain consisting of DS-compliant nodes. - DS codepoint: a specific value of the DSCP portion of the DS field, used to select a PHB. - DS-compliant: enabled to support differentiated services functions and behaviors as defined in [DSFIELD], this document (DS Architecture), and other differentiated services documents; usually used in reference to a node or device. - Mechanism: a specific algorithm or operation (e.g., queueing discipline) that is implemented in a node to realize a set of one or more per-hop behaviors. - Service: the overall treatment of a defined subset of a customer's traffic within a DS domain or end-to-end. - Service Level Agreement: a service contract between a customer and a service provider that specifies the forwarding service a customer should receive. A customer may be a user organization (source domain) or another DS domain (upstream domain). A SLA may include traffic conditioning rules which constitute a TCA in whole or in part. - Service Provisioning Policy: a policy which defines how traffic conditioners are configured on DS boundary nodes and how traffic streams are mapped to DS behavior aggregates to achieve a range of services. - Traffic conditioning: control functions performed to enforce rules specified in a TCA, including metering, marking, shaping, and policing. - Traffic Conditioning Agreement (TCA): an agreement specifying classifier rules and any corresponding traffic profiles and metering, marking, discarding and/or shaping rules which are to apply to the traffic streams selected by the classifier. A TCA encompasses all of the traffic conditioning rules explicitly specified within a SLA along with all of the rules implicit from the relevant service requirements and/or from a DS domain's service provisioning policy. - Traffic profile: a description of the temporal properties of a traffic stream such as rate and burst size. Strassner and Ellesson Expires 5 March 1999 [Page 6]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 - Traffic stream: an administratively significant set of one or more microflows which traverse a path segment. A traffic stream may consist of the set of active microflows which are selected by a particular classifier. Definitions taken from draft-ietf-rap-framework-01.txt: - Administrative Domain: A collection of network elements under the same administrative control and grouped together for administrative purposes. - Network Element (also called a Node): A networking device, such as a router, a switch, or a hub, where resource allocation decisions have to be made and the decisions have to be enforced. - Policy: The combination of rules and services where rules define the criteria for resource access and usage. - Policy control: The application of rules to determine whether or not access to a particular resource should be granted. - Policy Object: Contains policy-related info such as policy elements and is carried in a request or response related to resource allocation decision. - Policy Element: Subdivision of policy objects; contains single units of information necessary for the evaluation of policy rules. A single policy element carries an user or application identification whereas another policy element may carry user credentials or credit card information. Examples of policy elements include identity of the requesting user or application, user/app credentials, etc. The policy elements themselves are expected to be independent of which QoS signaling protocol is used. - Policy Decision Point (PDP): The point where policy decisions are made. - Policy Enforcement Point (PEP): The point where the policy decisions are actually enforced. - Policy Ignorant Node (PIN): A network element that does not explicitly support policy control using the mechanisms defined in this document (RAP Framework). - Resource: Something of value in a network infrastructure to which rules or policy criteria are first applied before access is granted. Examples of resources include the buffers in a router and bandwidth on an interface. - Service Provider: Controls the network infrastructure and may be responsible for the charging and accounting of services. Strassner and Ellesson Expires 5 March 1999 [Page 7]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 3. Areas of Terminology Conflict Section 2 listed previously-defined terms that are related to the definition of policy and policy-based networking. Of these terms, the following terms that have been previously defined need more definition in order to satisfy the goals of this document, and will be redefined in subsequent sections of this document: NAME OF THE TERM DEFINED IN PROBLEM WITH DEFINITION Service [DIFFSERV], Too simplistic a definition; needs [DIFFARCH] to be a more general concept Policing [DIFFARCH] Too specific to traffic conditioning Service Level [DIFFARCH] Too specific to traffic conditioning Agreement (SLA) Service [DIFFARCH] Too specific to Differentiated Provisioning Services architecture Policy [RAPFRAME] Too simplistic a definition Policy control [RAPFRAME] Too simplistic a definition Policy Object [RAPFRAME] Too specific to using QoS signaling protocol as transport 4. Policy Mental Model In the general sense, policies represent business goals and objectives, and describe how resources are allocated to meet these goals and objectives. With respect to networking, policy refers to the ability to administer and manage network elements in order to provide a set of services to clients of the network. "Clients" in this context refer to users as well as applications and services. An underlying assumption of this draft is that policy is stored in a centralized repository. This repository may be, but is not limited to, a directory accessed using the LDAP protocol [LDAP]. The rest of this section defines the underlying mental model to support this definition of policy and policy-based networking. Strassner and Ellesson Expires 5 March 1999 [Page 8]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 4.1 General Policy Architecture A general architecture is shown in Figure 1 below. This architecture is similar to that proposed in [SLA] with some minor modifications. +-------------------+ | Management Tool | +-------------------+ | Repository Client | +--------+----------+ | <--- Repository Access Protocol | +--------------------+ | Policy Repository | | (Directory Server, | | Database, etc. ) | +--------+-----------+ | <--- Repository Access Protocol | +--------+------------+ | Repository Client | +---------------------+ | Policy Decision | | Point (PDP) | +---------------------+ | <--- Policy Protocol | +--------+------------+ | Policy Enforcement | | Point (PEP) | +---------------------+ Figure 1. Architectural Overview The above diagram illustrates one common implementation that combines the use of a policy repository, a PDP, and a PEP. This diagram is not meant to imply that these entities must be located in physically separate devices, nor is it meant to imply that the only protocols used for communicating policy are those illustrated. Rather, it is simply meant to show one possible implementation for the purpose of defining the three important entities fundamental to policy: a repository, a PDP, and a PEP. Please refer to [SLA] for a description of how these entities are used and interact with each other. It is assumed that policy decisions will always be made in the PDP and implemented in the PEP. Specifically, the PEP is not able to make decisions on its own. This simplifies the definition and modeling of policy while leaving open the possibility for a single device to have both a Local PDP (LPDP) as well as a PEP. Strassner and Ellesson Expires 5 March 1999 [Page 9]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 The Repository Access Protocol and the Policy Protocol are in general different protocols. If the Policy Repository is a directory, then LDAP is one example of a Repository Access Protocol. However, the Policy Protocol could be any combination of COPS, SNMP, and Telnet/CLI. Given this rich diversity, a common language is needed to represent policy rules. The rest of this document defines the necessary terminology to enable the definition of such a language as well as the definition of how policy is defined, manipulated, and used in the PDP and the PEP. 4.2 How Policy Decisions Are Made Any PEP that encounters an event requiring a policy-based decision first asks a PDP how to handle this request. This results in one or more policy decisions made by the PDP that are in turn communicated to the PEP. A policy decision results in a specific set of operations that either provide a service that was contracted for, or implement a change in state (e.g., in the network) to provide a service. For example, if the network is designed to support differentiated classes of service for handling different types of traffic, network elements could send requests to a policy server asking how to map a given type of traffic. Policy decisions would then be made instructing what type of queueing mechanisms to use to handle that traffic (as an example). 4.3 What Is A Policy (In General Terms) 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, and simplifies their management. It also enables reuse of policy building blocks (policy rules, conditions and actions). This definition of policy can be enhanced in several different ways. However, it is the feelings of the authors that as simple as possible (but no simpler) a definition must first be used and put into practice before more complicated definitions of policy are deployed. Otherwise, it will be much harder to achieve interoperability of policy servers. Policy is a relationship among the attributes of the objects maintained by a policy application that control and manages one or more aspects of a set of PEPs. These PEPs are used to provide a set of services that are regulated by one or more policies. Key to this definition is the ability to separate the specification of the set of services to be provided in a vendor-independent manner from the implementation of vendor-specific mechanisms that are applied to vendor-specific network elements to supply those services. Strassner and Ellesson Expires 5 March 1999 [Page 10]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 4.4 Real-World Requirements of Policy A critical part of the underlying mental model is that it must be easy to detect conflicts between different policies and resolve them. The simplest view of a policy is that it specifies a set of actions that MUST be performed if a set of associated conditions is met. Therefore, the ability to detect and resolve conflicts between policy definitions (conditions as well as actions that are taken when a set of conditions are met) is crucial. One way of doing this is by imposing a priority and/or order on both the satisfaction of policy conditions as well as the execution of policy actions. However, it should be noted that priority and order are fundamental concepts of distributed systems and MUST be supported irrespective of being used to supply a means for policy conflict resolution. 4.5 Policy Components Policy is comprised of the following three functions: 1. Decision-making. This compares the current state of the network to a desired state described by an application-specific policy and decides how to achieve the desired state. 2. Enforcement. This implements a desired policy state through a set of management commands; when applied to network elements, these management commands change the configuration of the device using one or more mechanisms. These mechanisms MAY be vendor-specific. 3. Policing. This is an on-going active or passive examination of the network and its constituent devices for checking network health, whether policies are being satisfied, and whether clients are taking unfair advantage of network services. Decision-making uses static and/or dynamic data to determine if a type of policy is being satisfied and, if not, what steps are needed to satisfy that policy. Enforcement refers to the interpretation and execution of policies by consumers who are assumed to be trustworthy. Policing is the auditing of policy compliance to verify that the policy consumers properly implement policies. 4.6 Policy-Based Applications and Network Policy Policy is defined in terms of applications or processes that monitor and manipulate one or more entities in order to achieve a desired goal. To make the following discussion simpler to understand, this paper focuses on network policies. A network policy defines the relationships between clients that desire services of the network and the network elements that provide those services. Network Policy applications model two important things: 1) the state of the SLAs that they are enforcing, and/or 2) some part of the state of the (overall) network in order to ensure that their clients will obtain the services they require of (that portion of) the network. Strassner and Ellesson Expires 5 March 1999 [Page 11]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 Such applications will maintain a number of objects of various types, each with one or more attributes. Each of these objects either models the state of one or more network elements or maintains some part of the internal state of the policy application. Each of these state machines contains the mapping of services desired by users to the network elements that provide those services. A network policy, then, is a relationship among attributes of the objects maintained by the policy application that controls and manages some aspect of the network in terms of one or more services that the network provides. Since the application models some part of the state of the entity, it is also accurate to say that a policy is a statement about the desired state of the entity (e.g., the requirements to maintain its current state or the need to transition to a different state). 4.7 Difference Between Policy And Service A service is the expression of a relationship between a set of objects. A policy is a statement about a set of relationships between objects that provide a particular service. 4.8 Need For Canonical Representation Of Policy Policies represent business functions and goals. These correspond to network services, which are provided by vendor-specific network elements. The problem is that vendors will describe the same business function in different ways. This is because business functions are described at a necessarily high level, and are therefore subject to different interpretation. Since the network will implement the services that correspond to these business functions, differences in network elements will exacerbate this mapping. The solution is to use a canonical representation of policy. All policies MUST consist of a set of policy rules, and all policy rules MUST consist of a set of policy conditions and policy actions. This provides a consistent meta-structure for describing policy, enabling a vendor-independent exchange of policy information. However, this is not enough, because the definitions of policy conditions and actions could still be different, and if they were, interoperability of policy servers will not be achievable. Therefore, a canonical representation of policy conditions and policy actions MUST also be enforced. This in turn requires a categorization of policy rule, policy condition, and policy action into a set of application-specific domains (e.g., RSVP and Differentiated Services would have separate policy conditions and actions that identify their applicability). Given a class-based implementation of policy, the above could be implemented easily through defining subclasses that corresponded to the different policies, policy rules, policy conditions, and policy actions that were under control of the PDP. Strassner and Ellesson Expires 5 March 1999 [Page 12]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 5. Policy Terminology The following is a set of policy terminology definitions. 5.1 Policy A policy is a named object that represents an aggregation of Policy Rules. The policy describes the overall business function(s) to be accomplished, while the set of policy rules define how those business functions will be met. The business function(s) correspond to one or more SLOs of an SLA. 5.2 Policy Rule A policy rule is comprised of a set of conditions and a corresponding set of actions. This combination in effect defines a sequence of actions to be initiated when the corresponding set of conditions is either satisfied or not satisfied. For simplicity, it is recommended that positive (satisfaction) and negative (unable to meet) conditions be realized as separate rules that are folded into a single policy. Each policy rule is a declarative statement consisting of a Boolean expression that describes a situation to which the policy applies. When the expression is true, one set of actions is initiated, and when false, a different set of actions is initiated. This version of the document will only consider the expression of a rule as a condition statement (e.g., IF some set of conditions are met, THEN take this set of actions, ELSE take this other set of actions). 5.3 Policy Condition Policy Conditions consist of two parts, a policy condition type and a policy condition element. This structure is aimed at satisfying the need for a canonical representation of a policy condition. A policy condition type is a set of predefined conditions that can be attached to a policy rule for evaluation. This canonical set of conditions represent common conditions that all network vendors can implement. By including this canonical representation of policy conditions, the resulting set of policy conditions can be exchanged between multiple vendors' policy servers. This is necessary for interoperability as well as for a policy server to be able to parse rules to determine if any rules conflict may potentially conflict with each other. A policy condition element is a policy condition type instance that is being tested. Policy condition elements are related together to form a Boolean expression. The relations can be one of the following operators: in, not in, equal, not equal, less than, less than or equal, greater than, and greater than or equal. Strassner and Ellesson Expires 5 March 1999 [Page 13]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 5.4 Policy Action A policy action is the changing of the configuration of one or more network elements in order to achieve a desired policy state. This (new) policy state provides one or more (new) behaviors. As with policy conditions, a policy action is comprised of two parts, a policy action type and a policy action element. The policy action type defines a canonical set of operations or treatments that can be given to traffic flowing into the network element (e.g., deny, change code point, etc.) that is vendor-independent. Similarly, the policy action element specifies the type of mechanism to be used to provide the specified operation or treatment. 5.5 Policy Decision 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. Note that the action of a policy decision MAY be to simply invoke another policy rule for further processing of the request. 5.6 Policy Behavior A policy behavior controls how traffic is treated, what network resources must be utilized, and/or what network services are provided. Policy behaviors define one or more mechanisms that are used to implement the policy. Therefore, different devices can carry out the same policy using different behaviors. For example, one router might use a dropping behavior and another might use a queueing behavior during times of congestion in order to satisfy an overall delivery goal. Policy behaviors can include one or more of the following: - permit or deny forwarding of traffic based on: - source and destination address - source and destination port number - protocol type and options - other factors specific to vendor implementations - permit or deny access to a requested resource or service - encrypt the header and/or the payload - start or stop accounting and/or auditing - start or stop logging 5.7 Policy State A policy state is a description of the settings of one or more network elements. These settings correspond to providing the set of services to be provided by the network. For example, a Service Level Agreement can describe services contracted for by subscribers - this corresponds to a state that various network elements must be put into in order to provide those services. Strassner and Ellesson Expires 5 March 1999 [Page 14]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 5.8 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 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 metadata to determine which rule or rules should be applied. The difference between this and straight priority is that priority is inherently linear, whereas metadata is not (e.g., branching can be used). 5.9 Service Level Agreement (SLA) An SLA is a service contract between a customer and a Service Provider that specifies the expected operational characteristics of their relationship. Example operational characteristics include the details of the treatment which a customer's traffic and/or requests for service should receive. The details of the operational characteristics are defined in terms of Service Level Objectives (SLOs). The SLA documents the agreed levels and parameters of services provided, and can cover a wide range of parameters including items that effect the network element and items that don't (e.g., service hours and availability, user support levels, etc.). 5.10 Service Level Objective (SLO) An SLO partitions an SLA into individual objectives that can be mapped into policies that can be executed. The SLOs define metrics to enforce, police, and/or monitor the SLA. Some commonly used metrics to determine whether or not an SLA is being fulfilled include component system availability (e.g., up-time and MTBF), performance (e.g., response time), and serviceability (e.g., MTTR). Strassner and Ellesson Expires 5 March 1999 [Page 15]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 5.11 Policy Event A policy event is a notification that triggers one or more policy evaluations. A particular event may or may not initiate a policy decision and/or a policy enforcement action. 5.12 Policy Evaluation Policy evaluation is the determination of whether or not the network (or a part of it) is in a desired policy state. This is usually determined by processing static and/or dynamic data against one or more policy rules, the key point being that the decision is made by comparing definitional data stored in the policy repository with current data from the network that does not have to be stored in the policy repository. If it is found that the network elements are not in the desired policy state, then one or more policy actions will be taken to move the network elements from their current state to the desired state. This is called policy enforcement. 5.13 Policy Enforcement Policy enforcement is the action of placing the network (or a part of the network) in a desired policy state using a set of management commands. 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. 5.14 Policy Policing Policy policing is an on-going active or passive examination of the network and its constituent devices for checking network health, whether policies are being satisfied, and whether clients are taking unfair advantage of network services. This is done for one or more of the following reasons: - to monitor network statistics as part of checking network health - to monitor network statistics as part of checking whether policies that are currently in use are being satisfied - to ensure that clients of a given set of policies are not abusing their privileges 5.15 Policy Agent A policy agent is a software module that generates and responds to policy events, evaluates policies, and enforces policies. 5.16 Policy-Driven Service A policy-driven service is a set of cooperating policy agents that Define, monitor and enforce a particular policy. Strassner and Ellesson Expires 5 March 1999 [Page 16]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 5.17 Policy Audit A policy audit matches conditions examines one or more active policies to determine if their actions are being executed correctly and the desired result (e.g., flow of traffic) is being carried out. This is equivalent to checking the state of the network to determine the set of policies that are and are not being satisfied. 5.18 Policy Consistency Checking Policy consistency checking is an analysis of currently active policies to determine their consistency or possible inconsistency with each other. When an inconsistency is discovered, a policy discrepancy is reported. 5.19 Policy Discrepancy A policy discrepancy is a notification that two or more policies are in actual or potential conflict in the sense that implementation of one policy may prevent or otherwise adversely effect the implementation of the other policies. 5.20 Policy Mechanism A policy mechanism is a set of vendor-specific commands that configures a network element to put a policy rule into effect. 5.21 Policy Verification Policy Verification is an analysis of a policy to determine if the desired state can be established and maintained for the duration of the corresponding policy rule being active. 5.22 Policy Restoration Policy Restoration is one or more actions taken to restore the system to a desired policy state. This could be invoked because of a policy action in response to an event, or because the current state got corrupted. 6. Policy Example This section will provide an example of the canonical use of policies, policy rules, policy conditions and policy actions. Assume that the following business rule is to be implemented as a policy: Provide the JitterFreeMPEG2 video service for authorized users between authorized points, but only at agreed-upon times Strassner and Ellesson Expires 5 March 1999 [Page 17]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 This rule can be loosely translated as: IF user IN ApprovedUsers AND service IN VideoServices AND source IN VideoSources AND destination IN VideoDestinations AND time IN ApprovedTimePeriods THEN provide JitterFreeMPEG2 The policy condition is loosely translated as: IF the user is a member of an approved group (ApprovedUsers) that are authorized to have this service) AND the service requested is one supported (VideoServicesgroup) AND the source of the request is approved (in the VideoSources group or has been authenticated) AND the destination is approved (in the VideoDestinations group or has been authenticated) AND the time requested is OK (in ApprovedTimePeriods) Here, the policy condition types are: user, service, source, destination, and time and the policy condition elements are: ApprovedUsers, VideoServices, VideoSources, VideoDestinations, and ApprovedTimePeriods, which are all instances of pre-defined groups of objects. The policy action is: IF the conditions are satisfied THEN provide the user with video having a QoS defined by the JitterFreeMPEG2 service Note that this policy could require "sub-policies" in order for it to be implemented. For example, RSVP requests might be used to precondition the path between VideoSources and VideoDestinations. Strassner and Ellesson Expires 5 March 1999 [Page 18]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 7. Terminology For Implementing Policy GUIs Part of the task of defining policy terminology is to enable policies to be represented in a user-friendly GUI. This section provides guidelines for doing this through the introduction of additional terminology designed expressly for this purpose. 7.1 Types Of Policies An effective policy GUI MUST be able to categorize and sort policies in ways that are meaningful to the user. Three are three broad means of doing this, based on differentiating between how a policy is used, how a policy is triggered, and the attributes of the policy. 7.2 How A Policy Is Used - Service And Usage Policies Service and Usage Policies are a means of categorizing policies by what they do and how they are used. Service policies describe services available in the network. Usage policies describe which policies will use which services when the usage policies are satisfied. Usage policies describe particular mechanism(s) employed to either maintain the current state of the object, or to transition an object from one state to a new state, in order to utilize the specified services. For example, the fact that a user can get a particular conditioning treatment, or can use IPSEC to encrypt the payloads of traffic, are both services that are provided and are represented as service policies. On the other hand, differentiating between two flows and assigning different services to the flows is an example of using usage policies to differentiate the handling of the flows. 7.3 How A Policy Is Triggered - Static vs. Dynamic Policies There are two fundamentally different ways that policies can be applied - statically in response to a set of pre-defined conditions and dynamically in response to one or more events. Both static and dynamic policies use statically defined rules to determine how the policy effects the objects that it is applied on. Furthermore, both types of policies are applied in response to an event. The difference lies in how they are applied. 7.3.1 Static Policies Static policies apply a fixed set of actions in a pre-determined way according to a set of pre-defined parameters that determine how the policy is used. These parameters restrict the application of the policy in some way. Examples include restricting the application of the policy to only certain times of the day, week, month, or year. For instance, the accounting department gets 75% of the bandwidth at the close of the quarter, or anyone can use streaming video after 7:00PM. The above examples each illustrate a means of restricting the application of the policy based on some external data or set of conditions. Strassner and Ellesson Expires 5 March 1999 [Page 19]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 7.3.2 Dynamic Policies This type of policy gets enforced when needed (i.e., when the network gets congested, or when a user with Gold Service logs on). Although the conditions of the enforcement are pre-defined, there is no set time or parameter that triggers the policy. Rather, the policy is triggered when a condition occurs. For example, Gold Service has one set of actions when the network is not congested and an additional set of actions when the network is congested. The mechanism that implements the gold service doesn't change; however, additional sets of actions (that ensure the delivery of Gold Service) are invoked when the network is congested. Since the network can be congested in different ways, different sets of actions are invoked. This is fundamentally different than the static policies defined above in that static policies always invoke the same set of actions the same way in response to an event. Dynamic policies may invoke different actions based on the semantics of the event. 7.4 Classifying Policies Based On Attributes Policies can be classified by the attributes that they possess. This includes what the policy applies to (e.g., a class of user or a certain type of application) as well as certain attributes that fundamentally change the applicability (conditions) and effect (actions) of the policy. Examples of these include physical location. For example, if a user is connected to his or her corporate Intranet through the public internet, then a different security policy might be applied to that communication and different restrictions may be placed on accessing resources than when that user connects through the corporate network. 7.5 Policy Triggers Some policies only come into force if certain usage conditions are met. For example, if the current network bandwidth utilization is low, users may be allowed to use certain applications (e.g., streaming video or interactive games) that they otherwise are not allowed to use. Furthermore, this privilege may be revoked if the traffic reaches a certain level. 8. Security Considerations Security and denial of service considerations are not explicitly Considered in this memo, as they are appropriate for the udnerlying Policy architecture. However, the policy architecture must be secure as far as the following aspects are concerned. First, the mechanisms proposed under the framework must minimize theft and denial of service threats. Second, it must be ensured that the entities (such as PEPs and PDPs) involved in policy control can verify each other's identity and establish necessary trust before communicating. Strassner and Ellesson Expires 5 March 1999 [Page 20]
INTERNET DRAFT draft-strassner-policy-terms-00.txt 5 August 1998 9. Acknowledegments Many thanks to the useful discussions and suggestions from the Internet Community at large but especially to Andrea Westerinen, John Lee, Lee Rafalow, Steve Schleimer and Fred Baker. 10. References [TERMS] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", Internet RFC 2119, March 1997. [DIFFARCH] D. Black, S. Blake, M. Carlson, E. Davies, Z. Whang, W. Weiss, "An Architecture for Differentiated Services", Internet draft <draft-ietf-diffserv-arch-00.txt>, May 1998 [DIFFSERV] K. Nichols and S. Blake, "Definition of the Differentiated Services Field (DS Byte) in the IPv4 and IPv6 Headers", Internet draft <draft-ietf-diffserv-00.txt>, May 1998 [DSFIELD] K. Nichols and S. Blake, "Definition of the Differentiated Services Field (DS Byte) in the IPv4 and IPv6 Headers", Internet Draft <draft-ietf-diffserv-header-00.txt>, May 1998. [LDAP] This refers to the current collection of LDAP RFCs (2251 - 2256) but especially to RFC 2251 (the protocol). [RAPFRAME] R. Yavatkar, D. Pendarakis, R. Guerin, "A Framework for Policy-based Admission Control", Internet Draft, < draft-ietf-rap-framework-01.txt>, May 1998 [SLA] R. Rajan, J-C Martin, editors, "Schema for Service Level Administration of Differentiated Services and Integrated Services in Networks", Internet Draft <draft-ellesson-sla-schema-02.txt>, June 1998 11. Authors' Addresses John Strassner Bldg 1 Cisco Systems 170 West Tasman Drive San Jose, CA 95134 Phone: +1-408-527-1069 Fax: +1-408-527-1722 E-mail: johns@cisco.com Ed Ellesson JDGA/501 IBM Corporation 4205 S. Miami Blvd. Research Triangle Park, NC 27709 Phone: +1-919-254-4115 Fax: +1-919-254-6243 E-mail: ellesson@raleigh.ibm.com Strassner and Ellesson Expires 5 March 1999 [Page 21]
