IPv6-Based Network Performance Metrics Using Active ... - Springer Link

Chapter 53

IPv6-Based Network Performance Metrics Using Active Measurements N. Soumyalatha, Rakesh Kumar Ambhati and Manjunath R. Kounte

Abstract In the real-time network scenario, the network service providers need to ensure the quality of service (QoS) parameters. Network performance metrics (NPMs) are needed to measure the network performance and guarantee the QoS parameters like availability, delivery, latency, bandwidth which are also important for researchers and network equipment designers. One-way active measurement protocol (OWAMP) and two-way active measurement protocol (TWAMP) are the two active measurement approaches to measure the network performance. OWAMP measures one-way metrics and TWAMP measures two-way metrics. In this paper, currently prevalent active measurement methodologies and implementation of TWAMP approach are discussed. IPv6 TWAMP implementation for wireless networks is proposed, to obtain metrics, namely round-trip delay, twoway packet loss, jitter, packet reordering, packet duplication, and loss patterns. Keywords Network performance metrics surement OWAMP TWAMP

Active measurement Passive mea-

53.1 Introduction IP networks enable users to transfer information in the form of voice, video, e-mail, and computer files. There are two Internet protocol versions: IP version 4 (IPv4) and IP version 6 (IPv6). IPv4 addresses are 32 bit long with 232 addresses. N. Soumyalatha (&) M. R. Kounte Department of Electronics and Communication Engineering, REVA ITM, Bangalore, India e-mail: [email protected] M. R. Kounte e-mail: [email protected] R. K. Ambhati Central Research Laboratory, BEL, Bangalore, India e-mail: [email protected]

V. Chakravarthi et al. (eds.), Proceedings of International Conference on VLSI, Communication, Advanced Devices, Signals & Systems and Networking (VCASAN-2013), Lecture Notes in Electrical Engineering 258, DOI: 10.1007/978-81-322-1524-0_53, Ó Springer India 2013

451

452

N. Soumyalatha et al.

IPv6 addresses are 128 bit long with 2128 address space. QoS is to be ensured by Internet Service Provider (ISP) to abide by the service level agreement (SLA) made between ISP and network users. NPMs are generally used by ISPs to measure the network performance and guarantee QoS parameters. NPMs are useful [1] for network end users to cross-check QoS guaranteed by network provider and network equipment manufacturers for design and testing of newly developed networking equipments. It is also used by network researchers to experiment the quality of test networks deployed for research purposes.

53.1.1 Network Performance Metrics As per RFC-2330, in an operational network, metric should have repeatable property (i.e., when same methodology is repeated under identical conditions, similar measurements must be obtained). Therefore, adhering to definition of metric, NPMs [2] are broadly categorized into four types: (1) availability, (2) loss, (3) delay, and (4) utilization. Each NPM is measured in terms of certain submetrics pertaining to it, by IP Performance Metrics Working Group (IPPMWG). These parameters mentioned below give insight into QoS of any fully operational network provided by network provider. Brief explanations of NPMs are mentioned in the following sections: Availability: Availability is measured in terms of connectivity and functionality in the network management layer. Parameters concerned to this metric are as follows: connectivity (RFC-2678) [3] and functionality. Loss: Loss is the number of packet lost in transit from source to destination during a specific time interval. Parameters concerned to this metric are as follows: oneway loss (RFC-2680) [4], round-trip packet loss (RFC-6673) [5], and one-way loss patterns (RFC-3357) [6] (loss distance and loss period). Loss distance: Difference in sequence numbers of two successively lost packets. Loss period: The length of a packet loss event in successive lost packets. Delay: Delay is the time taken for a packet to make the average round trip or one way from the sender to the distant destination and back. Parameters concerned to this metric are as follows: one-way delay (RFC-2679) [7], round-trip delay (RFC-2681) [8], and packet delay variation (RFC-3393) [9]. Utilization: Utilization is the throughput for the link expressed as a percentage of the access rate. Parameters concerned to this metric are as follows: link capacity, available bandwidth, and throughput.

