Integrated Quality of Service and Network Management

Transcription

1 Integrated Quality of Service and Network Management Rohit Joshi, Chen-Khong Tham Department of Electrical Engineering, National University of Singapore 10 Kent Ridge Crescent, Singapore Abstract This paper presents the design and implementation of an application that provides a platform to do both networklevel and Quality of Service (QoS) monitoring. It aims to remotely monitor critical application flows by collecting traffic data from different network points using the Real Time Flow Measurement (RTFM) architecture and fits in to the development of a QoS distribution monitoring concept. We demonstrate the feasibility of our application through the implementation of a testbed with a Diff-Serv enabled Linux router and two different sources, one on Ethernet and the other using ATM and monitoring these two critical flows that have been given different preferences for differentiated services. The strengths and weaknesses of the application are also presented. 1. Introduction In this age of Internet and Intranets, more and more applications are becoming bandwidth hungry. Even on a relatively unloaded IP network, delivery delays can vary enough to continuously and adversely affect real-time applications. For applications with real-time requirements, such as those that deliver multimedia, the most demanding of which are two-way applications like telephony and video-conferencing, providing effective Quality of Service (QoS) is of utmost importance. Currently, the main QoS monitoring approach is to monitor end-to-end. But end-to-end QoS monitoring fails to provide statistics at different parts of network. To locate the network segment s causing possible QoS degradation, the QoS distribution monitoring approach [1] is required. Effective performance monitoring of mission critical application also requires monitoring network traffic at higher network layers. Thus, an integrated remote monitoring application is required that provides one platform to monitor both the network and QoS for mission critical applications. The rest of the paper is organized as follows. Section 2 deals with the basics of QoS and network management. Section 3 presents a literature survey of currently employed QoS and network monitoring techniques. Section 4 introduces the Real Time Flow Measurement (RTFM) architecture. Section 5 describes the background behind the developed application. Section 6 presents an overview of the developed software and describes its design. Section 7 deals with the QoS support in Linux. Design and implementation of the testbed is covered in the section 8. Experiments and results are presented in section 9. Section 10 discusses the strengths and weaknesses of the software. Section 11 describes the future work to be done. Finally, section 12 concludes the paper. 2. QoS and Network Management Quality of Service (QoS) protocols are designed to distinguish traffic with strict timing requirements from those that can tolerate delay, jitter and lossand to manage these traffic accordingly. QoS does not create bandwidth, but manages it so it is used more effectively to meet the wide range or application requirements. The goal of QoS is to provide some level of predictability and control beyond the current IP best-effort service. The QoS architecture on IP [2] supports two types: 1. Resource reservation (integrated services): network resources are apportioned according to an application s QoS request, and subject to bandwidth management policy. 2. Prioritization (differentiated services): network traffic is classified and apportioned network resources according to bandwidth management policy criteria. To enable QoS, network elements give preferential treatment to classifications identified as having more demanding requirements. 1

