Subject: multiple clients involved in a policy

From: Pradosh Kumar Mohapatra <[email-masked]>
Date: Wed, 23 Jun 1999 12:34:59 -0700

Hi,
Thanks for the answers to my previous questions regarding PEP and PDPs.
From the documents that I read, I could come to the conclusion that the
policy execution, right now is a single client-to-server communication
where in, if some policy condition is triggered on the PEP, the PEP
sends a COPS message to the PDP, the PDP evaluates it and sends the
decision (some action to be taken based on the condition) to the PEP.
I am not sure how the current framework will provide space to do the
following:
say a policy is entered by the administrator which states if event e1
occurs in device d1, event e2 occurs in device d2, ...., then do some
action a1 in d1, a3 in d3 ... etc.

e1, e2, .... can be events (transitions in the document by Silvano)
occuring at the same time in d1, d2, ... or they occur in different time
frames.

Does the current architecture support this?
If so, then how?

Regards,
Pradosh

---

From: "Hugh F. Mahon" <[email-masked]>
Date: Fri, 25 Jun 1999 15:53:46 MDT

Hi Pradosh,

> Does the current architecture support this?

As Andrew and Steve have pointed out, the PEP is on the device 
enforcing the policies.  The PDP can be on the device with the PEP or 
remote.  I agree with Steve's comments about scalability of PEPs and 
PDPs separated across the network. 

The question of how the PEP and PDP work and their roles in policy 
operations comes up quite often.  I think many people have ideas of how 
these things relate, but you are right that for general policy these 
components have not been well documented.  Here is my attempt at 
describing the components of a policy system :-).

The functional components can be broken out as follows:

        - policy UI (policy authoring/editing)
        - policy repository
        - policy server
        - policy interpreter
        - Policy Decision Point (PDP)
        - Policy Enforcement Point (PEP)

As far as implementation of a policy system, these functional 
components could all stand alone, or be grouped in various ways.  Much 
of the discussion has centered around the data stored in the 
repository.  A directory service using LDAP as its interface is the 
current focus for the role of repository.  The other components are 
largely undiscussed to date.  Of course there could be other 
components as part of a policy management system, those listed above 
are the minimal set.  An architecture which defined the interfaces 
between these components would allow extensibility in an interoperable 
way. 

The terms PDP and PEP derive from the work of the RAP working group 
[1].  The terms PEP and PDP are described in the document "A Framework 
For Policy-based Admission Control"[2].  The usage models described 
for these terms is strongly tied to a signaled QoS environment, which 
after all is what RSVP, the 'R' in RAP, is all about.  

These terms still make sense for other policy usage since decisions 
must be made and enforced (or acted on).  

One way to group components is to have the PDP and PEP on the same 
device, so that when a decision is required the activities are all 
local.  This allows for efficient operation if the device can support 
processing and storage of decision data, and all of the effects are 
local to the device.  Note that this description does not specify 
where the policy interpretation is located.  Policy interpretation may 
reside on a separate system and convert policy into a 'native' 
configuration format for a given device.  In this way, although a 
device would contain the ability to make decisions, it does not need 
to have the capability to deal with general policy descriptions.  The 
policy would be translated into the more easily consumed 
device-specific form before reaching the device.  Policy 
interpretation (or translation) may reside with the PDP or separately.

As noted in Steve's message, it is important to understand the cost to 
the network of sending decision requests and responses across the 
network.  PDPs which are remote from PEPs would likely be used for 
highly-granular activities.  Examples include the establishment of a 
long-term connection, such as for a teleconference.  Following Steve's 
example, if signaling were used to establish QoS for a user browsing 
the Web, it would make more sense for the PEP to make a request to the 
PDP about the first connection to the Web server, and the PEP to cache 
the answer and reuse the PDP's response for successive connections to 
the same Web server. 

A PEP is also not limited to using one PDP.  For example, a PEP may 
use a remote PDP for handling RSVP requests, but may use a local PDP 
for handling DiffServ-like operations. 

Of course, if the result of a policy decision is to affect more than 
one device (or a device other than the one where the decision request 
was initiated) it may make sense for the PDP to be remote from the 
PEPs.  How such a relationship would be described has not been defined.

Another interesting document to read is "Policy Framework Architecture" 
[3].

The Policy server is another component which has not been discussed in 
detail relative to the work of the Policy Framework WG.  A central 
repository is important, but there are other aspects of information 
management other than storage and retrieval which must occur between 
the policy authoring tool and the policy interpreter.  The policy 
server, and possibly other components (for such tasks as policy 
conflict detection, etc.), would fit in this space.

References:

[1] IETF RSVP Admission Protocol (RAP) Working Group, 
    http://www.ietf.org/html.charters/rap-charter.html 
[2] "A Framework For Policy-based Admission Control", Raj Yavatkar, 
    Dimitrios Pendarakis, Roch Guerin, 
    http://www.ietf.org/internet-drafts/draft-ietf-rap-framework-03.txt
[3] "Policy Framework Architecture", G. Waters, J. Wheeler, A. 
    Westerinen, L. Rafalow, R. Moore
    http://www.ietf.org/internet-drafts/draft-waters-policy-arch-00.txt

I realize that this leaves room for more questions, but I hope it also 
answers some questions.

Thanks,

Hugh Mahon              |__|
[email-masked]       |  |
                           |\  /|
                           | \/ |

 "We can lick gravity, but sometimes the paperwork is overwhelming."
                         -- Werner Von Braun