COPS-PR performance measurements

Implementation

The two PIBs
The first problem faced in the implementation process was the development of some data structure for the representation of policy information.
As solution to this problem I decided to adopt PIBs solution. In fact, these allow to the PDP to communicate with the PEP in a standard way, with a common syntax and semantics of policy information. Due to the adopted solution a second problem rise: the implementation of a PRC in a object oriented language. The PRCs of the implemented PIBs are realized with a common technique. According to SPPI definition a PRC of a PIB is a “SEQUENCE OF TableEntry” and a “TableEntry” is a “SEQUENCE OF Attribute”. To render this definition, I have implemented a class “Table” that is a container of objects of class “Entry”. This one has a set of attribute which is identical to that of the modeled PRC. 
The implemented PIBs are two. The Framework PIB (the PRCs realized are: PRC Support Table, Interface Capability Set Table, Role Combo Table, IP Filter Table) and the Diff-Serv PIB (PRC: Data Path Table, Classifier Table, Classifier Element Table, Mark Action Table, Queue Table, Scheduler Table, QoS Interface Classification Capability Table, QoS Scheduler Capability Table, QoS Interface Queue Capability Table).

PDP and PEP 

The other prototypes realized are those of PDP and PEP. During the work I implemented two pairs of PDP/PEP. 
The first one is composed of a multi-thread server (the “start up PDP”) that allows to simulate the start up interaction with a client (the “start up PEP”). 
The PEP connects to the PDP and sends, as COPS-PR request messages, the Diff-serv capability and role combination of the interface that it controls. The PDP installs the capability in its own PIBs and, then, sends, as COPS-PR decision message, the Diff-serv configuration to the PEP. The realized PDP is state full. Thus rise the problem of the maintenance of the updated state of the capabilities and role combinations of all connected PEPs, and of the correct association between a single PEP and its capability and between PEP and its role combination. I solved the problem by the implementation of some associative maps in which the PDP inserts the PEP identifier (PEPId object) and the capability/role combination received.
Another problem faced during the realization process of  the PDP was that of the construction of the decision message with the diff-serv configuration for the PEP. To solve the problem I decided to exploit the diff-serv data path concept. I fixed the sequence of the constituent element of the data path, while theirs number and theirs interconnection pattern is variable ( thus is also variable the complexity of the policy/configuration). 
The PDP obtains the configuration browsing along the data path, represented by the PRCs of the Diff-serv PIB, and exploring it completely, using the interconnection information included in every PRC (next attribute). When receiving the decision message the PEP parses it and install (copy) the configuration in its own Diff-serv PIB.

The second couple of PDP/PEP (named “Decision PDP” and “Decision PEP” ) wants to simulate the scenario in which the configuration of N “Decision PEPs” is made by the “Decision PDP” after it receives the configuration request of a third network element, or when it checks the activation of an higher level policy.
The prototype of “Decision PDP” is a multi-thread server that takes an operative event and, as response to this, configures N connected “Decision PEPs”. The decisions messages with the configuration are build as previous. The PEP parses the received message and install the configuration in its DiffServ-PIB. The operative event selected is the registration (via COPS OPEN message) of the Nth “Decision PEP”. This event is simple to implement and, for measurement purposes of configuration provisioning, is equivalent to an external request or to the activation of a higher level policy.

To implement the prototypes of the PDPs and of the PEPs, I have used a set of free API, distributed by Vovida organization (www.vovida.org <http://www.vovida.org>). The API realize the COPS-PR stack.

The last phase of the job is that of measurements (this stage of the work is still to finishing). To make the measure, I decide to put the PDP process on a dedicated machine and the N PEP processes on two separated machines, running in parallel (max 500 process). The computer are connected by a 100 Mbit swithched LAN. I have designed four type of measure:
1)	The measurement (server side) of the all start up interaction. The measure is done with one “start up PDP” and one “start up PEP”, since is improbable that more than one PEP starts up simultaneously, or that a PEP starts before that the PDP ends to serve the previous one. I think to measure the time elapsed between “connection accept” made by the PDP and the return of the “send” function of the decision message.
2)	The measurement of the time necessary to the “Decision PDP” to provision N “Decision PEP” with a Diff-serv configuration. I think to measure the time elapsed between the recording of the “operative event” and the return of the “send” function of the last decision message sent, by the PDP, to the last served PEP.
3)	The measurement of the entire provisioning time, form the recording of the “operative event” (server side) to the actual installation of the configuration by the last “Decision PEP” (client side). This measure would request the assessment of two temporal event on two distinct machine (that with the “Decision PDP” and that with the N “Decision PEPs”). This is impossible with the profiling method used (see below). Instead, I think to measure an approximation of the total provisioning time only PEP side. I measure the time elapsed between the sending of the registration message of the last PEP and the installation of the Diff-serv configuration made by the last PEP served. I think that this approximation is very little because the high bit rate of the LAN and relative small processing time of the last OPEN message respect to the total provisioning time.
4)	The measurement of the updating time of the Diff-serv PIB. I think to measure the time elapsed between the return of the “receive” function of the decision message and the end of the PIB up date.

As profiling method I’m using the “time stamp counter” of the Pentium processor. The counter is incremented by an unity every clock cycle. The counter can be used very simply to record the execution time of an instruction set. The execution time is the difference between the value of the counter just after and just before the instruction block, divided for the processor frequency. This method has been chosen for its high precision (a single clock cycle) and for its low over head. The method is applicable to the proposed measure with some few other attentions due to the threaded execution of PDPs. 
All measures will also be repeated with four different Diff-Serv configuration. This to evaluate the impact of the policy complexity on the times recorded.

Please, any one is interested can make me questions and send me his/her comments/suggestions.