CLIAMS:CLAIMS

We claim:
1. A system for creating a generic testing environment to test a Device Under Test (DUT), said system comprises of:

an external load generator; and
a mediator framework, wherein said mediator framework is further configured for:
receiving testing information using a pairing interface, wherein said testing information comprises of at least one testing requirement and a context information;
sensing a plurality of data packets from said external load generator;
inserting at least one of said plurality of data packets with corresponding session; and
routing said at least one data packet to said DUT.

2. The system as in claim 1, wherein said session information is created using a session establishment module.

3. The system as in claim 1, wherein said mediator framework is further configured to fetch a DUT Id of said DUT and a session Id as said context information.

4. The system as in claim 1, wherein said mediator framework is further configured to fetch information related to percentage of packets to be forwarded, type of packet to be forwarded, input interface, and output interface as said testing requirement.

5. The system as in claim 1, wherein said mediator framework is further configured to receive user defined values as said testing requirements.

6. The system as in claim 1, wherein said mediator framework is further configured to use pre-configured default values for said testing requirements.

7. The system as in claim 1, wherein said mediator framework is further configured to insert said at least one of said plurality of data packets with corresponding session by:

filtering said testing information using a configuration module;

storing said filtered testing information in a client information database;

reading said stored filtered testing information from said client information database using a switching module; and

directing said at least one data packet to said DUT using said switching module.

8. The system as in claim 7, wherein said switching module is further configured to direct said at least one data packet to said DUT using a header rewriting mechanism, wherein said DUT Id is associated with said created session.

9. The system as in claim 7, wherein said switching module is further configured to direct said at least one data packet to said DUT using a tunneling mechanism, wherein a template header of a proprietary protocol being supported by said DUT is associated with header of said at least one data packet.

10. A method for creating a generic testing environment to test a Device Under Test (DUT), said method comprises of:

fetching testing information, wherein said testing information comprises of at least one testing requirement and a context information;

inserting at least one of a plurality of data packets with corresponding session; and

routing said at least one data packet to said DUT.

11. The method as in claim 10, wherein said context information further comprises of a DUT Id of said DUT and a session Id.

12. The method as in claim 10, wherein said testing requirement further comprises of information related to percentage of packets to be forwarded, type of packet to be forwarded, input interface, and output interface.

13. The method as in claim 10, wherein inserting said at least one of said plurality of data packets with corresponding session further comprises:

filtering said testing information;
storing said filtered testing information in a client information database;
reading said stored filtered testing information from said client information database; and
directing said at least one data packet to said DUT, based on said stored filtered testing information.

14. The method as in claim 10, wherein said at least one data packet is directed to said DUT using a header rewriting mechanism, wherein said DUT Id is associated with said created session.

15. The method as in claim 10, wherein said at least one data packet is directed to said DUT using a tunneling mechanism, wherein a template header of a proprietary protocol being supported by said DUT is associated with header of said at least one data packet.
Dated: 04th day of October, 2013 Signature:
Vikram Pratap Singh Thakur
Patent Agent
,TagSPECI:FORM 2
The Patent Act 1970
(39 of 1970)
&
The Patent Rules, 2005
COMPLETE SPECIFICATION
(SEE SECTION 10 AND RULE 13)
TITLE OF THE INVENTION

METHOD AND SYSTEM FOR PROVIDING A DATA AGNOSTIC FRAMEWORK FOR PERFORMANCE TESTING OF A DEVICE

APPLICANTS:
Name : HCL Technologies Limited
Nationality : Indian
Address : HCL Technologies Ltd., 50-53 Greams
Road, Chennai – 600006, Tamil Nadu, India
The following Specification particularly describes and ascertains the nature of this invention and the manner in which it is to be performed:
TECHNICAL FIELD
[001] The embodiments herein relate to performance testing and, more particularly, to provide a generic testing environment in order to facilitate performance testing of a device.

