QMon: A Class-based QoS Monitoring Tool

Transcription

1 QMon: A Class-based QoS Monitoring Tool 1 QMon: A Class-based QoS Monitoring Tool André Ferreira, Emanuel Freitas, Filipe Leitão Abstract Current applications and services are continuously putting higher demands to network infrastructures, growing side-by-side with the network available bandwidth. With the deployment of New Generation Networks and subjacent services, monitoring the Quality of Service (QoS) delivered to applications assumes a crucial role as it allows a more rational management of network resources. In fact, to maintain an adequate QoS level for the applications, a systematic monitoring of their traffic is needed to detect eventual network behaviour changes, which may endanger the fulfilment of negotiated Service Level Agreements (SLAs). The most established paradigm for multiservice networks is based on Service Classes, where traffic generated by applications is classified and aggregated based on its characteristics to receive a similar behaviour within the network. In this context, QoS monitoring, to be effective, has to be carried out on a service class basis. Attending to the shortage of off-the-shelf class-based monitoring solutions, this project is focused on the development of a QoS monitoring tool conceived to multiservice networks. In this context, we propose a scalable QoS monitoring Java application, totally user parameterized and with support for service class differentiation. Benefiting from an edge-to-edge design perspective, this service-oriented tool is able to make a periodic evaluation of relevant QoS metrics, for each service class, on an end-to-end path basis. Monitoring results, stored on a mysql database, are useful to drive both online and offline traffic engineering and service management tasks. Index Terms Quality of Service, Active Measurements, Monitoring Tools, Network Management. N I. INTRODUCTION OWADAYS, Internet Service Providers (ISPs) are gathering efforts to converge services into a unified network infrastructure. This means that multiple applications with different Quality of Service (QoS) requirements need to coexist, sharing the available resources in the same network infrastructure. For demanding applications requiring tight QoS levels, assuring these service levels consistently still remains a challenge. The continuous grown of available network bandwidth is commonly pointed out as a reason to overcome this problem, however, it is only an additional motivation for applications to be more and more bandwidth consuming and QoS dependent. Service providers also follow this trend providing a bandwidth increase, and at same time, offering highly demanding services, such as telemedicine or interactive TV. This new generation of Department of Informatics, School of Engineering - University of Minho, Campus de Gualtar, Braga, Portugal. A version of this paper has been submitted to the 5th Euro-NGI 2009 Conference on Next Generation Internet Networks applications has a completely distinct behaviour when compared, for instance, with voice applications, requiring also a differentiated treatment from the network. In this context, measuring and monitoring the network activity and performance on a per service basis is of paramount importance to control QoS delivery. Providing measurement analysis has been a hot topic for network researchers for a long time and, in the last years, concrete development has been achieved toward active measurement solutions. Within IETF, IP Performance Metrics working group has standardized methods for Delay [1] and Loss [2] measurements, which converge in the relatively recent One-Way Active Measurement Protocol [3]. RIPE NCC project [4] is a good example of how to provide active measurements for European ISPs. Currently, the NCC solution does not support differentiation based on service classes. Other network-monitoring solutions mostly evaluate the network status and analyze its behaviour from a peer-to-peer single class point-of-view. These solutions are limitative within the New Generation Networks context, where the main concerns regarding monitoring are related to a scalable evaluation of end-to-end QoS delivery. In this work, we propose QMon a scalable and classbased QoS monitoring tool, which can be deployed within a single domain or over multiple network domains. The tool can be fully parameterized, which means that a user can easily configure the application to monitor a specific service behaviour, and use it for assessing each service class status and performance. A major advantage of our solution is that it is a Java multiplatform implementation. This means that, it is totally independent from specific monitoring and measurement hardware and network infrastructure. This also fosters portability, while being a cost-effective solution. The RIPE NCC project, as an effective operational network-monitoring platform, has been a strong reference for the present work, taking in consideration its successes and limitations. In our opinion, positive aspects include the use of a dedicated measurement infrastructure, active measurements, probing traffic resembling real traffic and the support for interprovider network measurements. A major limitation is that the network is viewed as a single class of best-effort IP service without performance guarantees. In addition, it is a proprietary commercial solution. The main objective of QMon, as a flexible, software-based monitoring tool, is to provide relevant information about the network QoS status in multiservice environments. In fact, systematic network monitoring is an essential management

