Networks¶

Overview¶

INET heavily builds upon the modular architecture of OMNeT++. It provides numerous domain specific and highly parameterizable components which can be combined in many ways. The primary means of building large custom network simulations in INET is the composition of existing models with custom models, starting from small components and gradually forming ever larger ones up until the composition of the network. Users are not required to have programming experience to create simulations unless they also want to implement their own protocols, for example.

Assembling an INET simulation starts with defining a module representing the network. Networks are compound modules which contain network nodes, automatic network configurators, and sometimes additionally transmission medium, physical environment, various visualizer, and other infrastructure related modules. Networks also contain connections between network nodes representing cables. Large hierarchical networks may be further organized into compound modules to directly express the hierarchy.

There are no predefined networks in INET, because it is very easy to create one, and because of the vast possibilities. However, the OMNeT++ IDE provides several topology generator wizards for advanced scenarios.

As INET is an OMNeT++-based framework, users mainly use NED to describe the model topology, and ini files to provide configuration. [1]

Built-in Network Nodes and Other Top-Level Modules¶

INET provides several pre-assembled network nodes with carefully selected components. They support customization via parameters and parametric submodule types, but they are not meant to be universal. Sometimes it may be necessary to create special network node models for particular simulation scenarios. In any case, the following list gives a taste of the built-in network nodes.

• StandardHost contains the most common Internet protocols: UDP, TCP, IPv4, IPv6, Ethernet, IEEE 802.11. It also supports an optional mobility model, optional energy models, and any number of applications which are entirely configurable from INI files.
• EtherSwitch models an Ethernet switch containing a relay unit and one MAC unit per port.
• Router provides the most common routing protocols: OSPF, BGP, RIP, PIM.
• AccessPoint models a Wifi access point with multiple IEEE 802.11 network interfaces and multiple Ethernet ports.
• WirelessHost provides a network node with one (default) IEEE 802.11 network interface in infrastructure mode, suitable for using with an AccessPoint.
• AdhocHost is a WirelessHost with the network interface configured in ad-hoc mode and forwarding enabled.

Network nodes communicate at the network level by exchanging OMNeT++ messages which are the abstract representations of physical signals on the transmission medium. Signals are either sent through OMNeT++ connections in the wired case, or sent directly to the gate of the receiving network node in the wireless case. Signals encapsulate INET-specific packets that represent the transmitted digital data. Packets are further divided into chunks that provide alternative representations for smaller pieces of data (e.g. protocol headers, application data).

Additionally, there are components that occur on network level, but they are not models of physical network nodes. They are necessary to model other aspects. Some of them are:

• A radio medium module such as Ieee80211RadioMedium, ApskScalarRadioMedium and UnitDiskRadioMedium (there are a few of them) are a required component of wireless networks.
• PhysicalEnvironment models the effect of the physical environment (i.e. obstacles) on radio signal propagation. It is an optional component.
• Configurators such as Ipv4NetworkConfigurator, L2NetworkConfigurator and NextHopNetworkConfigurator configure various aspects of the network. For example, Ipv4NetworkConfigurator assigns IP addresses to hosts and routers, and sets up static routing. It is used when modeling dynamic IP address assignment (e.g. via DHCP) or dynamic routing is not of importance. L2NetworkConfigurator allows one to configure 802.1 LANs and provide STP/RSTP-related parameters such as link cost, port priority and the “is-edge” flag.
• ScenarioManager allows scripted scenarios, such as timed failure and recovery of network nodes.
• Group coordinators are needed for the operation of some group mobility mdels. For example, MoBanCoordinator is the coordinator module for the MoBAN mobility model.
• Visualizers like PacketDropOsgVisualizer provide graphical rendering of some aspect of the simulation either in 2D (canvas) or 3D (using OSG or osgEarth). The usual choice is IntegratedVisualizer which bundles together an instance of each specific visualizer type in a compound module.

Typical Networks¶

Wired Networks¶

Wired network connections, for example Ethernet cables, are represented with standard OMNeT++ connections using the DatarateChannel NED type. The channel’s datarate and delay parameters must be provided for all wired connections. The number of wired interfaces in a host (or router) usually does not need to be manually configured, because it can be automatically inferred from the actual number of links to neighbor nodes.

The following example shows how straightforward it is to create a model for a simple wired network. This network contains a server connected to a router using PPP, which in turn is connected to a switch using Ethernet. The network also contains a parameterizable number of clients, all connected to the switch forming a star topology. The utilized network nodes are all predefined modules in INET. To avoid the manual configuration of IP addresses and routing tables, an automatic network configurator is also included.

network WiredNetworkExample
{
parameters:
int numClients; // number of clients in the network
submodules:
configurator: Ipv4NetworkConfigurator; // network autoconfiguration
server: StandardHost; // predefined standard host
router: Router; // predefined router
switch: EtherSwitch; // predefined ethernet switch
client[numClients]: StandardHost;
connections: // network level connections
router.pppg++ <--> { datarate = 1GBps; } <--> server.pppg++; // PPP
switch.ethg++ <--> Eth1G <--> router.ethg++; // bidirectional ethernet
for i=0..numClients-1 {
client[i].ethg++ <--> Eth1G <--> switch.ethg++; // ethernet
}
}


