[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
 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
 
 
                   <draft-ietf-policy-framework-00.txt>
                    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 <set of conditions to be met> THEN
   <set or sequence of actions to be taken>, 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 <condition> then <action>.  The
   <condition> 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 <action> 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, <draft-pan-
       diameter-sip-01.txt>, November 1998.
 
   [IPSEC] Sanchez, L.A., Condell, M.N., "Security Policy System",
       Internet Draft,  <draft-ietf-ipsec-sps-00.txt>, November 1998.
 
   [LDAPEVENT] ldap event notification draft.
 
   [MODEL] Moore, B., Ellesson, E., Strassner, J., "Policy Framework
       Core Information Model", Internet-Draft, <draft-ietf-policy-
       core-info-model-01.txt>, 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", <draft-ietf-policy-requirements-00.txt>, 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, <draft-ietf-policy-core-
        schema-01.txt>, February September 1999.
 
   [TERMS] J. Strassner, E. Ellesson, "Terminology for describing
        network policy and services", Internet Draft, <draft-strassner-
        policy-terms-01.txt>, 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]