BACKGROUND
[002] In today’s world of ‘always-on’ connectivity and ever increasing user base, huge loads are placed on the network components every day. The professional and competitive environment of today’s times is such that the network breakdowns can no longer be ignored. To do away with these issues and be better prepared in times of the inevitable breakdown of systems, ‘performance testing’ has become an important part of a software life cycle. It enables to gauge threshold characteristics of network entities under heavy load conditions. Precisely, ‘performance testing’ is a process of measuring characteristics such as threshold, stability, capability and benchmarking of a system under high usage conditions and the responsiveness of it. The performance test tools that are available assesses end-to-end network performance using load patterns which mimic the usage patterns of a large group of actual users. Furthermore, the performance test tool solution can simulate multiuser protocol sessions and generate network packets in continuous burst. Generally, the performance test tool solution’s architecture comprises of a protocol test simulator/test suite and a load generator which are tightly integrated and highly interdependent. However, this interdependency introduces ‘rigidity’ which constrains the applicability of performance testing. Below mentioned are few example scenarios which highlight this fact:
• Roadblock arises when an implementer of a protocol needs to stress test a product which implements new protocol. As the new protocol is not offered in existing protocol test suites, the implementer is either forced to develop an in-house proprietary performance test solution (whole) or to purchase load generator from a suitable performance tool vendor to generate raw data. This type of simulation in which raw data is aimed at a test machine is useless since packets which are coming from external load generator are without any context and finally Device Under Test (DUT) fails to recognize them.
• A performance test tool user may not be able to independently extend test suites to suit his/her needs due to tight integration and interdependency that exists between load generator and protocol test simulator. Furthermore, this tight integration and interdependency introduces rigidity which adds delay to the whole testing process.
• Cost of maintaining a performance test tool from a vendor is very high, as costly protocol suites are to be purchased independent of the hardware (the load generation unit) used. Further, additional licenses are to be purchased even for minute alterations that are made to protocol implementations offered in a test suite.

