Table Of Contents

Network Nodes¶

Overview¶

Hosts, routers, switches, access points, mobile phones, and other network nodes are represented in INET with compound modules. A few node types like StandardHost, Router were introduced in the previous chapter, and networks were demonstrated to be built from them. In this chapter, the internals of these node models will be explored to provide a deeper understanding of their customization possibilities and to give some guidance on assembling custom node models.

Ingredients¶

Node models are assembled from other modules representing applications, communication protocols, network interfaces, routing tables, mobility models, energy models, and other functionalities. These modules can be categorized into the following:

Applications often models user behavior, the application program (e.g., browser), and the application layer protocol (e.g., HTTP). Applications typically utilize transport layer protocols (e.g., TCP and/or UDP), but they may also directly use lower layer protocols (e.g., IP or Ethernet) via sockets.
Routing protocols are provided as separate modules: OSPF, BGP, and AODV for MANET routing. These modules use TCP, UDP, and IPv4, and manipulate routes in the Ipv4RoutingTable module.
Transport layer protocols are connected to applications and network layer protocols. They are most often represented by simple modules, currently TCP, UDP, and SCTP are supported. TCP has several implementations: Tcp is the OMNeT++ native implementation; TcpLwip module wraps the lwIP TCP stack; and TcpNsc module wraps the Network Simulation Cradle library.
Network layer protocols are connected to transport layer protocols and network interfaces, usually modeled as compound modules: Ipv4NetworkLayer for IPv4, and Ipv6NetworkLayer for IPv6. The Ipv4NetworkLayer module contains several protocol modules: Ipv4, Arp, Icmp, and Icmpv6.
Network interfaces are represented by compound modules which are connected to the network layer protocols and other network interfaces in the wired case. They are usually modeled as compound modules containing separate modules for queues, classifiers, MAC, and PHY protocols.
Link layer protocols are usually simple modules sitting in network interface modules. Some protocols, for example IEEE 802.11 MAC, are modeled as compound modules themselves due to the complexity of the protocol.
Physical layer protocols are compound modules also being part of network interface modules.
Interface table maintains the set of network interfaces (e.g. eth0, wlan0) in the network node. Interfaces are registered dynamically during the initialization of network interfaces.
Routing tables maintain the list of routes for the corresponding network protocol (e.g., Ipv4RoutingTable for Ipv4). Routes are added by automatic network configurators or routing protocols. Network protocols use the routing tables to determine the best matching route for datagrams.
Mobility modules are responsible for moving around the network node in the simulated scene. The mobility model is mandatory for wireless simulations even if the network node is stationary. The mobility module stores the location of the network node which is needed to compute wireless propagation and path loss. Different mobility models are provided as different modules. Network nodes define their mobility submodule with a parametric type, so the mobility model can be changed in the configuration.
Energy modules model energy storage mechanisms, energy consumption of devices and software processes, energy generation of devices, and energy management processes that shutdown and startup network nodes.
Status (NodeStatus) keeps track of the status of the network node (up, down, etc.)
Other modules with particular functionality such as PcapRecorder, are also available.

Node Architecture¶

Within network nodes, OMNeT++ connections are used to represent communication opportunities between protocols. Packets and messages sent on these connections represent software or hardware activity.

Although protocols may also be connected to each other directly, in most cases, they are connected via dispatcher modules. Dispatchers (MessageDispatcher) are small, low-overhead modules that allow protocol components to be connected in one-to-many and many-to-many fashions, ensuring that messages and packets sent from one component end up being delivered to the correct component. Dispatchers require no manual configuration, as they use discovery and peek into packets.

In their pre-assembled node models, dispatchers allow arbitrary protocol components to communicate directly with each other, not just ones in neighboring layers.

Customizing Nodes¶

The built-in network nodes are designed to be as versatile and customizable as possible. This is achieved through several ways:

Submodule and Gate Vectors¶

