INET an OMNeT++ Framework

As OMNeT++ is a very versatile tool, there are a great number of ready- made simulation models provided for download. One of those is the INET framework [104].

The INET framework is ideal for simulating IP-based networks. The dif- ferent network layers can be distinguished and layer specific protocols are

Figure 3.3: OMNeT++ in tegrated in the Eclipse IDE

Figure 3.4: Analyzing results of a vector file

provided. On the link layer Point-to-Point Protocol (PPP), Ethernet and wireless Local Area Network (WLAN) interfaces can be configured, the net- work layer features IPv4 and IPv6, routing protocols like Open Shortest Path First (OSPF), and IP control protocols like the Internet Control Message Protocol (ICMPv4 and ICMPv6), and the Resource ReSerVation Protocol (RSVP). On the transport layer TCP and UDP are implemented. In ad- dition, a lot of protocol independent modules like routing tables, routers, switches, and hubs are available. They are all configured as simple modules and can be combined to form compound modules and networks.

One of those compound modules for instance is the StandardHost (Fig- ure 3.5) which consists of a complete IP stack with PPP or Ethernet inter- faces, a network layer, a Ping application, TCP or UDP as transport layer protocols and corresponding applications. This host has been complemented with the transport protocol SCTP, a suitable application, a dump module and external interfaces. These modules will be specified in Section 5.1 and Chapter 6.

StandardHost notificationBoard interfaceTable routingTable namTrace ppp eth networkLayer pingApp tcpApp tcp udpApp udp

Figure 3.5: Compound Module StandardHost

dresses and do the routing according to rules derived from routing tables. Although the FlatNetworkConfigurator can be used to automatically dis- tribute addresses among the hosts of a network, the preferred configuration mode is setting up routing tables where routes to other hosts or networks can be configured. Especially for multihomed hosts, where each IP address has to belong to a different subnet, this feature helps to keep the network scenarios close to reality.

Together with OMNeT++, INET provides an ideal basis for the imple- mentation of another transport protocol. Since OMNeT++ is public-source, it is free for academic institutes, as long as it serves a strictly noncommercial purpose.

Analyzing Protocols

Evaluating the functionality of a protocol implies the ability to control whether the parameters are set properly and the message flow is correct. Therefore, the packets arriving at the network adapter have to be traced, i.e. the byte sequence has to be recorded and analyzed according to the pro- tocol specifications.

In this chapter first methods to filter packets are explained and text-based network analyzers introduced, before Wireshark is presented in more detail. Wireshark is the most popular GUI-based network analyzer, which has been expanded, as part of this thesis, by adding a feature to draw graphs of the SCTP message flow.

4.1

Packet Capturing

To be able to analyze the network traffic, an application needs access to the link layer. There are three methods, which are used depending on the operating system.

The BSD Packet Filter (BPF), also known as Berkeley Packet Filter, was introduced in [54]. It is supported by most Berkeley-derived implementa- tions, e.g. FreeBSD. Figure 4.1 shows the mechanism to capture packets with a BPF device as described in [83]. Each packet that arrives at the link layer, i.e. which is destined for that computer, is filtered by the BPF device according to the application’s needs. A filter could be an expression like sctp and dst host 10.1

which would result in the extraction of packets that have SCTP as transport layer and are bound to hosts, which belong to the 10.1.0.0 subnet. Thus, not all of the received packets are copied to the application. In addition, applications specify a snaplen, which means that only the beginning snaplen

data link IPv6 IPv4 BPF filter filter buffer buffer application application process kernel

Copy of received packets Copy of transmitted packets

Figure 4.1: Data link access with a BPF device

bytes of a packet are needed, which again reduces the load. A third possibility to reduce the overhead lies in the organization of the buffer. In fact, there are two buffers, one of which is filled, while the contents of the other is copied to the application. As only full buffers are copied, the number of system calls is decreased. Further information about the configuration of BPF devices is given in [112].

In the Solaris operating system the Data Link Provider Interface (DLPI) is integrated, which was designed by AT&T. The access to DLPI is provided by sending and receiving STREAMS messages. The process of filtering is similar to the BPF filtering, but the BPF filtering is done before copying the data, while with DLPI, all packets are copied first. Both devices work with pseudomachines, BPF with a register machine and DLPI with a stack machine. Stevens states that BPF is 3-20 times faster [83].

Linux takes a different approach. The user can choose between two kinds of sockets to create:

1. A socket of type SOCK PACKET

fd = socket(AF_INET, SOCK_PACKET, htons(ETH_P_ALL)) 2. A socket of family PF PACKET

fd = socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL))

ETH P ALL specifies the frame type, which could also be ETH P IP (to get only IPv4 packets) or others. In the second call SOCK RAW could be substituted by SOCK DGRAM if the application is only interested in the link layer.

The second kind of call is more advanced than the first one, as the socket can be bound to a device, and thus a filtering per device is made possible. In contrast to BPF the number of system calls is much higher, as several frames cannot be bundled for one call.

To provide the user with an implementation-independent access to the link layer, the libpcap packet capture library was designed by McCanne and Van Jacobson in 1994 [103]. It features an API between the packet cap- ture facility provided by the operating system and the application. It even includes a filtering mechanism in case it is not supplied by the OS. The libpcap will be used by the ExtInterface described in Section 5.1.