5.1.2.1 Requirements
The device which was called external interface or ExtInterface had to fit seamlessly in the INET framework. To achieve this objective, the following requirements had to be met.
• The ExtInterface was supposed to be usable on all platforms that are supported by the INET framework, i.e. most Unix based OSs and a variety of Windows operating system versions.
• The ExtInterface was expected to be easily expandable such that not only SCTP messages, but packets from all IP-based protocols like UDP and TCP, and also OSPF and other protocols could pass from the simulation to a real network and vice versa.
• As multihoming is an important feature, multiple external interfaces had to be supported. Thereby it was to be possible, that these in- terfaces belonged to one host or were distributed among several net- work components, such that the simulation was connected by multiple ExtInterfaces to the real network.
• From the simulation’s point of view the interface was supposed to look like the already supported interfaces for PPP or Ethernet.
• The following scenarios had to be feasible:
– Single simulated host connected to a real host or network. – A simulated network connected to a real host or network.
– A simulated network connected via multiple ExtInterfaces to dif- ferent hosts that communicate with each other through the simu- lation.
5.1.2.2 Receiving and sending real packets
When an IP packet is received by the host running the simulation for a node being simulated, it must be transformed into an OMNet++ object and in- jected into the simulated network. The network stack of the host running the simulation should not process these packets. Therefore, the host can- not have the IP addresses of the simulated node configured as addresses of one of its real interfaces. This means that using raw sockets is not an ap- propriate mechanism for receiving these packets. The packet capture library libpcap, however, provides an appropriate way of capturing these packets (see Chapter 4.1).
Figure 5.1 shows the schematic of the sending and receiving process. When packets arrive at the data link of the host, the libpcap extracts pack- ets, which are meant for the simulation, by applying a capture filter (here: ip and dst host 10.0.0.1). Thus, it makes sure that only packets which are sent to the simulation are captured and not the ones sent by the simulation. Sending packets from the simulation to nodes in the real network is done by using raw IP sockets (solid lines). Hereby, the host sends packets whose source address is the simulated endpoint’s address, i.e they do not belong to the real network adapter. This is not a problem for the Unix based operating systems but may not be supported by all versions of the Windows operating system. In this case the libpcap could also be used to send the packets.
The routing in the real network has to be configured such that the host running the simulation acts like a router which provides access to the network
Simulation IP address: 10.0.0.1
libpcap Real network adapter
IP address: 195.15.16.1
Packets for and from 195.15.16.1 Packets for 195.15.16.1 and 10.0.0.1 Capture filter ip and dst host 10.0.0.1 Raw socket Source address: 10.0.0.1
Figure 5.1: Sending and receiving real packets
being simulated. In the example of Figure 5.1, the real endpoint has to have a route to 10.0.0.1 with the gateway set to 195.15.16.1.
The regular network traffic to and from the host is not influenced by these actions.
For sending packets, a method of transforming the simulation’s internal format to the network format has to be implemented for each protocol. This is called a serializer. For receiving packets a method called parser will trans- form the packet in network format into the simulation’s internal format. The code is structured in a way that these methods are encapsulated on a per protocol basis.
5.1.2.3 Scheduling Events
A discrete event simulation, which also takes interactions with the real ex- ternal world into account, has to handle two kinds of events: internal events which have their origin in the simulation and external events which stem from the interface to the external world. Also, the simulation time has to be synchronized to the real time. This is possible assuming that there is a speedup in the simulation compared to real-time, i.e. the simulated time runs faster than the real time. As the experiments will show, this is a valid assumption when using state-of-the art computer hardware and networks having a limited total packet rate. Time synchronization is basically done by looking at the time of the next scheduled event. If this time is already
in the past, this event is processed. Otherwise external events are processed and the simulation is put to sleep until either the next internal event has to be processed or another external event arrives. It is important to note that internal events have to be given a higher priority.
Due to limitations of the libpcap library, the simulation is put to sleep for a fixed small amount of time, if no external event is present. This results also in a time granularity for all internal events. Choosing a small value for this granularity led to good results. It should be noted that operating systems have a systems based timer granularity for putting processes to sleep, hence choosing a smaller value for the simulation granularity than the systems granularity does not provide any benefit.