2 QMon: A Class-based QoS Monitoring Tool 2 task as it allows to: (i) keep track of ongoing QoS and network performance levels; (ii) verify Service Level Specification (SLS) compliance; (iii) provide feedback to traffic control mechanisms and trigger network recovery procedures; and generically (iv) support traffic engineering tasks. These aspects, along with the lack of service-oriented QoS monitoring tools, stress the relevance and real applicability of the proposed solution. This paper is organized as follows: QMon design goals an architecture are presented in Section II and III, respectively; QMon components are specified in Section IV; implementation aspects are detailed in Section V; the results are illustrated and discussed in Section VI; and conclusions and future work are included in Section VII. Scalable the performance of a monitoring solution should be, as much as possible, independent of the size of the network being measured. The edge-to-edge nature of the proposed monitoring solution allows to improve scalability. III. MONITORING ARCHITECTURE To face the design goals previously described, we propose the monitoring architecture illustrated in Figure 1. II. DESIGN GOALS The main objective of this project is to develop a versatile monitoring tool able to perform QoS measurements in a-per class-basis, following the IETF IPPM Working Group [5] guidelines. The relevant metrics under study should be defined according to the requirements of each service class and to the definition of SLSs; generically, one-way delay, jitter and packet loss are the metrics considered for the defined service class. The proposed monitoring architecture (see Figure 1) lay on the following design goals: One-way measurements since Internet routing is a- symmetrical, one-way measurements allow, for instance, to identify the direction in which a eventual problem is experienced; Active measurements active monitoring carried out on an edge-to-edge basis, i.e. between the network boundaries in which a service level needs to be enforced, is particularly suitable for QoS control and SLS auditing. To fully control probing traffic characteristics, we include a traffic generation tool in the monitoring architecture; Fully configurable our solution offers a wide range of configurable options in order to adjust it to different measurement scenarios. This versatility includes a flexible traffic generation tool, which is able to generate probing traffic resembling as much as possible the applications characteristics sharing the class; the definition of the relevant metrics for each service class; and the identification of the involved Q-boxes; Infrastructure independent - in an end-to-end scenario, it is usual to have packets traversing different administrative domains, following, eventually, distinct administrative and configuration policies. Therefore, the interaction with network infrastructure and its particularities has to be minimal 1 ; Figure 1: QMon architecture The proposed solution encompasses two main elements: the QMon Q-boxes and the server. The Q-boxes are strategically distributed in the network, typically at its boundaries, and their main task is to exchange probing traffic in order to compute the QoS metrics of each service class. The server gathers all these measurements and Q-boxes configurations into a central database. Collected data remains available for subsequent analysis and support of management and traffic control actions over distinct time scales. These two elements are software based, more specifically, Java applications that can be installed in any available machine. In this way, implementation costs are minimized. As mentioned previously, to improve scalability the network is viewed as a black box, i.e., apart from the measuring ability of Q-boxes, our solution do not impose special requirements from network nodes and do not depend on network configuration particularities. This is a clear advantage over hardware-based or proprietary approaches [4]. 1 Although it is not within the scope of our work, considering the usage of the monitoring tool in a controlled environment (e.g. single administrative domain), it would be interesting to interact with the network nodes in a path, to get available QoS measures (e.g. in routers MIBs) and useful information on how nodes handle probing traffic. This would enhance the scope of current measurement capabilities. A. QMon Server The server is a central component of the architecture, where the measurements from all Q-boxes are stored. As measures are being received, they are inserted into a local or remote

