Sablona na TMA, do ktorej postupne pisem sem prekopirovane casti:

• tma_template.zip: sablona pre TMA

Pripomienky pre seba (Ado):

• je potrebne este prekontrolovat aby casy sedeli (raz mozno pisem v sucasnom, niekedy zas v minulom stave)
• co je spravne analyser alebo analyzer??? Piseme ich s malym alebo velkym zaciatocnym pismenom?

## JG: som za pouzivanie Z v slove analyzer, americka anglictina je v takychto materialoch beznejsia. a zaciatocne pismeno by malo ostat male, ak hovorime o analyzeri vo vseobecnosti. ak spominame nejaky konkretny (BM Analyzer, WebAnalyzer), tak ma byt zaciatocne pismeno samozrejme velke.

• Normally both '-ise' and '-ize' endings for verbs are allowed in UK English, while only '-ize' is found in the US. English teachers around the world insist on consistency, so the basic rule is: if you're using '-ize' for your verbs then use 'analyze'; if you use '-ise', then stick to 'analyse'.
• treba sa rozhodnut ktory Analyzer budeme uvadzat (BMAnalyzer, WebAnalyzer). Teraz raz pouzivam jeden, niekedy zas druhy

## JG: myslim, ze toto si elegantne osetril tym, ze v kapitole o basicmetri uvadzas bmanalyzer, spominas jeho nastupujucu webovu verziu a zaroven uvadzas, ze v dalsom texte budeme uvadzat len oznacenie "analyzer" (a toto moze byt v celom zvysku clanku pisane malymi pismenami).

## JG: poznamka pre mna - treba skontrolovat a v pripade potreby opravit slova metering vs. measuring vs. monitoring

Overview and Insight into the MONICA Research Group

Abstract: This paper deals with the activities of the MONICA research group of the Computer Networks Laboratory at the Technical University of Kosice in Slovakia. MONICA stands for the Monitoring and Optimization of Network Infrastructures, Communications and Applications. Our main areas of interest are related to development of the BasicMeter tool built in conformity with the IPFIX architecture. In this paper we give an overview of our solution and proposal of several enhancements over the scope of IPFIX, such as time synchronization for the one-way delay measurements, the protocol for direct communication with analyzing application, the centralized management of the monitoring platform, and the support for the real-time monitoring.

Keywords: network monitoring, network traffic, monitoring tool, IPFIX

Introduction

Network traffic monitoring plays key role in the operation of computer networks. There are plenty of motivation factors for the network monitoring with different purposes in different application domains such as usage-based accounting, SLA evaluation, security analysis, traffic engineering, traffic parameters analysis and their optimization as a supporting mechanism for the implementation of QoS needed for some certain services, etc. Importance of the network monitoring is obvious.

We work in the area of monitoring nearly ten years in the Computer Networks Laboratory at the Technical University of Kosice in Slovakia. All it began by short stay of our colleagues in the Fraunhofer Institute for Open Communication Systems in Berlin. Then we developed our first own monitoring tool based on the NetFlow specification, later we implemented support of IPFIX protocol in it. After several years we have established the MONICA Research Group with focus on the monitoring and optimization of network infrastructures, communications and applications.

All the MONICA activities are somehow connected to the network monitoring. We follow several goals:

\begin{itemize}

\item Development of tools and methods for the obtaining of IP flow information - main goal is the development of BasicMeter tool in conformity with the IPFIX and PSAMP. Along with the work on IPFIX implementation we work also on optimization of the monitoring itself and adding some features which are not covered by the IPFIX specification.

\item Development of tools utilizing the monitoring in different application domains - mail goal is utilization of information obtained by the BasicMeter tool for different purposes such as usage-based accounting, SLA evaluation, intrusion detection, and traffic engineering.

\item Experimental deployment of the monitoring tools even in the laboratory environment and in the real networks with the goal of testing the functionality and interoperability, performance analysis and getting feedbacks for further development.

\end{itemize}

In the following sections we provide an overview of the MONICA activities starting with a brief introduction of the BasicMeter tool and following with an overview of its enhancements with insight into the selected ones.

The BasicMeter Tool

