Subject: draft-ietf-policy-arch-proposal-00.txt

From: Raju Rajan <[email-masked]>
Date: Mon, 22 Feb 1999 20:23:16 +0000

Internet Engineering Task Force                        Raju Rajan
INTERNET DRAFT                                        Sanjay Kamat
22 February 1999                                              IBM

          A Proposal for a Simple Policy Framework and Architecture
                 draft-rajan-kamat-policy-arch-proposal-00

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 learn the current status of any Internet-Draft, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 
Directories on ds.internic.net (US East Coast), nic.nordu.net 
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

Copyright Notice

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

Abstract

Many new services defined in the IETF have a regulatory component, i.e., network 
administrators have to decide what users, applications or hosts should have 
access to what resources/services under what conditions. Large-scale deployment 
of such services is critically dependent on the presence of a network-wide 
policy infrastructure that allows Internet Service Providers (ISPs) and 
corporate administrators to regulate the network rather than configure 
individual devices. A key component of this effort is to evolve standards-based 
means of representing and storing policy information in a unified manner, with a 
focus on schema for storing QoS policy information in directories. This document 
presents concepts, terminology, a policy framework and requirements for such a 
definition.

1.0 Introduction
The Internet is transitioning from a best-effort service model to one capable of 
providing differential packet treatment on various time-scales and levels of 
granularity. The IETF has developed several approaches to providing QoS in the 
Internet such as RSVP, ISSLL, MPLS, etc., and also a large and comprehensive 
suite of security protocols and mechanisms to allow user authentication, 
encryption and data compression [IPSEC]. While some mechanisms for regulation of 
services are best provided within protocols themselves, it is very dangerous to 
completely isolate policy definition for different services from one another, 
for several reasons. 
* Different services may benefit by using common policy transport mechanisms 
and semantics.
* Policies regarding different services are defined using common categories 
such as users, applications, hosts, etc. Administering these separately for 
each service could be time consuming and messy.
* Policies for different protocols may have interaction effects. For instance, 
network resources are wasted if a QoS policy reserves bandwidth for a flow 
that another security policy forbids.
* ISPs and corporate administrators would prefer to define new hybrid services, 
such as VPNs that combine security and QoS features. These higher level 
services need to be administered in a uniform manner, which would be best 
done given a common policy infrastructure.

However, given the diverse needs of different environments and the heterogeneity 
of information availability and functionality in network devices, the evolution 
of a single ubiquitous policy solution is very ambitious. This document does not 
attempt such a silver-bullet, one-size-fits all solution. What we instead seek 
to do is 
1. Derive a common terminology and conceptual framework for policy-based network 
control
2. Develop an appreciation for the policy needs of current services, with an 
emphasis on QoS services, 
3. Distil from these a simple, common architecture that illuminates our 
workspace,
4. Present an overview of existing and proposed "pieces of the puzzle" that may 
be usefully employed to implement the architecture,
5. Show that the architecture assumed does not restrict the solution space by 
outlining different feasible enhancements and extensions, and
6. Obtain requirements for and constraints on a common policy representation 
that may be stored in a directory ("directory schema") with a focus on 
Quality of Service.

A key motive for this effort is the drive to evolve standards-based means of 
representing information ("schema") in a unified manner, and storing such 
information in LDAP-accessible directories. This document presents concepts, 
terminology, a policy framework and requirements for such a definition. 

2.0 Policy : Terminology and Conceptual Framework
In this section we develop some basic terms and concepts that will allow a 
shared understanding of the requirements for a policy infrastructure with an 
emphasis on QoS policy.

2.1 Conceptual Hierarchy 
Given the wide and varied usage of the term "policy", it is imperative that the 
word be clearly defined in the networking context. As a starting point, we shall 
use policy to denote the unified regulation of access to network resources and 
services based on administrative criteria. A complementary perspective on policy 
is to think of it in terms of (relatively) static performance goals or 
operational rules for a dynamic network environment. A policy infrastructure is 
the collection of information models, protocols and services that allow the 
intentions of administrators to be represented, stored, communicated and 
translated into instructions executed at various network elements that encounter 
packet streams. While there are innumerable features of policy that render 
simplistic any hierarchical representation of this infrastructure, we present a 
conceptual model that describes, for purposes of exposition, different levels of 
abstraction at which regulation may be expressed and exercised. 

