Subject: RE: policy time period condition in diffserv PIB

From: "Iliff, Tina" <[email-masked]>
Date: Fri, 03 Aug 2001 13:39:33 +0000

Saurabh,
 
You are correct.  Also, to answer your question:  "But the doubt I have is
when does the PDP actually create two PIB instance. Is it that if the PDP
wants to have more PIB instances it forces the PEP for sending another REQ
???" -- Yes 

Tina Iliff

-----Original Message-----
From: Saurabh kapoor [mailto:[email-masked]]
Sent: Friday, August 03, 2001 5:42 AM
To: Iliff, Tina; Ponnappan Appan
Cc: V V V Satya Naganna; [email-masked]
Subject: Re: policy time period condition in diffserv PIB
 
My understanding of the active and deactivate PIB instances is that the
[COPS-PR] supports multiple, disjoint, independent instances of the PIB to
represent multiple instances of configured policy.  The motive is to allow
for the pre-provisioning of policy that can then be made active by a single,
short decision from the PDP. ( The PEP has to mandate only the policies
described in the active PIB instance )
    
As stated by you, although many PIB instances may be configured on a device
only one of them can be active at any given time, the active one being
selected by the PDP.  To facilitate this selection, the Framework PIB
supports an attribute to make a PIB instance the 
active one and, similarly, to report the active PIB instance to the PDP in a
COPS request message. Setting the attribute frwkPibIncarnationActive in the
Incarnation Table to 'true' in one PIB instance MUST ensure that the
attribute is 'false' in all other contexts. 
Regarding the creation and deletion of these PIB instances: Each PIB
instance is identified by a context.  A COPS context can be defined as an
independent COPS request state for a particular subject category
(client-type). Each of these states is identified by a unique client handle
in the COPS-PR Protocol.
But the doubt I have is when does the PDP actually create two PIB instance.
Is it that if the PDP wants to have more PIB instances it forces the PEP for
sending another REQ ??? 
Saurabh Kapoor
----------------------------------------------------------------------------
----------
----- Original Message ----- 

From: Ponnappan Appan <mailto:[email-masked]>  
To: Iliff, Tina <mailto:[email-masked]>  
Cc: Saurabh <mailto:[email-masked]>  kapoor ; [email-masked]
<mailto:[email-masked]>  ; V <mailto:[email-masked]>  V V Satya
Naganna ; Radhika <mailto:[email-masked]>  ; Attili
<mailto:[email-masked]>  Venkata Ravi Kishore 
Sent: Friday, August 03, 2001 2:46 PM
Subject: Re: policy time period condition in diffserv PIB
 
Hi, 
I have some questions on your suggestion of using multiple request-state 
feature in COPS-PR and pibIncarnationTable in framework PIB, for
activating/de-activating policy rules: 
1. In your solution, is there: 
    a. one PIB instance for all the policy rules which are active all the
time, 
         corresponding to the client handle that is used when the PEP
connects 
         first time? 
    b. one PIB instance for each distinct "time-of-day" class instance
defined 
         in the policy rules? 
2. What does activate and de-activate mean for a PIB instance? This does 
     not seem to be explained in framework PIB. It also says that there can 
     be only one PIB instance active. 
"Iliff, Tina" wrote: 
Another alternative would be for the PDP to install all policies with only
one being active.Then, when the active context should change the PDP would
send a Unsolicited DEC (with the Install command and the Handle of the
correct "Time-of-day" request-state) and only one instance of the
frwkPibIncarnation class with the Active attribute set to True.
Tina Iliff 
 
-----Original Message----- 
From: Ponnappan Appan [ mailto:[email-masked] <mailto:[email-masked]>
] 
Sent: Thursday, August 02, 2001 4:57 AM 
To: Saurabh kapoor 
Cc: [email-masked]; V V V Satya Naganna; Radhika; Attili Venkata Ravi
Kishore 
Subject: Re: policy time period condition in diffserv PIB 
The PDP takes care of scheduling the rules and NOT the PEP. 
The PDP can send an unsolicited COPS DEC message with 'install' when the
scheduling 
period starts. Similarly it sends an unsolicited COPS DEC message with
'remove' when 
the period ends.  
Saurabh kapoor wrote:  
Hi,The draft-ietf-diffserv-pib-03.txt does not seem to contain policy time 
period condition as specified in PCIM.How can a PDP push a set of policies
and mandate that the policies should be active 
only during the Time Period as specified in the policies?( For example
certain set policies are to be active between 9:00 to 6:00, how can this
time information of the policy be fitted into the PIB ?)Regards,Saurabh
Kapoor

---

From: Ponnappan Appan <[email-masked]>
Date: Mon, 06 Aug 2001 10:44:44 +0800

I also read the  COPS-PR RFC and the latest framework PIB draft. My main
question is:
Why only one PIB instance need to be active at a given time? Also, my
assumption is that
(it is not explicitly stated in COPS-PR RFC or framework PIB draft)
deactivating a PIB
instance results in deletion(locally in the PEP) of the traffic
control(TC) instances
corresponding to ALL the PRIs in the PIB instance that is being
deactivated.

Let us say we have two sets of policy rules - one set being valid all
the time and another
set being valid from 9AM to 5PM on all days. If we map first set to one
PIB instance and the
second set to another PIB instance, we would require both the PIB
instances to be active
between 9AM to 5PM on alll days, which is not allowed.

Regards,

"Iliff, Tina" wrote:

> Saurabh,
>
> You are correct.Also, to answer your question:"But the doubt I have is
> when does the PDP actually create two PIB instance. Is it that if the
> PDP wants to have more PIB instances it forces the PEP for sending
> another REQ ???" -- Yes
>
> Tina Iliff
>

---

From: "Saurabh kapoor" <[email-masked]>
Date: Fri, 17 Aug 2001 15:05:02 +0530

Hi , 
This is regarding diffserv implementation (through COPS PR )  

==> I have a few doubts regarding the mapping of a few parameters of qosInfoModel (draft-ietf-policy-qos-info-model-03)
 onto the diffservPIB (draft-ietf-diffserv-pib-04).

1) 'qpAdmissionScope' attribute of the qosPolicyAdmissionAction class. 
'This property specifies whether the admission decision is done per flow or per the entire class of flows.
2) 'qpFairness' attribute of the qosPolicyBanwidth Action class.
3) 'qpMaxDelay' attribute of the qosPolicyBanwidth Action class.
4) 'qpMaxJitter' attribute of the qosPolicyBanwidth Action class.

==> Another doubt is can we have multiple datapath tables for the same combination of "interfaceType and Role" ?
i.e.,   If there are two different policies P1 and P2  for the Interface type "A1", role combination "A+B".

For policy P1 , PDP constructs and sends a datapath table which consists of interface type "A1", role combination "A+B" 
For policy P2, PDP constructs and sends another datapath table which consists of same interface type"A1", role combination "A+B".

Thanks in advance ~  
Saurabh Kapoor
--------------------------------------------------------------------------------------