BasicMeter is a metering tool designed for network traffic parameters monitoring. The measurement is based on passive method, which does not require generation of additional network traffic. The concept of the BasicMeter architecture is in conformity with the IPFIX requirements. Its main components are depicted on the figure[]; their brief description is the following:

• BEEM - stands for BasicmEter Exporting and Metering process. It covers packet capturing, filtering, sampling, creating and maintaining of flow records in the flow cache, and exporting of flow records from observation point by IPFIX protocol. It is a console application written in C language. Configuration of BEEM can be done by the modification of its XML configuration file.
• JXColl - stands for Java XML Collector. It can collect flow records exported from several observation points in the format of protocols Netflow v5, Netflow v9, or IPFIX. Flow records can be stored in a database (for future use and analysis) and/or directly sent to an analyzing application by ACP. JXColl can also generate accounting records and store them into the special database for the usage-based accounting. Configuration of JXColl can be done by the modification of its XML configuration file.
• BM Analyzer - stands for the BasicMeter Analyzer. It provides user front-end for both the visualization of the information obtained by observation points and management of the every single component of the BasicMeter tool. BM Analyzer is a standalone Java application accessible via Java Webstart technology, but ongoing version is designed as a modular web application integrating centralized management and many potential IPFIX applicabilities.
• ACP - stands for Analyzer - Collector Protocol which serves for direct communication of collector and analyzer making this communication fast enough for the real-time monitoring.

Regarding to the roles of these main components (BEEM, JXColl, BMAnalyzer), in the following they will be referred as the exporter, collector and analyzer.

Enhancements of the IPFIX Based Tools Developed by MONICA Research Group

As we mentioned before, along with the implementation of IPFIX based monitoring tool we work on several enhancements and add-ons. These can be divided into two categories -- enhancements of the architecture for obtaining of IP flow information, and application domains specific tools.

Enhancements of the architecture for obtaining of IP flow information being developed by MONICA:

\begin{itemize}

\item Analyzer - Collector Protocol (ACP) for direct communication of collector and analyzer as a supporting mechanism for the real-time monitoring. In the BasicMeter architecture the analyzer is intended to visualize the data computed on the basis of the gathered traffic information, and to manage the other components of the tool. However, the analyzer itself is not a subject of the IPFIX specifications and therefore we had to draft and implement our own network protocols for the data flow and communication between the analyzer and the other components of the metering tool. Along with the ACP we have developed also application programmable interface (API), so it can by easily implemented into the any analyzer-like application. More details are provided in the dedicated subsection of the paper.

\item Exporter - Collector - Analyzer Manager (ECAM) for the centralized management and easy deployment of the monitoring tool. ECAM is implemented at the each component of the BasicMeter tool providing user-friendly configuration of all the exporters and collectors in the observation domain from the analyzer user interface. It also provides information on status of exporting and collecting processes and has a possibility for remote control of them including start/stop/restart of such processes. Meanwhile, configuration data model has been drafted by the IPFIX WG, so we will follow it and incorporate it into our solution.

\item Data WareHouse for data preprocessing and storing for efficient access by the analyzing application. This is supporting mechanism for achieving smaller response time during the selection of historical flow records from the database, especially when the select would return large amount of records. More details are provided in the dedicated subsection of the paper.

\item Adaptive export of flow records from the observation points for the purpose of real-time monitoring. In some application domains, where the real-time monitoring is required (e.g. traffic engineering, intrusion detection, etc), short exporting interval should be used. However, very short intervals would lead to the exhausting of the system resources consumed by the monitoring tool. Therefore we developed an idea of adapting the exporting interval to the changing behavior of the network traffic.

\item Measurement of one-way delay (OWD) with compensation of observation points’ clock skew. The basic idea of OWD measurement seems to be very simple -- it is just subtraction of timestamps for single packet observed at the different points. However, implementation of this idea should solve several problems such as generation of unique packet identifiers, time synchronization of the observation points, and compensation of their clocks' skew. There are existing solutions with very high precision, but these are typically very expensive because the high precision can be achieved only by using of the specialized hardware components. Our approach is precise enough and costs almost nothing. More details are provided in the dedicated subsection of the paper.

