Subject: RE: multiple clients involved in a policy

From: Andrew Smith <[email-masked]>
Date: Fri, 25 Jun 1999 17:54:20 -0700

And, just to confuse things, the "R" in RAP now stands for "Resource" not
"RSVP". We just re-chartered the WG to start looking at ways to communicate
different types of info between PDPs and PEPs - it's now the "Resource
Assignment Protocol" WG - we thought that backwards compatibility in TLAs
was a Good Thing even though the name could have been better.

BTW, the charter that is currently on the RAP web page referenced by Hugh
[1] needs to be fixed since right now it says we're going to some things
that the diffserv WG is actually going to do.

Andrew Smith
RAP WG co-chair

> -----Original Message-----
> From: Hugh F. Mahon [mailto:[email-masked]]
> Sent: Friday, June 25, 1999 2:54 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: multiple clients involved in a policy
> 
> 
> Hi Pradosh,
> 
> > 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
> 
> 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