|
Details ARCHITECTURE J-OWAMP implements the OWAMP architecture shown below. The OWAMP architecture is based on two inter-dependent protocols, OWAMP-Control and OWAMP-Test, that can guarantee complete isolation between client entities and server entities. The OWAMP-Control is used to start and end OWAMP-Test sessions as well as receive the results of those tests, whereas the OWAMP-Test protocol is used to allow the exchange of test packets between any two points that belong to the monitored network. The proposed architecture includes the following elements (Figure 1): · Session-Sender - the sending endpoint of an OWAMP-Test session; · Session-Receiver - the receiving endpoint of an OWAMP-Test session; · Server - an end system that manages one or more OWAMP-Test sessions, is capable of configuring per-session state in session endpoints, and is capable of returning the results of a test session; · Control-Client - an end system that initiates requests for OWAMP-Test sessions, triggers the start of a set of sessions, and may trigger their termination; · Fetch-Client - an end system that initiates requests to fetch the results of completed OWAMP-Test sessions.
Fig. 1. OWAMP architecture. A network element can carry out several logical functions at the same time. For example, we can have only two network elements, one implementing the Control-Client, the Fetch-Client and the Session-Sender and the other implementing the Server and the Session-Receiver (Figure 2).
Fig. 2. OWAMP simplified architecture. The architecture of Figure 1 allows several Session-Sender / Session-Receiver pairs to be controlled by only one Control-Client, one Server and one Fetch-Client, which decreases the processing load at the endpoints. In this scenario, the network manager can control all OWAMP-Test sessions from a single machine, which is not possible in the simplified scenario. The OWAMP-Control protocol runs over TCP. At the start of each session, the Control-Client and the Server define the sender and receiver IP addresses and the sender and receiver UDP port numbers of the test packets, the start time and duration of the OWAMP-Test session, the size of the test packets and the distribution of the interval between two consecutive test packets. The OWAMP-Test runs over UDP and is used to exchange test packets between Session-Sender and Session-Receiver. The packets include a Timestamp indicating the start time of packet transmission, a Sequence Number and flag indicating whether or not the sender is synchronized with an exterior system (using GPS or NTP). OWAMP supports testing in networks with service differentiation, using DSCP (Differentiated Services Codepoint) and PHB ID (Per Hop Behaviour Identification Code). It also supports the encryption and authentication of the test and control messages. The OWAMP specification allows the use of proprietary protocols (that can be monolithic or distributed programming interfaces) in all connections that do not compromise interoperability. In J-OWAMP we used the OWAMP-Control as the communication protocol between Control-Client and Session-Sender and between Server and Session-Receiver.
IMPLEMENTATION J-OWAMP was developed in Java language due to some favourable characteristics of this language, like semantic simplicity, portability and the availability of a set of classes that greatly simplify the development of distributed applications. The system is structured in two levels: Messages and Entities. At the Messages level, there is a set of classes corresponding to each of the data packets exchanged in the OWAMP protocol. The main class, called Packet, is the basis for all messages (derived classes). It contains all methods (basic functions) for manipulating and formatting the different data types involved in the protocol. It also contains the methods that are needed to receive and send packets using a socket. Each type of packet is defined in a class that derives from the Packet class. Each of these classes include two new subclasses, one used to send the packet, with suffix ToBeSend, and another used to receive the packet, with suffix Receiver. Sending a packet always involves two actions: transferring all its bytes to a buffer and sending the bytes through a socket. Thus the subclass responsible for sending a packet always includes two methods to perform these actions: the datagramToBuffer method and a method with prefix sendTCP for control packets or sendUDP for test packets. Receiving a packet also involves two actions: receiving the bytes through a socket and transferring the bytes from buffer to the packet object. Thus, the subclass responsible for receiving a packet includes two methods to perform these actions, one with prefix receive and another with prefix create_Datagram. The Packet class also contains the Timestamp subclass that includes the methods and objects required to obtain and process the temporal information of the system. At the Entities level, a set of seven classes was developed in order to implement the five elements of the OWAMP architecture (Client, Server, Session-Sender, Session-Receiver and Fetch-Client). These classes are: · OWAMP_Base extends Thread · OWAMP_ControlClient extends OWAMP_Base · OWAMP_Server extends OWAMP_Base · OWAMP_SessionTerminal extends OWAMP_Base · OWAMP_SessionReceiver extends OWAMP_SessionTerminal · OWAMP_SessionSender extends OWAMP_SessionTerminal · OWAMP_FetchClient extends OWAMP_Base More details on each developed class for J-OWAMP version 1.0 can be found here. For versions 1.2 and 2.1 we developed three new classes: · HiResTimer - This class is used to define an object to read time information with high resolution; · MySQLcom - used to connect to a database and save to or read information from it; · CalculateCI extends OWAMP_Base - used to calculate the confidence intervals of a Confidence Interval session. It is used in the J-OWAMP web interface. |
