Network Working Group G. Waters
INTERNET-DRAFT J. Wheeler
Nortel Networks
A. Westerinen
Microsoft
L. Rafalow
R. Moore
IBM
February 1999
Policy Framework Architecture
<draft-waters-policy-arch-00.txt>
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 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 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
scalable.
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
architecture:
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
line/script.
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
devices.
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
made.
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
|
V
+--------------------+
| 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
representation.
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
Tool.
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
service.
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
|
V
+--------------------+
| 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 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.
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
allowed).
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
devices.
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
functions.
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
results.
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
environment.
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
Director.
9. Acknowledgements
TBD.
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
Email: rafalow@us.ibm.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
Glenn Waters
Nortel Networks
310-875 Carling Avenue,
Ottawa, Ontario K1S 5P1
Canada
Phone: +1 613-798-4925
Email: gww@nortelnetworks.com
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
Email: andreawe@microsoft.com
Jeff Wheeler
Nortel Networks
14508 134th St. KPN
Gig Harbor, WA 98329
Phone: +1 425-637-2953
Email: jwheeler@baynetworks.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.
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
"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.
Waters, et. al. Expires: Feb 26, 1999 + 6 months [Page 18]