53

IPv6-Based Network Performance Metrics

453

53.1.2 Network Monitoring Methods NPMs mentioned in previous section can be obtained by monitoring network passively or actively. Both passive monitoring and active monitoring approaches are mentioned below briefly. (1) Passive monitoring: Passive monitoring method needs additional hardware to be installed at the end points of network, currently being monitored, and all network traffic passing via installed hardware is logged. Logged network traffic is analyzed for the performance metrics required. This method does analysis on real-time traffic and is not intrusive in nature. Yet, this approach needs enormous storage space [10, 11]. Networking equipments such as gateways, routers, sniffers are required. One of the examples for passive monitoring is Wireshark. Figure 53.1 depicts a typical passive monitoring metrics gathering scenario, where in all traffic passed via hub is logged into a database. This logged traffic is data mined later to obtain metrics of interest. (2) Active monitoring: Active monitoring method unlike passive monitoring injects additional traffic into network and thus consumes away the legitimate bandwidth of network that can be used for end-user applications. Therefore, any active monitoring protocol should test the network for concerned metrics with minimum consumption of available bandwidth. Figure 53.2 depicts a typical active monitoring scenario wherein additional traffic is generated, i.e., time-stamped and injected into network from one network end point and same traffic is received at other end point. The packet received and sent time stamps are logged for deriving the metrics of interest. Active monitoring approach unlike passive monitoring is intrusive in nature and does not require any special hardware installation. Both active monitoring and passive monitoring have advantages and disadvantages [12]. Focus of this paper is

traffic

router

traffic

hub Duplicated traffic

Database

Fig. 53.1 Passive network monitoring

router

454


router

Injected Traffic sent

Injected router

router

Traffic received

router

Fig. 53.2 Active network monitoring

on specific active monitoring strategies; therefore, two popular active measurement protocols and their working are briefly discussed in next section.

53.2 Active Measurement Protocols Various active measurement tools [13], namely Pathchar, pchar, Cprobe, nettimer, Iperf, Ping, Owping, QoSMet, are available. Those are developed to obtain both one-way metrics and two-way metrics. Most of the tools not standardized and also based on Internet control message protocol (ICMP) are used; however, there are few limitations with these tools. Some routers reject the incoming ICMP packet because of security concerns. OWAMP and TWAMP are active measurement protocols standardized by Internet Engineering Task Force (IFTF). Both generate UDP test traffic to obtain metrics. Both protocols use TCP connections to establish the initial control sessions between participating hosts. This TCP control session is used to negotiate the test session parameters like number of packets to be sent, size of the packet to be sent, UDP port to be used.

53.2.1 Owamp One-way active measurement protocol defined in RFC-4656 measures one-way metrics such as one-way delay, one-way packet loss, one-way connectivity, oneway delay variation etc., across the network end points, by comparing the time

53


455

stamps of the test packets on the sender’s and receiver’s end. Therefore, clocks of both the source and the destination should be synchronized. OWAMP consists of two protocols, namely OWAMP-Control and OWAMPTest. OWAMP-Control: This protocol initiate, start, and stop test sessions and to fetch their results. OWAMP-Test: This protocol exchanges test packets between two network nodes used to obtain metrics. Figure 53.3 depicts the typical OWAMP architecture [14] and components involved in implementation of protocol. Control-Client is a network node that starts and stops OWAMP-Test sessions. Session-Sender is a network node, which sends test packets to the SessionReceiver during test sessions. Session-Receiver receives the test packets to measure one-way metrics. Server is a network node that facilitates one or more test sessions and publish metrics. Fetch-Client is a network node that fetches results that are published by server. The Control-Client starts a test session by sending an OWAMP-Control message to the server. Session-Sender sends test packets, which are time-stamped. Session-Receiver receives test packets, calculates relevant metrics, and sends results to server. Finally, the client fetches the result for analysis from the server. (1) Clock Synchronization. For measuring certain metrics, namely one-way delay, clocks must be synchronized in order to ensure that the metric is accurate. Clock synchronization [15] is achieved by using global positioning system (GPS), network time protocol (NTP), and precision time protocol (PTP). GPS gives most precise result, but it is more expensive. NTP gives accuracy of around few ms on a wide area network (WAN). PTP and GPS give nanosecond accuracy.

