Subject: RE: Policy questions

From: Andrew Smith <[email-masked]>
Date: Tue, 22 Jun 1999 12:14:28 -0700

I'll let others answer the first part of your questions. 

Enforcement of policy decisions in PEP devices for RSVP admission policy is
described in the RAG WG documents e.g. in
http://www.ietf.org/internet-drafts/draft-ietf-rap-framework-03.txt and the
succeeding references. Enforcement of other types of policy decisions have
not really been well described in the standards' literature so far - I think
it is left as an exercise for the implementor to work out how to use MIBs
and other configuration mechanisms (e.g. command line/telnet) to make
devices apply the desired rules. IETF is just starting up standards' work in
some of these areas e.g. configuration of diffserv QoS rules (there will be
a number of drafts submitted this week to the diffserv WG on this topic). I
believe that there is work in progress in the AAA WG on how to enforce
policy rules for some other application areas e.g. security policy. 

Right now in the QoS policy area (with the exception of RSVP policy), I
believe that proprietary solutions (e.g. vendor/enterprise MIBs,
command-lines, proprietary uses of COPS) are the only viable mechanisms.

Andrew Smith
RAP WG co-chair

> -----Original Message-----
> From: Pradosh Kumar Mohapatra [mailto:[email-masked]]
> Sent: Tuesday, June 22, 1999 9:10 AM
> To: [email-masked]
> Subject: Policy questions
> 
> 
> Hi,
> I have a few questions regarding the overall operation of the policy
> framwork and
> architecture:
> 
> 1) Is there any specification for the policy server architecture? What
> does it
> mean by 'policy server maintaining a state?.' How do you define the
> states of the
> overall architecture? Is there any DFA or something of that stuff that
> is
> implemented in the policy server?
> 2) How does the actual enforcement of policy in PEP work? Once the
> administrator
> defines some policies in the server, how does it get stored in the PEP
> so that
> when such a condition arises, the PEP will require to send a policy
> notification
> to the PDP?
> 
> I did not get any proper answers to the above questions after going
> through all
> the documents.
> 
> Thanks and Regards,
> Pradosh
> 
> 
> 
>

---

From: [email-masked] (SteveJ)
Date: Tue, 22 Jun 1999 14:38:52 -0700

Hi Pradosh,

> > when such a condition arises, the PEP will require to send a policy
I might be able to help you out here by describing what we do in our PEPs. I
think Andrew did a good job of explaining how the information is passed to
the PEP today by most vendors - several of the policy server vendors use
mechanisms like CLI to 'configure' the PEPs.   We take a slightly different
approach in the PEPs.  First, our PEPs are host-based.  That is, they reside
on clients and servers.  This allows us to change the model slightly because
we have better classification of flows and more resident storage for policy
information. To some degree, this is similar to what the folks at IBM are
doing with their IBM Common Policy Engine (CPE) - a combined PDP-PEP.

We're not convinced that a model where the PEP 'sends a policy notification
to the PDP' is scalable.  After all, even a simple browser page can involve
dozens of flows.  Add dozens of pages and potentially dozens or hundreds of
clients, and you see the problem. Keep in mind that the original
architecture of COPS was inspired by RSVP where the policies would be
associated with per-flow reservations.  While we do support this, we prefer
to have the PDP/policy server set policy objects into our PEP.  We then
watch for flows either in promiscuous mode (if we're a non-intrusive
monitor), as they pass through us (if we're a gateway), or when they're
initiated by the applications (when we're running on the hosts) - we don't
notify the PDP on a per-flow basis.  Our classification engine identifies
the flow start and notifies the local policy agent (or tells the PDP that a
flow has started).  The policy agent looks at our PIB to see if this flow
needs to have one or more policies applied.  If so, it 'configures'  the
enforcement agents to apply the specific policies to the flow.  Depending on
the duration (one of our policy objects) of the policy, the policy may
terminate when the flow does or it may continue until it expires.

So, although this is a bit different than the current RAP framework might
describe, with the updates to their charter, and less reliance on RSVP, we
should see (actually we already are) more scalable approaches in the
relationships of Policy Server, PDP, and PEP.

Steve

----------------------------------------------------------------
Steve Jackowski
President/CEO
Deterministic Networks, Inc.
245M Mt. Hermon Rd. #140
Scotts Valley, Ca 95066

Office: (831) 421-0388 x18
Home office: (831) 426-4001
Mobile: (408) 813-6294
Fax: (831) 421-0394