2 A network management system contains two primary elements: a manager and its agents. The manager is the console through which then network administrator performs network management functions. The agents are the entities that interface to the actual device being managed. Management Information Base (MIB) is like the database, used by both the agent and managing process to determine the structure and content of management information. Network management standards do not require these components to be placed at particular positions in the network. Functional requirements for network management are fault management, accounting management, performance management, configuration management and security management. The Simple Network Management Protocol (SNMP) is an application-layer protocol designed to facilitate the exchange of management information between network devices. 3. Monitoring Techniques The mechanism for QoS monitoring can be classified into two categories according to the QoS information that can be obtained from them:-- end-to-end QoS monitoring and QoS distribution monitoring [1]. In an end-to-end QoS monitoring approach, only the end-to-end QoS between the sender and the receiver of a real-time flow is monitored. In a QoS distribution monitoring approach, the QoS distribution experienced by the flow in different network segments is monitored in addition to the end-to-end QoS. Different people have proposed different techniques to do effective QoS monitoring. Mourelatou et al [3] proposed an agent-based approach to identify QoS problems. The agents are responsible for monitoring the end-to-end QoS. They showed that a management system is capable of identifying the cause of performance degradation by correlating the information from these QoS monitoring agents. Ehab Al-Saher et al. [4] looked at an event-driven dynamic monitoring approach for multimedia networks. Chen et al. [5] introduced a software approach to monitoring end-to-end QoS in ATM networks. In order to monitor the QoS of a selected virtual connection, test cells are sent along a parallel connection that has been established with the same route and QoS class as the selected virtual connection. Another possible QoS monitoring approach is Real Time Control Protocol (RTCP) based scheme. Waldbusser [6] proposed an extension to a remote network monitoring specification. This work is termed as RMON-2. With RMON-2, a probe is not limited to monitoring and decoding network-layer traffic. It can also view higher layer protocols running on top of the network-layer protocol. In particular, an RMON-2 probe is capable of seeing above the IP layer by reading the enclosed higherlevel headers such as TCP and viewing the headers at the application level. This allows a network manager to perform application layer monitoring that is required in QoS monitoring. Brownlee et al. [7] proposed an architecture, referred as real-time flow measurement (RTFM) architecture, for the measurement and reporting of network traffic flows. A traffic flow, which may be generated by a multimedia application, is defined as an artificial logical equivalent to a call or connection [8]. RTFM mechanism can also provide application-layer monitoring. This project uses RTFM architecture. RTFM basics are dealt in the next section. 4. Real Time Flow Monitoring Architecture (RTFM) The Realtime Traffic Flow Measurement Working Group has developed RTFM Traffic Measurement System. It is described in RFC 2064 [7], RFC 2722 [8],RFC2720 [9], RFC2723 [10] and RFC2123 [11]. RTFM mainly consists of meters, managers, meter readers and analysis application as shown in the Figure 1 Manager Meter Meter Reader Figure 1: RTFM architecture Analysis Application Manager: A traffic measurement manager is an application, which configures 'meter' entities and 2

3 controls 'meter reader' entities. It sends configuration commands to the meters, and supervises the proper operation of each meter and meter reader. Meter: Meters are placed at measurement points determined by Network Operations personnel. Each meter selectively records network activity as directed by its configuration settings. It can also aggregate, transform and further process the recorded activity before the data is stored. Meter Reader: A meter reader transports usage data from meters so that it is available to analysis applications. Analysis Application: An analysis application processes the usage data so as to provide information and reports which are useful for network engineering and management purposes. Each meter can be read by multiple meter readers, as is shown in the figure 2: Meter1 Meter Reader A Meter2 Meter Reader B Meter3 Meter4 Figure 2: Interaction between meter readers and meters Here, meter 1 is read by meter reader A, and meter 4 is read by meter reader B. Meters 1 and 4 have no redundancy; if either meter fails, usage data for their network segments will be lost. Meters 2 and 3, however, measure traffic on the same network segment. One of them may fail leaving the other collecting the segment's usage data. Meters 2 and 3 are read by meter reader A and by meter reader B. If one meter-reader fails, the other will continue collecting usage data from both meters. The architecture does not require multiple meter readers to be synchronized. 5. Background of the Monitoring Application Meter : Requirements of the meter have been outlined in RFC2722[9]. This project uses NeTraMet, only freely available netmeter currently. NeTraMet runs on Linux, Solaris and Irix using libpcap to observe Ethernet packet headers, or on a PC using the CRYNWYR packet driver. NeTraMet can also run with OC3Mon, an ATM traffic monitor system developed by NLANR and MCI. NeTraMet s outer block is a single loop which implements four asynchronous processes in the decreasing order of priority handling SNMP requests, monitoring Ethernet, handling keyboard commands and memory management. When a packet arrives at the meter, two key data structures are built, one for source and one for its destination. Generally, the packets are matched against the current ruleset with the keys in source to destination order; if this succeeds the packet is counted. Figure 3 shows how this occurs: - Manager : Requirements of RTFM manager have been outlined in RFC 2722[9]. This project uses NeMaC, which is the combined manager as well as collector. NeMaC can be used to control several meters at a time. When it runs, it produces a logfile, recording any unusual events observed for any of the meters being controlled. It opens a flows file named IPaddress.flows.nnn e.g flows.001, to record all the statistics that it collects from the meter. Current Packet Header Rule Set Packet Processor Ignore match key flow key Count (via flow key) Search Index Flow Table Collect Packet Matching Engine Meter Reader 3 Figure 3: Packet Processing in the meter