In order to run a simulation using the above network, an OMNeT++ INI file must be created. The INI file selects the network, sets its number of clients parameter, and configures a simple TCP application for each client. The server is configured to have a TCP application which echos back all data received from the clients individually.

network = WiredNetworkExample
*.numClients = 10 # number of clients in network
*.client[*].numApps = 1 # number of applications on clients
*.client[*].app[0].typename = "TcpSessionApp" # client application type
*.client[*].app[0].connectPort = 1000 # destination port
*.client[*].app[0].sendBytes = 1MB # amount of data to send
*.server.numApps = 1 # number of applications on server
*.server.app[0].typename = "TcpEchoApp" # server application type
*.server.app[0].localPort = 1000 # TCP server listen port


When the above simulation is run, each client application connects to the server using a TCP socket. Then each one of them sends 1MB of data, which in turn is echoed back by the server, and the simulation concludes. The default statistics are written to the results folder of the simulation for later analysis.

Wireless Networks¶

Wireless network connections are not modeled with OMNeT++ connections due the dynamically changing nature of connectivity. For wireless networks, an additional module, one that represents the transmission medium, is required to maintain connectivity information.

network WirelessNetworkExample
submodules:
configurator: Ipv4NetworkConfigurator;
host1: WirelessHost { @display("p=200,100"); }
host2: WirelessHost { @display("p=500,100"); }
accessPoint: AccessPoint { @display("p=374,200"); }
}


In the above network, positions in the display strings provide positions for the transmission medium during the computation of signal propagation and path loss.

In addition, host1 is configured to periodically send UDP packets to host2 over the AP.

network = WirelessNetworkExample
*.host1.numApps = 1
*.host1.app[0].typename = "UdpBasicApp"
*.host1.app[0].destPort = 1000
*.host1.app[0].messageLength = 100Byte
*.host1.app[0].sendInterval = 100ms
*.host2.numApps = 1
*.host2.app[0].typename = "UdpSink"
*.host2.app[0].localPort = 1000
**.arp.typename = "GlobalArp"


network MobileAdhocNetworkExample
{
parameters:
int numHosts; // number of nodes in the network
submodules:
configurator: Ipv4NetworkConfigurator; // network autoconfiguration
}

network = MobileAdhocNetworkExample
*.numHosts = 10 # number of hosts in the MANET
*.host[*].mobility.typename = "MassMobility" # stochastic mobility model
*.host[*].mobility.initFromDisplayString = false # ignore display string
*.host[*].mobility.changeInterval = truncnormal(2s, 0.5s) # between turns
*.host[*].mobility.angleDelta = normal(0deg, 30deg) # random turn
*.host[*].mobility.speed = truncnormal(20mps, 8mps) # random speed
*.host[*].numApps = 1 # number of applications on hosts
*.host[*].app[0].typename = "PingApp" # application type for all hosts
*.host[*].app[0].destAddr = "host[0]" # ping destination
*.host[*].app[0].startTime = uniform(1s,5s) # to avoid synchronization
*.host[*].app[0].printPing = true # print usual ping results to stdout


This section contains quick and somewhat superficial advice to many practical tasks.

Automatic Wired Interfaces¶

In many wired network simulations, the number of wired interfaces need not be manually configured, because it can be automatically inferred from the actual number of connections between network nodes.

router1.ethg++ <--> Eth1G <--> router2.ethg++; // automatic interfaces


Multiple Wireless Interfaces¶

All built-in wireless network nodes support multiple wireless interfaces, but only one is enabled by default.

*.host[*].numWlanInterfaces = 2 # number of wireless network interfaces
*.host[*].wlan[0].agent.defaultSsid = "alpha" # connects to alpha network
*.host[*].wlan[1].agent.defaultSsid = "bravo" # connects to bravo network


Nearly all application layer modules, but several other components as well, have parameters that specify network addresses. They typically accept addresses given with any of the following syntax variations:

• literal IPv4 address: "186.54.66.2"
• literal IPv6 address: "3011:7cd6:750b:5fd6:aba3:c231:e9f9:6a43"
• module name: "server", "subnet.server[3]"
• interface of a host or router: "server/eth0", "subnet.server[3]/eth0"
• IPv4 or IPv6 address of a host or router: "server(ipv4)", "subnet.server[3](ipv6)"
• IPv4 or IPv6 address of an interface of a host or router: "server/eth0(ipv4)", "subnet.server[3]/eth0(ipv6)"

Enabling Dual IP Stack¶

All built-in network nodes support dual Internet protocol stacks, that is both IPv4 and IPv6 are available. They are also supported by transport layer protocols, link layer protocols, and most applications. Only IPv4 is enabled by default, so in order to use IPv6, it must be enabled first, and an application supporting IPv6 (e.g., PingApp must be used). The following example shows how to configure two ping applications in a single node where one is using an IPv4 and the other is using an IPv6 destination address.

*.host[*].hasIpv4 = true # enable IPv4 protocol
*.host[*].hasIpv6 = true # enable IPv6 protocol
*.host[*].numApps = 2 # number of applications on hosts
*.host[*].app[*].typename = "PingApp" # type for both applications

*.host[*].forwarding = true