Network Level View: This is a high-level perspective that incorporates topology, 
connectivity, end-to-end performance objectives, expressed in terms of static 
and dynamic resources in the network. The human administrator interacts with the 
network usually through a human friendly language or intuitive representation 
such as a GUI. Such a representation may also contain aspects of network 
monitoring, where the current state of the network is represented so that the 
administrator may ascertain the extent to which policy is enforced in the 
network. As an instance of a network level view, an administrator may require 
that all http traffic from server A to managers in campus B (see figure 2) be 
transmitted through a gold-QoS, high-security tunnel with a 2 MBps reservation. 
The definition of "gold-QoS" and "high-security" may be deterministic or 
probabilistic, but we assume that these are fairly well defined in-context, and 
not vague and fuzzy.

Role or Group Level View: A network level policy injunction requires different 
behaviors at various network nodes depending on their roles within the network. 
For instance, with respect to the above example, all firewalls and access 
routers in campus B have a similar role to play. They must be instructed to 
permit encrypted traffic from server A into campus B. Thus, the network view may 
be resolved into distinct role or policy group level views, which correspond to 
the policy objectives and requirements at like network nodes or interfaces. A 
particular network element may play several roles, and several such elements may 
play the same role. Each network element is controlled by the policies 
corresponding to all the roles that it plays. The role level policy view is 
resolvable into a collection of atomic injuctions called policy rules. Each 
policy rule corresponds to a statement of the form
           If <PolicyRuleCondition> then <Action>
where <PolicyRuleCondition> is expressed in terms of administrative categories 
such as users, hosts, applications, etc., and <Action> identifies the associated 
privileges or deserved treatment. A simple policy rule for a firewall in campus 
B that would allow all IPSec packets from server A would have the condition 
"Host: Server A; Protocol: IPSec" associated with the action "ALLOW". 

Device-specific or Configuration Level View: Each network node has vendor-
specific resource allocation mechanisms and packet forwarding paths, and role 
level rules need to be ultimately translated into device-specific instructions. 
One aspect of a device specific view is the maintenance of caches, filters or 
classifiers to be placed in the datapath to identify the treatment associated 
with individual packets. A second aspect is the reservation of resources and the 
delivery policy mandated services. For instance, to ensure that http traffic 
from server A is assured of bandwidth, it may be necessary to insert a 
classifier in an access router, and set the WFQ weights appropriately.

In order to evolve a schema, it is necessary to identify the level at which 
policy is to be represented and standardized. The network level view of policy 
is intimately tied with the to the remaining network management infrastructure, 
and it is unclear what would constitute an intuitive and yet flexible object 
model. Further, it involves an implicit knowledge of topology, and it is 
difficult to automate the translation of such a view to the device level. 
Consequently, the network level view is best left to different network 
management vendors to design and customize. At the other extreme, the device 
level view is too vendor-specific and scales poorly to large networks. In the 
rest of this document, we assume that role level views are sought to be 
standardized in schema, and that these are composed of "policy rules".

2.2 Needs of QoS Policy
In order to obtain some insight into the semantics of policy rules 
required for QoS and other services, we present an over-view of the 
policy needs of integrated and differentiated services.