Fig. 53.3 OWAMP architecture

456


Fig. 53.4 TWAMP architecture

53.2.2 Twamp Two-way active measurement protocol defined in RFC-5357, extension of OWAMP, is predominantly used to measure two-way metrics. Synchronization of clocks of hosts participating in protocol is not required to obtain two-way metrics, namely round-trip time, round-trip loss. Figure 53.4 depicts the typical TWAMP architecture [16] and components involved in implementation of protocol. TWAMP architecture is similar to OWAMP, except changes in the following modules: Session-Receiver node is replaced by Session-Reflector node that is plainly reflecting test packets sent by Session-Sender, as part of test session. Server component does not return the results of a test session as the SessionReflector does not collect any results. Hence, Fetch-Client component is not required. All the metrics are obtained, analyzed, and published by Session-Sender only.

53.3 Proposed System The proposed system is targeted for IPv6-based wireless networks, especially to test 3G, Wi-Fi, Wi-Fi direct and developed on the Android Ice-cream Sandwich platform. The following NPMs are targeted, namely round-trip delay, round-trip loss, delay variation, packer reordering, packet duplication, loss distance, and loss period. As part of the proposed system, two Android applications, namely TwampClient and Twamp-Server, are developed. Proposed system test setup is shown below in Fig. 53.5.

53


457

Fig. 53.5 Twamp-Client, Twamp-Server test setup

53.3.1 Wireless LAN Wireless LAN is deployed using D-Link wireless routers. These wireless routers, which are IPv6-enabled, assign IPv6 addresses to mobile nodes that provide IPv6 wireless network.

53.3.2 Twamp-Server Twamp-Server, Android application installed on mobile node, listens for possible Twamp-Client nodes on port 861 (as mentioned in RFC-5357). As Twamp-Client gets connected, Twamp protocol is initiated. Twamp-Server acts like ‘‘SessionReflector’’ entity as mentioned in Twamp architecture.

53.3.3 Twamp-Client Twamp-Client is another Android application installed on another mobile node and takes input from user, namely packet size, number of packets, payload pattern, delay between packets, and Twamp-Server IPv6 address. Twamp-Client sends control and session-initiation requests to Twamp-Server. Twamp-Client acts as Session-Sender as mentioned in Twamp architecture.

458


Twamp-Client initiates TCP connection with Twamp-Server that initiates TWAMP protocol control session. After successful establishment of control session, test session parameters are negotiated; final test results are cached and displayed at Twamp-Client application.

53.3.4 Test Results Twamp-Client and Twamp-Server applications are run in congested wireless LAN, and following measurements pertaining to various metrics targeted are obtained and mentioned below. Screenshot of the metrics obtained is shown in Fig. 53.6. Wherein the metrics, namely round-trip delay, packet lost, delay variation, packet duplication, reordering, loss distance, and loss period, are determined and displayed. In the Table 53.1, first two columns show the metric under less network traffic scenario. Third and fourth columns show the metrics obtained under highly congested wireless network scenario. Nill indicates that no packet duplication and reordering.

Fig. 53.6 Screenshot showing the results for 1,000 packets

53


459

Table 53.1 Test results Packet size (in bytes) to number of packets 1000/1000 1200/2000 1200/5000 1300/10000 Average round-trip (RT) delay (ms) RT loss Jitter Packet duplication Packet reordering Max loss distance Max loss period

5.5

6.0

7.5

9.0

0 0.00155 Nil Nil 0 0

0 0.00165 Nil Nil 0 0

100 0.00175 Nil Nil 17 23

