Subject: RE: COPS message content

From: Andrew Smith <[email-masked]>
Date: Mon, 19 Jul 1999 15:46:46 -0700

Pradosh,

This is partly a question for the RAP WG list.

The base COPS protocol
(http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-06.txt) does not
define the contents for the ClientSI objects.

So far the only COPS client-type fully defined is that for use with RSVP.
The contents of the ClientSI objects in this application are defined in
section 2.3 of
http://www.ietf.org/internet-drafts/draft-ietf-rap-cops-rsvp-05.txt. This
section includes by reference many of the object formats from the RSVP
protocol itself (RFC2205). It did not make sense to try to force these
existing RSVP objects into a different common format for this application.

For the "COPS for Provisioning" application, there is a recent proposal for
the contents of the ClientSI objects in
http://www.ietf.org/internet-drafts/draft-ietf-rap-pr-00.txt. As you
correctly point out, this does not currently reflect any of the
syntax/organisation of LDAP schemas from which the provisioning rules might
be derived. The working assumption (I think) is that a PDP would have to
take rules out of a "policy repository" (this might be an LDAP directory or
it might also be some other type of store) and translate them in some way
before provisioning the appropriate rules into a PEP. It is not clear that
there is always a suitable direct translation into PEP-speak - more likely
there is quite a complex algorithm to be executed by the PDP in taking
dynamic network conditions into consideration (e.g. topology, time-of-day,
traffic patterns etc.) in this algorithm. So, IMHO, a tight coupling of COPS
objects to LDAP syntax would seem like the wrong approach.

I think that the details of the translation algorithm run by the PDP can,
and will, be left for implementor differentiation: only the on-the-wire
formats for COPS (and LDAP) need to be standardised although we will
probably need to discuss the internal PDP algorithms in this working group
to some extent in order to make sure that the wire-protocols are adequate
for the job (this is the proof-of-concept stuff that is talked about in the
Policy WG charter).

I hope that is a fair summary of the current consensus.

Andrew Smith
RAP WG co-chair

> -----Original Message-----
> From: Pradosh Kumar Mohapatra [mailto:[email-masked]]
> Sent: Friday, July 16, 1999 2:08 PM
> To: policy
> Subject: COPS message content
> 
> 
> Hi,
> Being new to the mailing-list, I really don't know whether 
> there is any
> information available on the message content of a COPS 
> message sent from
> PEP to PDP or PDP to PEP. I am referring to the ClientSI part of the
> COPS messages. Can't there be any standard way to represent 
> this part of
> the protocol, given the fact that we have the ldap structure of policy
> in place.
> From whatever I have read, I came to understand that this field of the
> protocol is very much specific to the discipline that it 
> related to e.g.
> qos, or security. If it is so, then after the packet reaches the PDP,
> how does the PDP operate? What are the details about how it 
> accesses the
> LDAP and matches a rule? If a rule is matched, what contents 
> does it put
> in the reply message?
> 
> Regards,
> Pradosh
>

---

From: [email-masked] (SteveJ)
Date: Mon, 19 Jul 1999 20:07:17 -0700

Pradosh and Andrew,

> objects to LDAP syntax would seem like the wrong approach.
While I agree that a tight coupling of LDAP to COPS would be the wrong
approach, I can't help thinking that the policy objects themselves should
more closely follow what is described in the Policy Framework.  I believe
the jury is still out on how the Policy Server/Repository -- PDP -- PEP will
actually be implemented.  Today there are vendors who think these are three
separate entities, others who think the Policy Server and PDP are combined,
and still others who think the PDP and PEP should be combined.  In my
personal opinion, the first has scaling problems with per-flow requests to
the PDP.  The second has scaling problems with PEP requests to the Policy
Server, and only the third seems uniformly scalable - policies and
associated rules are distributed to remote PDP/PEP entities from the
repository.  The distribution may take multiple forms - LDAP for
bulk/default policies, COPS, SNMP or other protocol for realtime
updates/changes based on network conditions that can't be defined in the
initial ruleset.

> for the job (this is the proof-of-concept stuff that is talked about in
the
I agree that the PDP translation must be left to the implementor, so the
wire protocols ideally should meet the needs of all the scenarios above.  We
really won't know the optimal model until real world deployments begin to
see larger volumes.

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

---

From: Shai Herzog <[email-masked]>
Date: Wed, 28 Jul 1999 12:11:29 -0400

At 02:07 PM 7/19/99, SteveJ wrote:

>I believe
>actually be implemented.

I always believed Policy Server and PDP are the same thing so the three
tier architecture is

Repository -- PDP -- PEP

And the protocol used are LDAP (Repository -- PDP) and COPS (PDP-PEP).

Shai

__________________________________________________________________
Shai Herzog, Founder & CTO         http://www.iphighway.com/herzog
Cell: (917) 449-7889                      Parker Plaza, 16th Floor
Tel : (201) 585-0800                                 400 Kelby St.
Fax : (212) 656-1006                             Fort-Lee NJ 07024