Integrated services with RSVP signaling approach seeks to provide per-flow QoS 
assurances with dynamic resource reservation. A flow is defined by the 5-tuple  
(source address, destination address, protocol, source port, destination port). 
RSVP is a protocol for reserving network resources for unicast or multicast 
flows, with stringent requirements satisfied by a guaranteed service, and more 
flexible requirements by a relaxed controlled load service. In this context, 
there is need to provide policy control of individual flows, and regulate their 
ability to reserve network resources. RSVP is capable of opaquely transporting 
policy-objects which may be used by policy-aware nodes to derive more 
information about the user, application or end-points of communication. The role 
of policy allows for highly granulated interactions with billing, accounting or 
accreditation systems resulting in informed control over the size and nature of 
the QoS reservations in the network. (See {RAP} for a discussion of policy based 
admission control framework and sample policies). Differentiated services 
(DiffServ), on the other hand, are aimed at traffic aggregates that may not 
correspond to fine-grained flows. The frequency of signaling is much coarser, 
and may occur through a variety of mechanisms (bandwidth brokers, off-line 
communication, service level agreements, etc.) The DiffServ approach relies more 
on administrative control of bandwidth, delay or dropping preferences, rather 
than per-flow signaling protocols to communicate service level information to 
network elements.  For such services we wish to enable flexible definition of 
class-based packet handling behaviors and class-based policy control. See 
{DIFFSRV} for a discussion of DiffServ framework and sample behavior/service 
descriptions).

While these mechanisms address the issue of how to provide quality of service, 
the complementary issue of which packets are eligible for what services is a 
policy issue. For instance, an e-tailer may wish to provide preferential 
treatment to real-time transaction oriented web-traffic. Or an ISP may seek to 
ensure that voice-over-IP is assigned to a low-loss, low-delay class of service, 
while limiting the number of simultaneously supported voice calls. Or consider a 
network administrator of an RSVP capable intranet who wishes to restrict 
individual Controlled Load reservations from certain sources during the day to a 
certain token rate and also limit the total bandwidth of such reserved flows. In 
these and other examples, the utility of QoS services depends heavily on the 
presence of mechanisms for administering them. In fact, large-scale deployment 
of QoS services is critically dependent on the presence of a network-wide policy 
infrastructure that allows Internet Service Providers (ISPs) and corporate 
administrators to control the network rather than configure individual devices.

Speaking broadly, the policy needs of QoS administrators are of three kinds. 
First, administrators would like to be able to provision networks, i.e., earmark 
resources for use by certain types of traffic. Second, they would like to 
control the terms and conditions under which users are able to reserve bandwidth 
in the network. Third, they would like to substitute one QoS service for 
another; for instance, require that integrated service categories be provided 
using comparable differentiated service categories. We now closely examine these 
different requirements.

2.2.1 Policy Categories
 Starting with the broad aim that administrators require mechanisms to control 
access to QoS resources, we are drawn to describe the specific bases or criteria 
for discrimination in QoS networks. These would include:

1 The end-points of communication: The source and destination IP addresses may 
be directly obtained from the IP packet, as long as no intermediate proxies 
that encapsulate packets are involved. Other information, such as 
source/destination MAC addresses or other layer 2 end-point information may 
be used to regulate communication.
2 The route or path of communication: The treatment of packets and the 
availability of reservable resources depend on the route along which the data 
packets flow. For instance, packets flowing over a dedicated line may require 
no particular reservation, while the same packets routed over a backup public 
network would need special treatment. Simplistic routing-based policies may 
be described based on the incoming or outgoing interfaces of devices at which 
the policy is enforced.
3 Communicating users or groups: The identity and organizational status of 
people involved in communication plays a large role in determining their 
access to network resources. Rich and versatile policy solutions are made 
possible by the availability of this information is available within the 
network, for instance, using signaling protocols such as RSVP.
4 Application information: The characteristics of the particular application 
generating traffic, whether it has real-time requirements, for instance, will 
determine the quality and nature of resources allocated to the traffic. While 
some such information may be deduced from the port and protocol numbers in IP 
packets, a more comprehensive solution that does not involve laborious 
content inspection and state maintenance is possible only if the traffic 
generating host is involved in signaling application requirements.
5 Dynamic Network Characteristics: It is often useful to take the availability 
of resources in the network, or their scarcity, into account while allowing 
or denying the use of resources by a particular flow or group of flows. 
6 Accounting information: The ability to base resource access decisions on the 
availability of credits or tokens is seen as an important application of 
policy.

