INTERNET-DRAFT M. Stevens Expires: March 2000 W. Weiss Lucent Technologies H. Mahon Hewlett Packard B. Moore IBM J. Strassner Cisco Systems G. Waters Nortel Networks A. Westerinen J. Wheeler Microsoft September 1999 Policy Framework Monday, September 13, 1999, 4:20 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 (1999). All Rights Reserved. Abstract This document articulates the requirements and basic framework of a policy-based management system for IP networks. It focuses on the storage and retrieval of Policy Rules from a repository, for use in Stevens, et. al. Expires: Sep 1999 + 6 months [Page 1] Internet Draft Policy Framework September 1999 the management and operation of IP networks. This framework document describes functional components and operational characteristics of a system that is intended to be device and vendor independent, interoperable and scalable. There are three basic sections of this draft, addressing: o the motivation for policy-based management that briefly describes the requirements for implementing policy in IP networks; o a reference model that defines a first-level functional decomposition of such a framework, and captures the key concepts in defining policy tools, Policy Rules, the use of a repository and schema, and the mechanisms underlying the definition, storage and retrieval of policies; and o a description of each of the functional components, as well as a narrative about how a policy system can implement prescribed policies. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 2] Internet Draft Policy Framework September 1999 Table of Contents 1. Introduction......................................................3 2. Terminology.......................................................7 3. Policy Framework..................................................8 3.1. The Conceptual Model.........................................8 3.2. Policy Specification.........................................9 3.3. Policy Rules................................................10 3.4. Policy Mechanisms...........................................10 3.5. Options for Packaging.......................................11 4. Functional Groupings.............................................13 4.1. Policy Infrastructure.......................................14 4.1.1. Policy Editor.............................................15 4.1.2. SLO Translation...........................................15 4.1.3. Rule Validation...........................................16 4.1.4. Global Conflict Detection.................................16 4.2. Rule Storage and Retrieval..................................17 4.3. Policy Consumer Functions...................................17 4.3.1. Changing Policy...........................................17 4.3.2. Evaluation of Policy Conditions...........................18 4.3.3. Device Adapter and Execution of Policy Actions............19 4.3.4. Transformation............................................19 4.3.5. Local Conflict Detection..................................20 4.4. Policy Assessment...........................................21 4.4.1. Assessment of the Feasibility of Policy Rules.............21 4.5. Policy Execution............................................21 4.6. Roles.......................................................24 4.7. Interfacing with Components Outside the Policy Infrastructure25 4.7.1. Network Management Products...............................25 5. Policy Conflicts.................................................25 6. Interoperability.................................................26 7. Future: Inter-Network and Inter-Domain Communication.............27 8. Intellectual Property............................................27 9. Acknowledgements.................................................28 10. Security Considerations.........................................28 11. References......................................................28 12. Editors' Addresses..............................................29 13. Full Copyright Statement........................................30 1. Introduction The purpose of a policy system is to manage and control a network as a whole, so that network operations conform to the business goals of the organization that operates the network. Ultimately, achieving such control requires altering the behavior of the individual entities that comprise the network. One approach is to alter the behavior of these entities individually by using a centralized network management application. Iterating through a list of network entities, a management application achieves control of the network by Stevens, et. al. Expires: Sep 1999 + 6 months [Page 3] Internet Draft Policy Framework September 1999 manipulating the operational parameters of each network entity separately. Taking this approach places a disproportionate burden upon network management applications. To effectively control a network, network management software must have explicit knowledge of the management interfaces of each entity it endeavors to control, as well as knowledge of the capabilities of each of these entities. As a result, network management software is often forced to manage only those features controlled by the management interfaces common to the majority of the entities in the network. Implementing policy in this way in an IP network remains piecemeal and proprietary. The policy framework described in this memo represents an alternative approach to controlling the operational characteristics of an IP network. Unlike traditional network management approaches, the systems developed within the policy framework implement policy by centralizing the storage of prescribed rules instead of implementing policy by centralizing control functions into a single software application. A policy system devised under this framework shifts the focus from configuring individual devices to setting policy for the network in aggregate, and controlling device behavior through network policy. At the center of such a policy systems is the Policy Rule. Policy rules may be general and abstract or specific and concrete. In either case, Policy Rules represent a pairing of conditions and actions that are intended to be device- and vendor-independent. The Policy Rule serves as the point of interoperability between entities participating in any policy system developed within this framework. To make the Policy Rule into the main point of interoperability, an information model describes three things: o the composition of Policy Rules o the characteristics of devices that are being controlled by Policy Rules o the relationships and interactions among the objects being managed. The composition of Policy Rules, along with some of the characteristics of devices that are being controlled by Policy Rules, are described by a schema [SCHEMA]. This defines the format and the organization of the storage for Policy Rules, as well as the data that characterize the devices being controlled by Policy Rules. Other characteristics of devices, used to capture the semantics and relationships between different objects being managed, define how the conditions and actions represented in a Policy Rule are interpreted and what effect they have on the functions of the device. These are described in [MODEL]. This memo presents a context for the schema and semantic definitions, and enumerates the functional elements that may be required to realize a complete policy system. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 4] Internet Draft Policy Framework September 1999 A policy system built upon the expression of rules must demonstrate at least three abilities: 1. The ability to enable a user to define and update Policy Rules. 2. The ability to store and retrieve Policy Rules. 3. The ability to interpret, implement and enforce Policy Rules. To better understand the ramifications of the list above, we can recast it as a list of the functional elements of a policy system. A possible breakdown follows: 1. A Policy Management Tool, to enable an entity (e.g.: person, application) to define and update Policy Rules and optionally, monitor their deployment. For example: a graphical or command line/script interface. 2. A Policy Repository, for persistent storage and retrieval of Policy Rules. (Note: that the repository simply stores data, it does not in general process or act on it). 3. A Policy Consumer, which is a convenient grouping of functions is a responsible for acquiring Policy Rules, deploying Policy Rules, and optionally translating Policy Rules into a form useable by Policy Targets. 4. A Policy Target, which is a functional element whose behavior is dictated by Policy Rules. The Policy Target carries out the action indicated by the Policy Rule. Policy Consumers and Policy Targets are logical entities and represent interfaces, not necessarily physical entities. Consequently, Policy Consumers, and Policy Targets can be realized in a number of combinations. A Policy Consumer can be realized in software running on a general-purpose computer separate from the Policy Target. Alternatively, a Policy Consumer can be coupled with a Policy Target and realized in software running on a specialized device like a router or switch or on general-purpose computer. Regardless of where the Policy Consumer software executes, its purpose is to acquire, optionally translate and deploy Policy Rules. Functionally, translating rules is separate from the implementation of the rule, which is the evaluation of conditions and the execution of actions. Although a single software or device entity may be responsible for both the acquisition and deployment of Policy Rules, Policy Consumers can be functionally distinct from the targets of the Policy Rules. For example, a Policy Rule may state that a certain group of users are to be given priority service. A network device may be able to make a decision based on criteria similar to that expressed in the Stevens, et. al. Expires: Sep 1999 + 6 months [Page 5] Internet Draft Policy Framework September 1999 Policy Rule. A Policy Consumer may be employed to interpret the Policy Rule and create an analogous but more device-specific form. For example, the Policy Consumer might translate a condition expressed in terms of resource names into one containing network addresses. In such a case, the network device is the Policy Target. Policy Rules may also contain references to time in their conditions. Some Policy Targets may be incapable of evaluating conditions containing time. In such a case, a Policy Consumer may decompose the Policy Rule and distribute the decision process between itself and the Policy Target. In some situations, a physical device can be involved in affecting policy in a network while not being the Policy Target. In such a situation, the Policy Consumer and Policy Target functions combined and realized in a software application, and the physical device is simply manipulated by the software in which the Policy Consumer and Policy Target are realized. Examples of include devices that have no facility to interpret policy, but can be used to affect policy. A router capable of enabling and disabling its ports, but incapable of interpreting standardized policy expressions stored in a repository, can serve as another example. Suppose an organization has a set of game servers, and wants to limit access to these servers to periods of the day outside normal working hours. A Policy Rule governing access to the servers could be written in two ways. o It could specify time conditions, and an action indicating that access to the servers should be enabled or disabled. o It could specify the same time conditions, but the action could contain directives specific to the device where the policy is to be deployed. In either case, the aforementioned router can be used to affect policy. Both rules require the development of software to interpret the Policy Rule on behalf of the router. The first option can be standardized, and although the device cannot evaluate the Policy Rule, an application can be created to function as the Policy Consumer and Policy Target. The latter form of the Policy Rule is more device-specific. In both cases, the Target of the rule is the router. Another motivation for the functional split is illustrated where policy condition(s) cannot be evaluated by the same entity that executes the action(s). So, the information stored in the policy action must, for certain cases, be device-specific. This framework accommodates both device-specific as well as device-independent policies. The purpose of discerning a difference between Policy Consumers and Policy Targets is to make it easier to understand Policy Rule semantics and develop the building blocks for standard policy Stevens, et. al. Expires: Sep 1999 + 6 months [Page 6] Internet Draft Policy Framework September 1999 expressions. In an effort to devise examples of Policy Rules, people often express rules that imply two distinct subjects within the same rule. The result is either a rule that makes no sense to others, or one that leads us to the development of device-specific rules. It is important to note the steps in "implementing a Policy Rule". Policy Consumers acquire and optionally translate Policy Rules. Policy Targets implement Policy Rules in a much more constrained fashion. Two choices are possible: o behaving according to contents of the Policy Rule as a result of treating the behavioral specification as a set of direct commands. o operating in a manner consistent with configuration parameters received from a Policy Consumer that has interpreted Policy Rules on behalf of the Policy Rule Implementers may choose to add mechanisms to measure the effectiveness of Policy Rules, to establish feedback loops, and to ensure synchronization between functional elements, however this memo does not address such mechanisms. For more information on these ancillary functional elements see [REQUIRE]. 2. Terminology The following terms are derived from those previously defined in the Internet Drafts, "Terminology for describing network policy and services" [TERMS] and "A Framework for Policy-based Admission Control" [RAPFRAME], but are not identical. These terms are in the process of being harmonized. The concepts listed below are summarized and made more specific to establish the terminology used throughout the remainder of this document. Policy Conflict: Occurs when the conditions associated with two or more Policy Rules are simultaneously satisfied, but not all of the actions associated with the Policy Rules can be performed together. Policy Consumer: A convenient grouping of functions responsible for acquiring Policy Rules, deploying Policy Rules, and optionally translating Policy Rules in to a form useable by policy targets. Policy Decision: A potentially, multi-step process of evaluating policy that is not restricted to a single functional element; it may occur in a Policy Consumer, a Policy Target or both. Policy Deployment: the action of placing the network (or a part of the network) in a desired 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. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 7] Internet Draft Policy Framework September 1999 Policy Enforcement: The performance of (device-specific) actions specified in a Policy Rule, in one or more Policy Targets, that are consistent with the (not necessarily device-specific) actions described in the Policy Rule as a result of making a policy decision. Policy Rule: A specification of a set of optionally sequenced actions to be initiated when a specified set of conditions is satisfied. A Policy Rule takes the form, IF THEN , and is designed to specify the behavior of a Policy Target. Policy Target: An entity whose behavior is dictated by Policy Rules. The Policy Target carries out the action(s) indicated by the Policy Rule. Service Level Agreement (SLA): A service contract between a service consumer (customer) and a service provider or a bilateral agreement between service providers that specifies the expected operational characteristics of their relationship. 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. Service Level Objective (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. 3. Policy Framework 3.1. The Conceptual Model This section introduces a policy framework, provides a first-level functional decomposition of it, and describes the role of the functional elements in the framework. This is a conceptual model, and not intended as a specification of components that must be present in a policy system. Such issues as communication between multiple Policy Consumers will be covered later in this memo. This framework permits the implementation of three different abstractions of policies using the functional elements shown in Figure 1. The policy framework does not require that all functional elements be implemented nor does it specify implementation packaging of functional elements. The three levels of abstraction supported by this model are: o The administrators' view of policy is to abstract general configuration and operational characteristics of the resources in a policy domain and the management of service-level objectives (SLOs) for these resources. SLOs are frequently derived from contractual service-level agreements (SLAs) and may be probabilistic in nature. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 8] Internet Draft Policy Framework September 1999 The Policy Management Tool may provide significant value-add in the level of abstraction and degree of sophistication of the GUI presentation of SLAs and SLOs, and in the mapping between these and the lower-level Policy Rules. o The Policy Rules, as stored in the Policy Repository according to a defined information model (which may also take the form of separate schemata that are derived from it), provide a deterministic set of policies for managing the behavior of resources in the policy domain. These Policy Rules are usually produced by the Policy Management Tool, stored in the Policy Repository and consumed by the Policy Consumer. However, note that in some cases, it is desirable to ship the Policy Rules directly to the Policy Consumers (without first storing them in the Policy Repository), to allow for further processing before they are stored. For example, a Policy Rule could be specified in the Policy Management Tool, but a feasibility check, as well as conflict resolution, may first be performed before storing the Policy Rule in the Policy Repository. o The policy mechanisms are policy discipline-specific and may be implementation-specific mechanisms and representations of the Policy Rules. They are the APIs, methods, protocols and other constructs used to forward and evaluate policies and perform actions on network components. Ultimately, policy mechanisms result in Policy Targets taking action to deliver the services as prescribed at the administrative interface of the Policy Management Tool. 3.2. Policy Specification The administrative user of the Policy Management Tool functional component specifies abstract policies that have meaning to the administrator and, indirectly, the end user or application for whom the policy is prescribed. Although specific enough to implement service level objectives via the Policy Management Tools' abstraction of the Policy Rules and mechanisms, these administratively specified Policy Rules may not generally be specific enough to allow for direct mapping to network equipment configurations for deployment. It would be unusual (but not impossible) for an administrator or software automating administrative function to specify policy for a specific traffic filter or queuing parameters. The Policy Management Tool also provides the mapping of the prescribed policies to a set of Policy Rules. Policy Management Tools should implement consistency checking of the Policy Rules to verify that the Policy Rules are consistent prior to placing them into the Policy Repository (see section 5). It is not necessary to employ all functional elements as distinct physical entities. It is also possible to implement the Policy Rules and policy mechanism layers without implementing a Policy Management Tool component. In fact, the central purpose of this framework is to Stevens, et. al. Expires: Sep 1999 + 6 months [Page 9] Internet Draft Policy Framework September 1999 enable interoperable implementations of Policy Consumers and Policy Targets using common schema in a Policy Repository. 3.3. Policy Rules The Policy Management Tool produces the Policy Rules, which the Policy Consumers then use to appropriately influence the behavior of the Policy Targets. The Policy Rules specify the logic used to deliver the prescribed service and service-levels. Policy Consumers interpret and may further validate the Policy Rules and then map these rules to the underlying policy mechanisms of the Policy Targets. The Policy Consumers may also transform the Policy Rules into forms that Policy Targets can use directly. Policy rules are of the form: if then . The expression may be a compound expression and it may be related to entities such as hosts, applications, protocols, users, other system sub-components, etc. The may be a set of actions that specify services to grant or deny or other parameters to be input to the provision of one or more services. The set of actions associated with a Policy Rule may be ordered or unordered. The policy information model, as described in [MODEL], is a platform- and technology-independent object-oriented model that describes not only the structural characteristics of a set of managed objects (e.g., users, network devices, and services) but also describes the relationships between those devices. This information is then mapped to a form that is suitable for storage in a particular repository. An example of such a mapping is described in [SCHEMA]. Although other policy repositories are permitted in this framework, a directory is specifically referenced as the exemplary Policy Repository for the abstract and device/vendor-independent rule set. LDAP is used as the preferred access protocol for directories. Furthermore, directory schemata, as defined in [SCHEMA], are given as an example of a means to store Policy Rules and other data necessary to control a network. In a directory, Policy Rules are represented as a set of object entries that include object classes for Policy Rules, policy conditions and policy actions. These Policy Rules co- reside with objects representing network devices and services as well as with other objects representing such entities as users, printers, and file servers. For LDAP implementations, Policy Consumers may detect changes in Policy Rules by periodic polling of the directory, by use of the (currently draft) LDAP event notification mechanisms [LDAPEVENT], or by some other notification mechanism. Selecting or defining an event mechanism for a policy system is outside the scope of this working group. 3.4. Policy Mechanisms Policy Mechanisms are defined as the underlying methods, protocols, and tools used to perform the actual implementation (evaluation and Stevens, et. al. Expires: Sep 1999 + 6 months [Page 10] Internet Draft Policy Framework September 1999 action execution) of the Policy Rules. Usually, the Policy Consumer translates the Policy Rules and generates appropriate instructions for the Policy Target. Sometimes, the Policy Consumer simply identifies the appropriate Policy Rules for a given flow or environment and passes them to the appropriate Policy Targets. These policies are then evaluated and enforced by the Policy Targets as appropriate for a given event. In either case, these policies may be discipline-specific and, perhaps, device-specific. Typical uses are specifying the traffic shaping parameters for a QoS policy or the address filters for a firewall policy. It is not in the scope of this framework to specify actual mechanisms, but to provide a common interface through Policy Rule abstraction for access to the actual mechanisms. 3.5. Options for Packaging As indicated earlier, the boxes in Figure 1 represent functional elements of the framework, not actual products. A policy product may implement exactly one of the functional elements, more than one functional element, or even a part of one of the functional elements. Figure 2, for example, shows a multi-role policy server that includes both a Policy Management Tool and a Policy Consumer. The implementation details of these two elements are hidden inside the server's boundaries. The only interfaces visible outside the server are the Policy Management Tool's user interface, the Policy Consumer's protocol for communicating with the Policy Targets, and the interfaces via which the Policy Management Tool and the Policy Consumer communicate with the Policy Repository. Note that a given product may need multiple repositories to efficiently store and retrieve data that is used to make policy decisions. For example, if the main repository is a directory, and SNMP information needs to be used as part of a decision, then it would be a bad idea to store the values of (for example) SNMP counters in a directory. However, the directory could be used to specify the location and access method (for example, via a URL) of other data. The line formed by asterisks in Figure 2 illustrates how the manufacturer of a multi-role policy server might add additional communication paths for transfer of policy information within the server. This is not meant to imply that not having this line of communication is better or worse than having it û it simply describes a manufacturer's packaging option. In such a case, the line formed by asterisks represents a path by which policy information input at the user interface can be sent directly to the embedded Policy Consumer, without first having to be placed in the Policy Repository. Since this line is within the server, it has no bearing on interoperability. In the future, it may be determined that this communication path should be standardized between separately packaged Policy Management Tools and Policy Consumers. In this case the framework would be Stevens, et. al. Expires: Sep 1999 + 6 months [Page 11] Internet Draft Policy Framework September 1999 modified to show this interface as either required or optional for a Policy Management Tool and a Policy Consumer to implement. Currently, the line represents an internal product interface, for the simplicity of standardization, and to gain experience to provide the above interfaces. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 12] Internet Draft Policy Framework September 1999 Policy Specifications + - - - - - | - - - - - - - + V | +--------------------+ | | Policy | | | Management Tool | | +---------+----------+ | * | | Repository Access * +---------------------------+ Protocol(e.g.: LDAP) | * | | * <- Alternate Policy +---------+----------+ | * Communication Path | | Policy Repository | <-- Policies * | (Directory Server, | | * | | Database, etc.) | * +---------+----------+ | * | | * +---------------------------+ Repository Access | * | | Protocol(e.g.: LDAP) +---------+----------+ | | Policy Consumer | | | | | +---------+----------+ | | | | <-- Protocol for affecting Policy Targets | + - - - - - - - - - - - - - + | +---------+----------+ | Policy Target | | | +--------------------+ Figure 1. A Packaging Option for the Functional Components 4. Functional Groupings A policy system implementation can be composed of the four functional entities, shown in Figure 2. Some of these components have previously appeared in IETF drafts in different shapes and forms, as a Policy Server [IPSEC] [DIAMETER], as RAP's PDP and PEP [RAPFRAME], and as bandwidth brokers. It is important to separate the functional components and describe the relationships between them. That is the purpose of this section and Figure 2. Note: This is an enumeration of policy functions and, as such, it does not describe any implementation details such as distribution, platform, or language. It merely shows an example of convenient groups of functions within a policy system. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 13] Internet Draft Policy Framework September 1999 Policy Management Tool 1. Policy Editing 2. Policy Presentation 3. Rule Translation 4. Rule Validation 5. Global Conflict Resolution 6. Other Functions Policy Repository 1. Storage 2. Search 3. Retrieval Policy Consumer 1. Rule Locator 2. Device Adapter 3. State Resource Validation (Requirements Checking) 4. Policy Rule Translation 5. Policy Transformation 6. Other Functions Policy Target 1. Operate as specified by Policy Rule 2. Optionally, Policy Rule Validation 3. Optionally, Feedback 4. Other Functions Figure 2. Policy Infrastructure Functional Groupings 4.1. Policy Infrastructure Likely a sub-component of the Policy Management Tool, the Policy Editor provides the policy editing, policy presentation, rule translation, and rule validation functions. In this component, many rules are translated from abstract or human understandable forms to the syntax of the policy information model of the repository. Basic syntactic and semantic validation is also possible. The Policy Consumer is responsible for Policy Rule interpretation and initiating deployment. Its responsibilities may include trigger detection and handling, rule location and applicability analysis, network and resource-specific rule validation and device adaptation functions. In certain cases, it transforms and/or passes the Policy Rule and data into a form and syntax that the Policy Target can accept, leaving the implementation of the Policy Rule to the Policy Targets. Policy Targets are responsible for the evaluation of policy conditions and Policy Targets handle the execution of actions. These entities may also perform related device-specific functions, such as Policy Rule validation and policy conflict detection. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 14] Internet Draft Policy Framework September 1999 These functions are reviewed in the following sections. 4.1.1. Policy Editor The Policy Editor is a mechanism for entering, viewing and editing Policy Rules in the Policy Repository. Network and policy administrators would use the Policy Editor. It could be implemented as a full-featured graphical user interface, a simple Web-based form, and/or support a command line or scripting interface. Policy Rules may be of several forms. Probabilistic rules may be of the form: "with 99% probability, provide sub-second response-time for department D using application A." Other general specifications may be of the form: "I want 100Mb/s of premium traffic going from point A to point B" or "I want a video conference between the sales team managers". Alternately, more specific rules may be defined, such as "For NetworkDevice1 and 3, configure drop queues as follows ..." or "From source=10.56.43.x to destination=10.56.66.x, enable Premium Service" for these types of traffic. There is wide latitude in the level of abstraction and function of the policy editor UI. However, it is beyond the scope of this document to specify such functions. Once a Policy Rule has been entered into the Editor and before it is stored in the repository, simple validation should be performed. This is described in 4.1.3. The Policy Editor should provide feedback to the administrator of the validation results. At the simplest level, this could result in a "Valid/Invalid Policy" message. More useful, however, would be for the Editor to indicate the erroneous rule conditions or actions, or display the pre-existing Policy Rules with which the new rule conflicts. Further rule definition or update would then be the responsibility of the administrator. However, it is beyond the scope of this document to specify such functions. 4.1.2. SLO Translation Translation of general policy specifications or SLOs into Policy Rules that the Policy Consumer can interpret is performed by the Rule Translation function. This function maps a high level (e.g. business-oriented) specification of a Policy Rule, with its associated parameters, to a more specific Policy Rule format pertaining to that service. It is expected that an information model and schema for QoS, DHCP, IPSec and other Policy Rule disciplines will be defined. Using QoS as an example, the Rule Translator would take general Policy Rules related to the specification of "normal" or "premium" service, and translate these to the specific format defined for QoS policy. This format is device- and platform-independent and could be performed by the Policy Management Tool. Note, however, that another level of translation is usually necessary to enable a device to interpret and execute the policy. The Policy Consumer does this form of translation. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 15] Internet Draft Policy Framework September 1999 As another example, the following Policy Rule could be defined: "Traffic between Point A and Point B should receive Expedited Forwarding". This could be translated into the following two Policy Rules: o source = 10.24.195.x, destination = 10.101.227.x, any protocol, provide Expedited Forwarding o source = 10.101.227.x, destination =10.24.195.x, any protocol, provide Expedited Forwarding where the action to perform Expedited Forwarding is enabled through the marking of packets with the Differentiated Service Code Point (DSCP) of 101110. In this example, the network has been configured to treat packets with a DSCP 101110 as packets that receive Expedited Forwarding treatment. Thus these rules apply to the ingress interface for the network, on either an end system or a router, where packets will be marked. 4.1.3. Rule Validation The Rule Validation function performs checking of a policy prescription and/or rule, and returns the results of this checking. Two kinds of checking should be performed: o Validation of the data types of the terms of the specified Policy Rule. For example, if a policy term calls for the input of an IP address, then the system should ensure that a valid IP address and mask are specified (as opposed to, for example, an integer). o Validation of the semantics of the Policy Rule. This has to do with ensuring that the construction of a Policy Rule, and its conditions and actions, from a set of pre-defined building blocks, actually makes sense. Policy rules can be syntactically correct yet make no sense. For example, a rule may be defined stating that "Traffic at 50 Mb/s should receive Expedited Forwarding treatment and run only between 10.23.24.56 and 10.23.24.56". This is syntactically valid but semantically wrong since it specifies the same source and destination address. 4.1.4. Global Conflict Detection The Global Conflict Detection function checks to see whether or not a newly entered policy conflicts with other policies. It is called "global" in order to connote that this type of conflict detection is not bound to any specific device, subnet, or network. The Global Conflict Detection component should check for static conflicts derived from Policy Rules whose conditions are simultaneously satisfied, but whose actions conflict with those of currently existing rules. For example, an administrator may define two rules stating that "A maximum of 10 video conference channels are Stevens, et. al. Expires: Sep 1999 + 6 months [Page 16] Internet Draft Policy Framework September 1999 allowed on NetworkA", and that "eight video conference lines are dedicated to Finance on Tuesdays from 9-10am". If a third rule provisioning 3 video conference lines for Legal every day at 9-10am were to be added to the rule set, a conflict should be detected. The administrator is attempting to provision for 11 video channels (versus the maximum of 10 channels allowed). See [TERMS] draft for further clarification. Not all policy conflicts can be detected by the Global Conflict Detection function. Rules may be "time based" (specifying an effective validity period in the future) or based on dynamic state information. These rules may indeed conflict with others. But, these conflicts may only be detected at the time that the rule becomes valid and enforcement actions are attempted. For example, one may have Policy Rules that apply in normal, congested, and business- critical (e.g., financial crisis, take away all bandwidth from everywhere to support this) conditions. On the surface, they appear to conflict with each other. However, in reality, they don't, since they are meant to apply in non-overlapping time periods and conditions. The validation performed in this component is also called off-line validation, meaning that it is not performed at the same time as the execution of the policy. On-line validation occurs within the Policy Assessment component, discussed in Section 4.4. 4.2. Rule Storage and Retrieval Once a Policy Rule has been translated and verified, its storage in the Policy Repository is required. This may be done before or after the Policy Consumer starts processing the Policy Rule. Utilization of Policy Rules to maintain or change system/device state requires retrieval of these rules from the Policy Repository. In addition, the repository is accessed during the rule validation process discussed above. It is assumed that standard LDAPv3 mechanisms are used to accomplish these tasks. This assumption is discussed further in Section 6, below. 4.3. Policy Consumer Functions 4.3.1. Changing Policy Data in the Policy Repository will change from time to time and Policy Consumers need to be informed of these changes as they happen. This framework does not specify the means for notifying Policy Consumers of changes. There are a number of possible ways to make this notification. (e.g. polling, LDAP change notification, using SNMP traps, etc.) Stevens, et. al. Expires: Sep 1999 + 6 months [Page 17] Internet Draft Policy Framework September 1999 4.3.2. Evaluation of Policy Conditions Evaluation of policy conditions may involve the Policy Consumer, the Policy Target, or both the Policy Consumer and the Policy Target. When evaluation applies to a single device, or when it applies to detailed packet conditions that only the Policy Target (as opposed to a physically separate Policy Consumer) can understand, then condition evaluation will typically occur only in the Policy Target. At the other extreme, if only global conditions such as time of day or the overall state of the network are being evaluated, then the condition evaluation may take place entirely in the Policy Consumer. In many cases, though, the evaluation of policy conditions may be shared between the Policy Consumer and the Policy Target. An example will show clearly how a Policy Consumer and a Policy Target might share policy condition evaluation. The Policy Consumer in this example is one that translates policy rules into configuration settings, and then downloads these configuration settings to its Policy Targets. Such a Policy Consumer might have retrieved from the Policy Repository the following two rules for one of its Policy Targets: Rule 1: If there is overall congestion in the network, then drop packets received from subnet-1. Rule-2: In there is not overall congestion in the network, then accept and process packets received from subnet-1. "Overall network congestion" in these conditions does not indicate a single interface's or single device's understanding of the current state of the network. Instead, it refers to an understanding of the state of the network as a whole, which might involve a management application (the "congestion application") that interacts with various probes in the network, and/or introduces artificial traffic into the network and measures the progress of this traffic. In this simplified example, this application would need to provide a binary answer ("Yes, the network is congested" or "No, the network is not congested") to the Policy Consumer. Based on whether or not the network is currently experiencing congestion, the Policy Consumer acts. If the network is congested, then the Policy Consumer downloads to the Policy Target a set of configuration parameters that will cause it to drop packets from subnet-1. If the network is not congested, then the Policy Consumer downloads a different set of configuration parameters, that cause the Policy Target to process packets from subnet-1. This initial configuration download isn't the end of the Policy Consumer's responsibilities in this case. After this, it must continue to interact with the congestion application, and be ready to download new configuration parameters to the Policy Target if, in the Stevens, et. al. Expires: Sep 1999 + 6 months [Page 18] Internet Draft Policy Framework September 1999 opinion of this application, the network becomes congested, or ceases to be congested. As an implementation option, a Policy Consumer may elect to cache the congestion application's opinion about whether the network is congested, so that it can quickly determine which configuration settings to download if a new Policy Target contacts it. This sort of cached data would typically be stored locally by the Policy Consumer, as opposed to being stored in the Policy Repository. 4.3.3. Device Adapter and Execution of Policy Actions The Device Adapter function has two distinct purposes, One purpose is take the canonical representation of Policy Rules (as stored in the Policy Repository) and interpret them on behalf of devices not equipped to interpret them directly. In this case, the device adapter function can be realized as a Policy Consumer which is effectively a proxy, enabling legacy devices to participate in the implementation of policy within a given network without having to retrofit the legacy devices. The second use of the Device Adapter function is to relieve the Policy Consumer of having to know all of the intimate details of the Policy Targets that it controls. The problem is that a given network may contain many different types of devices, each with different capabilities. This means that a single configuration can not be given to different devices. Instead, the device configuration will vary as a function of vendor, device type, protocol used, and other factors. The problem is that many vendors make so many devices, that it becomes impossible for a single Policy Consumer to be able to control all of them, due to their differing interfaces and capabilities. Operating in a multi-vendor network exacerbates this problem. The solution is to develop a set of extensions to the Policy Consumer that are able to individually translate the policy generated by the Policy Consumer to an equivalent form that is usable by a specific set of devices. 4.3.4. Transformation There are in general four models for sending a policy from the Policy Consumer to a Policy Target (not including the case where the Policy Consumer and the Policy Target are co-located in the same physical box). These four models support the different types of network devices described in section 4.5 below. They are: o Pass-Through. Simply pass the policy retrieved from the Policy Repository to the Policy Target directly, and let the Policy Target interpret, evaluate and execute it. o Modify-Transform-Send. The Policy Consumer interprets and evaluates the policy (possibly adding some data or changing some parameters in the process) and then ships the modified form of the policy to Stevens, et. al. Expires: Sep 1999 + 6 months [Page 19] Internet Draft Policy Framework September 1999 the Policy Target, which then evaluates and executes the modified policy. o Command-Transform-Send. The Policy Consumer interprets and evaluates the policy, and then generates a set of commands that the Policy Target can use to implement the policy. o Proxy. The Policy Consumer must use a Policy Proxy to be able to communicate to the Policy Target. 4.3.5. Local Conflict Detection The Local Conflict Detection (LCD) component is an integral part of the Policy Consumer. Whereas the Global Conflict Detection components checks for policy conflicts that do not apply to any specific network device, the LCD checks for policy conflicts that apply to all network devices that are controlled by a given Policy Consumer. The LCD detects local conflicts and checks that the requirements of the policies can be satisfied and assesses the feasibility of a policy (new, changed, or deleted) in which this Policy Consumer has interest. The types of checks performed include: o Conflict Detection. This entails checking that the new, modified, or deleted policy does not conflict with any existing local policy. o Requirements Checking. This is a set of checks to ensure that the resources needed by a policy, in isolation from all other local policies, are available in the devices to which this policy applies. For example, suppose that a policy requires that a certain set of paths through the network (via the devices that this PDP manages) provide a certain specific queuing behavior. Suppose further that on one of the paths at one of the interfaces, no advanced queuing mechanisms are available. This would mean that the needs of the policy are not satisfied. Thus, the policy itself is not satisfied, implying that this policy cannot be implemented in these devices. o Feasibility. This compares the available services of the network with respect to the full set of policies that want to use those services. Feasibility checking will most likely require post-policy deployment checking that is sensitized to the particular network elements involved as well as the nature and effects of the deployed policies. This is beyond the scope of this document. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 20] Internet Draft Policy Framework September 1999 4.4. Policy Assessment 4.4.1. Assessment of the Feasibility of Policy Rules A set of Policy Rules may be infeasible for reasons other than being in conflict. Resource availability and the state of the network may render Policy Rules impracticable. Such and assessment of Policy Rules may involve multiple components (e.g.: the Policy Consumer and the device). When assessment applies to a single device, or when it applies to detailed packet conditions that only the Policy Target (as opposed to a physically separate Policy Consumer) can understand, then this function is associated with executing in the Policy Target only. The Validation components gather, (optionally) store, and monitor network state and resource information. Upon a request to evaluate a Policy Rule set, the Validation function uses this information and returns a determination as to the feasibility if the Policy Rule. Often, authentication and authorization checking are required of the Validation components. Examples include checking the current time of day against the authorized times that a user or application can access certain resources, or checking against the level of service that a user or application can request. State and resource validation is also concerned with the current availability of network resources. In other words, the services and/or resources requested must exist in the quantity required. If requested resources are available, then the actions of a Policy Rule may be executed. The notion of current resource availability is dynamic and depends on how resources are currently provisioned in the network and what resources are presently in use by, or reserved for, other traffic. 4.5. Policy Execution It is important to understand that the critical point of interoperability with regard to network policy resides in a realized information model rather than in a transport protocol and its message semantics. Instances of the classes described in the core policy schema contain data that describe operational policies. To affect policies in the network, entities within the network must interpret prescribed policies. Not all entities within a network necessarily possess the ability to interpret policies directly. Such entities may require assistance in interpreting policies. Network devices can be categorized into groups: policy-aware and policy-unaware. Policy-unaware devices are devices that are unable to interpret any portion of the policy information model or schema. However, they can still participate in a policy-based network if an application can translate the policies into a form that the policy- Stevens, et. al. Expires: Sep 1999 + 6 months [Page 21] Internet Draft Policy Framework September 1999 unaware device can implement. It is irrelevant that the policy- unaware device doesn't know it is executing policies; what is relevant is that it is participating in a policy solution. Policy-aware devices fall into four groups: policy-interpretive, policy-compliant, policy-capable, and policy-proxied. Policy- interpretive devices have the capability to interpret expressions of policy as represented in a repository conforming to the core policy schema. For example, an interpretive device that possesses the capability of delivering specified quality of service can read the QoS policy schema, and interpret and enforce policies without the aid of an external application. Policy-compliant devices can interpret portions of the policy schema. In the case of QoS policy schema, a policy-aware device possesses the capability to interpret the classes within the policy schema that describe vendor- and implementation-independent expressions of QoS. Policy-compliant devices cannot interpret the QoS rules, but can interpret QoS parameters as defined by QoS classes within the schema. Both policy-capable as well as policy-proxied devices are those that can not directly interpret policy as defined in a policy schema or information model. An intermediate process must be used in both cases to transform the policy as stored in the Policy Repository to a form that can be executed by the Policy Target. The difference is that a policy-capable device can communicate directly with the Policy Consumer, whereas the policy-proxied device requires a proxy to communicate with the Policy Consumer. Both policy-unaware and policy-aware devices require assistance in interpreting policies. A Policy Consumer is an example of an application that can assist both policy-unaware and policy-aware devices by interpreting policies. In the case of policy-unaware devices, a Policy Consumer may find it necessary to transfer policy and other related information to and from an intermediate process (which then talks directly to the device), in order to affect policy. Typically, the Policy Consumer may need to read or write configuration and read state information associated with a given network device as it prepares a device to implement specific policies. Recommending a specific protocol or mechanism for the purpose of establishing communication from Policy Consumers to policy-unaware devices is beyond the scope of the Policy Framework working group; however, we recognize that a number of options exist. A MIB is an instance of a data structure that describes configuration and state information of a device or service. Therefore, a Policy Consumer could use a MIB for configuration and for discerning state of the policy-unaware devices or services with which the MIB is associated. Another option may be to use a command-line interface. In such cases, a Policy Consumer can use the command-line interface to configure the device as needed. Note that in both of these cases, control may be effected through the use of an intermediate process. In this case, the role of the Policy Consumer changes to Stevens, et. al. Expires: Sep 1999 + 6 months [Page 22] Internet Draft Policy Framework September 1999 communicating its requests to the intermediate application, which is then responsible for communicating with and controlling the appropriate devices on behalf of the Policy Consumer. In the case of policy-aware devices, a Policy Consumer may find it necessary to transfer information to and from devices. However, since the device is capable of interpreting certain classes defined within the policy schema, the Policy Consumer may not need to use the MIB or command-line interface to configure the device. Instead, a Policy Consumer could use any protocol to transmit instances of the policy schema classes that represent the desired operation, and let the policy Target perform the actual configuration. Examples of protocols include COPS, SNMP, and Telnet. Selecting a protocol and establishing a technique for encoding classes within PIBs remains outside the scope of the Policy working group. It is important to point out that the use of a PIB is not a requirement for implementation of policy-based management. In fact, it is possible to implement a Policy Management environment without the use of a PIB or similar mechanism. It is possible that the Policy Consumer resides with the Policy Target, such that there is no network connection between the Policy Consumer and Policy Target. In such a case, the function of communication between the Policy Consumer and Policy Target is completely implementation dependent since there is no interface that can be exposed. In such an implementation where the Policy Consumer and Policy Target reside within the same system (e.g., a network element such as a router) the Policy Consumer and Policy Target may even be simply different objects or functions within a single process. As we develop policy systems in IP networks, we must be careful to distinguish protocol components from information model components. In order for a structure to be considered as part of the information model, it must reflect the schema that describes the information model. The policy information model is designed to enable interoperability, and a device or service-specific data structure reduces interoperability. Any mapping between standardized expressions of policy and the parameters of proprietary algorithms takes place in the application responsible for and capable of interpreting policy (e.g. a Policy Consumer). Furthermore, more than one Policy Consumer may need to share information represented in the standard schema. Using an appropriate policy protocol such as COPS, policy-aware entities may express objects of the information model in a variety of agreed-upon formats (yet to be defined) and transmit them as necessary. The Policy Framework working group is focused on describing policy information in a platform- and technology-independent way, not on how that information is accessed by policy-aware entities. The interface Stevens, et. al. Expires: Sep 1999 + 6 months [Page 23] Internet Draft Policy Framework September 1999 between the policy management system and the managed entity is the Policy Consumer, whether it is separate from or resident on the managed entity itself. 4.6. Roles This section is under development. Continued development and coordination with other IETF working groups is under way. Roles may require additional configuration at the Policy Target and there is concern that administrative overhead may be significantly increased using a a roles mechanism that requires device-specific configuration. The specific policy to apply to a device interface may depend on many factors, including the physical and/or logical characteristics of the interface, the status of the interface, user configuration parameters, or other parameters such as time of day, geographical location, and function in the network. Rather than specifying policies explicitly for each interface of each device in a given policy domain, and then trying to match these policies to the particular parameters of interest, policies can be specified in terms of roles. Roles provide a powerful means of indirection: o new policies are specified for a role, instead of having to specify them for each and every individual network interface o the modification of existing policies is specified within a role, instead of having to modify them for each and every individual network interface o existing policies are applied to a newly-installed network interface by assigning the relevant roles to the new interface, rather than copying policies from existing interfaces to the new interface o roles enable network administrators to generate network-wide policies, rather than having to remember all the individual components to which policies should be applied o neither the permanently-stored policy data, nor the Policy Consumer, needs to have intimate knowledge of each and every device in the network; rather, each device can inform the Policy Consumer of the roles for which it needs policy data. Roles are labels that are used to pass policy information between the Policy Consumer and the Policy Target. Roles abstract device capabilities, and are useful for aggregating device interfaces to apply a common set of changes to without having to name specific device interfaces. For example, this enables "all Frame Relay Edge Stevens, et. al. Expires: Sep 1999 + 6 months [Page 24] Internet Draft Policy Framework September 1999 interfaces" to be provisioned in one operation, instead of individually. A given device interface may have multiple roles associated with it. This simply means that a given device interface performs many separately identifiable functions in the network. Policy classes have an attribute called a "role-combination" which is an unordered set of roles. Instances of a given policy class are applied to a device interface if and only if the set of roles in the role-combination is identical to the set of the roles of the interface. When the Policy Consumer and the Policy Target first connect, the Policy Target reports all of the role-combinations that it supports to the Policy Consumer. This enables the Policy Consumer to determine which policies are applicable to which interfaces of which devices. For example, if a device has five interfaces with roles A and B, and four interfaces with roles A and C, then it must request policy data for two role-combinations: A+B and A+C. The Policy Target also reports changes to its role-combinations to the Policy Consumer. 4.7. Interfacing with Components Outside the Policy Infrastructure 4.7.1. Network Management Products Existing network management products can play an integral role in comprehensive policy systems. A Network Management product can be used to configure network elements based on the definition of Policy Rules. In such a case, a network management product can become a Policy Consumer or provide services to one. It can be used by a Policy Consumer to install a device-specific mechanism on a network element to implement a rule. A network monitoring application provided by the Network Management product could be used for independent policy verification. The Network Management product would also be useful for accessing the network topology. Network topology information is critical for making certain types of policy decisions. 5. Policy Conflicts A policy conflict occurs when the conditions of two or more Policy Rules are concurrently satisfied but the actions that they mandate produce inconsistent results with each other. For example, a Policy Rule specifying that "all engineers get bronze service" is in conflict with another rule defining that "the lead engineer gets gold service". This is a direct conflict, since there are directly identifiable terms in each Policy Rule that conflict. However, there are also indirect conflicts, such as with this third rule: "all ftp traffic gets best effort". This conflicts only if an engineer decides to send FTP traffic. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 25] Internet Draft Policy Framework September 1999 A conflict may be determined before execution of the policy is attempted. This function is represented in policy systems two different mechanisms: (1) "Global Conflict Detection" (section 4.1.4) and (2) "Local Conflict Detection" (section 4.3.5). For example, the conflict may be detected by the Global Conflict Detection component when the policy is entered into the Policy Editor. Alternatively, the conflict may go unnoticed until the Policy Target tries to validate or implement it. A different type of conflict may also be determined when the policy is processed at the Policy Consumer. An example of when this type of conflict can occur is when one Policy Consumer loads a policy into a Policy Target and a second Policy Consumer attempts to load a conflicting policy. Conflict detection is an important aspect of a policy infrastructure however, a generic algorithm is not defined in this document. Regarding conflict resolution, various mechanisms and degrees of sophistication exist in implementations. The policy schema specifies a rule priority attribute to aid in conflict resolution [SCHEMA]. Beyond the support of conflict resolution that is specified in the schema, conflict resolution is a local implementation issue and is beyond the scope of this document. 6. Interoperability The framework outlined in this memo defines two types of entities that access the data repository: the administrative tools and the policy consumers. Both of these entities require interoperability with the data repository on at least two levels. The first level of interoperability is on the data model level. The entities require knowledge of the structure, syntax, and semantics of the data in order to be interoperable. Failure to fully comply with any of the data definitions will cause an entity to produce incorrect results. The second level of interoperability is on the data access level. For the specific case of a directory used as the repository, the policy framework chooses LDAPv3 (or higher) as the protocol to access the repository. Assuming a compliant LDAPv3 implementation, data access should be interoperable. Other access protocols are suited for alternative repositories. However, the current LDAP standards are not fully sufficient to ensure data repository interoperability. Three deficiencies have been identified that hinder interoperability. These are: o Change notification: the ability to notify data access entities when data changes and how the data changed; and, Stevens, et. al. Expires: Sep 1999 + 6 months [Page 26] Internet Draft Policy Framework September 1999 o Transactional integrity: the ability of the repository to ensure that a set of related operations are completed as a set. o Referential integrity: the ability of the repository to ensure that a given operation applied to one object affects related objects in the appropriate way Interoperability problems will occur if implementations choose to use proprietary change notification mechanisms or implement notification in a non-consistent fashion. Lack of transactional and referential integrity will result in interoperability problems since implementations may update objects in different order, or fail to apply certain operations to all objects. This could cause data repository corruption. The use of directories as a component of a policy infrastructure is dependent on other IETF Working Groups' efforts to define and standardize missing LDAP features. Meanwhile, the LDAP Core Policy Schema [SCHEMA] is being defined in way that seeks to minimize the impacts of these missing features. 7. Future: Inter-Network and Inter-Domain Communication The inter-domain communication interface of a policy management system is concerned with communication with other policy systems in adjacent domains. This communication may be across enterprise-carrier or carrier-carrier boundaries. The primary purpose of inter-domain exchanges is to negotiate SLAs with adjacent networks to establish policy services within the adjacent network. Ideally, the adjacent network should have sufficient SLAs in place with its downstream neighbor to support the requested service end-to-end. Adjusting provisioning at domain boundaries entails re-negotiation of SLAs with adjacent domains. Linking provisioning with policy management in the future makes it possible to manage how provisioning is performed, an area of importance to managing policy in a carrier environment. The area of inter-domain communication for policy service requests is an ongoing research topic. Protocol requirements, message contents, etc. are still under study within several IETF working groups including RAP, DiffServ, Policy, and AAA working groups. 8. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it Stevens, et. al. Expires: Sep 1999 + 6 months [Page 27] Internet Draft Policy Framework September 1999 has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 9. Acknowledgements TBD 10. Security Considerations Security and denial of service considerations are not explicitly considered in this memo. However, the implementation of a policy infrastructure 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 (Policy Management Tools, the Policy Repository, Policy Consumers, and Policy Targets) involved in policy- based management can verify each other's identity and establish necessary trust before communicating. 11. References [DIAMETER] Pan, P., Schulzrinne, H., Calhoun, P., "DIAMETER: Policy and Accounting Extension for SIP", Internet Draft, , November 1998. [IPSEC] Sanchez, L.A., Condell, M.N., "Security Policy System", Internet Draft, , November 1998. [LDAPEVENT] ldap event notification draft. [MODEL] Moore, B., Ellesson, E., Strassner, J., "Policy Framework Core Information Model", Internet-Draft, , September 1999. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 28] Internet Draft Policy Framework September 1999 [RAPFRAME] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for Policy-based Admission Control", Internet Draft, < draft-ietf- rap-framework-01.txt>, May 1998. [REQUIRE] Mahon, H. "Requirements for a Policy System for IP Network", , August 1999. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [SCHEMA] Strassner, J., Ellesson, E., Moore, B. "Policy Framework LDAP Core Schema", Internet Draft, , February September 1999. [TERMS] J. Strassner, E. Ellesson, "Terminology for describing network policy and services", Internet Draft, , August 1998. 12. Editors' Addresses Hugh Mahon Hewlett Packard 3404 East Harmony Road, MS A2 Fort Collins, CO 80528 Phone: +1 970-898-BITS Email: hugh_mahon@hp.com Robert Moore IBM Corporation, BRQA/502 4205 S. Miami Blvd. Research Triangle Park, NC 27709 Phone: +1 919-254-4436 Email: remoore@us.ibm.com Mark Stevens Lucent Technologies 300 Baker Avenue, Suite 100 Concord, MA 01742 Phone: +1 978-287-9102 Email: markstevens@lucent.com John Strassner Cisco Systems 190 Tasman Drive, Building E San Jose, CA 95134 Phone: +1 408-527-1069 Email: johns@cisco.com Stevens, et. al. Expires: Sep 1999 + 6 months [Page 29] Internet Draft Policy Framework September 1999 Glenn Waters Nortel Networks 310-875 Carling Avenue, Ottawa, Ontario K1S 5P1 Canada Phone: +1 613-798-4925 Email: gww@nortelnetworks.com Walter Weiss Lucent Technologies 300 Baker Avenue, Suite 100 Concord, MA 01742 Phone: +1 978-287-9130 Email: wweiss@lucent.com Andrea Westerinen Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425-705-2553 Email: andreawe@microsoft.com Jeffrey Wheeler Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: +1 425-705-2553 Email: jwheeler@microsoft.com 13. Full Copyright Statement Copyright (C) The Internet Society (1999). 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. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 30] Internet Draft Policy Framework September 1999 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. Stevens, et. al. Expires: Sep 1999 + 6 months [Page 31]