3 QMon: A Class-based QoS Monitoring Tool 3 database (e.g. MySQL or Oracle), remaining available to be accessed by external entities, which can make independent data manipulation. The status of all existing Q-boxes and their configuration is also maintained in the server. This allows data to be changed on-the-fly by sending them update messages. The server is also responsible for notifying the Q-boxes when a new Q-box becomes active or inactive, and new service measurement policies need to be deployed. The communication primitives exchanged between the server and the Q-boxes will be described in the next section. Note that, despite the central nature of the information gathering, in the medium/short term, the measures remain available in the Q-boxes to guide distributed traffic engineering, avoiding the functional dependence and congestion of a single central entity. B. QMon Q-box Q-boxes are responsible for generating, sending and receiving probing traffic, to evaluate the relevant metrics of each service class. This means that the characteristics of probing traffic and the metrics evaluated are servicedependent, and depend on the configuration previously received from the server for each service class. The sending process follows the same line, where the defined rate stems from the previous user definition on the server. Receiving packets is the end function for the Q-box. This process has to calculate the multiple metrics, sending them to the server. In practice, the text-boxes configuration parameters may be derived from both the negotiated SLAs and the internal ISP policies for service configuration and control. A. Server specification IV. SPECIFYING QMON COMPONENTS 1) Client-Server communication Communication among Q-boxes and the server is made through the protocol illustrated in Figure 2. measuring process and start receiving probing traffic. If a Q-box is already registered with the same identification a proper notification (USED_BOX) is sent, otherwise the server sends an OK message; 2. The server sends all the information that the Q-box needs before sending measurement traffic. This process is based on two distinct sequences of messages: one informing the characteristics of the defined service classes; and the other providing each Q-box IP address and identification. After this, the new Q-box is ready to send and receive probing traffic to and from all test boxes 2, according to the service classes characteristics; 3. At this stage, every time a sample of probing traffic is fully received by a Q-box, the metrics of the corresponding service class are calculated and sent to the server. This process is done repeatedly while the test box remains operational. The server receives these messages and inserts its contents into a database; B. After a new Q-box is registered, the server notifies all other active Q-boxes of its existence, using the same session that it has already established with each one of them. This sustains the dynamic adding of new Q-boxes to the platform, without interrupting the measurement procedure; C. When a Q-box shuts down, the existing session between this Q-box and the server will be closed. The server will notify this occurrence to other Q-boxes in order to stop the measurement flow to the offline Q-box; D. Whenever a new service class is defined or updated in the database, its new settings are also sent to all the involved Q-boxes. Thus, measurement traffic related to new service classes may start without interrupting the measurement procedures for the remaining classes; E. Similarly, whenever a service class is removed from the database, the server notifies all the involved Q-boxes, so that they can remove the obsolete class from their local information structure. Once again, the measurement procedure for the remaining service classes is not disrupted. 2) Database Figure 2: Q-Box/Server communication scheme. A. The initialization of a Q-box comprises the following phases: 1. Initially, the new Q-box establishes contact with the server and sends its identification. The server registers the Q-box and notifies other Q-boxes that a new box is in place (B), so it can be included in the The routing process in IP networks is commonly dynamic, meaning that, from an end-to-end perspective, packets can be sent through different routes over time. This brings the need to perform route pinning on a particular end-to-end flow. Thus, each set of metrics is associated with the route found in the period of time that the measurement was carried out, i.e., the measuring time interval. For each sample, the values of the 2 In fact, only the Q-boxes within the service scope need to be informed.