500 0.00195 Nil Nil 53 79

From the results in Table 53.1, it is clearly evident that under heavy traffic scenario, metrics such as average round-trip delay and loss distance and loss period undergo degradation.

53.3.5 Our Contributions Currently, very less network performance measurement tools are available for measuring IPv6-based wireless network. Our contribution is developing a tool to measure the performance of IPv6-based wireless networks on Android platform by implementing TWAMP, which measures all two-way metrics such as round-trip time, round-trip packet loss, round-trip delay variation.

53.4 Conclusion Current implementation of Twamp-Client and Twamp-Server Android application obtains metrics such as round-trip loss, round-trip delay, delay variation, packet duplication, packet reordering, loss distance, loss period for IPv6-based wireless network. In future work, Twamp-Client and Twamp-Server are intended to be implemented as Android service, which runs periodically to obtain more statistically accurate metrics.

References 1. Claffy K, Monk T (1997) What’s next for internet data analysis? Status and challenges facing the community. In: Proceedings of the IEEE, California Univ, San Diego, La Jolla, CA, USA 2. Lee HJ, Kim MS, Hong JW, Lee GH (2002) QoS parameters to network performance metrics mapping for SLA monitoring. http://mail.apnoms.org/knom/knom-review/v5n2/4.pdf

460


3. Mahdavi J, Paxson V (1999) IPPM metrics for measuring connectivity. RFC-2498. http:// www.ietf.org/rfc/rfc2678.txt 4. Almes G, Kaidindi S, Zekauskas M (1999) A one-way packet loss metrics for IPPM. RFC2680. http://www.ietf.org/rfc/rfc2680.txt 5. Morton A (2012) Round-trip packet loss metrics. RFC- 6673. http://tools.ietf.org/html/ rfc6673 6. Koodli R, Ravikanth R (2002) One-way loss pattern sample metrics. RFC-3357. http:// tools.ietf.org/html/rfc3357 7. Almes G, Kalidindi S, Zekauskas M (1999) A one-way delay metrics for IPPM. RFC-2679. http://tools.ietf.org/html/rfc2679 8. Almes G, Kalidindi S, Zekauskas M (1999) A round-trip delay metric for IPPM. RFC-2681. http://tools.ietf.org/html/rfc2681 9. Demichelis C, Chimento P (2002) IP packet delay variation metric for IP performance metrics. RFC-3393. http://tools.ietf.org/html/rfc3393 10. Mohan V, Janardhan Reddy YR, Kalpana K (2011) Active and passive network measurements: a survey. Int J Comput Sci Inf Technol, ISSN: 0975-9646, 2(4):1372–1385 11. Calyam P, Krymskiy D, Sridharan M, Schopis P (2005) Active and passive measurements on campus, regional and national network backbone paths. Computer Communications and Networks, ICCCN 2005. In: Proceedings 14th International Conference on ISBN: 0-78039428-3, ISSN: 1095-2055, pp 537–542 12. Pezaros D, Hutchison D, Gardner RD, Garcia FJ, Sventek JS (2004) Inline measurements: a native measurement technique for IPv6. Networking and Communication Conference, INCC 2004. ISBN: 0-7803-8325-7, pp 105–110 13. Michaut F, Lepage F (2005) Application oriented network metrology: metrics and active measurement tools. Communications Surveys & Tutorials, IEEE ISSN: 1553-877X, 7(2):2–24 14. Shalunov S, Teitelbaum B, Karp A, Boote J, Zekauskas M (2006) A one-way active measurement protocol. RFC-4656. http://tools.ietf.org/html/rfc4656 15. Paxson V, Mahdavi J, Mathis M (1998) Framework for IP performance metrics. RFC 2330. http://tools.ietf.org/html/rfc2330 16. Hedayat H, Krzanowski R, Morton A, Yum K, Babiarz J (2008) A two-way active measurement protocol. RFC-5357. http://tools.ietf.org/html/rfc5357