2.2.2  QoS Policy Goals 
The criteria listed above for discriminating amongst flows or groups of flows 
are not peculiar to QoS policy. However, there are specific ends that are sought 
to be achieved in the case of integrated or differentiated services through 
control over resource allocation. 

Integrated services secured through the use of RSVP signaling: RSVP has 
been devised to explicitly carry and process policy objects together with 
reservation requests and responses. In its simplest form, policy may be 
used to control the number, size and the nature of RSVP reservation 
requests depending on the information in the header of RSVP Path and Resv 
messages, or the TSpec and RSpec parameters. This use of policy in such an 
environment allows enterprises to be able to police QoS requests on a per-
flow, per-user or per-application basis. However, a number of interesting 
and important forms of policy may only be expressed using policy objects 
carried with RSVP signaling messages These include objects that identify 
and authenticate users, applications or hosts, define the relative 
(reservation) priorities, carry accounting and charging information, etc.

Proxy RSVP: This refers to the use of policy to control the establishment 
of RSVP tunnels between routers or other intermediate devices within the 
network, and the use of these QoS tunnels by traffic flowing through these 
intermediate devices. There are three common proxy instances:
* RSVP tunnels for best effort traffic,
* RSVP aggregation, i.e., combining multiple RSVP tunnels into one,
* Other QoS protocol to RSVP translation.

Differentiated services secured through provisioning: This includes the 
case of using policy to specify and control DiffServ within a domain, and, 
in an inter-domain scenario, control bilateral agreements across peer 
network boundaries. In such cases, policies are used to map across the two 
domain specific semantics, and enforce access control restrictions, such 
as ensuring that the amount of in-profile traffic is within the specified 
contractual limits.

Multiple QoS Protocols Tunneling through DiffServ: RSVP or other QoS 
protocols may be used within a domain, being mapped onto differentiated 
services across domains. In such cases, policies are needed at the domain 
boundary  to translate between signaled and differentiated service 
semantics, to enforce traffic monitoring and to exercise access control 
over network resources. 

2.3 Processing Policy Rules
If we conceptualize policy control in terms of an infrastructure designed to 
translate administrative intentions into transformations effected on packet 
streams, then its complexity arises from the need for mechanisms that gather 
spatially dispersed, dynamic network information and process them to make policy 
decisions. Consider a policy that allows traffic from certain users to be 
granted preferential QoS treatment. The complexity of implementing such a policy 
depends on a variety of factors. On a policy capable end-host, it may be 
relatively easy to map the login id of the user to their name, and based on a 
table lookup, mark packets with the ToS pattern that connotes preferential 
service in the rest of the provisioned network. In the fortuitous case that 
users are tied to their workstations, network nodes may access a table that maps 
users to host addresses, and then use source or destination addresses in packet 
headers to grant preferential QoS treatment. Or a QoS protocol such as RSVP may 
be used to carry user information as policy objects, used to deny or grant 
bandwidth requests. Or, in the case of users dialing up from home, user 
information may be obtained from a protocol such as Radius, and then used by the 
access router to mark ToS bits of the packet stream. In any event, policies are 
expressed in terms of categories such as users, hosts, applications, account 
balances, etc. Network elements that handle packets need to (a) associate the 
information in the packet header with the policy category, (b) evaluate the 
policy conditions to see if they hold, and (c) carry out appropriate operations 
on the packet. 