4 QMon: A Class-based QoS Monitoring Tool 4 calculated metrics are stored in a MySQL database [6], according to the structure represented in Figure 3. Figure 3: Developed database scheme Whenever a new set of metrics is added, the existence of a measurement flow between two Q-boxes is verified, followed by the verification of the associated route, being created if they are still not defined. This relationship is obtained by forcing each record from Table Metrics to be related with a route between two Q-boxes. Table Flows identifies the origin and destination of end-toend flows between Q-boxes, being assigned a unique identifier. Table Routes identifies the routes and their number of hops, each one associated to the existing flow identification. Table Metrics identifies the values of each metric. These metrics are differentiated per service class, and report to average values of a probing sample in the corresponding measurement time interval. traffic reflecting traffic generated by a specific application 4. In addition to manipulate the packet building process, it is also required to parameterize the probing rate, as applications (and users) exhibit different behaviours and characteristics. These aspects are contemplated in our solution, and we keeping them as generic as possible. In more detail, there is one independent sending process for each Service Class, modulated as an ON/OFF source. During the ON state, the sending process will build and send synthetic traffic for a certain period of time (determined by the number of probes appropriated for that Service Class sample); during the OFF state, the sending process will stand-by for a configurable time period (a time value between samples). For each ON state, and for each service class, the sending process will check the service class configuration for the waiting times, the number and type (TCP/UDP) of packets to build and send in the sample. This makes the traffic model generic and functional for all Service Classes. This process is quite simple yet realistic, as probing traffic can be adjusted to the class characteristics. Initially, the sending process builds a packet with the specific Service Class identifiers, then, sends it to every Q-box in the network and, finally, waits a very short period of time before sending a new one. B. Q-box specification Each Q-box has three main structures (that can be updated by the server on-the-fly 3 using the messages previously defined): Q-box list contains the identification and the address of all active Q-boxes; Class of Service configuration contains the configuration parameters of all classes. The configuration parameters for each class are: protocol, port, number of packets per sample, time between samples and timeout of a sample; Samples - contains the timestamps of packets within a sample and the paths from the sender Q-boxes; and three main processes: Sending process responsible for creating and sending the samples; Receive Process responsible for receiving the samples from all Q-boxes; Server Communication Process responsible for the communication with the server. 1) Sending process An important advantage of developing the sending process is to obtain full control of low-level packet building; this is achieved using the Jpcap library [7]. This control gives the opportunity to construct probing samples (which are a set of packets following a certain pattern) of synthetic network 3 The information on the Q-box is updated while it is still active. Figure 4: ON/OFF process scheme; Y is the number of active Q-boxes; T is the Poisson waiting time; n is the number of packets sent in a Service Class sample. This waiting time is what determines the bit rate of the probing source. In addition to Constant Bit Rate (CBR) sources, probing traffic may also follow a Variable Bit Rate (VBR) pattern. During the ON period, the traffic rate variability is determined by a Poisson distribution, which regulates the inter-packet waiting time. This variability also reduces the chance of traffic synchronization, as periodic network perturbations resulting from probing itself can drive the network into a synchronization state, which may end up affecting the measurements, leading to biased metrics. The traffic generation process is independent of the destination Q-box, as no session is established. In this way, the measurement overhead and latency are reduced. The choice of 4 It is not the scope of this work to generate synthetic traffic identical to a specific application, but to create a generic context solution where the user can define the expected traffic characteristics adjusted to the service class being measured.