SUMMARY
[003] In view of the foregoing, an embodiment herein provides a system for creating a generic testing environment to test a Device Under Test (DUT), the system comprises of an external load generator; and a mediator framework. The mediator framework is further configured for receiving testing information using a pairing interface, wherein the testing information comprises of at least one testing requirement and a context information. The mediator framework further senses a plurality of data packets from the external load generator. Further, the mediator framework inserts at least one of the plurality of data packets with corresponding session and then, routs the at least one data packet to the DUT.
[004] Embodiments further disclose a method for creating a generic testing environment to test a Device Under Test (DUT), the method comprises of fetching testing information, wherein the testing information comprises of at least one testing requirement and a context information. Further, at least one of a plurality of data packets is inserted with corresponding session and then, the at least one data packet is routed to the DUT.
[005] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES
[006] The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:
[007] FIG. 1 illustrates a block diagram of data agnostic framework, as disclosed in the embodiments herein;
[008] FIG. 2 is a block diagram that shows various components of mediator framework, as disclosed in the embodiments herein;
[009] FIG. 3 is a flow diagram which shows various steps involved in the process of providing generic testing environment in order to facilitate performance testing of a device, as disclosed in the embodiments herein; and
[0010] FIG. 4 is a flow diagram which shows various steps involved in the process of inserting raw Internet Protocol (IP) packets for corresponding session, as disclosed in the embodiments herein.
DETAILED DESCRIPTION OF INVENTION
[0011] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0012] The embodiments herein disclose a mediator framework which provides a data agnostic framework in order to provide a generic testing environment to facilitate performance testing of a device. Referring now to the drawings, and more particularly to FIGS. 1 through 4, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.
[0013] FIG. 1 illustrates a block diagram of data agnostic framework, as disclosed in the embodiments herein. The data agnostic framework 100 comprises a mediator framework 101, an external load generator 102, a Device Under Test (DUT) 103 and a session establishment module 104.
[0014] The mediator framework 101 receives or fetches information regarding session that is created to test particular DUT 103 through a suitable pairing interface. In an embodiment, the information which is required for testing (i.e., testing information) can be configured by the user through different Application Programming Interfaces (APIs) that are present in the pairing interface of the mediator framework 101. In a preferred embodiment, the mediator framework 101 provides at least one suitable user interface (preferably through an Application Program Interface (API) layer) for the users to configure ‘context information’ and ‘testing requirements’. The ‘testing information’ may contain ‘context information’ and ‘testing requirements’. In another embodiment, the ‘context information’ may contain the details like DUT’s 103 IP address (i.e., IP address of device that is to be tested), client Identity (ID), and session ID and so on. The configured ‘user requirements’ may include details (but not limited to) like type of packet, percentage of packets to be forwarded, input interface, output interface and proprietary protocol information. While configuring, some of the parameters such as percentage of packet to be forwarded, input interface, output interface and type of packet may be kept optional. Further, the mediator framework 101 can assigns default values for the ‘testing requirements’ if user does not configure through pairing interface.
[0015] In a preferred embodiment, the parameter ‘type of packet’ refers to the type of raw IP packet (for example UDP or TCP and so on) that is to be forwarded to a particular DUT 103 and the parameter ‘percentage of packets to be forwarded’ refers to amount of raw IP packets that are needed to be sent to a particular DUT 103 out of all raw IP packets received from the external load generator 102. The parameter ‘input interface’ refers to the interface address through which data arrives at the mediator framework 101. Similarly, ‘output interface’ refers to the interface address via which the data has to be sent to the desired destination (i.e., DUT 103). The parameter ‘proprietary protocol information’ contains the details of proprietary protocol header information (proprietary protocol’s packet structure in XML format) to cater to needs of testing a proprietary protocol. In another embodiment, ‘data’ refers to the group of incoming raw IP packets that are delivered by the external load generator 102.
[0016] In an embodiment, session can be created with the DUT 103 by using the session establishment module 104 present in the data agnostic framework 100. The session is created based on the requirements (such as destination Internet Protocol (IP) address, number of virtual users required for testing and so on) given by a user at the time of testing the DUT 103. Moreover, the session establishment module 104 may have necessary hardware and/or software to support performance testing of a device (i.e., DUT 103)’ by establishing session with the DUT 103. For example, the session establishment module 104 can be (but not limited to) a protocol test simulator or a test simulator.
[0017] Further, the mediator framework 101 uses the session information (i.e., information related to the session which is created by the session establishment module 104) to test the performance of the DUT 103. In an embodiment, the user of the session establishment module 104 can fetch the ‘context information’ from the session establishment module 104 and configure to the mediator framework 101 through different API’s that are present in the pairing interface of the mediator framework 101.
[0018] The mediator framework 101 may fetch the load required to test the DUT 103 by using any suitable load generator (i.e., the external load generator 102). The external load generator 102 can be any load generator which is capable of performing ‘rapid load generation’ externally. In an embodiment, ‘rapid load generation’ may refer to the process of generating loads rapidly by delivering large number of raw IP packets in bursts to the desired destination. Further, the external load generator 102 is configured with the destination IP address in order to direct raw IP packets towards the desired destination. In another embodiment, the incoming raw IP packets can be directed to the destination (i.e., the mediator framework 101) by using any suitable physical interface between the external load generator 102 and the mediator framework 101.
[0019] Later, the mediator framework 101 inserts a selected percentage of raw IP packets (i.e., load) for corresponding signaling session and finally transmits the raw IP packets to the desired DUT 103 by using a suitable network/IP interface. ‘Inserting raw IP packets for given signaling session’ refer to a process of associating incoming raw IP packets with a particular communication session based on the configured context information and testing requirements.
[0020] In an embodiment, the mediator framework 101 uses ‘layer 2 switching’ to route the data to the desired destination (i.e., DUT 103). Moreover, the mediator framework 101 may act as a ‘traffic switcher’ which is at lower layer (known as ‘kernel’ layer) of a communication protocol and takes incoming raw IP packets from the external load generator 102 and routes the data according to the configured testing requirements. As the mediator framework 101 resides at the lower layer (kernel layer), it utilizes the benefits of ‘layer 2 switching’ or ‘fast switching’. In other words, the mediator framework 101 being at the lower layer, can improve routing speed and there by overall performance.
[0021] FIG. 2 is a block diagram that shows various components of mediator framework, as disclosed in the embodiments herein. The mediator framework 101 further comprises of a pairing interface 201, a configuration module 202, a client information database 203, a hook module 204 and a switching module 205.
[0022] The pairing interface 201 is an API layer through which the mediator framework 101 can fetch or receive the ‘testing information’. Further, the pairing interface 201 comprises of API’s such as ‘add client context info’, ‘modify client context info’, ‘delete client context info’ and so on which may be used by the mediator framework 101 to fetch or receive the ‘context information’ and ‘testing requirements’ from the user of the session establishment module 104. In a preferred embodiment, ‘client’ may refer to the device for which performance is to be tested (i.e., DUT 103).
[0023] The configuration module 202 filters the ‘testing information’ based on the parameters configured by the user. In an embodiment, the parameters may include percentage of packets to be forwarded, output interface and type of packet and so on. In a preferred embodiment, ‘filtering’ refers to the process of creating a list in which the configuration module 202 of the mediator framework 101 maps the context information and testing requirements for each DUT 103 (that is to be tested).
[0024] The client information database 203 is an in-memory database which can store the ‘testing information’ temporarily. In an embodiment, the client information database 203 may comprises the details of client ID, DUT’s IP address, input interface, output interface, percentage of packets to be forwarded and so on.
[0025] The hook module 204 of the mediator framework 101 senses the raw IP packets that are coming from the external load generator 102. Further, the hook module 204 captures these incoming raw IP packets as these raw IP packets have mediator framework’s 101 IP address as their destination IP address. Finally, the hook module 204 sends an acknowledgement signal to the switching module 205 indicating the status of availability of packets.
[0026] The switching module 205 of the mediator framework 101 is a ‘traffic switcher’ which routes the data according to the filtered testing information. In an embodiment ‘switching’ refers to the process of sending data to a desired destination after in-memory database lookup. The switching module 205 performs the task of switching by directing the raw IP packets towards desired destination (i.e., DUT 103). In an embodiment, the raw IP packets can be directed to the desired DUT 103 by modifying header part of the raw IP packets. In an embodiment, the switching module 205 may modify the header part of the raw IP packets by using any suitable technique such as (but not limited to) header rewriting or tunneling. The technique ‘header rewriting’ can be used for testing the devices over ordinary protocols and the technique ‘tunneling’ can be used for testing the devices over proprietary protocols.
[0027] FIG. 3 is a flow diagram which shows various steps involved in the process of providing generic testing environment in order to facilitate performance testing of a device, as disclosed in the embodiments herein.
[0028] Initially, to test performance of a device (i.e., DUT 103) which is present in the data agnostic framework 100, a signaling session has to be created with the DUT 103. When data is transmitted from one device to another without establishing a session, the device that receives the data may not be able to read or understand the data received and hence, may reject the received data. ‘Session’ may refer to a specific sequence of interaction established between at least two devices for exchange of information such that each device involved understands data transmitted by each other device in the session. So, a session is established between the DUT 103 and the session establishment module 104; which facilitates the session establishment module 104 to communicate with the DUT 103. For example, let us consider a server is being used by 100 users and sends data at rate of 30 Mbps. In order to test performance of this server (i.e., DUT 103), initially a session must be created with the server. This can be done by configuring the details of number of users required and IP address of the server to the session establishment module 104.
[0029] The mediator framework 101 receives or fetches (302) the ‘testing information’ that is required to test the performance of a device (i.e., DUT 103) through the pairing interface 201. In an embodiment, user can configure the necessary testing information (i.e., context information and user requirements) to the mediator framework 101 by using different API’s (such as ‘add client context info’, ‘modify client context info’, ‘delete client context info’ and so on) that are present in the pairing interface 201 of the mediator framework 101.
[0030] Further, the load required for testing the DUT 103 can be generated from an external load generating device i.e., from the external load generator 102. Initially, the external load generator 102 is initialized with the mediator framework 101 by pre-configuring the ‘mediator framework’s 101 IP address (destination IP address)’ with the external load generator 102. After initialization, the external load generator 102 starts sending the raw IP packets to the mediator framework 101 as the mediator framework’s 101 IP address is initialized with the external load generator 102. In an embodiment, a suitable network/IP interface can be used in between the mediator framework 101 and the external load generator 102 in order to send load from the external load generator 102 to the mediator framework 101.
[0031] Later, the hook module 204 of the mediator framework 101 senses (304) the incoming raw IP packets (i.e. the load) from the external load generator 102 (as the raw IP packets have mediator framework’s 101 IP address as the destination IP address). After sensing incoming raw IP packets, the hook module 204 sends an acknowledgement signal to the switching module 205 indicating status of availability of the raw IP packets. If the raw IP packets are available with the hook module 204, a ‘packet available’ acknowledgement may be sent to the switching module 205 indicating the availability of the raw IP packets i.e. load. In other case (when no packets are received from the external load generator 102), the hook module 204 may send the acknowledgement as ‘packets unavailable’ to the switching module 205.
[0032] Further, the switching module 205 inserts (306) the available raw IP packets for corresponding signaling session (which are created by the session establishment module 104) by using the ‘testing information’ which is configured to the mediator framework 101. Finally, the switching module 205 routes (308) the raw IP packets to the desired DUT 103 by directing them using suitable mechanism such as (but not limited to) header rewriting and tunneling. The various actions in method 300 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 3 may be omitted.
[0033] FIG. 4 is a flow diagram which shows various steps involved in the process of inserting raw Internet Protocol (IP) packets for corresponding session, as disclosed in the embodiments herein.
[0034] After receiving or fetching the testing information (i.e., context information and user requirements)’ through the pairing interface 201, the configuration module 202 of the mediator framework 101 filters (402) the information by creating a list. In an embodiment, the list can be created by mapping the testing information for each DUT 103 using DUT’s client ID. For example, list can be created by considering the parameter ‘type of packet’ in which the devices having same ‘type of packet’ may be arranged in an order. If the parameter ‘percentage of packets to be forwarded’ is considered, devices having highest load (i.e., devices having high value for ‘percentage of packets to be forwarded’) may be placed on top of the list.
[0035] Let us consider another example, in which 4 clients (say C1, C2, C3 and C4) are to be tested to know their performance. Let, C1 and C2 requires TCP packets for testing where as C3 and C4 requires UDP packets for testing. Then, the configuration module 202 prepares a list (considering ‘type of packet’) as C1, C2, C3, and C4 in sequential order. In the list, C1, C2 are placed in sequential order as they need same type of packet (TCP packets) for testing. Similarly, C3 and C4 are placed in sequential order as they need same type of packet (UDP) for testing. Finally, the configuration module 202 stores (402) the filtered information in the in-memory database of the client information database 203.
[0036] In an embodiment, the client information database 203 comprises details like client identity (ID), input interface, output interface, percentage of packets to be forwarded, DUT’s IP address and type of packet. The following is an example table that shows how the context information and the user requirements can be mapped in the client information database 203.