2.3.1 Associating policy categories with packet information
The mapping of policy categories to header information present in data packets 
may be static or dynamic; and may be made in a variety of different ways.
* If policy categories are identical to, or can be immediately deduced from 
data packets, the mapping of high level policy to enforcement is direct and 
static. An simple example of this is when policy is expressed in terms of 
source IP addresses.  Direct mechanisms do not require state.
* Sometimes, is suffices to refer to lookup tables for resolving policy 
categories into packet header based conditions. The example is when users are 
tied to host addresses, but for administrative convenience policies are 
expressed in terms of users than host addresses. In this case the mapping is 
static, but indirect. 
* Policy categories may be obtained in context, through state that has been 
established in the operational environment. This is a very important case, as 
with user names or application information that can be obtained directly at 
an end host.
* The mapping between policy categories and header fields may be dynamic, in 
which case intermediary packets are used to communicate mapping information. 
For instance, policy category information may be transmitted by signaling 
protocols, and used to control the associated data stream. One example is the 
use of RSVP policy objects to ascertain the identity of a dial-up user in 
order to accept or deny a reservation. Note that this identity may now be 
used to put the data stream in a secure (proxy) IPSec tunnel. This latter use 
of information presented through one protocol to deliver a different service 
(cross-service policy function) considerably expands the utility of policy. 
Another instance of the use of intermediaries is when dynamic port number 
information (say for FTP data) is obtained by examining the content of 
signaling packets.
* In addition to obtaining information directly and through intermediary 
packets, a network device may contact a centralized network location to 
obtain information on the policy category a particular flow belongs to. An 
example of such indirect methods is when IP address to FQDN information is 
obtained from a DHCP server, triggered perhaps by an unfamiliar packet stream 
in an access router

2.3.2 Evaluating the Policy Condition
Once the policy categories associated with a packet or packet stream have been 
ascertained, any policy condition involving those categories must be evaluated. 
Typically, conditions involve checking set membership -- does "John Doe" belong 
to the group "Pseudonym-users", or is a certain account balance positive. Now, 
this stage of policy processing is relatively straightforward if the condition 
or relation being evaluated changes slowly or never. User and host groups are 
good examples of such stable policy conditions. However, certain other policy 
categories, such as account balances, are volatile and it is customary to use 
specialized servers and protocols to track their state. So the evaluation of the 
condition is outsourced or specialized information solicited from an external 
entity. An extreme example of  spatially dispersed, volatile information is the 
evaluation of conditions based on network congestion. (Such a condition would, 
however, need precise semantics -- where is this state measured and how -- to be 
meaningfully implemented.)  In this case, information regarding packet losses, 
queue lengths or delays must be solicited from multiple network elements and 
combined in order to evaluate the policy condition.

2.3.3 Executing Policy Actions
There is tremendous diversity of capabilities and execution environments across 
network devices, and the ambitious goal of controlling them through a policy 
infrastructure has to strike the right tradeoff among design objectives. On one 
hand, it is important for policy actions to be clearly specified directives that 
different machines would interpret and execute in a comparable manner, i.e., 
policy must be implementable uniformly across the network. On the other hand, 
policy cannot be specified at the machine instruction or configuration levels, 
even though this would make for precise control. One reasonable compromise is to 
suggest that policy should control standard protocols and behaviors; and not be 
used to define new protocols. This does not preclude the use of policy as a glue 
to define new services by configuring and combining existing mechanisms, but it 
does move away from defining state machines of arbitrary complexity. In short, 
policy actions should parameterize existing protocols or behaviors.

3.0 A Simple Policy Architecture
Considering the great heterogeneity of large networks -- varying device 
processing and storage capabilities, the differential availability of 
information regarding policy categories, as well as different policy 
requirements, control mechanisms and network protocols -- it is improbable that 
an entire policy infrastructure can be based on one single design. In keeping 
with the more restricted aim of this framework document of unifying policy 
representation, we first address architectural requirements for the creation, 
storage and communication of policy rules.

The administrator must be able to view and express requirements at the network 
level. At a minimum this requires a management tool that is capable of creating 
policy rules and storing them in the common format. 

The policy repository is at the core of the architecture for unified policy 
representation. It acts as the memory of the network, and stores policy rules 
for easy retrieval. As policy rules are expressed in terms of relatively static 
categories, and the frequency of information retrieval is expected to far exceed 
update frequency, a directory is well suited to be a repository. 

   o                  o                          
   |   ------------   |      
  / \                / \ Administrator

  Administrative Function