5 QMon: A Class-based QoS Monitoring Tool 5 packet type is determined when configuring the probing source of each Service Class. Thus, the sending process automatically checks the configurations for that Service Class in the database and generates the respective TCP or UDP packet. As mentioned before, packet building is carried out resorting to the defined settings for the respective Service Class. Having full control of packet building opens the opportunity to use the probe payload to convey useful information for the destination box: <boxid>::<serviceclassid>::<timestamp>:: <seqnumber>:: <path> More specifically, <boxid> is the identifier of the current Q-box generating the traffic; <serviceclassid> is the Service Class identifier; <timestamp> is the current system time at the origin Q-box, which is going to be synchronized with the destination box using NTP (Network Time Protocol) [8]; <seqnumber> provides a sample identification function so that the destination box knows exactly the number of packets sent in this sample and, therefore, loss can be detected 5 ; <path> indicates the path between the origin and destination boxes 6. The sending process described above is fully configurable and flexible. When a new service class is defined, the new QoS parameters will be automatically interpreted and measured in all destination boxes within its scope. 2) Receive Process For the probing traffic reception and analysis, all Q-boxes are listening for incoming packets/probes. When a new packet is received a timestamp is added to it and a validation process starts. This validation process consists in two steps. Firstly, the list of active boxes is verified, if the sender of the packet is unknown, the packet is discarded. Secondly, the payload of the packet is checked to see if it matches the syntax previously defined. After validating the packet, the payload data is verified in four stages. In a first stage, the identification of the sender box should match the sender address of the packet. Secondly, the identification of the service class is validated. Then, the sender timestamp is checked against the receiver timestamp. Finally, the sequence number should match the range of values defined for its class. If any of these stages fails, the packet is discarded. After this validation and verification process, the information of the packet is gathered into a structure that contains the box identification, the class identification, the path, and the timestamps generated at sender and receiver. If 5 When sending TCP packets, we avoid TCP acks so the origin box is unable to know that a packet is lost, and no retransmission is carried out. 6 The path is evaluated using a traceroute-based approach carried out at the beginning of the ON state. We have decided to insert the path in all probing packets to increase their length and, in this way, avoid compression by the networks transferring them, affecting the transmission time [4]. the received packet is the first of a new sample, the Q-box, the service class identification and the system time plus the timeout value defined for the class are inserted into a timeout table. The timeout table contains the time limit that a Q-box should wait for the missing packets from a sample. When all the packets from a sample are received or when the timeout expires, the QoS metrics are calculated. In the QoS metrics evaluation, three metrics are considered for each sample: mean delay, jitter and packet loss ratio. In addition, the maximum delay and maximum jitter in the sample are also determined. The mean delay is given by: According to [9], the jitter is given by, where, R i is the arrival timestamp and S i is the send timestamp of the packet i. When jitter cannot be evaluated (e.g. lack of packets), the error value -1 is reported to the server. The packet loss ratio is given by: After the evaluating the QoS metrics, the corresponding values are sent to the server in a METRICS message, using the following syntax: METRICS:<boxId>::<sendBoxId>::<path>:: <timestamp>::<class>::<maxdelay>::<meandelay>::<jitter>:: <packetlossratio> The <boxid> is the identification of the current Q-box; <sendboxid> is the Q-box which sent the sample; <path> identifies the path between <sendboxid> and <boxid>; <timestamp> indicates the mean timestamp of the sample, i.e., the mean between the timestamp of the first and of the last packet within the sample; <class> is the identification of the Service Class; <maxdelay> is the maximum delay found in the sample; <meandelay>, <jitter> and <packetlossratio> are the calculated QoS metrics. 3) Server Communication Process When a Q-box receives a notification from the server that other Q-box has become active, the identification of the new box is inserted in the list of active Q-boxes. A new record to