\item Implementation of new information elements into the information model. Some of our enhancements required implementation of the information elements which were not defined by the IPFIX information model. Therefore we defined own ones and export them with the Enterprise ID of 26235.

\end{itemize}

Application domains specific tools being developed by MONICA:

\begin{itemize}

\item Usage-based accounting which allows more flexible accounting for network services than flat-rate accounting and brings advantages for both service providers and users. Our solution contains the accounting database and additional function of collector which creates accounting records by aggregation of flow records using specified criteria.

\item SLA evaluation for tracking of the agreement fulfillment between subscriber and provider. Our solution provides web interface for the both sides with the specific information about the operation and traffic parameters of the last mile. It has a modular architecture, so it is easy to add new components upon the needs of such type of users.

\item Anomaly based IDS which builds information characterizing the normal traffic, evaluates the current traffic, and alerts administrator when violation occurs. Anomaly detection is implemented by fuzzy subsystems designated for the detection of the specific types of network attacks, and also for the detection of general anomalies of the network traffic.

\item Adaptive anomaly driven traffic engineering (AADTE) using different dynamically applied configuration changes into the network devices, such as routing optimization, usage of QoS mechanisms, or security policy enforcement. Specific optimizing changes are selected by the domain-specific decision maker module when the traffic anomaly is detected.

\item Monitoring of information systems

\end{itemize}

Detailed description of all the enhancements would be over the scope of this paper, thus we present just selected ones in the following subsections.

Analyzer Collector Protocol

###ACP (Analyzer Collector Protocol) for the direct communication of collector and analyzer ### zakladna myslienka a motivacne faktory (support for real-time monitoring), referencia na predchadzajuce clanky (info doplnim)

In the primary concept of the BasicMeter tool, the measured data should be stored in a database for later analyzes. However, this method is in the case of real-time monitoring and data computation inapt.

The time necessary for the Analyser to get the traffic information using a database depends on many factors that are difficult to estimate. These factors are e.g. the time needed by the exporter to prepare and transmit the flow record to the collector; the time required by the collector to parse the flow record and transmit the data to the database; or the time required by the analyzer to process the received data from the database. Another significant time period is the one that is consumed by the database server to store the data and to return the result for the analyzer’s query; This time period is hardly dependent on various database technologies and data storing techniques. Moreover, width the growth of data in the database, the processing of the queries is becoming more and more time-consuming.

For this reason we developed the Analyzer-Collector Protocol (ACP) which allows the Analyzer to gain data about network traffic directly from the Collector without the ineffective access to the database. The collector is permanently inserting the traffic data into a database and if needed, by the means of ACP it is simultaneously sending exactly the same data − or by a customizable filter a part of it − to the analyzer.

ACP is a binary, application layer protocol. The communication (TCP is used for) is bidirectional and works on the base of the client-server model, where the client side is represented by the analyzer and the server side is represented by the collector. Over ACP, besides data, control messages are also transmitted. These messages are dedicated for format and accuracy check of the received data by the analyzer.

The communication is based on sending queries by the analyzer and sending replies with data by the collector. This type of communication could be easily illustrated by a Finite State Machine (FSM) of both sides. The particular communication phases are represented with machines states at which every message has its own unique ID. Figure 1a and 1b depict the state transitions of Analyzer-Collector Protocol. State graph in Figure 1a is representing a Mealy type Finite State Machine. Figure 1b is describing a Moore Machine. For the reason that the outputs of the Moore Machine are representing the particular activities of the Analyzer (e.g. receiving the data), they are not present in Figure 1b.

@Control messages sent by analyzer are: MA TV0(MA TV1) − incorrect (correct) authentication data; M0 TV0 (M0 TV1) − incorrect (correct) template; M1 TV0 (M1 TV1) − incorrect (correct) filter; M2 TV0 (M2 TV1) − data transmission unsuccessfully (successfully) suspended; M3 TV0 (M3 TV1) − data transmission unsuccessfully (successfully) resumed; M4 TV0 (M4 TV1) − not supported (accepted) mode of data transmission; M5 − acknowledging the received data.

