Architecture of the INET Framework

The INET Framework builds upon OMNeT++, and uses the same concept: modules communicating by message passing.

Modules and protocols

Protocols are represented by simple modules. A simple module's external interface (gates [connectors] and parameters) is described in a NED file, and the implementation is contained in a C++ class with the same name. Some examples: TCP, IPv4.

These modules can be freely combined to form hosts and other network devices with the NED language (no C++ code and no recompilation required). Various pre-assembled host, router, switch, access point, etc. models can be found in the Nodes/ subdirectory (for example: StandardHost, Router), but you can also create your own ones for tailored to your particular simulation scenarios.

Network interfaces (Ethernet, 802.11, etc) are usually compound modules (i.e. assembled from simple modules) themselves, and are being composed of a queue, a MAC, and possibly other simple modules. See EthernetInterface as an example.

Not all modules implement protocols though. There are modules which hold data (for example IPv4RoutingTable), perform autoconfiguration of a network (FlatNetworkConfigurator), move a mobile node around (for example ConstSpeedMobility), and perform housekeeping associated with radio channels in wireless simulations (IRadioMedium).

Protocol headers and packet formats are described in message definition files (msg files), which are translated into C++ classes by OMNeT++'s opp_msgc tool. The generated message classes subclass from OMNeT++'s cMessage class.

About the documentation

The INET Framework documentation itself is also comprised of two bodies of HTML pages: neddoc generated from NED and MSG files using OMNeT++'s opp_neddoc tool, and the documentation of the underlying C++ classes, generated from the source files using Doxygen. The C++ doc is generated in a way that it contains the full C++ source code as HTML pages. It is syntax highlighted, and variable and class names are hyperlinked and cross-referenced, which makes it convenient for exploring the code.

Common modules in hosts and routers

There are some common modules that appear in all (or many) host, router and device models.

InterfaceTable. This module contains the table of network interfaces (eth0, wlan0, etc) in the host. This module does not send or receive messages: it is accessed by other modules using standard C++ member function calls. Other modules rely on the interface table submodule within the host to be called interfaceTable to be able to find it. (They obtain a cModule * pointer to it, then cast it to InterfaceTable * to be able to call its functions). Network interfaces get dynamically registered (added to the table) by simple modules implementing the network interface, for example EtherMAC.
IPv4RoutingTable. This module contains the IP (v4) routing table, and heavily relies on InterfaceTable for its operation. This module is also accessed from other modules (typically IPv4) by calling the public member functions of its C++ class. There are member functions for querying, adding, deleting routes, and finding the best matching route for a given destination IP address. The routing table submodule within the host (router) must be called routingTable for other modules to find it.
IPv6RoutingTable. This is like IPv4RoutingTable, but for IPv6.

Common modules at network level

Some modules have only one instance, at global network level:

FlatNetworkConfigurator assigns IP addresses to hosts and routers, and sets up static routing.
ScenarioManager makes simulations scriptable. Modules can be made to support scripting by implementing the IScriptable C++ interface.
IRadioMedium is required for wireless simulations. It keeps track of which nodes are within interference distance of other nodes.

Communication between protocol layers

In the INET Framework, when an upper-layer protocol wants to send a data packet over a lower-layer protocol, the upper-layer module just sends the message object representing the packet to the lower-layer module, which will in turn encapsulate it and send it. The reverse process takes place when a lower layer protocol receives a packet and sends it up after decapsulation.

It is often necessary to convey extra information with the packet. For example, when an application-layer module wants to send data over TCP, some connection identifier needs to be specified for TCP. When TCP sends a segment over IP, IP will need a destination address and possibly other parameters like TTL. When IP sends a datagram to an Ethernet interface for transmission, a destination MAC address must be specified. This extra information is attached to the message object to as control info.

Control info are small value objects, which are attached to packets (message objects) with its setControlInfo() member function. Control info only holds auxiliary information for the next protocol layer, and is not supposed to be sent over the network to other hosts and routers.