6 QMon: A Class-based QoS Monitoring Tool 6 save its samples is also created and inserted in the metrics structure. When a Q-box becomes inactive the corresponding records are deleted from the list of active Q-boxes and from the metrics structure. When the server sends information about a new service class, the Q-box inserts those values in the Service Class configuration structure and starts the sending process for that class. If the server notifies that a service class is due to be removed, the Q-box stops the sending process for that class and removes the corresponding record from the structure. V. QMON IMPLEMENTATION The main programming language used in the development of QMon is Java. This object-oriented language is clearly one of the best options for networking programming as it allows high-level control and abstraction of network complexity. For low-level network control, the open source library Jpcap [7] was used. This section will focus on the implementation details of the architecture main components: QMon Server and Q-box. A. QMon Server 1) Server/Q-box Communication The server stays in a listening state, waiting for new connection requests from the Q-boxes. Thus, when a new Q- box establishes contact, a new TCP socket is created, establishing a session with the new machine. Then, the server records the IP address, the identification of each Q-box, and a thread indicator related to this text-box/server session. In this way, the server has the knowledge of all existing Q-boxes, and the ability to notify them if any Q-box s state changes. The process of notification is carried out through the invocation of methods implemented in the communication thread that each Q-box has with the server. When Q-boxes or service classes are added or removed, these methods are invoked, for addressed Q-boxes. Each Q-box sends to the server messages with the measurement values obtained for each sample, so they can be insert into the database. To interact with the database we have created a generic API, which allows performing queries and statements to MySQL or Oracle 10g databases. Additionally, we have created an extension of this API that allows the server to insert, remove and query our database, in particular. These methods take into account any restrictions that the destination table may have. The process of obtaining the metric values is carried out querying the database. Thus, we have implemented a function that begins by performing a query, filtering entries for the required time length, for a particular origin, destination and metric. Each point in a graph corresponds to the average of all entries within that time interval. The shorter the time slice representing a point, the higher the resolution of the series represented in the graph. However, this interval of time cannot be too short, otherwise it may contain no entries. The value for the time slice is currently received as parameter so that the graphical representation can be easily set, with variable granularity. We have used the function specified above to render four graphs, where the metric values are obtained for the last 5, 10, 30 and 60 minutes. The time to represent in each graph is easily changed by simply adjusting this parameter. Each time the web page is reloaded, a database query is issued to retrieve the identification of all origin and destination Q-boxes. In this way, the identification of the Q-boxes presented in the existing roll boxes is dynamic. So when a reference to a Q-box is inserted or removed from the database, the information in the front-end is automatically updated. B. Q-box As planned, the Q-box has a simple role in the whole architecture with a plug-and-play profile. For this reason, there is no need for interface complexity and additional functions beyond the basic. The text-box application has a simple text-based interface that guides the user through simple initial configurations. First, all active network interfaces that can be used by the application are shown and detailed: ============================== = QMon TESTBOX v1.0 = ============================== Log SendBox Interface: 1 Type: Ethernet MAC Address: 0:1d:ba:19:60:ee: Network Address: /fe80:0:0:0:d938:f9aa:8a8d:35ef null / / Log SendBox Interface: 2 Type: Ethernet MAC Address: 0:16:ea:26:3d:e: Network Address: /fe80:0:0:0:cc9:f70e:d6a4:67da null / / ) Front-end To access the measurement results, we have developed a web front-end, since it provides easy access to this information, with a distributed profile. The front-end consists of a php page with different graphs. To provide access to QMon front-end, we have created and configured a php and an apache web server. Next, the user is questioned for essential information to proceed with the application initialization: QBox Identification: Aveiro Server Address: Interface: 2 The BOX identification is the key for distinguishing the Q- box in the database. Obviously, the Server Address has to be