@Control messages sent by collector are: MA TV0 (MA TV1) − access denied (garanted); M0 TV0 (M0 TV1) − the requested template was rejected (accepted); M1 TV0 (M1 TV1) − filter rejected (accepted) ; M2 TV0 (M2 TV1) − suspension of data transmission was rejected (accepted); M3 TV0 (M3 TV1) − resume of data transmission was rejected (accepted); M4 TV0 (M4 TV1) − mode of data transmission is not supported (mode of data transmission supported and also accepted).

Where MX states for control message type; TVY states for truth value of the request—response.

@tieto casti by sme mohli zakomponovat v nasledujucej casti a tak by sme skratili clanok o presne 13 riadkov

### sem pojdu minimalne tie obrazky o FSM.

At the initial state, the collector is awaiting the analyzer’s connection at a pre-agreed port (2138 by default). If the connection is established successfully both sides traverse to their S1 (Start) states. Before the bi-directional communication can be opened, the analyzer has to authenticate (MA) itself. On each request the collector responses with an acceptance (TV1) or rejection (TV0) message. Successful authentication brings both sides to their S2 (Waiting) states, otherwise the collector terminates the connection. In S2 state the analyzer using the template message (M0) can set the desired format of the received data. If the template is accepted, the collector traverses to its S4 (Transmitting) state and starts with the data transmission in the format of the accepted template. On the other hand, the analyzer traverses to its S3 (Receiving) state and starts to receive the data from the collector. In this phase the template could be changed at any time. Real data besides control messages are sent/received only in states S3 /S4 . By default, the collector exports all the traffic information obtained from the exporter(s). However, in a case of need, by setting the filter (M1) it is also possible to receive only specific information. This optional step is accepted by the collector only in its S4 state, while only one filter can be set in a time. The filter can be canceled or replaced with empty filter rule in the collector’s S4 state. Traffic information can be filtered based on the source, destination and measuring point’s IP adresses; source and destination port; and protocol. When necessary the transmission of the data can be suspended (M2) anytime in which case the collector first sends every data from the currently processed flow record to the analyzer and then both sides traverse to their S5 (Suspended) states. In general, the collector has no reason to discard the suspension request. The data transmission can be resumed (M3) anytime which brings both sides to their previous states. By default the collector sends the data in N-tuples, which means that during one cycle of data reception the analyzer receives N values. This type of data transmission (M4) can be changed optionally in the collector’s S4 state. Data can be also transmitted one-by-one. Data transfer synchronization is ensured by acknowledging each received data (M5). Unfortunately receiving data by ACP brings a certain delay with itself too. However, compared to the delay when obtaining traffic data using a database this time period is significantly less. Thus from the point of real-time monitoring, gathering traffic data by ACP is more affordable.

Application Interface of the ACP

In the BasicMeter architecture while only one collector is needed, from analyzers could be more. In this case the ACP would need to be implemented more than once (analyzers may vary in structures and purposes). While the implementation of this kind of protocol is in some cases really problematic, there was a need for an Application Programmable Interface (API) which would simplify the implementation process of the ACP in various analyzers.

For this reason we developed the Application Programmable Interface for servicing the Analyzer-Collector Protocol (ACPapi). ACPapi was designed to simplify the work of the programmers during the development of real-time data dependent applications. Its main purpose is to serve the ACP whereby the programmers do not have to care for the implementation details of this protocol. Obtaining the data with ACPapi was designed as a design pattern in which the incoming messages and data are read in a cycle. Of course the data could be obtained by other methods too, but from the point of real-time data computation this method is the more favorable where the developer is forced to analyze the received data immediately.

FURTHER WORK

ACP - At the current state of the ACP, templates are sent as arrays containing the IDs of the information elements, but in the future we count with replacing the arrays with a binary description of these elements.

ACPapi - Future work should be aimed at the replacement of the actual design pattern of ACPapi and to the optimization of the templates by replacing the arrays with a common binary description of the information elements.

Data WareHouse for data preprocessing and storing for efficient access by the analyzing application

###motivacne faktory (predpriprava dat pre vizualizaciu a rychlejsi pristup k nim), myslienkovy postup (architektura ani konkretny navrh zatial nie su), referenciu niet na co dat