4 Flow Monitoring A traffic flow is a stream of packets exchanged between two network hosts, flow s source and destination. Flows are bi-directional in that packets and bytes can be counted in the to (source to destination) and from (destination to source). Within the meter, a flow is implemented as a data structure containing the attributes of its source and destination, its packet and byte counters, the times it was first and last observed, and other information used for control purposes. The meter could simply create flows for every possible combination of source and destination attributes it observes, but this would quickly exhaust its memory. Instead the meter uses a set of rules to decide which flows are of interest, and other packets are ignored. Each rule tests one attribute of a flow, using a mask to specify which bits are of interest. In this way a tree of rules can be built up to classify packets into flows; each packet can then be 'counted' in its appropriate flow. Simple Ruleset Language (SRL) A rule file is an ASCII file that contains information needed by netmeter and netmanager. SRL (the Simple Ruleset Language) is a procedural language for creating RTFM rulesets. It uses different statements, which help to easily specify the requirements of the network manager. SRL programs will be compiled into rulesets, which can then be downloaded to RTFM meter. Flow attributes The identity of the flow is determined by the address attributes of its two hosts and these attributes can be of three kind adjacent (link layer), peer ( network layer), transport ( transport layer). Flow attributes can be divided into four categories adjacent attributes, peer attributes, transport attributes and general attributes. Mask can be provided in rules to test fields within the addresses. Type can be provided to test protocol field from IP packet header e.g. type =1 refers to ICMP. General attributes are those that relate to traffic flow itself, rather than to its end point addresses and are available for all flows. Number of bytes observed, number of packets, first time the flow was observed, Last Active Time of the flow and flow index number and many others can be known using these. Frame Statistics displays information regarding all the flows that were active during that sample period. Frame statistics provides total number of packets observed, total size of these packets in both the directions. These data are useful to find the network utilization. Node Statistics provides the information like average packet size, packet backlog, processor idle %, minimum processor % etc, which are also helpful to analyse the network, are displayed here. Differentiated Services monitoring Differentiated Services Code Point (DSCodePoint) (0..63) in the IP packet header can be used to differentiate flows. Rulesets can be written to distinguish flows from different networks according to the DSCodePoint. Quality of Service (QoS) Monitoring The concept of QoS monitoring using RTFM is explained in detail in RFC2274 [10]. Basically, QoS parameters like delay, throughput and other rates are stored in a form of a distribution at a metering point. As such, it does not support traditional way of Endto-End QoS monitoring, but rather it helps in providing distributed QoS monitoring. Distribution is a compact representation of the data, with the values being stored as counters between a minimum and maximum in an array of 'buckets', with defined steps in each bucket. Some special form of distributions are:- 1. Short-term bit rate - The data could also be recorded as the maximum and minimum data rate of the flow, found over specific time periods during the lifetime of a flow. Bit rate could be used to define the throughput of a flow, and if the RTFM flow is defined to be the sum of all traffic in a network, one can find the throughput of the network. If we are interested in '10-second' forward data rates, the meter can compute this for each flow of interest as follows: maintain an array of counters to hold the flow's 10-second data rate distribution. every 10 seconds, compute and save the 10- second octet count, and save a copy of the flow's forward octet counter. 2. Inter-arrival times. The meter knows the time that it encounters each individual packet. Statistics 4

5 can be kept to record the inter-arrival times of the packets, which would give an indication of the jitter found in the flow. 3. Turn-around statistics: Since the meter knows the time that it encounters each individual packet, it can produce statistics of the time intervals between packets in opposite directions are observed on the network. For protocols such as SNMP (where every packet elicits an answering packet) this gives a good indication of turnaround times. How to specify the distribution Distribution specification in the rulefile is done in the following way FromPacketSize : !1500 = 60.0!0: ToInterArrivalTime : 2.3.1!1800 = !0: FromBitRate : 2.3.1!10000 = !0: Here, there are three rules: FromPacketSize, ToInterarrivalTime and FromBitRate. In Distribution there are two types of bytes: Mask Bytes and Value Bytes. In FromPacketSize !1500 is the mask byte and !0 is the value byte. Mask bytes has four sub field: Transform (linear or logarithmic), Scale Factor (power of 10 multiplier for Limits and Counts), Lower Limit (highest value for first bucket), Upper Limit (highest value of last bucket). Value bytes also have four sub-fields: Buckets (number of buckets, does not include overflow bucket which is there by default), Parameter 1, Parameter 2 and Parameter 3. How these parameters are used depends on the distribution valued attribute. So, the second rule above specifies an interarrivaltime distribution, using a logarithmic scale for an array of 60 counters (and an overflow bucket) for rates from 1 ms to 1.8 s. Arrival times are measured in microseconds; hence the scale factor of 3 indicates that the limits are given in milliseconds. Measurement Architecture (explained earlier). To monitor critical applications, the user may specify his traffic flow measurement requirements by writing rulesets using Simple Ruleset Language (SRL), allowing them to collect the flow data they need while ignoring other traffic. This application provides network performance statistics in terms of frames (consisting of many flows), flows and node meter statistics. It also lets the user to monitor QoS in a distributed manner using distributed valued attributes. This can help the user to gather in-depth information regarding any part of the network and monitor any application. Information about busiest flows, long-term high volume flows, short-term burst flows are also provided. The application is a program, which can monitor different network segments to which a NeTraMet traffic meter is attached and displays information to help the user understand how the traffic is flowing on that network. It has a client application written in Java that lets the user remotely monitor the network and also acts as a traffic analyser. This client can launch any meter as well as manager by specifying the IP addresses. The client can also upload any file saved at any location which is useful for analysing previous flow records, log files or rule files. Figures 4 and 5 show the flow monitoring application 6. Overview and Design of the Monitoring Application The developed application is a Java based remotenetwork management and Quality-of-Service (QoS) monitoring system, which does non-intrusive monitoring. It s based on the Real Time Flow Figure 4: Flow Table 5