7 QMon: A Class-based QoS Monitoring Tool 7 the one used to build the control connection between the Q- box and the server. Finally, the Interface, chosen by the user from the network interfaces presented previously, is the one used to send and receive the packets. After the initial configuration, the Q-box generates two distinct procedures: packet building and sending; and packet reception and analysis. These procedures are detailed below. 1) Packet building and sending procedure When the Q-box application is initiated (and after the initial configuration), a main thread is going to be actively waiting for server communications. When a NEW_CLASS message is received from the server, the current thread processes it, launching a new one, which works with the received parameters. This is where the sending process starts for a Service Class. The new launched thread is going to be active while the Service Class is registered on the local database. When a REMOVE_CLASS message is received from the server, the class entry is removed and the thread is dropped. This sending process follows the ON-OFF state transition explained previously. In the ON state, the thread calls the sendsample method, and gets asleep for a defined period, corresponding to the OFF state. The sendsample method is responsible for building and sending a sample. The sample is created according to the Service Class configuration parameters and forwarded, packet-by-packet for each active Q-box registered. The preliminary task before sending a sample is to trace the route for each destination Q-box. This allows discovering the traversed path beforehand so that it can be inserted in the packet payload for additional information (e.g., to determine the number of hops; to detect route changing, which may justify significant changes in the QoS measures). This traceroute like process was developed building ICMP packets, using the Jpcap library. Jpcap author example [10] was modified to save the result in a string type instead of continuously printing it. To be more accurate on the obtained result, we do not consider two consecutive equal hops, which is a possible and well-known problem of this procedure. Having performed the path discovery for each destination Q-box, we proceed with the payload construction. As said before, the payload includes useful data to the destination Q- box, namely: box ID; Service Class ID; timestamp; packet sequence number; and path. The timestamp is calculated using the Java method System.currentTimeMillis(). Although this is is not completely accurate due to possible delays between the packets build and send process, it is a viable solution for testing our prototype. Once the payload is complete, the probing packet can be build, and marked taking into account the Service Class typeof-service. To allow a plug-and-play profile, the default router for the current network need to be found automatically. Inspired by a Jpcap code sample, the default router is found by opening a connection to any URL (in our implementation, we have used a valid URL: followed by a packet capture. The default router will be identified by the origin MAC Address of incoming packets. Alternatively, the system registered default router could be checked, however, that would make our system dependent on the existing operating system, which contradicts our multiplatform design. After sending a packet, the process waits for a random interpacket time defined, as explained before, by a Poisson distribution. After all packets within a sample are sent, the process is restarted and kept active while the Service Class is registered or the user does not stop it. 2) Packet reception and analysis procedure The packet reception and analysis procedure is implemented in two threads. The first one is responsible for capturing the packets and analyse them. As explained before, every time a packet is captured, this thread analyses and checks it. If the packet and payload data are correct, the timestamps (send and arrive) are saved in the correct position (depending on the sequence number) of an ArrayList. To avoid packet duplication, if the position on the ArrayList already contains a value the packet is discarded. There are multiple ArrayLists to save the timestamps of all Service Classes from all Q-boxes. Those ArrayLists are saved into a HashMap where the key is the Q-box (the sender) identification and the Service Class to which those timestamps belong. The maximum size of each ArrayList is the number of packets that we expect to receive from each Service Class. Thus, when a packet is received and its information is inserted, if the ArrayList reaches its full capacity, the sample is complete and the QoS metrics should be calculated and sent to the server. The second thread is responsible for verifying the timeout table, searching for expired time values. When the first packet of one sample is received, the current time of the system and the timeout value defined for the corresponding Service Class, are inserted into a HashMap, where the key is the Q-box and Service Class identifier. Along the time, this thread compares the system time with the timeout values in the table; if a timeout values is exceeded, the QoS metrics for that sample are calculated and sent to the server. C. Time Synchronization The reliability of QoS measurements depends, among other characteristics, on appropriate synchronization methods between Q-boxes. Inaccuracies on time reference of communicating Q-boxes must be avoided, since it would result in unreliable measures between them. The protocol used to synchronize the Q-boxes is NTP (Network Time Protocol), which is the most used protocol to synchronize time across the Internet. NTP is organized in a hierarchical client-server model, through several levels called stratum. Ideally, a stratum 1 NTP server that synchronizes directly with a reference clock stratum 0 (e.g., GPS) should be used. However, we were unable to use such technology, so we configured a dedicated NTP server, which synchronizes from 3 public NTPs servers. Q-boxes where then set to synchronize only with our server. In this way, all Q-boxes use the same time reference, reducing inaccuracies that could result from