Processing the analyzers’ queries by the database is very tedious even at a relatively small number of stored data. Width the growth of data the time required by the database for processing the queries can exceed more than tens of seconds. Further problem occures in the analyzer during the processing of the obtained data, where the evaulation of the graphical continuance from a huge number of data (millions of records) is difficult to implement. Unfortunately both of these problems have an adverse impact on the functionality of the BasicMeter tool.

For these reasons it was necessary to optimize the storing procedure of the data in the database and the access to them. But transition to a new database technology needed a time-consuming and complex analysis of the existing data and requirements from both the collector and the analyzer. Considerring the main factors in selecting the right technology for large-scale databases [Inmon1992], Data WareHouses would be the right choice. Unfortunately, while the analyzer is still under developement, some of its requirements were still not fully defined. This would made the transition to the new technology pointless and hardly to implement.

Solving the above mentioned problems remained still necessary. For this reason we created some stored procedures and triggers in the BasicMeters’ database. The principle of filling the tables was highly inspired by the Data WareHouse technologies, while our main effort was aimed at the pre-processing and aggregation of the indexed data on the basis of time characteristics. With this feature we were able to reduce the time needed for evaluation of the queries in the database and improve the effectiveness of the generation of the graphical continuance in the analyzer.

FURTHER WORK

Althoug the optimization steps over the database fulfilled their goals, they serve only as a temporary solution. Therfore, in future, the database of the BasicMeter should be subjected to a thorough analysis, during which should be identified all the requirements. Consequently one of the database technologies for large-scale databases should be chosen and implemented.

Measurement of OWD with compensation of observation points’ clock skew

###v strucnosti z adovej diplomovky, referencia na medjcn, plany na pokracovanie tejto casti vyvoja

One of the most significant parameter of network traffic is delay. Among different types of delay, One-Way Delay (OWD) is the most accurate however its determination is also more difficult. The measurement of OWD is based on the principle of sending a message with a timestamp between two endpoints, while in the source the time of the broadcast and in the endpoint the time of the receipt of this message is recorded. The value of OWD is given by the difference of the timestamps, which is correct only in the case when the clocks on both endpoints are synchronized. Unfortunately this circumstance is not easy to achieve. Moreover the principle of OWD measurement requires generation of additional traffic for the timestamps which would break the concept passive measurements. To deal with these problems we designed and implemented OWD measurement in the BasicMeter tool in the following way.

In the architecture of the measuring tool the individual exporters are sending information about captured traffic in flow records to the collector. This allowed us to carry timestamps from the two endpoints (at least two exporters are needed) to the collector and calculate the delay value directly in it. Moreover the individual flow records inter alia include various information about time characteristics and flow identifiers. So instead of using timestamps, we used IPFIX information elements describing time characteristics (flowStart and flowEnd) and in this way we avoided the unwanted generation of additional traffic.

To calculate OWD we needed information about such a packet, which passes both measuring points while a flow characteristic is recorded about it in the flow record. Such packets are first and last packets of the flow. If the absolute start and end time of the flow is not identical, we get two timestamps of two IP packets, otherwise we get only one timestamp of one IP packet. Based on the count of acquired timestamps we are able to calculate one or two OWD values.

Unfortunately it is not certain that the IP packet captured within a flow by one measuring point is idenctical to the IP packet captured within the same flow by the other measuring point. In this case we would get inaccurate OWD values. To avoid such a situation, we used a method from the article [gorazd] about unique packet identifiers. With this method − based on certain fields of IP packet and data transmitted in it − is possible to generate an identifier to identify the first and last IP packet of the flow. For the transmission of these identifiers between the exporter(s) and collector we created two new information elements (firstPacketID and lastPacketID) which are exported along with the other information in the flow records.

Based on these fact, the absolute value of the difference of two corresponding timestamps will indicate the value of one way delay. Timestamps are considered as corresponding if they satisfy the following conditions[husiv2010]: flow records came from different measuring points; both are absolut time of start (flowStart) or end (flowEnd) of the flow; both have identical identifiers of first (firstPacketID) or last (lastPacketID) IP packet of the flow; both belong to the same flow[husiv2008].