6 Figure 5: Flow Statistics Say meter A is placed near the router and meter B is placed in a LAN, our client application placed remotely can get data from both the points. The manager, that uses SNMP as connection medium, can be placed anywhere as long as it can connect to the netmeter. Currently, server has to placed with the netmanager and cannot be placed anywhere, but this can be easily improved because programming has been done in a very flexible way. Gather Statistics Router + metera (running as a stand alone app.) Client application Gather Statistics launch meterb Bridge Router Basic Design The application client has been written in Java but the server has been written in Tcl. Basic design is explained below in figure 6 Connection request Server Listening At port 800 dispatch Web Proxy Campus Backbone Figure 7: Overview of the system Internet ruleset Client Meter Meter Reader update launch read request reply launch read Server Thread Flow File update Auto- Polling read Server array Dispatch Scheduler 7. QoS Support / Traffic Control on Linux Recent Linux kernel offers a wide variety of traffic control functions. Reference [12] explains the basic principle involved in the implementation of QoS in Linux. The traffic control code in the Linux kernel consists of the following major conceptual components: queuing disciplines classes (within a queuing discipline) filters/policing Each network device has a queuing discipline associated with it, which controls how packets enqueued on that device are treated. Few main queuing disciplines supported by Linux traffic control are: Class Based Queuing (CBQ), Token Figure 6: Basic design of the application 6

7 Bucket Flow (TBF), First In First Out (FIFO), Priority, Generalized RED (GRED) and Diff-Serv Marker (DS MARK). Queues and classes are tied to one another. Each class owns a queue, which by default is a FIFO queue. When the enqueue function of a queuing discipline is called, the queuing discipline applies the filters to determine the class to which the packet belongs. Filters are used to classify packets based on certain properties of the packet e.g. TOS byte in IP packet header, IP addresses, port numbers etc. Queuing disciplines use filters to assign incoming packets to one of its classes. 8. Design and Implementation of Test bed To test the effectiveness of the application, we tried a set up in which the traffic can be sent through both Ethernet and ATM via a Diff-Serv enabled router which prioritizes the applications and sent it to the other network or over the ATM backbone. The setup involves a Diff-Serv enabled linux router, two computers (representing two different subnets) using Ethernet and two other computers using ATM technology and connected via a Fore ATM Switch. Linux machine acts as an Ethernet/ATM gateway and router Fore Switch Dell / ATM To set up such a test bed, the first step was to configure the Linux box, acting as a router for the differentiated services. This involved installing Kernel and iproute2, applying the required patches, configuring kernel to enable QoS and networking options and recompiling the kernel. Routing daemon was run and routing table was modified. Then, IP over ATM was configured. The first step required was to download the ATM on Linux distribution, to patch, rebuild, and boot the kernel, and to compile and install the ATM tools. The second step involved configuring Classical IP over ATM to run on Linux. Then, the setup was done for configuring Ethernet / ATM gateway on Linux. This involved configuring the kernel to support multiple Ethernet cards and changing the routing table and configure other PC in the network to have the Linux box as the gateway. Setting up of Queue, Classes and filters for Expedited Forwarding (EF) and Assured Forwarding (AF) For differentiated services setup, scripts need to be written for queuing (class-based/pfifo etc.), classes and providing varying Quality of Service to different applications U32 / Meter Class 1:1 DSCP ox2e Compaq / Ethernet Dell / Ethernet Linux Diffserv Router + Ethernet/ATM Gateway Dell /ATM Ethernet ATM Exceeded Limit nomatch Class 1:2 Class 1:3 FIFO dsmark Queuing discipline DSCP ox18 DSCP ox1a Figure 9: Network Topology Figure 10: Diff-Serv Queue set-up This queuing structure was implemented through a configuration script. A dsmarker was attached to 7

8 the interface eth1 on the root node. All the packets coming in from source subnet address were marked with a DSCP of 0x2e (EF class/phb) up to a point where they start exceeding their allocated rate (of 1Mbps and burst of 2Kbps). In this case, the packets are demoted to class 1:2 where they will be remarked to DSCP 0x18 (AF21). Any packets from the subnet /16 were marked 0x1a (AF22). A very small part of the script is shown below: Now, the server was run on the same Linux machine. Remote Java Client was run on the Compaq Ethernet Machine ( ). Diff-Serv script, as shown above, was executed. Video traffic was streamed for a long time from two sources, one running Ethernet in subnet and other doing IP over ATM in subnet The following figures show the results: tc qdisc add dev eth1 handle 1:0 root dsmark indices 64 tc class change dev eth1 classid 1:1 dsmark mask 0x3 value 0xb8 tc filter add dev eth1 parent 1:0 protocol ip prio 4 handle 1: u32 divisor 1 tc filter add dev eth1 parent 1:0 prio 4 u32 match ip src police rate 1Mbit burst 2K continue flowid 1:1.. Figure 10: Diff-Serv Script 9. Testing Of Monitoring Application in Diffserv Domain The network topology has been shown in figure 9. Dell Machine ( ) running on Ethernet and another Dell Machine ( ) running ATM acted like two sources, sending traffic to the Compaq Machine ( ) running Ethernet via the Linux diffserv router. To conduct the experiment, NeTraMet was run on outgoing Ethernet interface of the Linux machine ( ). NeMaC was also run on the same machine. SRL rule file was downloaded to this NeTraMet meter. The following figure shows some part of SRL file. if SourcePeerType == IP save; else ignore; if DestPeerAddress == /16 save, { save SourcePeerAddress; save SourcePeerType;... save ToPacketSize = !0 & 1.0.1!1520; save ToInterArrivalTime = !0 & 2.3.1!1800; Figure 12: SRL script Figure 13: Table showing all the flows Figure 13 shows table of all flows with destination address as , as specified in the rule file. Each flow has unique flow identity number. Flows coming from address were marked as AF class (0x1a) and the flows coming from were allotted EF class (0x2e). As seen from the table, Flow 41, with Source Peer Address as and is of type 1 (IP) and has transport address as 6 (TCP), has DSCodepoint as 46 (0x2e-EF flow). Similarly, Flow 39 with Source Peer Address as have DSCodepoint as 18 (Hex- 0x1a). So this is an AF flow. All the other flows, which come from the other destinations or have ended or does not match the criteria of the filter of the queuing discipline (BE class) have not been assigned any DSCodepoint. The flow statistics tab shows all the statistics about each and every flow that matches the conditions in the rule file. Total bytes, total packets, peak number of bytes, time at which this peak occurred and various other statistics can be seen from this table. After getting the statistics of all the flows, monitoring of only critical flows were done. For this purpose, 8

9 Diff-Serv flows were especially selected. Flow 41 was chosen and the flow monitoring was done. Figure 14 shows the ongoing flow monitoring. Running video application was suddenly closed. The drop in the flow in the figure signifies that. The application was restarted and the flow was restored as shown in the figure. The histogram besides the flow monitor provides the current statistics (599 in this case). The packet size distribution can be seen in Figure 16 This application can be used to plot any distribution supported by the RTFM architecture. Figure 16: Packet Size Distribution Figure 14: flow monitor QoS Monitoring : The distribution of inter-arrival time is shown in the figure below. Heavy traffic used to test makes the packets of this critical flow suffer different delays. Although, maximum number of packets are in the least delay suffered zone but having sizeable amount of traffic in higher delay regions is really note worthy. Figure 15: Inter-arrival time of the packets of flow 39 9 This demonstrates the flexibility and the strength of the developed software. The packet Size distribution figure shows that the measured flow has packets of roughly constant range size. 10. Strengths and Weaknesses of this monitoring software The strengths of the monitoring application described in this paper are: 1. The application provides complete network monitoring statistics of the transport layer, network layer and the link layer. 2. It does non-intrusive monitoring, as it does not query the network devices to get the traffic information. So, the software wouldn t effect or disrupt any network device in any possible way. 3. It integrates QoS monitoring in a distributed manner and providing all the usual QoS parameters. 4. The application allows remote monitoring, and the user can connect to any meter or the manager in the network. So, network statistics of different parts of the network can be displayed. 5. The application is written in Java, Tcl (commonly used network management languages) and hence involves all the advantages including platform independence.

10 6. Differentiated services flows can also be monitored. Thus, it can be used to monitor the preferential treatment given to flows and identify the cause or the misbehaving flows if there is QoS degradation in the critical flow or flows. 7. Monitoring can be done both for IP networks and ATM networks The software is based on the existing NeTraMet and NeMaC. Thus, it carries the limitation of these existing software. Currently, NeTraMet does not support metering for multicast flows. Hence, the monitoring software can not be used for multicast flows. But efforts are underway to extend multicast metering capabilities to NeTraMet. 11. Future Work In the last experiment, the machine connected usinf Ethernet was the destination. Currently, experiments with the machine connected to the ATM switch as the destination are being done. For ATM measurements NeTraMet-OC3Mon running on DOS is being considered. The experiments will be done in the same diff-serv domain. These experiments will show how the same remote client can monitor data from both Ethernet and ATM and segments of the network. 12. Conclusion This paper has introduced an integrated network and QoS monitoring application especially for missioncritical applications. It started with the introduction and then explained the concepts of Quality of Service and network management. Background and basic design of the developed QoS monitoring application was also explained. The feasibility of the monitoring application was demonstrated by setting up a network topology with a Diff-Serv router and used the traffic control features in Linux. Experiments conducted and the results obtained have been shown. As shown in the tests, the important advantage of the application is that it can track flows with differentiated services, apart from displaying normal QoS and network statistics. Furthermore, this monitoring application can obtain and analyze the traffic data even till the transport layer. Acknowledgements This work was done at the Computer and Communication Lab, National University of Singapore. The authors would like to thank Mr. Nevil Brownlee, the co-author of RTFM architecture; and Raymond A. Samalo, who constantly extended his assistance as and when required. References [1] Y. Jiang, C.K. Tham and C.C. Ko, A QoS Distribution Monitoring Scheme for Performance Management of Multimedia Networks, Proceedings of IEEE GLOBECOM 99 [2] D. Clark, S.Shenker, and L. Zhang, Supporting Realtime Applications in an Integrated Services Packet Network: Architecture and Mechanisms, ACM Sigcomm Proc., [3] K.E. Mourelatou, A.T.Bouloutas, and M.E. Anagnostou, An Approach to Identifying QoS Problems, Computer Communications 17, , 1994 [4] Ehab Al-Saher, Hierarchial Filtering based Monitoring Architecture for Large-Scale Distributes Systems, PhD Dissertation, Computer Science Department, Old Dominion University, July 1998 [5] T.M.Chen, S.S.Liu, M.J. Procanik, D.C.Wang and D.D.Casey, INQUIRE: A Software approach to Monitoring QoS in ATM networks, IEEE Network, 32-37, March-April [6] S.Waldbusser, Remote Network Monitoring Management Information Base Version 2 using SMIv2, IETF RFC2021, 1997 [7] N. Brownlee, C.Mills and G.Ruth, Traffic Flow Measurement: Architecture, IETF RFC2064 [8] N. Brownlee, C.Mills and G.Ruth, Traffic Flow Measurement: Meter MIB IETF RFC2720 [9] N. Brownlee, C.Mills and G.Ruth, New Attributes for Traffic Flow Measurement, IETF RFC2724 [10] N. Brownlee, SRL: A Language for Describing Traffic Flows and Specifying Actions for Flow Groups, IETF RFC2723 [11] N. Brownlee, Traffic Flow Measurements: Experiences with NeTraMet, IETF RFC2123,1997 [12] Werner Almesberger, Jamal Hadi Salim, Alexey Kuznetsov, Differentiated Services on Linux, Internet Draft, June