Internet DRAFT - draft-waters-policy-arch


HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 12:07:02 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Thu, 11 Mar 1999 18:36:00 GMT
ETag: "3ddbd6-a70b-36e80d10"
Accept-Ranges: bytes
Content-Length: 42763
Connection: close
Content-Type: text/plain

 Network Working Group                                         G. Waters
 INTERNET-DRAFT                                               J. Wheeler
                                                         Nortel Networks
                                                           A. Westerinen
                                                              L. Rafalow
                                                                R. Moore
                                                           February 1999

                       Policy Framework Architecture

                     Friday, February 26, 1999, 4:28 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 obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress.''

   To view the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in an Internet-Drafts Shadow
   Directory, see

 Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.


   This document articulates the requirements and basic components of a
   policy-based management architecture.  It focuses on the storage and
   retrieval of policy rules from a directory-based repository, for use
   in the management of network devices.  The architecture is described
   in terms of its functional components and operational characteristics.
   It is intended to be device and vendor independent, interoperable and

   There are three basic sections of this draft, addressing:

   o the motivation for policy-based management that briefly describes
     the requirements for a policy framework architecture;

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months           [Page 1]
 Internet Draft       Policy Framework Architecture        February 1999

   o a reference model that defines a first-level functional
     decomposition 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 an architecture that describes each of the functional components,
     and includes a narrative about how the architecture will execute.

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months           [Page 2]
 Internet Draft       Policy Framework Architecture        February 1999

   Table of Contents

   1. Introduction......................................................4
   2. Terminology.......................................................5
   3. Reference Model...................................................6
      3.1. The Model....................................................6
      3.2. Policy Prescription..........................................7
      3.3. Policy Rules.................................................8
      3.4. Policy Mechanisms............................................8
   4. Architecture......................................................9
      4.1. Functional Components of the Policy Architecture............10
      4.1.1. Policy Editor.............................................10
      4.1.2. Rule Translation..........................................10
      4.1.3. Rule Validation...........................................11
      4.1.4. Rule Storage and Retrieval................................12
      4.1.5. Policy Trigger and Rule Location..........................12
      4.1.6. State and Resource Validation.............................12
      4.1.7. Device Adapter and Execution of Policy Actions............13
      4.2. Interfacing with Components Outside the Policy Architecture.14
      4.2.1. Network Manager...........................................14
      4.2.2. AAA Service...............................................14
   5. Policy Conflicts.................................................14
   6. Interoperability.................................................15
   7. Future: Inter-Network and Inter-Domain Communication.............16
   8. Intellectual Property............................................16
   9. Acknowledgements.................................................16
   10. Security Considerations.........................................17
   11. References......................................................17
   12. Editors' Addresses..............................................17
   13. Full Copyright Statement........................................18

 1. Introduction

   Policy-based management involves the use of administratively
   prescribed rules that specify actions in response to defined criteria.
   Rules may be general and abstract, requiring interpretation by the
   policy framework, or very specific.  They are condition/action pairs.

   Several components are critical to the definition of a policy

   1. The ability to define and update policy rules.

   2. The ability to store and retrieve rules.

   3. The ability to decipher the conditional criteria of a rule.

   4. The ability to take the specified actions of a rule, if the
      conditional criteria are met.

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months           [Page 3]
 Internet Draft       Policy Framework Architecture        February 1999

   At the center of this architecture is the policy rule.  Its format and
   storage are critical to a policy based management framework and
   addressed by the policy schema.

   The retrieval and execution of the policy rules can take many forms.
   No single implementation is generically correct.  However, all
   implementations of a policy-based management architecture must address
   several key components.  These are:

   1. Interface to define and update rules - Either graphical or command

   2. Repository to retain and retrieve rules.

   3. Decision point to assess the conditional criteria of a rule.

   4. Enforcement point to execute the actions of a rule, when the
      conditions evaluate to "true".

   Implementations may choose to add policy execution feedback (for
   example, to assess the effectiveness of an action in maintaining or
   changing state).  However, this feature is not addressed in this memo.

   Several other concepts must also be understood and addressed in a
   policy architecture.  These are the scope to which policy rules
   extend, rule conflict detection and resolution, and how
   interoperability is achieved.  Each of these concepts is addressed in
   this draft.

 2. Terminology

   The following terms are derived from those previously defined in the
   Internet Drafts, "Terminology for describing network policy and
   services" (draft-strassner-policy-terms-00.txt) [TERMS] and "A
   Framework for Policy-based Admission Control" (draft-ietf-rap-
   framework-01.txt) [RAPFRAME].  The concepts are summarized here, and
   made more specific, to establish the terminology used throughout the
   remainder of this document.

   Policy Conflict: Occurs when the conditions of two or more policies
      can be simultaneously satisfied, but the actions of at least one of
      the policies can not be simultaneously executed.

   Policy Consistency Checking: An analysis of policies to determine
      their consistency or possible inconsistency with each other.  When
      an inconsistency is discovered, a policy discrepancy is reported.

   Policy Decision: The abstraction of evaluating the applicability of
      policy rules, compiling the applicable rules into a form that can
      be handled by the devices, and activating the compiled rules in the

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months           [Page 4]
 Internet Draft       Policy Framework Architecture        February 1999

   Policy Decision Point (PDP): The point where policy decisions are

   Policy Enforcement: The action of placing the network (or a part of
      the network) in a desired policy state using a set of actions
      specified in a policy rule.

   Policy Enforcement Point (PEP): The point where the policy decisions
      are actually enforced.

   Policy Rule: A specification of a sequence of 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 of
      actions to take>.

   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. Reference Model

 3.1. The Model

   This section describes a Basic Reference Model (BRM), a first-level
   functional decomposition for the policy framework, and describes the
   role of functional components in the model.  The policy architecture
   (see section 4) will build upon this reference model and provide
   function and architecture details.

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months           [Page 5]
 Internet Draft       Policy Framework Architecture        February 1999

             Policy prescriptions
            |      Policy        |
            |  Management Tool   |
                      |  <--- Repository Access Protocol
                      |                  (e.g., LDAP)
            | Policy Repository  |
            | (Directory Server, |  <-- Policy rules
            |  Database, etc. )  |
                      |  <--- Repository Access Protocol
                      |                  (e.g., LDAP)
            |   Policy Decision  |
            |     Point (PDP)    |
                      | <--- Policy Protocol for policy mechanisms
            | Policy Enforcement |
            |     Point (PEP)    |

   Figure 1.    Reference Model Overview

   This reference model permits the implementation of three different
   abstractions of policies using the functional components shown in
   Figure 1 above.  The policy framework does not require that all
   functional components be implemented nor does it specify
   implementation packaging of functional components.

   o The administrators' view of policy is an abstraction of general
     configuration and operational characteristics of the resources in a
     policy domain and of service-level objectives (SLOs) on these
     resources.  SLOs are frequently derived from contractual service-
     level agreements (SLA) and may be probabilistic in nature.  The
     Policy Management Tool may provide significant value-add in the
     level of abstraction and degree of sophistication of the GUI
     presentation and the mapping to and from the lower-level policy rule

   o The policy rules, as stored in the policy repository using defined
     schemata, provide a deterministic set of policies for managing
     resources in the policy domain.  These policy rules are produced by

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months           [Page 6]
 Internet Draft       Policy Framework Architecture        February 1999

     the Policy Management Tools and consumed by the Policy Decision
     Points (PDP).   Policy rules are network device-independent.

   o The policy mechanisms are policy discipline-specific and may be
     implementation-specific.  They are used for configuring the
     necessary logic in the respective network components, the Policy
     Enforcement Points (PEP), used to ultimately deliver the services as
     prescribed at the administrative interface of the Policy Management

 3.2. Policy Prescription

   The administrative user of the Policy Management Tool functional
   component specifies abstract policies that have meaning to the
   administrator and, indirectly, the end user 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
   prescriptions are not generally specific enough to allow for direct
   mapping to network equipment configurations for deployment.  It would
   be unusual for an administrator to specify policy for a specific
   traffic filter, amount of bandwidth, or for specific end-to-end
   latency from an application or user.

   The administrator will typically prescribe policies applying to end
   users, applications, and network devices within a policy domain.
   Policy domain boundaries may be defined in the context of business,
   administrative, geographical, and political constraints.  For end-to-
   end service and service-level prescriptions, coordination between
   policy domains may be specified in either formal or informal service
   level agreements.

   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 deterministic prior to placing them into the Policy
   Repository (see section 5).

   As stated previously, it is not necessary to employ all three
   functional components.  The output of the Policy Management Tool may
   be to a legacy network management product, providing cross-table
   definitions to existing LAN and WAN Network Management services,
   ultimately providing input for device reconfiguration or filter/policy
   creation and implementation in network devices.

   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 architecture framework is to enable
   interoperable implementations of Policy Decision Points using common
   schema in a Policy Repository.

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months           [Page 7]
 Internet Draft       Policy Framework Architecture        February 1999

 3.3. Policy Rules

   As previously noted, the Policy Management Tool functional component
   produces the policy rules and the Policy Decision Point components are
   consumers of the policy rules.  The policy rules specify the logic
   used to deliver the prescribed service and service-levels.  The PDP
   components interpret and may further validate the policy rules and
   then map these rules to the underlying policy mechanisms.

   Generally, 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,
   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 some

   Although other policy repositories are permitted in this framework,
   LDAP is specifically referenced in this architecture as the  access
   protocol and schemata used to store the policy rules.  In LDAP, then,
   the policy rules are represented as a set of object entries that
   include, among others, object classes for policy rules, for policy
   conditions and for policy actions. For LDAP implementations, PDPs may
   detect changes in policy rules by periodic polling, or preferably by
   use of the (currently draft) LDAP event notification mechanisms.
   Other notification mechanisms may also be defined but are 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 of the policy
   rules in the specific network devices.  The PDP evaluates the policy
   rules and generates appropriate instructions for the Policy
   Enforcement Points (PEP) for which it provides the higher-level
   abstraction translation service.  These policy discipline-specific
   and, perhaps, device-specific instructions may, for example, specify
   the traffic shaping parameters for a QOS policy or the address filters
   for a firewall policy.

   It is not in the scope of this architecture framework to specify
   actual mechanisms, but to provide a common interface through policy
   rule abstraction for access to the actual mechanisms.

 4. Architecture

   The policy architecture is 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] and as bandwidth brokers. It is important to
   separate out the functional components and describe the relationships
   between them. That is the purpose of this section and Figure 2.

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months           [Page 8]
 Internet Draft       Policy Framework Architecture        February 1999

   Note: This is an architecture of policy functions and, as such, it
   does not describe any implementation details such as distribution,
   platform, or language.

         Policy prescriptions
        |      Policy        |  Functions:  Policy Editor
        |  Management Tool   |              Rule Translation
        +---------+----------+              Rule Validation
                  |  <--- Repository Access Protocol
                  |                  (e.g., LDAP)
        | Policy Repository  |
        | (Directory Server, |  Functions:  Storage and Retrieval
        |  Database, etc. )  |                of Rules
                  |  <--- Repository Access Protocol
                  |                  (e.g., LDAP)
        |   Policy Decision  |  Functions: Policy Trigger and
        |     Point (PDP)    |               rule locator.
        +---------+----------+             Device Adapter
                  |                        State and Resource Validation
                  | <--- Policy Protocol for policy mechanisms
        | Policy Enforcement |  Function: Execution of specified Actions
        |     Point (PEP)    |            Device State and Resource
        +--------------------+              Validation

   Figure 2.    Policy Architecture Functional Definition

 4.1. Functional Components of the Policy Architecture

   The Policy Management Tool is composed of policy editing, rules
   translation and validation functions.

   The Policy Decision Point is composed of trigger detection and
   handling, rule location and applicability analysis, network and
   resource-specific rule validation and device adaptation functions.

   Policy Enforcement Points are responsible for execution of actions,
   and may perform device-specific condition checking and validation.

   Each of these functions are reviewed in the following sections.

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months           [Page 9]
 Internet Draft       Policy Framework Architecture        February 1999

 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 Policy Management Tools.  It could be
   implemented as a drag-and-drop GUI, be a simple Web-based form, and/or
   support a command line or scripting interface.

   Policy prescriptions and rules may be of several forms.  Probabilistic
   prescriptions 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,
   perform Premium Service". There is wide latitude in the level of
   abstraction and function of the policy editor UI.

   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.  However, it is
   not beyond the scope of the interface to indicate the erroneous rule
   conditions or actions, or display the pre-existing policy rules that
   are in conflict.  Further rule definition or update would then be the
   responsibility of the administrator.

 4.1.2. Rule Translation

   Translation of general policy prescriptions or SLOs into specific,
   actionable policy rules is performed by the Rule Translator function.
   Mapping a policy prescription with its associated parameters to the
   specific policy rules and formats pertaining to that service is
   accomplished in this component.

   It is expected that QoS, DHCP, IPSec and other policy rules (schema
   and semantics) will be defined.  Using QoS as a example, the Rule
   Translator would take general policy prescriptions related to the
   specification of "normal" or "premium" service, and translate these to
   the specific format defined for QoS policy.

   As another example, the following policy prescription could be
   defined, "Premium Traffic between Point A and Point B".  This could be
   translated into the following policy rules:

   o source = 10.24.195.x, dest = 10.101.227.x, any protocol, perform
     Premium Service action

   o source = 10.101.227.x, dest =10.24.195.x, any protocol, perform
     Premium Service action

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months          [Page 10]
 Internet Draft       Policy Framework Architecture        February 1999

   where the Premium Service action is to mark packets with DS byte 2.
   (In this example, the network has been configured to treat packets
   with a DS byte 2 as premium service packets.)

 4.1.3. Rule Validation

   The Rule Validation performs checking of a policy prescription and/or
   rule, and returns the results of this checking.  Two kinds of
   conflicts should be detected:

   o Syntactic, semantic, or logical issues in the rule definition.  For
     example, a rule may be defined stating that "Premium traffic at 50
     Mb/s should run between and".  This is
     syntactically valid but semantically wrong since it specifies the
     same source and destination address.

   o Static conflicts with currently existing rules.  For example, an
     administrator may define two rules stating that "A maximum of 10
     video conference channels are allowed on NetworkA", and that "8
     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

   Not all policy conflicts can be detected by the Rule Validation
   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.

   As mentioned above, the validation performed in this component is off-
   line validation.  On-line validation occurs within the State and
   Resource Validation component, discussed in 4.1.6.

 4.1.4. Rule Storage and Retrieval

   Once a rule has been translated and verified, its storage in the
   repository is required.  Utilization of policy rules to maintain or
   change system/device state requires retrieval of these rules from the
   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.1.5. Policy Trigger and Rule Location

   Triggers to evaluate one or more policy rules include events, polling,
   and system/component requests.  The detection of an event, the receipt
   and processing of a request, or the monitoring of a polling interval

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months          [Page 11]
 Internet Draft       Policy Framework Architecture        February 1999

   are the functions of the Policy Trigger function.  Using the data or
   parameters in the trigger, this function locates applicable rules in
   the policy repository.  The State and Resource Validation function
   (Section 4.1.6) actually performs the policy condition evaluation.

   Event triggers could be time of day, repository update, receipt of an
   SNMP trap, notification of user logon, etc.

   Requests could be a query from a PEP* component for a policy decision.
   The Policy Trigger and Rule Locator:

   o Receive the query

   o Locate rules which match the parameters in the query

   o Invoke the State and Resource Validation to evaluate the "matched"
     rule conditions (e.g., authenticating with AAA Service and/or
     checking resource settings)

   o Send a decision back to the initiator of the query, perhaps in a
     device-specific format as specified by the Device Adapter (4.1.7).

 4.1.6. State and Resource Validation

   Evaluation of policy conditions may involve multiple components (e.g.:
   the policy server and the device). When evaluation applies to a single
   device this function may be co-located with the PEP.

   The Validation components gather, (optionally) store, and monitor
   network state and resource information. Upon a request to evaluate a
   policy rule's condition set, the Validation function uses this
   information and returns a determination of True or False.

   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. If requested resources are
   available, then the actions of a policy rule may be executed. 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.

   The state of the network and its individual resources may be obtained
   by applying measurement, estimation, protocol-specific query, or other


   * The device may detect an event related to its operation and send
     that event to the Policy Interpreter.

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months          [Page 12]
 Internet Draft       Policy Framework Architecture        February 1999

   techniques. In addition, standard management interfaces, like SNMP,
   will be utilized. Regardless of how the information is obtained, state
   and resource data can be (optionally) locally stored/cached by the
   Validation components for quick retrieval and processing.

 4.1.7. Device Adapter and Execution of Policy Actions

   The Device Adapter function takes the canonical representation of
   policy rules (as stored in the Policy Repository) and maps them into
   device-specific mechanisms. The device adaptation allows different
   protocols (e.g., COPS, Telnet/CLI, SNMP, network manager proprietary
   interface) to be used to communicate with the network systems and

   It is the responsibility of the Device Adapter component to determine
   which network devices are affected by a policy rule, and then to make
   decisions based on the actual network devices' capabilities.
   Decisions that need to be made include the:

   o Protocol for communication to the network element

   o Device-specific mechanism that must be employed to implement and
     execute the rule action.  For example, a traffic filter and a
     policer instance could be installed on an edge device.

   The Device Adapter is informed of changes in the Repository/Data Store
   or in the managed environment by the Policy Trigger and Rule Locator

   In attempting to apply policy actions, the Device Adapter may
   determine that a run-time conflict exists at one or more network
   elements.  Although these conflicts occur, the handling and
   determination of run-time conflicts and other errors are beyond the
   scope of this document.  They are implementation-specific issues.

 4.2. Interfacing with Components Outside the Policy Architecture

 4.2.1. Network Manager

   Existing network management applications can play an integral role in
   a comprehensive policy architecture.  The Network Manager can be used
   to configure network elements based on the definition of policy rules.
   It can be used by the Policy Interpreter to install a device-specific
   mechanism on a network element to implement a rule.  A network
   monitoring application provided by the Network Manager could be used
   for independent policy validation.

   The Network Manager would also be useful for accessing the network
   topology.  For example, the PDP could use the Manager to determine
   which network devices are edge devices (for DiffServ QoS policy
   management), their types, and their capabilities.

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months          [Page 13]
 Internet Draft       Policy Framework Architecture        February 1999

 4.2.2. AAA Service

   The AAA (Authorization, Authentication, and Accounting) Service could
   be used by several of the components within the policy system.  For
   example, it could be used by the PDP to determine if a dynamic request
   for service is allowed.  Or, it could be used by the Rule Validation
   to ensure that the administrator submitting a policy prescription has
   the necessary privileges.

 5. Policy Conflicts

   A policy conflict occurs when two or more actions are expected to
   execute at the same time but are inconsistent with each other. For
   example, unless identified with appropriate precedence rules, a policy
   rule specifying that "all engineers get bronze service" is in conflict
   with another rule defining that "the lead engineer gets gold service".
   The actions may be linked to one or more policies.

   A conflict may be determined before execution of the policy is
   attempted. This function is represented in the policy architecture as
   the "Rule Validation" (section 4.1.3). For example, the conflict may
   be detected at the time the policy is entered into the Policy
   Repository or when the policy is loaded by the PDP.

   A conflict may also be determined when the policy decision is made at
   the PDP. An example of when this type of conflict can occur is when
   one policy server loads a policy into a device and a second policy
   server attempts to load a conflicting policy.

   Conflict detection is an important aspect of a policy architecture.
   However, various mechanisms and degrees of sophistication exist to
   support this functionality.  A generic algorithm is not defined in
   this document.

   Regarding conflict resolution, again, various mechanisms and degrees
   of sophistication exist in implementations.  The policy schema does
   specify 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 not a part of this architecture.

   Note that it is not a conflict when the resources required to execute
   an action are not available. This is an execution error.

 6. Interoperability

   The architecture defined by this memo defines two types of entities
   that access the data repository: the administrative tools and the
   policy decision points. Both of these entities require
   interoperability with the data repository on at least two levels.

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months          [Page 14]
 Internet Draft       Policy Framework Architecture        February 1999

   The first level of interoperability is on the data schema 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

   The second level of interoperability is on the data access level.
   Initially, the policy framework chooses LDAPv3 (or higher) as the
   protocol to access the repository. Assuming a compliant LDAPv3
   implementation, data access should be interoperable.

   However, the current LDAP standards are not fully sufficient to ensure
   data repository interoperability. Two 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,

   o Transactional integrity: the ability of the repository to ensure
     that a set of related operations are completed as a set.

   Interoperability problems will occur if implementations choose to use
   proprietary change notification mechanisms or implement notification
   in a non-consistent fashion.

   Lack of transactional integrity will result in interoperability
   problems since implementations may update objects in different orders.
   This could cause data repository corruption. This architecture is
   dependent on other IETF Working Groups'efforts to define and
   standardize missing LDAP 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

   The area of inter-domain communication for policy service requests is
   an ongoing research topic. Protocol requirements, message contents,

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months          [Page 15]
 Internet Draft       Policy Framework Architecture        February 1999

   etc. are still under study within several IETF working groups
   including 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 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

 9. Acknowledgements


 10. Security Considerations

   Security and denial of service considerations are not explicitly
   considered in this memo.  However, the implementation of the policy
   architecture must be secure as far as the following aspects are
   concerned. First, the mechanisms proposed under the framework must
   minimize theft and denial of service threats. Second, it must be
   ensured that the entities (such as PEPs and PDPs) involved in policy
   control can verify each other's identity and establish necessary trust
   before communicating.

 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.

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months          [Page 16]
 Internet Draft       Policy Framework Architecture        February 1999

   [IPSEC] Sanchez, L.A., Condell, M.N., "Security Policy System",
       Internet Draft,  <draft-ietf-ipsec-sps-00.txt>, November 1998.

   [RAPFRAME] Yavatkar, R., Pendarakis, D., Guerin, R., "A Framework for
        Policy-based Admission Control", Internet Draft, < draft-ietf-
        rap-framework-01.txt>, May 1998.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels", RFC 2119, BCP 14, March 1997.

   [SCHEMA] Strassner, J., Ellesson, E., "Policy Framework Core
        Information Model", Internet Draft, <draft-ietf-policy-core-
        schema-01.txt>, February 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

   Lee Rafalow
   IBM Corporation, JDGA/501
   4205 S. Miami Blvd.
   Research Triangle Park, NC 27709

   Phone:  +1 919-254-4455

   Robert Moore
   IBM Corporation, BRQA/502
   4205 S. Miami Blvd.
   Research Triangle Park, NC 27709

   Phone:  +1 919-254-4436

   Glenn Waters
   Nortel Networks
   310-875 Carling Avenue,
   Ottawa, Ontario K1S 5P1

   Phone:  +1 613-798-4925

   Andrea Westerinen
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA  98052

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months          [Page 17]
 Internet Draft       Policy Framework Architecture        February 1999

   Phone:  +1 425-705-2553

   Jeff Wheeler
   Nortel Networks
   14508 134th St. KPN
   Gig Harbor, WA  98329

   Phone:  +1 425-637-2953

 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.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an

 Waters, et. al.     Expires: Feb 26, 1999 + 6 months          [Page 18]