But befor we could make the actual calculation of one way delay, we had to ensure the above mentioned measuring points’ clocks synchornization too. Unfortunately neither of the existing methods for clock synchronization have met our needs. Therefore we designed your our own method for metering points’ clocks synchronization.

In the BasicMeter architecture one collector is superior to a number of exporters. This hierarchy led us to chose as the reference point of the synchornization the collector. So the measuring points are synchronized towards the collector which resulting in getting the same connection as in the case of the transmission of the timestamps . So the exporter is sending for synchornization purpose a timestamp t0 containing the time of the broadcast of the stamp and receiving a timestamp t1 containing the time of the receipt of stamp t0 in the collector. Then the exporter creates a timestamp t2 containing the time of the receipt of stamp t1 from the collector. Based on these three times One-way delay OW D = (t2 −t0 )/2; and real clock offset o = (t2 − t1 ) − OW D can be calculated. After approximation of clock offset with linear function we got two parameters a and b. The clock correction for the measuring points then could be easily calculated as follows:

s Cs (t) = Cs (t) − (a.t + b) (1) s

Where Cs means synchronized clock on metering point side with clock Cs , a and b are parameters acquired via approximation.

Finally we could start to calculate OWD. When all previously mentioned conditions are satisfied we got in the collector two corresponding timestamps belonging to the same IP packet, which has passed both synchronized measuring points. In this case one-way delay was calculated by the collector and sent to the database. Otherwise the collector kept the timestamps for a customizable amount of time in a buffer. If during this time there were no more corresponding timestamps the calcultaion of OWD will be not performed and the timestamps they will be removed from the buffer and.

During experiments it was showed that with the above described method for OWD measurement one could calculate accurate values with up to microsecond time precision. To ensure this method brings accurate OWD values in nanosecond time presision too further tests are required.

FURTHER WORK

Measuring with the designed module also deliver a disadvantage. Since the flow of data records are kept in caches for a given period of time (depends on the parameters set by the exporting process), using both the module for real-time network traffic monitoring and the module for One-Way Delay measurement at the same time is excluded. Therefore, in the future is necessary to move the One-Way Delay measurement process into a layer of the BasicMeter architecture which has the least impact on the monitoring of network characteristics.

The future work of the authors will focus on the solution of the issues related to the synchronization convergence in extensive measuring networks with a large number of metering points. In addition, the problem of measuring link asymmetry will be a subject of further research by the authors. Also factors influencing instability of the inaccuracy rate will be researched, which is needed for determining of appropriate period for its recalculation.

Monitoring of information systems

Our work in field of the information systems security monitoring led to proposal of the monitoring tool architecture based on IPFIX architecture. Proposed monitoring tool architecture empowers measurement of the operational parameters of an information system. It is easily scalable and powerfull enough to handle huge amount of monitored operations occuring during DoS and DDoS attacks on a monitored information system.

\subsubsection{Acknowledgment}

This work is the result of the project implementation: Center of Information and Communication Technologies for Knowledge Systems (ITMS project code: 26220120030) supported by the Research \& Development Operational Program funded by the ERDF.

Conclusions

Goal of this paper was to introduce the MONICA research group which is focused on network monitoring and related areas. We provided an overview of the MONICA activities and insight into the selected ones. We are open for the discussion and any kind of cooperation in this area -- further development of above mentioned or other related topics, co-publication of ideas and results, cooperation in drafting of new parts of the IPFIX architecture.

jg

\bibitem{ipfixprotocol} Claise, B.: Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information. RFC~5101 (2008)

\bibitem{baldovsky} Jakab, F., Baldovsk\'{y}, G., Gen\v{c}i, J., Giertl, J.: Unique Packet Identifiers for Multipoint Monitoring of QoS Parameters. In: Proceedings of ECI'2006, 7-th International Scientific Conf. on Electronic Computers and Informatics, Her\v{l}any, September 20-22, 2006, Her\v{l}any-Ko\v{s}ice, FEEI TUKE, 6pp., ISBN 80-8073-150-0 (2006)