-----               -----
|   |               |   |                           
| * |               | * |
-----               ----- Management tool
             
   Management Function

    -                  -                               
   ---                ---      
  -----              -----    
 -------            ------- Policy Repository
  Policy Storage Function

???                   ??? 
???                   ??? 
???                   ???  Policy Decision Point (PDP)
            
 Policy Decision Function

-----                -----
|&*&|                |&*&| 
| * |                | * | 
-----                ----- Policy Enforcement Point (PEP)                    
 Policy Enforcement Function

                          Figure 1
                     Policy Functional Model

The policy enforcement function (PEF) is the functional entity in the data path 
that delivers network resources to packets. For example, in terms of QoS 
services, the enforcement function may perform policing, buffer management 
scheduling, etc. The PEP queries the policy decision function (PDF) regarding 
specific actions that are to be applied in conditioning the packet stream. Thus, 
the PDP performs the key functions of mapping policy categories to information 
in data packet headers, and of determining which policy rules after evaluating 
the conditions. Note that the PDP is entity that brings together static rules 
and dynamic information required for their enforcement. 

3.1 The Role of Existing or Proposed Standard Protocols 
As shown in the above figure, each of the functions described above may be 
implemented in a distributed or even replicated manner. The management function 
may be spread across multiple management tools, or several tools may 
simultaneously be used to populate the repository. Likewise, the policy 
repository may be replicated or distributed across several directories. In many 
cases, the policy decision function may be substantially located at a 
specialized policy server that communicates with multiple network devices at 
which policy enforcement occurs. The policy decision function may also be split 
across several policy decision points which collaborate in making decisions. If 
multiple functions are not co-located, or if the same function is distributed 
across multiple devices, it is necessary to define standardized protocols for 
communication between different boxes. There are a number of existing and 
proposed protocols and mechanisms that may be usefully employed to realize the 
above architecture, which we discuss in this section. In the next section we 
discuss enhancements to the basic model to provide enhanced functionality.

Directories make good policy repositories, and are commonly accessed using LDAP, 
a lightweight protocol used extensively to communicate information about users, 
hosts and applications. Traditional databases, using a language such as SQL 
provide greater functionality in the repository, at the cost of being more 
heavyweight. While there are many choices of protocols for directory/database 
access from the management tool and PDF, LDAP appears to be favored by a number 
of vendors and users for its ubiquity, versatility and flexibility. LDAP schemas 
are versatile and allow considerable flexibility in choice of back-end directory 
management. Further, the LDAP client-server protocol is widely implemented and 
used for supporting a wide range of directory enabled applications. However, 
there are a number of shortcomings of LDAP that must be clearly understood by 
implementers. (Para on shortcomings of LDAP to be added -- asynchronous 
notification, replication support, security, referential integrity, support for 
"templates", limitations of query language.)

The RAP working group has recently moved to standardize the COPS protocol for 
outsourcing RSVP decision making from a PEF to PDF. This protocol is modular and 
may be extended for other policy outsourcing requirements. More recently, the 
Diameter protocol has been proposed for outsourcing authentication and security 
decision making. Extensions have been proposed to enhance Diameter to handle QoS 
outsourcing as well. 

SNMP is likely to continue as an integral component of the network management 
infrastructure. It can play many roles in implementing the above policy 
architecture. SNMP can be used at the PDF and PEF to record errors, policy usage 
and notify administrators of unusual occurrences within the network. It may be 
used by the management tool to notify the PDF of a policy update (as such an 
asynchronous notification feature is not yet available with LDAP). 

3.2 Enhanced Functionality
The basic functions described above may be extended by vendors seeking to 
enhance flexibility, ease of use, scalability or security. In this regard, there 
are multiple logical functions at which the same enhancement may be usefully 
provided. For instance, it is conceivable that some form of "sanity checking" 
for policy rules is part of each of the above pieces. The "correct" placement of 
extended functionality depends on access to information. For instance, if there 
are multiple administrators in a network, but one physical directory server, 
then the repository function is perhaps best enhanced to handle network level 
sanity checking. Below, we describe some obvious enhancements to each of the 
functions, with the caveat that the list is neither necessary nor exhaustive.