8 QMon: A Class-based QoS Monitoring Tool 8 using distinct synchronization sources. As future work, the synchronization method needs to be improved. VI. MEASUREMENT TESTBED AND RESULTS To test QMon, a multiclass network prototype was created. In this prototype, four service classes were defined and configured according to their QoS requirements and DiffServ guidelines [11]. Limitations on existing traffic, make difficult the test of QMon at is its full potential, not allowing to notice a significant difference between the different Service Classes. Thus, the monitoring solution was tested in two stages. Firstly, the sending process was tested resorting to the Wireshark tool [12]. Analyzing the logs on each Q-box, it was verified that the samples were sent correctly. Secondly, the receiving process was tested, using a simulator that was created to generate packets with specific timestamps to force distinct delay and jitter measures for each Service Class. The results for the delay metric are shown in Figure 5. Figure 5: Delay measures Comparing the QoS measures obtained with QMon with the expected measures considering the packets timestamp, we verify that metrics were correctly calculated. To visualize the QoS measurements, a web interface updated in real-time was created (see Figure 6). Each graph represents the temporal series of a specific metric between two Q-boxes, calculated resorting to the metrics stored in the database. In this example, the delay metric is represented on different time slices/temporal scales. Although the maximum time represented in the figure is one hour, the interface is configurable, and measurements in short, medium and long time scales can be observed, depending on the user configuration. Each service class is represented in the graph by the corresponding delay measures. For each point represented, the metrics values for the corresponding time slice are accumulated, and then divided by the number of samples obtained for that time slice. Thus, a mean value for a specific group of samples is calculated. This allows rendering graphs with the expected custom detail. VII. CONCLUSIONS AND FUTURE WORK In this paper, QMon - a QoS monitoring tool for multiservice networks has been proposed. This tool, which may be used by single users or by ISP s, is able to measure the QoS of distinct service classes between multiple measurement points in the network. The monitoring results can be accessed directly from the monitoring database or from a web interface available on the server. The proposed multiplatform tool provides an added value as a versatile and cost-effective QoS monitoring solution when compared to hardware-based monitoring platforms. As future work, we intent to further develop or improve several aspects of the proposed QoS monitoring solution, namely: (i) to provide authentication support for users and Q- boxes, and to avoid denial-of-service attacks, tacking security issues; (ii) to consider distinct monitoring methodologies for controlled networks, in addition to edge-to-edge active monitoring, such as passive capture of available data within the network nodes along the path. This allows enhancing the QoS evaluation of existing service classes; (iii) to reduce the size of the database and the amount of traffic exchanged between the server and the Q-boxes. Strategies for aggregate measurements are under study. For instance, the Q-boxes could only send measures to the server when a significant change in the metrics values is observed; (iv) currently, the configuration parameters are user defined and are the same for all Q-boxes. In the future, we are planning to derive those service parameters from the negotiated SLSs, sending them only to the Q-boxes within the scope of the service contracted in the SLSs. Figure 6: QMon metrics front-end REFERENCES [1] G. Almes et al, "A One-way Delay Metric for IPPM", RFC 2679, September [2] G. Almes et al, "A One-way Packet Loss Metric for IPPM", RFC 2680, September [3] S. Shalunov et al A One-way Active Measurement Protocol (OWAMP), RFC 4656, September [4] F.Georgatos et al, "Providing Active Measurements as a Regular Service for ISP's". In: Proceedings of the Passive and Active Measurements Workshop PAM2001, Amsterdam, April [5] Internet Engineering Task Force, IP Performance Measurements Working Group (IETF IPPM-WG), see

9 QMon: A Class-based QoS Monitoring Tool 9 [6] The MySQL database management system, see [7] Jpcap - [8] David L. Mills, Network Time Protocol (Version 3) Specification, Impl, RFC 1305, March 1992 [9] H. Schulzrinne et al,"rtp: A Transport Protocol for Real-Time Applications", RFC1889, January 1996 [10] [11] J. Babiarz et al, Configuration Guidelines for DiffServ Service Classes, RFC 4594, August 2006 [12] Wireshark network protocol analyzer -