One way is the usage of gate vectors and submodule vectors. The sizes of vectors may come from parameters or be derived from the number of external connections to the network node. For example, a host may have an arbitrary number of wireless interfaces, and it will automatically have as many Ethernet interfaces as the number of Ethernet devices connected to it.

Wireless interfaces for hosts are defined as follows:

wlan[numWlanInterfaces]: <snip> // wlan interfaces in StandardHost etc al.

Where numWlanInterfaces is a module parameter with a default value of either 0 or 1 (this is different for e.g. StandardHost and ned:WirelessHost.) To configure a host to have two interfaces, add the following line to the ini file:

**.hostA.numWlanInterfaces = 2

Conditional Submodules¶

Submodules that are not vectors are often conditional. For example, the TCP protocol module in hosts is conditional on the hasTcp parameter. Thus, to disable TCP support in a host (it is enabled by default), use the following ini file line:

**.hostA.hasTcp = false

Parametric Types¶

Another often-used way of customization is parametric types, where the type of a submodule (or a channel) may be specified as a string parameter. Almost all submodules in the built-in node types have parametric types. For example, the TCP protocol module is defined as follows:

tcp: <default("Tcp")> like ITcp if hasTcp;

The typename parameter of the tcp submodule defaults to the default implementation, Tcp. To use another implementation instead, add the following line to the ini file:

**.host*.tcp.typename = "TcpLwip"  # use lwIP's TCP implementation

Submodule vectors with parametric types are defined without the use of a module parameter to allow elements to have different types. An example is how applications are defined in hosts:

app[numApps]: <> like IApp;  // applications in StandardHost et al.

And applications can be added in the following way:

**.hostA.numApps = 2
**.hostA.apps[0].typename = "UdpBasicApp"
**.hostA.apps[1].typename = "PingApp"

Inheritance¶

Inheritance can be used to derive new, specialized node types from existing ones. A derived NED type may add new parameters, gates, submodules, or connections and may set inherited unassigned parameters to specific values.

For example, WirelessHost is derived from StandardHost, as shown below:

module WirelessHost extends StandardHost
{
    @display("i=device/wifilaptop");
    numWlanInterfaces = default(1);
}

Custom Network Nodes¶

Despite the many pre-assembled network nodes and the several available customization options, sometimes it is just easier to build a network node from scratch. The following example demonstrates how easy it is to build a simple network node.

This network node already contains a configurable application and several standard protocols. It also demonstrates the usage of the packet dispatching mechanism that is required to connect multiple protocols in a many-to-many relationship.

module NetworkNodeExample
{
    parameters:
    gates:
        inout ethg; // ethernet interface connector
        input radioIn; // incoming radio frames from physical medium
    submodules:
        app: <> like IApp; // configurable application
        tcp: Tcp; // standard TCP protocol
        ip: Ipv4; // standard IP protocol
        md: MessageDispatcher; // connects multiple interfaces to IP
        wlan: Ieee80211Interface; // standard wifi interface
        eth: EthernetInterface; // standard ethernet interface
        interfaceTable: InterfaceTable;
    connections: // network node internal connections
        app.socketOut --> tcp.appIn; // application sends data stream
        app.socketIn <-- tcp.appOut; // application receives data stream
        tcp.ipOut --> ip.transportIn; // TCP sends segments
        tcp.ipIn <-- ip.transportOut; // TCP receives segments
        ip.queueOut --> md.in++; // IP sends datagrams
        ip.queueIn <-- md.out++; // IP receives datagrams
        md.out++ --> wlan.upperLayerIn;
        md.in++ <-- wlan.upperLayerOut;
        md.out++ --> eth.upperLayerIn;
        md.in++ <-- eth.upperLayerOut;
        eth.phys <--> ethg; // Ethernet sends frames to cable
        radioIn --> wlan.radioIn; // IEEE 802.11 sends frames to medium
}

Table Of Contents

Network Nodes

Networks

Network Interfaces