Apart from being a simple input device for policy definition, management tools 
can use intuitive user interfaces to bring together network topology, 
connectivity and performance, with a language for expressing policy categories 
and goals. In this case, management tools function as translators of the network 
level view into a role level view. Such translation ensures that policy is 
uniform across the network, and reduces the need for expensive uniformity 
checks. (As an example for the need for uniformity, consider two firewalls in 
peer campuses that cannot communicate, being configured to use different IPSec 
encryption methods for the same traffic.) Further, management tools can perform 
several sanity checks on rules. They ensure that policy objects are 
syntactically correct, that objects referred to in policy definition exist, that 
policies are uniform across the network, and that multiple rules defined for 
each role are consistent. To the extent that the management tool has access to 
network device functionality and resource availability information, these may be 
included in consistency checking.

Policy repositories vary in their ability to be reliable, secure and 
distributed. They support query languages of differing complexity. Repositories 
enhanced to provide native support for policy categories would be natural 
locations to optimize a variety of policy consistency and sanity checks.

The policy decision function is the merging and processing point for static and 
dynamic information. A variety of protocols different information exchange 
protocols may be supported here, especially those for gathering volatile data 
required for decision making. PDPs may talk to different servers and devices in 
the network, or even to other PDPs, in order to collect billing and accounting 
information, group membership, addressing and routing information, as well as 
resource availability and usage. In addition, a PDF may be aware of the 
resources and capabilities of the PEPs it is connected to, and hence able to 
flag policy rules that cannot be applied because of device conditions.

Some of the shortcomings of existing mechanisms, such as the lack of 
asynchronous notification in LDAP, may be addressed by defining specialized 
protocols between functional entities. 

4.0 Policy Representation Requirements for QoS
The directory provides a convenient repository of the resource regulation 
policies, which may be accessed by a number of different policy decision points. 
The following considerations must guide the evolution of standardized means of 
representing policy, also known as policy schema:

* The schema must be defined at the role or policy group level view, and not at 
the network level nor at the level of device configuration.
* It is assumed that the policy repository will not store volatile information 
required for policy decision making. Hence, the schema must be devised to 
express administrative intent in terms of relatively static categories. The 
policy decision point will map policy categories to identify packet streams 
that need to be regulated.
* The schema definition should be generic enough to support a wide range of 
resource control environments.
* Policy schema must be used to configure and control standardized protocols 
and services, and not as a low-level programming language for networking 
devices.
* A QoS schema must be able to express the needs of provisioning, controlling 
reservations and QoS service substitution.  
* The schema shall be designed to be extensible to the needs of security and 
other network services. 
* From this perspective, it is desirable that the schema facilitates definition 
of a wide range of policies varying in their complexity. Simple policies (the 
common case) should be easy to specify, and there should be sufficient hooks 
to define sophisticated policies within the schema. Using the language 
analogy, an administrator's ability to define complex resource regulation 
policies should not be limited by the structure of the schema, although it 
may be limited by the available implementation of the policy enforcement 
environment. 
* The schema should facilitate simple addition and deletion of new rules, 
automated checks for rule ambiguities, and allow for diverse methods (varying 
in efficiency and ease of implementation) to be employed in the policy 
decision entity to search through rules. 
* While compactness of representation is of concern, it is subordinate to the 
needs of expressiveness and extensibility listed above. 

5.0 Security Considerations

6.0 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.
7.0  References

To be added

8.0  Authors' Addresses

Raju Rajan, 
30 Saw Mill River Road,
IBM Research,
Hawthorne, NY 10532
Phone: 914 784 7260
Email: [email-masked]

Sanjay Kamat
30 Saw Mill River Road,
IBM Research,
Hawthorne, NY 10532
Phone: 914 784 7402
Email: [email-masked]

12.0 Full Copyright Statement

Copyright (C) The Internet Society (1997).  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.

xxx.policy-framework-00.txt	Page 12	02/22/99 
12