\bibitem{medjcn} R\'ev\'es, M., Giertl, J., Jakab, F.: Improvement of Synchronization Accuracy in the Monitoring of Computer Networks. The Mediterranean Journal of Computers and Networks, Vol. 4, No. 1, pp. 37-43, ISSN 1744-2397 (2008)

\bibitem{bm} Jakab, F., Ko\v{s}\v{c}o, \v{L}., Potock\'y, M., Giertl, J.: Contribution to QoS Parameters Measurement: The BasicMeter Project. In: Conference Proceedings of the 4th International Conference on Emerging e-learning Technologies and Applications ICETA 2005, vol. 4, pp. 371–377 (2005)

\bibitem{aadte} Kopka, J., R\'ev\'es, M., Giertl, J.: Anomaly Detection Techniques for Adaptive Anomaly Driven Traffic Engineering. In: 10th Scientific Conference of Young Researchers (SCYR 2010), Košice, Slovakia, May 19th, 2010, Košice, Faculty of Electrical Engineering and Informatics, Technical University of Košice, I. Edition, pp. 254-257, ISBN 978-80-553-0423-6 (2010)

\bibitem{accounting} Ka\v{s}\v{c}\'ak, M., Jakab, F., Giertl, J., R\'ev\és, M.: Usage-based Accounting. In: Computer Science and Technology Research Survey, Košice, Department of Computers and Informatics, FEII TU of Košice, pp. 33-38, ISBN 978-80-553-0515-8 (2010)

\bibitem{acpaep} Jakab, F., Giertl, J., Jakab, R., Ka\v{s}\v{c}\'ak, M.: Improving Efficiency and Manageability in IPFIX Network Monitoring Platform. In: Proc. of the 6th International Network Conference, INC 2006, Plymouth, UK, 11.-14.7.2006, University of Plymouth, pp. 81-88, ISBN 1-84102-157-1 (2006)

\bibitem{acp} Giertl, J., Jakab, R., Ko\v{s}\v{c}o, \v{L}.: Communication Protocol in Computer Network Performance Parameters Measurement. In: Proceedings of the 4th International Information and Telecommunication Technologies Symposium (I2TS 2005), Federal University of Santa Catarina, Florianópolis, Brazil, December 14-16, 2005, pp. 161-162, ISBN 85-89264-05-X (2005)

\bibitem{ipfixapplicability} Zseby, T., Boschi, E., Brownlee, N., Claise, B.: IP Flow Information Export (IPFIX) Applicability. RFC 5472 (2009)

\bibitem{ipfixarchitecture} Sadasivan, G., Brownlee, N., Claise, B., Quittek, J.: Architecture for IP Flow Information Export. RFC 5470 (2009)

\bibitem{ipfixconfiguration} Muenz, G., Claise, B., Aitken, P.: Configuration Data Model for IPFIX and PSAMP, Internet-Draft (2011)

\bibitem{ipfixmodel} Quittek, J., Bryant, S., Claise, B., Aitken, P., Meyer, J.: Information Model for IP Flow Information Export. RFC 5102 (2008)

\bibitem{psamp} Zseby, T., Molina, M., Duffield, N., Niccolini, S., Raspall, F.: Sampling and Filtering Techniques for IP Packet Selection, RFC 5475 (2008)

\bibitem{ecam} Mihok, T., Giertl, J., R\'ev\és, M., Pek\'ar, A., Feci\v{l}ak, P.: System for Centralized Management of the BasicMeter Tool, In: IP Networking 1 – Theory and Practice, Zilina (2011)

\bibitem{time} Giertl, J., Husivarga, \v{L}., R\'ev\és, M., Pek\'ar, A., Feci\v{l}ak, P.: Measurement of Network Traffic Time Parameters. In: INFORMATICS'2011 – International Scientific Conference on Informatics, November 16th – 18th, 2011, Rožňava, Slovakia (2011)

\bibitem{ipfixrequirements} Quittek, J., Zseby, T., Claise, B., Zander, S.: Requirements for IP Flow Information Export (IPFIX). RFC 3917 (2004)

-- Main.giertl - 12 Oct 2011