Connecting Omnetpp to virtual Ethernet Interfaces

Transcription

1 Connecting Omnetpp to virtual Ethernet Interfaces Sorin COCORADĂ Department of Electronics and Computers Transilvania University of Brasov Address (12pt Times New Roman, centered) ROMANIA Abstract: - Network emulation provides the ability to connect a real network device to a network simulator, which models the network the real device interacts with. Because data packets may be represented differently in a simulator and in a real network, some form of translation is necessary. An interface to connect the simulator to the real world is also needed. This paper describes a method for bridging the OMNeT++ simulator to real Ethernet interfaces. Because the performance of the emulated device is critical for its applicability, several delay measurements have been performed. Key-Words: - emulation, network simulation, communication protocols, OMNeT++, real-time scheduling, performance evaluation 1. Introduction Implementing, optimizing and developing new and existing protocol or network architecture can be done using various approaches. The development process of a communication protocol typically begins by evaluating it using a simulator and continues by testing a real prototype in a test-bed. With the help of simulators, the development of new communication architectures and network protocols can be considerably simplified and improved. Discrete event-based network simulation is a well-established methodology for developing network protocols. There are many different software simulators, such as OMNeT++ [1] and ns- 3, each of them supporting its own particular features to facilitate the flexible analysis of arbitrary network protocols. Simulations provide the greatest most flexibility in testing, network simulators scaling well to network sizes of up to many thousand nodes. With a proper parameterization, the simulation model can approximate the real network, but some investigations like the effect of hardware delays, resource usage, and the interoperability with other protocol implementations cannot be considered in the simulation. Performance evaluations and conformance to different standards under real conditions are mostly carried out within network test-beds of prototype implementations. Testing the prototype in a real network during the implementation process is timeconsuming, cost intensive, especially when the number of hosts grows. Such an environment provides a limited flexibility due to a lack of topology controllability, shared test-bed usage or insufficient scalability, making the analysis of the protocols very difficult. Some free testbeds such as PlanetLab, Emulab and MoteLab [4] are available, but interferences with existing network applications are possible making results impossible to reproduce. Some tests cannot be fully performed in simulations, but they are also difficult to perform in a test-bed. [6] Network emulation combines the flexibility of discrete event-based network simulations with the precision of evaluation using real world testbeds [5]. Tools which support both simulation and emulation are classified as hybrid virtualization tools, requiring packets to cross the border between the simulated part of the system and the real world, in order to connect both of them together. The network traffic from simulation is injected in the real world and vice versa. The real system itself cannot (and should not be able to) distinguish between the emulated network device and a real one. All devices are treated exactly the same way. Thus, in order to behave like its real equivalent, the emulated device needs to imitate the required functionalities of the real device and to have the same physical network attributes. These requirements pose a series of challenges in connecting a simulator to the real environment: different time representations, different packet representations, and also a software-to-hardware interface are needed. In this paper, we describe, analyze and validate a method for bridging the OMNet++ simulator to ISBN:

2 Ethernet, like networks using the virtual TUN/TAP kernel interfaces provided by the Linux operating system. The rest of this paper is organized as follows: section 2 gives a short overview of related work; section 3 describes the architecture of the proposed approach; in section 4 the performance measurement methodology is described and the results of measurements are presented. Finally, the conclusions are presented in section Related work The authors in [3] designed several experiments to find out which network simulator is best able to extend a network testbed. They compared the ability of ns-3 and OMNeT++ simulators to provide a proposed environment, using both subjective and objective criteria. OMNeT++ showed fluctuations during delay measurements, but the paper does not investigate their cause. In [8][9], the OMNeT++ simulator was extended to support external IP point-to-point interfaces, using the libpcap library. The requirements for external interfaces were discussed and some implementation aspects were described. To verify the feasibility and evaluate performance, several complex setups were evaluated. Although some delay measurements results are provided, the paper does not analyze their structure in depth. An algorithm for connecting the INET simulation framework to applications in real-time is discussed and analyzed in [7]. In this case a mechanism to send data from the real world to the simulation is also needed, but the proposed approach cannot be used for network device emulation. VirtualMesh [10] provides instruments to test the real communication software stack for wireless mesh networks inside a controlled environment. The real traffic is captured through a Linux TUN/TAP virtual kernel interface and redirected to the OMNeT++ simulator. The delays introduced by the architecture are experimentally evaluated using ping, but the paper does not insist on the source and structure of these delays inside the simulation model. SliceTime [4] enables the precise evaluation of general purpose networking software with eventbased simulations by relieving the network simulation from its real-time constraint; synchronization between simulator and real world is achieved by executing the simulator inside a virtual machine with adjustable speed [5]. 3. Bridging the simulator to the virtual Ethernet interfaces In INET framework modeling Full-duplex Ethernet interfaces is achieved using the EthernetInterface compound module which consists of tree simple modules. These tree modules have the following functionalities: encapsulation /decapsulation (EtherEncap), scheduling (EtherQosQueue) and medium access control (EthertMAC). In order to ensure the interoperability between the physical network and the simulator, we want to modify the existing simulator architecture as little as possible; from the perspective of the hosts, switches and routers, the new interface should be similar to the existing Ethernet interface. The proposed modification includes replacing the EtherMAC, with the newly created module EtherTap. In computer networking, TUN/TAP are virtual network kernel devices. These network devices are implemented entirely in software, being different from real network devices that are implemented in hardware network adapters. TAP emulates an Ethernet device and operates with layer two frames such as Ethernet frames. TUN emulates a network layer device and operates with layer tree packets such as IP packets. The converter module creates the virtual device and attaches itself to the device. Packets sent by the operating system via a TUN/TAP are not delivered by wire, being delivered in our approach to the simulator which runs in user-space. The simulator also passes packets into the TUN/TAP device. In this case, the virtual device delivers these packets to the operating system network stack, thus emulating their reception from an external source. The entire process is illustrated in Figure 2. OMNet++ simulator Converter / syncronizer Internet Routing / bridging TUN/TAP device Fig. 1 The proposed architecture Physical NIC ISBN:

3 To achieve this goal, the original modules EtherQoSQueue, EtherMAC, and the new EtherTap module, which acts as a proxy between the kernel TUN/TAP device and the Ethernet encapsulation/decapsulation module of the simulator, have been included in the new interface module (called EtherTapInterface). The proposed architecture employs the protocol stack modularity of the simulator, without affecting the upper layer (network layer). The existing link layer is only partially modified by replacing the lower medium access component while the logical link control remains the same. When a frame leaves the simulator, the new EtherTapInterface module, translated from the simulators internal data representation format to the network representation format. When a frame arrives from the physical network to the simulator, the EtherTapInterface module translated the frame from the physical network format to the simulators representation format. Inside the EtherTap module, transmission and reception is handled separately using specific functions, which will be analyzed in the subsequent sections. To maintain the consistency between the network data flow and the simulator data flow, synchronization is also needed [2]. 3.1 Transmitting When the EtherTapInterface module receives a frame from the upper layer, it has to translate in the network format. Translation is achieved using protocol specific serialization functions. These functions have as inputs C++ objects and return a packed bytes stream which represents a packet in network byte order. Serialization starts at the outer header, left most (Ethernet) header and continues to the right up to the application inner header (application layer). After this operation, the resulting frame is written to the TUN/TAP interface descriptor using a standard system call. Usually the writing operation is non-blocking; the simulator continues the usual processing of the queued events 3.2 Receiving When a frame becomes available it should be processed as fast as possible. The simulator uses a single thread of execution and reading from a file descriptor is usually blocking, which makes the receive operation more complex than the transmit operation. If the simulator blocks the waiting for external frames, it cannot execute its own internal events. In these circumstances, a method for multiplexing between processing external events and processing internal events is needed. In this approach, external frames are received and processed only in idle intervals between internal events; otherwise external frames are ignored. To acquire external frames in a timely manner, internal events should be processed fast enough, so that there should remain sufficient time for processing the external ones. When an external Ethernet frame is read, it is translated to the simulators internal representation using a parser. To provide data link layer communication in our model, two new serialization/parsing classes have been added: Ethernet and ARP in addition to the existing ones (IPv4, ICMP, TCP, UDP, SCTP). Parsing is performed for each protocol header; the octet stream in Network Byte Order is converted to a C++ object, which is scheduled in the simulator s event queue. Ethernet II ICMP/ TCP/UDP IPv4 or ARP EthernetIIFrame IPv4 or ARP ICMP/TCP/UDP Headers in Network Byte Order Fig. 2 Header serializing and parsing 3.2 Synchronization OMNeT++ already has a real time scheduler; when installed using the scheduler-class omnetpp.ini entry, it will synchronize simulation execution to real (wall clock) time. Otherwise the simulation runs faster or slower, depending on the model complexity and processor speed. OMNeT++ real time scheduler works as follows: when startrun() or executionresumed() is called a base time (current ISBN:

4 real time) is determined because the simulation time always starts at zero. Later on, the scheduler object calls usleep() from getnextevent() to synchronize the simulation time to real time, that is, to wait until the current time minus base time becomes equal to the simulation time. Should the simulation lag behind real time, this scheduler will try to catch up by omitting sleep calls altogether [1]. This approach is adequate for running an independent simulation in real time but it is not suitable for external data exchanges. OMNeT++ is a discrete event simulator; emulating a system which interacts with an external environment enforces the simulator to schedule its internal events synchronously, in real time, while simultaneously processing the asynchronous events generated by the external environment, using a single thread of execution. In these circumstances, a custom real time schedules is needed, which is closely linked to receiving and transmitting system calls. Synchronizing to the external environment involves tree aspects: - synchronizing when transmitting frames; - synchronizing when receiving frames; - synchronizing on user input through the GUI; - synchronizing upon pausing and resuming the simulation. Because the scheduler runs in real time and the writing operation is in this case non-blocking (frames are buffered for transmit by the operating system), the frames transmission does not involve custom synchronization actions. Frames will be transmitted immediately after arriving at the EtherTapInterface module. Transmitting is implemented using a single function. Synchronizing on frames which can arrive at any time must be multiplexed with internal events processing and user input through the GUI. It is desirable that all this processing be performed with minimum delay. Acquiring external frames only when the simulator is idle prioritizes internal events; if the arrival rate is high, the queue occurs. After parsing an external frame, the resulting message (C++ object) becomes an internal event, being scheduled for execution at the current time. 4. Validation and performance In this section, a scenario for validating the described model is presented, while later on we focus on analyzing the implementation performance. The experimental setup is depicted in Figure 3. The computer hosting the simulator uses an Intel Core 2 Duo CPU (T7300) running at 2GHz. All measurements have been performed in text mode (Linux runlevel 3) using OMNeT++ Cmdenv express-mode and nice level set to -20. Physical host Gigabit Ethernet bridge Fig.3 Experimental setup StandardHost (Emulated) tap0 (virtual) eth0 (physical) To validate the proposed approach, a simple combination between a real host and an emulated host has been chosen. The emulated end system is hosted by a workstation connected to the real end system through a Gigabit Ethernet link. The virtual tap0 interface is the emulated systems end point. To connect the real environment (interface eth0) to the simulated environment (interface tap0) a bridge has been set up between the two interfaces. In this way, a broadcast link between the real system and the emulated system has been obtained. The technical metrics used to evaluate network devices include but are not limited to: delay, throughput, packet loss and jitter. In the next paragraphs only the delay is analyzed, focusing on the delay introduced by the simulator. For measuring delay, the commonly available Ping tool from the Linux operating system is used. Ping sends ICMP Echo Request packets to a remote network node and measures the elapsed time until the Echo Reply packets arrive at the local node. The round trip time (RTT) is reported in milliseconds. The following measurements using the ping tool have been performed and compared: RTT between the real host and the emulated host, RTT between the real host and the computer hosting the simulator, RTT between the computer hosting the simulator and the emulated host, and RTT between the computer hosting the simulator and its loopback interface. The chart below depicts the average RTT (1000 packets) vs. payload length. First the data transfer rate on the link between the real host and the computer hosting the simulation has been looked to 1Gbps, then to 100Mbps. ISBN:

