performance of networks such as throughput, loss rate, and jitter. Typically,. E2E flow monitoring is carried out at end hosts with known tools such as iperf.
End-to-End Flow Monitoring with IPFIX Byungjoon Lee1, Hyeongu Son2, Seunghyun Yoon1 and Youngseok Lee2 1
ETRI, NCP Team, Gajeong-Dong 161, Yuseong-Gu, Daejeon, Republic of Korea {bjlee, shpyoon}@etri.re.kr 2 Chungnam National University, Gung-Dong, Yuseong-Gu, Daejeon, Republic of Korea {hguson, lee}@etri.re.kr
Abstract. End-to-End (E2E) flow monitoring is useful for observing performance of networks such as throughput, loss rate, and jitter. Typically, E2E flow monitoring is carried out at end hosts with known tools such as iperf. However, in a large-scale network, the end-host approach for performance measurement may not be easily deployed because of expensive costs and high administrative overheads. Therefore, in this paper, we propose a new E2E flow monitoring method based on IP Flow Information eXport (IPFIX) that could provide QoS metrics such as throughput, retransmission rate, delay, and jitter for TCP/RTP flows. Especially, we present and evaluate a QoS monitoring scheme for RTP flows using SIP. We have extended the IPFIX templates for carrying QoS-related fields, and developed the E2E flow monitoring function with the open source that could be embedded into routers. From experiments, it was shown that the performance of TCP and RTP flows could be easily examined with the IPFIX-based approach. Keywords: End-to-end flow, IPFIX, Performance, Measurement, TCP, RTP
1
Introduction
An E2E flow in the Internet could be regarded as a sequence of packet arrivals consisting of single web session, a file transfer, a video stream, or a VoIP call. Recently, a lot of performance questions on an end-to-end flow are being raised by users as well as Internet Service Provider’s (ISP’s). Traditionally, a steady-state throughput of a long-lived TCP flow is considered to be a good indicator of the E2E flow performance, because most Internet traffic is associated with TCP protocol. Therefore, it is necessary to monitor the performance of TCP flows to correctly assess the end-to-end performance metrics of typical Internet applications such as Web downloading, email, and file exchanging. On the other hand, although only the best-effort service is available within the current Internet, ISP’s are willing to provide the QoS-guaranteed service for the specialized applications such as MMoIP for maximizing the revenue. Most of the MMoIP services including VoIP and VoD have their own QoS requirements that are determined by the high-level Service Level Agreements (SLA) between the subscribers and the providers of the service. It is essential for ISP’s to monitor QoS parameters of MMoIP services for assessing whether the services are correctly
2
Byungjoon Lee, Hyeongu Son, Seunghyun Yoon and Youngseok Lee
delivered to the subscribers. Generally, it could be assumed that each QoS-critical Internet application is bound with a specific signaling mechanism like industryproven and widely-accepted SIP or H.323 to collect charging-related information more easily. Hence, in this paper, we focus on monitoring QoS metrics of TCP flows and RTP sessions established by a signaling protocol of SIP, because SIP is the most popular signaling protocol in current IP network. For TCP, we figure out TCP throughput and the number of retransmitted packets of each TCP flow. For RTP sessions, we measure throughput, delay, and jitter of the RTP media streams created by SIP signaling messages. For the observation of the E2E flow performance metrics, we employ the IPFIX architecture [1], where routers with IPFIX-compliant traffic monitoring functions will monitor and export E2E flow information to the collector. In general, the IPFIX architecture is more useful than the end-host approach in a large-scale network, because routers of the E2E path could monitor the E2E flow and export the flow information to the collector. In the end-host approach, each end-host with specialized software like iperf should collect the QoS information and send it to the collector, which may not be scalable. In addition, in the router-based IPFIX approach, the problematic segments of the path that an E2E flow is traversing could be easily identified. In the IPFIX architecture, the performance information of each TCP flow or multimedia stream will be captured and computed by routers. The collected information is assembled into flow records, and exported to an external collector by IPFIX protocol [2]. The key concept of IPFIX protocol is the flexible and extensible template architecture that can be useful for various traffic monitoring applications. The template can be easily extended to export QoS measurement results. Hence, in this paper, we propose new IPFIX templates which provide throughput and the retransmission rate for TCP flows, and throughput, delay, and jitter for SIP/RTP multimedia streams. Then, we propose an RTP stream detection method using SIP signaling information. Through the experiments with the prototype system for monitoring E2E flow performance, it is seen that our approach could easily provide the performance metrics of E2E flows. The remainder of this paper is organized as follows. The related work is introduced in section 2. In section 3, the architecture of our system is explained. The results of the experiments with the prototype are introduced in section 4. Section 5 concludes this paper.
2
Related Work
In Internet2, there is a special working group called ‘Internet2 End to End Performance Initiative (E2Epi)’ [3] to establish the architecture and to propose E2E monitoring applications. Similarly, there has been an ‘Active Measurement Project (AMP)’ [4] that also addresses the issue of monitoring end-to-end performance using active measurement methods. However, with regard to the problem of detecting
End-to-End Flow Monitoring with IPFIX
3
problematic segments in the network, the measurement granularity for these projects is too coarse to give detailed flow-based monitoring results. An architecture to monitor end-to-end performance of selected flows has been proposed in [5]. Subscribers of an ISP service can check whether their flows are being serviced correctly by querying a database which stores per-flow information exported by each meter (i.e., routers) using Netflow v5 protocol. However, the suggested scheme cannot deliver the detailed measurement results of the QoS parameters because the Netflow v5 protocol can export only a limited set of performance parameters. Cisco nBar [6] suggests a mechanism to detect RTP flows using payload classification. This system can mark the detected flows to be shaped or policed for satisfying certain QoS requirements. However, this system does not provide a solution for end-to-end performance monitoring. A method to monitor end-to-end QoS metrics of media streams associated with SIP signaling has been presented in [7]. This method combines active and passive measurement methods. For active measurement, monitoring probes are injected to the network by agent-side packet generators. The measurement results are collected with SNMP and saved as flow files at the SIP proxy. Therefore, user agents and SIP proxy server software should be modified to use this scheme. Thus, this may be rather unrealistic because it is difficult in the real network to modify the software of the participating network entities for the specific measurement methods. A QoS measurement method [8] for RTP flows has been proposed by using nProbe [9]. A new IPFIX template was introduced to export QoS monitoring results to an external collector. However, this work does not take SIP signaling into consideration. In this paper, we extend the work in [8] to extract RTP flow information from SIP SDP payloads.
3
The Proposed E2E Flow Monitoring Method
3.1
The IPFIX-based Architecture
The system architecture of the proposed method is described in Fig. 1.
Fig. 1. The proposed IPFIX-based system architecture
4
Byungjoon Lee, Hyeongu Son, Seunghyun Yoon and Youngseok Lee
As specified in [1], the IPFIX architecture consists of IPFIX devices and collector processes. IPFIX devices observe flows, meter flows, and export metered results for each flow to collector processes via the IPFIX protocol. Thus, we employ the IPFIX framework that consists of flow probes and a collector. As shown in Fig. 1, the flow probe can be deployed as either a function of a router or a specific system that captures packets and processes flows. A flow probe observes end-to-end flows using 5-tuples of packet headers, meters each flow, and exports the metered results to collector via the IPFIX protocol. The collector saves the exported information into DBMS. The saved information can be used later for further analysis or visualization. As previously mentioned, the flow probe only observes TCP and RTP flows associated with SIP messages. For RTP flow observation, the flow probe extracts 5tuples of RTP flows associated with each SIP packet by inspection SDP payloads of SIP INVITE/OK messages. The extracted information is used for RTP flow identification. For the TCP/RTP flows, the QoS metrics are also metered and exported. 3.2
The E2E Flow Monitoring Scenario
3.2.1 TCP Flows In metering E2E performance parameters, it is assumed that every packet of a flow is captured without losses. Therefore, our flow monitoring scenario cannot be applied for the sampling-based measurement environment. Given that every packet could be observed, it is straightforward to meter TCP performance parameters, that is, the number of retransmissions of a flow. We maintain a range of total bytes transferred for each flow. This range [0, N] (N is integer, and N > 0) will be tracked from TCP sequence numbers. Whenever a packet for the given flow is captured, we calculate the range of the payload bytes [m, m+k] (m and k are integers, and m, k > 0) for the packet from its sequence number and payload size. If the range overlaps (m < N) with the current total range [0, N], we conclude a retransmission has occurred. Therefore, for our method of monitoring TCP flows, following information is necessary for each flow. The initial sequence number (ISN) is captured from the TCP SYN message. WRAP_CNT is for counting how many times the sequence number of a flow wrapped around the maximum sequence number (232-1) to zero. MAX_APN is the maximum value of Absolute Position Number (APN). By shifting the ISN of a flow to zero, we know the absolute location of each byte on the total N bytes transferred by the given flow. Therefore, when a new packet arrives, we calculate the APN of the first payload byte of the packet. If the value is smaller than MAX_APN of the flow, we assume that the retransmission has occurred. Though the similar phenomenon could be observed when a packet reordering event occurs, it is presumed that the packet reordering does not frequently happen, which are typically related with the routing table changes and non-FIFO queuing disciplines. Thus, the number of the retransmitted packets shows the quality of a flow.
End-to-End Flow Monitoring with IPFIX
5
3.2.2 RTP Flows Contrary to TCP flows, we need rather a sophisticated observation algorithm for RTP flows, because port numbers and IP addresses of RTP flows are not known in advance. As shown in Fig. 2, the 5-tuples of SIP-signaled RTP flows can be determined by inspecting the SDP payloads of SIP INVITE/OK packets exchanged between hosts [9]. IP address of the party who sent the SDP can be found at the line starts with ‘o=’, and the port numbers can be found at the lines starts with ‘m=’. As a call possibly includes several media streams, multiple port numbers can be found in a single SDP payload. The found 5-tuples are saved in a table, which is checked whenever a new RTP flow is detected. The QoS metrics are only metered for the RTP flows which have matching entry in the table.
Fig. 2. The 5-tuples of the RTP streams are calculated from the SDP payloads
The packet loss ratio of a RTP flow is metered as shown in Algo. 1. In the algorithm, current_seq and prev_seq are the RTP sequence numbers of the current and previous packets. initial_seq is the RTP sequence number of the first packet of the flow. As the number of the lost RTP packets is the difference between current_seq and prev_seq, the value of pkt_loss_ratio is easily computed. The jitter value of a RTP flow is metered by following a procedure specified in Algo. 2 in [12], where the current_time and prev_time are the timestamp values of the current and previous RTP packets. By tracking the value of variable ‘transit’, the delay is monitored. (1) (2) (3) (4)
num_of_lost_pkt = current_seq – prev_seq prev_seq = current_seq num_of_tot_pkt = prev_seq + 1 – initial_seq pkt_loss_ratio = ( num_of_lost_pkt / num_of_tot_pkt ) * 100 Algo. 1. Calculating packet loss ratio of a RTP flow (1) (2) (3) (4)
transit = current_time – prev_time j = | transit – last_transit | jitter += (j – jitter) / 16 last_transit = transit
Algo. 2. Calculating jitter of a RTP flow
6
3.3
Byungjoon Lee, Hyeongu Son, Seunghyun Yoon and Youngseok Lee
IPFIX Templates for exporting E2E flows
As the exporting information set differs by the protocol, we use different IPFIX flow templates for each of the protocol: SIP, RTP and TCP. The fields defined in TCP and RTP templates constitute a set of QoS parameters. The values of the fields are calculated by the flow probe as presented in the previous section. The template used for SIP flows is shown in Fig. 3. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 FlowSet ID = 0
Length = 36
Template ID = 260
Field Count = 7
0 SIP_CALL_ID = 130
50
0 SIP_RTP_SRC_PORT = 139
2
0 SIP_RTP_DST_PORT = 140
2
0 SIP_RTP_VIDEO_SRC_PORT = 141 2 0 SIP_RTP_VIDEO_DST_PORT = 142 2 0 SIP_RTP_SRC_IPV4_ADDR = 143
15
0 SIP_RTP_DST_IPV4_ADDR = 144
15
Fig. 3. The proposed IPFIX template for SIP messages
In Fig. 3, SIP_CALL_ID is an ID assigned by the flow probe to each SIP call. SIP_RTP_SRC_PORT and SIP_RTP_DST_PORT are source and destination port numbers assigned to the voice RTP flow. SIP_RTP_VIDEO_SRC_PORT and SIP_RTP_VIDEO_DST_PORT are source and destination port numbers assigned to the video RTP flow. SIP_RTP_SRC_IPV4_ADDR and SIP_RTP_DST_IPV4_ADDR are source and destination IP addresses of the SIP session. The packets exported by this template are used only for correlating each call with its constituent RTP flows. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 FlowSet ID = 0
Length = 60
Template ID = 261
Field Count = 13
0
LAST_SWITCHED = 21
4
0
FIRST_SWITCHED
4
0
IN_BYTES = 1
0
IN_PKTS = 2
4
0
L4_SRC_PORT = 7
2
0
IPV4_SRC_ADDR = 27
4
0
L4_DST_PORT = 11
2
0
IPV4_DST_ADDR = 28
4
0
RTP_IN_JITTER = 154
4
0
RTP_IN_PKT_LOST = 156
4
0
RTP_IN_MAX_DELTA = 159
4
0
RTP_IN_MIN_DELTA = 161
4
0
RTP_IN_AVE_DELTA = 163
4
=22
4
Fig. 4. The proposed IPFIX template for RTP flows
End-to-End Flow Monitoring with IPFIX
7
Fig. 4 is a IPFIX template for RTP flows. In this figure, LAST_SWITCHED and FIRST_SWITCHED are timestamp values demarking the start and end of a flow. IN_BYTE and IN_PKTS are counter values for the total volume and the number of packets observed. The values are used to calculate throughput of a flow. RTP_IN_JITTER is the jitter value of a flow. RTP_IN_PKT_LOST represents packet loss ratio of a flow. RTP_IN_MAX_DELTA, RTP_IN_MIN_DELTA, and RTP_IN_AVE_DELTA represent the maximum, minimum, and average delay. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 FlowSet ID = 0
Length = 48
Template ID = 262
Field Count = 10
0
TCP_RETRAN_COUNT = 251
4
0
LAST_SWITCHED = 21
4
0
FIRST_SWITCHED
4
0
IN_BYTES = 1
0
IN_PKTS = 2
4
0
L4_SRC_PORT = 7
2
0
IPV4_SRC_ADDR = 27
4
0
L4_DST_PORT = 11
2
0
IPV4_DST_ADDR = 28
4
=22
4
Fig. 5. TCP Template
Fig. 5 shows an IPFIX template for TCP flows. In this figure, TCP_RETRAN_COUNT is a counter for the number of retransmission. The fields are used to assess the transmission quality of a specific TCP flow.
4
Experiments
4.1
Environments
Fig. 6. Experimental environment
8
Byungjoon Lee, Hyeongu Son, Seunghyun Yoon and Youngseok Lee
The experimental environment is shown in Fig. 6. We set up two end nodes which are used for VoIP SIP soft-phone. TCP flows are also tested between these two machines. One end node is connected to the Internet through a commercial Wi-Fi access service. The other node is connected to the CNU campus network. We have monitored the end-to-end flows at two observation points: one is the access router and the other one is the border router of the CNU campus. The mirrored traffic is captured by flow exporters. The flow exporters send IPFIX messages to the external flow collector. We used WengoPhone [13] for the VoIP experiment. The flow probe is a plain Linux box equipped with our modified version of nProbe. The end hosts and flow collector are PCs running Windows XP. As previously mentioned, MySQL DBMS version 4.0.26 [10] is installed at the flow collector machine. 4.2
The Prototype
The prototype of the flow probe is built on top of nProbe [9]. By extending the nProbe to use IPFIX templates previously mentioned, we added following new features to the nProbe 4.0. - Supporting multiple templates: Previously, only a single IPFIX template can be used for metering. However, SIP-based RTP monitoring requires both the SIP template and RTP template to be used at once. Therefore, we modified nProbe to support the multi-template exporting function. - Adding new fields to the SIP template: As the original SIP template implemented in nProbe 4.0 does not support fields related to video RTP flows, we added these video RTP-related fields to the SIP template. To collect the IPFIX packets exported by the extended nProbe, we have implemented a simple IPFIX collector that simply converts the information contained in an IPFIX packet and saves the converted information into the MySQL [10] DBMS. The saved information is used for visualizing QoS of flows. 4.3
Results
First, Fig. 7 and 8 show the throughput and the number of retransmitted packets for a TCP flow observed at two flow probes. The congestion control behavior of the TCP sender is similarly seen at two flow probes, because there are no queueing delays at two routers in the campus network. The number of retransmitted packets belonging to a flow is generally similar but not exactly same at two flow probes, because the retransmitted packets are not included by the same flow. On average, it is shown that the throughput and the end-to-end QoS information of a TCP flow could be derived by our scheme.
End-to-End Flow Monitoring with IPFIX Bit Rate (Second Router)
Bit Rate (First Router) 12
12
10
10
8
8 Mbit/s
Mbit/s
9
6
6
4
4
2
2 0
0 0
60
120
180
240 sec
300
360
420
0
480
60
120
180
240 sec
300
360
420
480
Fig. 7. Throughput (bit rate) of a TCP flow observed by two flow probes installed at routers Retransmitted Packets (Second Router) 16
14
14
12
12 # of packets
# of packets
Retransmitted Packets (First Router) 16
10 8 6
10 8 6
4
4
2
2 0
0 0
60
120
180
240 sec
300
360
420
0
480
60
120
180
240 sec
300
360
420
480
Fig. 8. Retransmitted packets of a TCP flow observed by two flow probes installed at routers
Secondly, the representative QoS metrics 1 of bit rate, delay, and jitter for a SIP/RTP flow are shown in Fig. 9, 10, and 11. The RTP stream generated by the PCM codec shows the constant bit rate of 81 Kbps. In the experiment, the observed QoS metrics of bit rate, delay, and jitter imply the good quality of voice traffic. Specifically, delays and jitters shown in Fig. 10 and 11 are slightly different at each observation point, which caused by queueing delays at each router. Bit Rate (Second Router) 86
85
85
84
84
83
83 Kbit/s
Kbit/s
Bit Rate (First Router) 86
82 81
82 81 80
80
79 79
78
78 0
60
120
180
240 sec
300
360
420
77 0
60
120
180
240 sec
300
360
420
Fig. 9. Bit rates of a SIP/RTP flow observed by two flow probes installed at routers
1
The loss rate of the RTP flow is not shown because of very low packet loss rate and the page limit.
10
Byungjoon Lee, Hyeongu Son, Seunghyun Yoon and Youngseok Lee Average Delay (Second Router)
Average Delay(First Router) 20.5
20
20
19.5
19.5 ms
ms
20.5
19
19 18.5
18.5 18
18
17.5
17.5
0
60
120
180
240 sec
300
360
0
420
60
120
180
240 sec
300
360
420
Fig. 10. Average delays of a SIP/RTP flow observed by two flow probes installed at routers Jitter (First Router)
Jitter (Second Router) 20.2
20
20
19.8
19.8
19.6
19.6
19.4
19.4
ms
ms
20.2
19.2
19.2 19
19
18.8
18.8
18.6
18.6 18.4
18.4 0
60
120
180
240 sec
300
360
420
0
60
120
180
240 sec
300
360
420
Fig. 11. Jitter values of a SIP/RTP flow observed by two flow probes installed at routers
5. Conclusion & Future Work In this paper, we presented an end-to-end performance measurement scheme using IPFIX and its applications on TCP and SIP/RTP flows. Our method is useful for detecting problematic network segments because multiple flow probes on the path are monitoring QoS information of E2E flows. Since our IPFIX-based scheme is based on passive measurement by routers, it does not require any special software or hardware to be set up at the end host. Hence, the proposed method could be easily deployed. However, our IPFIX-based QoS monitoring method may have an issue regarding high performance, because it assumes no packet loss for monitoring flows. It is widely known that loss-free packet capturing is difficult to achieve at the high-speed line rates. Since our proposal does not use RTCP sender reports which include the QoS metrics measured at the RTP end hosts, it could be extended to combine the flow information from both routers and end-hosts for detailed QoS information.
End-to-End Flow Monitoring with IPFIX
11
REFERENCE [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13]
G. Sadasivan, N. Brownlee, B. Claise and J.Quittek, Architecture for IP Flow Information Export, IETF Internet-Draft, draft-ietf-ipfix-architecture-12. B. Claise, Specification of the IPFIX protocol for the Exchange of IP Traffic Flow Information. IETF Internet-Draft, draft-ietf-ipfix-protocol-24.txt E2E Performance Initiative, http://e2epi.internet2.edu/ NLANR AMP, http://amp.nlanr.net/ W. Song and D. Choi, Experiences in End-to-End Performance Monitoring on KOREN, APNOMS 2006. Cisco nBar, http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/nbarw_wp.pdf T. Lindh and E. Roos, Monitoring of SIP-Based Communication using Signalling Information for Performance Measurements, ICISP 2006. H. Son, B. Lee, S. Shin and Y. Lee, Flow-level QoS Monitoring of Multimedia Streaming Traffic with IPFIX, KNOM 2007. nProbe, http://www.ntop.org/nProbe.html MySQL, http://www.mysql.com J. Rosenberg and H. Schulzrinne, An Offer/Answer Model with the Session Description Protocol (SDP), IETF RFC 3264. H. Schulzrinne, S. Casner, R. Frederick and V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, IETF RFC 1889. WengoPhone, http://openwengo.com
![[PDF] Network Security with NetFlow and IPFIX - Google Sites](https://m.moam.info/img/260x300/pdf-network-security-with-netflow-and-ipfix-google_64779974097c474b228c418b.jpg)
![[PDF]Books Network Security with NetFlow and IPFIX: Big Data ...](https://m.moam.info/img/260x300/pdfbooks-network-security-with-netflow-and-ipfix-b_6477dee4097c4737708c2dec.jpg)
![[PDF]Books Network Security with NetFlow and IPFIX ... - Google Sites](https://m.moam.info/img/260x300/pdfbooks-network-security-with-netflow-and-ipfix-g_6478ad14097c474c228d658f.jpg)
![[PDF] Network Security with NetFlow and IPFIX - Google Sites](https://m.moam.info/img/260x300/pdf-network-security-with-netflow-and-ipfix-google_64779974097c474e708be1e5.jpg)
![[PDF]Books Network Security with NetFlow and IPFIX: Big Data ...](https://m.moam.info/img/260x300/pdfbooks-network-security-with-netflow-and-ipfix-b_6477bcb8097c4796708c0896.jpg)