Client ID Input interface Output
interface Percentage of packets to be forwarded DUT’s IP address Type of
packet
1 Eth0 Eth3 100 ab.cd.ef.gh UDP
2 Eth1 Eth5 100 ij.kl.mn.op UDP
3 Eth7 Eth2 30 qr.st.uv.wx TCP
4 Eth4 Eth6 10 wx.xy.yz.zz TCP
Table 1
[0037] The above table shows an example client information database in which there are four DUT’s. Each DUT is mapped with a unique ‘client ID’ (say ‘1’, ‘2’, ‘3’, and ‘4’). Further, the details under ‘input interface’ and ‘output interface’ specifies input (Eth0, Eth1 Eth7, Eth4) and output (Eth3, Eth5, Eth2 Eth6) interfaces that are used by the raw IP packets to enter and leave the mediator framework 101 respectively. Further, ‘percentage of packets to be forwarded’ provides information on how much percentage of packets to be forwarded for a particular DUT when a session is established. For the DUT having client ID as 1, 100% of raw IP packets (i.e., total load that is coming from external load generator 102) are to be forwarded to the particular DUT. The information under ‘DUT’s IP address’ specifies the address of DUT to which data is to be routed. For, the DUT having client ID 4, the IP address to which data is to be sent is given as ‘wx.xy.yz.zz’. Similarly, ‘type of packet’ defines specific type of packet that is to be sent to particular DUT 103. For the client having client ID 1, the User Datagram Protocol (UDP) packets are required to test its performance.
[0038] In an embodiment, the configuration module 202 can assign default values for the ‘testing requirement’ (i.e., regarding percentage of packets, input and output interface and type of packet fields), if user does not provide any specific information. For example, the default value for the parameter ‘percentage of packets to be forwarded’ can be given as 100. So, whenever user does not provide any specific information regarding ‘percentage of packets to be forwarded’ to a particular DUT 103, the configuration module 202 assigns the value ‘100’ to the field and delivers total load that is received from the external load generator 102. In case of input and output interfaces, the configuration module 202 selects suitable interfaces based on the DUT’s 103 IP address. After storing the ‘testing information’ in the client information database 203, the switching module 205 reads (404) the mapped ‘testing information’ from the client information database 203.
[0039] Further, the hook module 204 of the mediator framework 101 senses the load (i.e., the raw IP packets) which is coming from the external load generator 102. Upon receiving the load, the hook module 204 sends an acknowledgement signal to the switching module 205 indicating the status of availability of raw IP packets. Furthermore the switching module 205 directs (408) the available raw IP packets to the desired destination (i.e., to DUT 103). The switching module 205 may direct the available raw IP packets to the DUT 103 by using any suitable mechanism such as (but not limited to) header rewriting or tunneling.
[0040] In an embodiment, ‘header rewriting’ refers to rewriting the header part (such as IP, Media Access Control (MAC) address) of the raw IP packets with the DUT’s 103 IP address. This further helps the DUT 103 to recognize the raw IP packets that are coming from the mediator framework 101. The process of header rewriting is important because the raw IP packets which are coming from the external load generator 102 have source IP address as external load generator’s 102 IP address and destination IP address as mediator framework’s 101 IP address. When the raw IP packets are sent to the DUT 103, they may not be recognized by the DUT 103 as destination IP address is registered as mediator framework’s 101 IP address. Hence, in order to make these raw IP packets usable by the DUT 103, corresponding session ID should be send along with the raw IP packets and the header parts of these packets are to be rewritten with the DUT’s 103 IP address.
[0041] For example, let us consider a device having IP address ‘ab.cd.ef.gh’ is to be tested. The mediator framework 101 (having IP address ‘ij.kl.mn.op’) receives raw IP packets from the external load generator 102 to test the device. The raw IP packets that are received by the mediator framework 101 contain destination IP address as ‘ij.kl.mn.op’; which is IP address of the mediator framework 101. In order to send the received raw IP packets to the DUT 103, the destination IP address in the header of raw IP packets is to be changed to ‘ab.cd.ef.gh’ (i.e., IP address of the DUT 103). Further, the switching module 205 of the mediator framework 101 performs this header rewriting before sending it to the DUT 103.
[0042] In case of testing a device over proprietary protocol, a special mechanism is needed as the DUT 103 may not understand a proprietary protocol. The term ‘proprietary protocol’ may refer to a communication protocol which is owned by an organization or an individual. The mediator framework 101 uses ‘tunneling’ mechanism to test the device over a proprietary protocol. ‘Tunneling’ refers to a mechanism where one network protocol (the delivery protocol) encapsulates a different payload protocol. Further, tunneling makes a payload to be carried over an incompatible delivery network and provides a secure path through a un trusted network.
[0043] For example, assume 2 network entities named A and C, need to communicate with each other, over a proprietary protocol. But for data to reach from A to C it has to pass through an intermediate node B, which does not understand this proprietary protocol. So, A could wrap its proprietary data in a protocol which B understands and then forwards it to B. This could be done by adding an additional header to the existing protocol packet that is presented in A. Now, B could transfer the proprietary protocol without needing to understand the contents of the payload. Similarly, for the DUT 103 to understand a ‘proprietary protocol’, a ‘template header’ is to be added to the header part of the raw IP packets along with session ID while testing (as DUT 103 may not directly understand a proprietary protocol). In an embodiment, ‘template header’ contains proprietary protocol’s packet structure. The switching module 205 of the mediator framework 101 adds this template header to the incoming raw IP packet (if the testing is over a proprietary protocol). In an embodiment, the user can pre-configure the required proprietary protocol’s packet structure information to the mediator framework 101 by using API’s present in the pairing interface 201.
[0044] The following example shows the overall process of inserting raw IP packets for corresponding session. Consider that 25 percent of total data is to be sent to the DUT 103 through an output interface (say Eth3 interface) in order to test its performance. Let ‘ab.cd.ef.gh’ be the IP address of the DUT 103. Initially, the session establishment module 104 establishes a session with the DUT 103 by using the ‘testing information’ which is configured through the pairing interface 201 of the mediator framework 101. Further, the configuration module 202 of the mediator framework 101 filters the context information (client ID and DUT’s IP address) and testing requirements (here, 25% of packets and Eth3 interface) and further maps them in corresponding fields of the client information database 203. Now, the hook module 204 senses the raw IP packets which are coming from the external load generator 102 and acknowledges the switching module 205 indicating status of availability of raw IP packets. Further, the switching module 205 directs the incoming raw IP packets to the DUT 103 by using any suitable mechanisms such as header rewriting and tunneling. Finally, the switching module 205 routes 25 percent of total incoming raw IP packets to the DUT 103 through the output interface Eth3. The various actions in method 400 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 4 may be omitted.
[0045] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The network elements shown in Fig. 1 to Fig. 2 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.
[0046] The embodiment disclosed herein specifies a system for testing performance of a device which is under test. The mechanism allows a data agnostic framework which provides a generic testing environment in order to facilitate performance testing of a device. Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or any suitable programmable device. The method is implemented in a preferred embodiment through or together with a software program written in e.g. Very high speed integrated circuit Hardware Description Language (VHDL) another programming language, or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof, e.g. one processor and two FPGAs. However, so as to decrease implementation cost and to make the solution more affordable, use of Ethernet driver layer switching is preferred. Further, the Ethernet driver layer switching may also help to provide enough load to the device under test using multiple interfaces. The device may also include means which could be e.g. hardware means like e.g. an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means are at least one hardware means and/or at least one software means. The method embodiments described herein could be implemented in pure hardware or partly in hardware and partly in software. The device may also include only software means. Alternatively, the invention may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[0047] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the claims as described herein.