5 Routing (TAP device) Ping reply Kernel The table above reveals that the data between kernel space and user space are exchanged four times, the user/kernel data transfer being critical to emulator performance. Using the gettimeofday function, the execution time of parsing, processing and serializing inside the simulator has been measured. Because Linux is a non real time operating system, the function execution time depends on the system load; this approach is considered relevant because the RTT reported by ping also depends on the same system load. The table below summarizes the values (milliseconds) measured for different processing stages when 1000 ICMP Echo packets are sent, each having a 1000 bytes payload. Fig. 4 RTT vs. payload length Similar measurements have been conducted to determine the RTT between the physical host and the computer running the simulation. The average RTT values range from 0.158ms to 0.239ms for the 1Gbps link and from 0.18ms to 0.444ms for the 100Mbps link; these values are significantly lower than the RTT for the emulated host. The differences show that processing inside the simulator is much slower than proceeding in real TCP/IP stack, because the simulator has not been built with a view towards performance. To highlight the simulator s performance further investigations will be focused on measuring the RTT between the emulated host and the computer running the simulation, using ping. The results are shown in Figure 4, with thickened line. Taking measurements using the loopback interface leads to values ranging from 0.007ms to 0.008ms. To analyze the emulation performance, the processing has been divided in several stages whose execution times have been measured separately. The table below enumerates the stages involved in processing a packet, since the echo request is sent by the ping tool and until the echo reply is received by ping. Table 1. ICMP processing inside and outside the simulator Operation description Space Ping request Routing (TAP device) Kernel OMNeT++ parse OMNeT++ process OMNeT++ serialize Table 2. Message processing durations Min Avg Max Stdev RTT Parse Processing Serialize Delta The first line shows the RTT reported by the ping tool; the next tree lines show processing times inside the simulator (parsing after receiving a frame from the kernel, processing the OMNeT++ message inside the simulators stack up to the network layer and serializing the message again before transmitting). The parsing routine does not include Internet checksum verification; the ICMP payload is copied from the ICMP packet to the C++ object byte-by-byte, which may be inefficient. The serializing routine includes two Internet checksum calculations: one for the IPv4 header and another one for ICMP. The last line from Table 2 shows the difference between the value of the RTT reported by ping and the cumulated value of parsing, processing and serializing. This value includes the time needed to exchange data between kernel space and user space and other residual values. Approximately 70% (0.329ms) of the round trip time is spent inside the simulator, limiting the throughput to about 3000 packets per second. 5. Conclusion and future work In this paper a method for interfacing the OMNeT++ simulator to real networks was described, analyzed and validated. The approach is based on virtual TUN/TAP kernel interfaces which ISBN:

6 makes it possible to emulate broadcast channels starting from the data link layer of the network stack. The conducted experiments have proven the functionality of the proposed bridging method. To evaluate the performance of the implementation, the delay was measured using the ping tool. The findings show that real network devices can communicate with the emulated device but the delays introduced by the processing inside the simulator are higher, given that the similar was not build with a view to performance. Further work can be conducted to improve the efficiency of the parsing, serializing and synchronization routines in order to reduce their execution times. References: [1] A. Varga et al. OMNeT++ Manual version Available at [2] C. P. Mayer, T. Gamer, Integrating real world applications into OMNeT++, Telematics Techincal Reports, Karlsruhe, 2008 [3] D. Gunther, M. Steichen, N. Kerr, P. Muller, Evaluating network simulators as extensions of real network testbeds, Proceedings of the 14th Communications and Networking Symposium, 2011, pp [4] E. Weingärtner, F. Schmidt, H. Vom Lehn, T. Heer, K. Wehrle, SliceTime: a platform for scalable and accurate network emulation, Proceedings of the 8th USENIX conference on Networked systems design and implementation, 2011, pp. 19 [5] E. Weingartner, F. Schmidt, T. Heer, K. Wehrle, Synchronized network emulation: matching prototypes with complex simulations. SIGMETRICS Perform. Eval. Rev. 36, 2 (2008), pp [6] I. Aktaş, H. vom Lehn, C. Habets, F. Schmidt, K. Wehrle, FANTASY: fully automatic network emulation architecture with cross-layer support, SIMUTOOLS '12: Proceedings of the 5th International ICST Conference on Simulation Tools and Techniques, 2012 [7] I. Rungeler, M. Tuxen, B. Penoff, A. Wagner, A new fast algorithm for connecting the INET simulation framework to applications in realtime, Proceedings of the 4th International ICST Conference on Simulation Tools and Techniques, pp , 2011 [8] I. Rungeler, M. Tuxen,, E.P. Rathgeb, Integration of SCTP in the OMNeT++ Simulation Environment, Proceedings of the 1st international conference on Simulation tools and techniques for communications, networks and systems, 2008 [9] M. Tuxen, I. Rungeler, E.P. Rathgeb, Interface connecting the INET frameowrk with the real world, Proceedings of the 1st international conference on Simulation tools and techniques for communications, networks and systems, 2008 [10] T. Staub, R. Gantenbein, T. Braun, VirtualMesh: An Emulation Framework for Wireless Mesh Networks in OMNeT++, in Simulation, vol. 87 Issue 1-2, 2011, pp ISBN: