INET 4.3.0

This is a new minor stable release of the INET 4.x branch. The highlights of this
release are the infrastructure for Time-Sensitive Networking protocols, the EIGRP
routing protocol and DCTCP congestion control.

For TSN support, a new modular Ethernet MAC and PHY layer model has been added
which provides Ethernet frame preemption, Ethernet cut-through switching, a gating
mechanism for packet queueing, and a clock model which also models clock drifting.

New API level features include intra-node packet streaming, inter-node transmission
update support, bit level packet data identity tracking, and the ability to define
and measure packet flows.

There are also a number of small improvements, and several bug fixes. Some changes
are backward incompatible, so existing models may need to be updated. This version
requires OMNeT++ 6.0 preview 10 or later.

For a complete list of all added, removed, and change folders, NED modules, packet
chunks, packet tags, statistics, C++ classes, and signals please refer to src/ChangeLog.

Notable backward incompatible changes

1. Packet API

The packet tag, chunk tag and chunk region tag APIs have been changed to
store all tags using shared pointers. Moreover, the vectors containing said
tags have also been changed to be stored using shared pointers. These shared
data structures are automatically copied behind the scenes when they are
modified, and they are also shared among multiple packets.

The reasoning is that packets are copied quite often, so this operation must
be very efficient both in terms of space and time. Often the copied packet is
not modified with respect to the attached tags, so it makes sense to share these
data structures. The previous packet API already shared the packet data between
copies, but it didn't share the attached tags.

Internally, the class TagSet has been replaced with another class, SharedTagSet,
and similarly, the class RegionTagSet has been replaced with SharedRegionTagSet.

This change requires the modification of simulation models, because tags are
now returned as shared pointers. Moreover, a different method must be called,
namely the ones with the 'ForUpdate' suffix, to modify existing tags. Due to
this copy-on-write semantics, this change can also break existing user code.

2. Ethernet

Several modules which had an abbreviated Ether in their names have been renamed
to have the complete word, Ethernet, in their names instead. This change affects
many names: EthernetSwitch, EthernetMac, EthernetLink, EthernetSignal, etc.

The Ethernet switch relay functionality provided by the MacRelayUnit and
Ieee8021dRelay modules have been refactored. The most prominent change is that
these modules no longer work on Ethernet frames only. They simply expect the
packets to contain the necessary metadata such as the incoming interface
indication (InterfaceInd) and the source and destination MAC address indication
(MacAddressInd) in order to operate.

A new WireJunction module has been added which replaces the functionality of
the old EtherBus and EtherHub modules. This module represents a generic wiring
hub, and simply broadcasts messages (packets, frames, signals) received on one
port to all other ports, mimicking the propagation of wired electrical signals.

The physical signal class hierarchy has been refactored, the old Signal class
has been split into a generic wireless signal, called WirelessSignal, and
a generic wired signal, called WiredSignal, both subclassed from Signal.

The renames may break existing simulations but they are easy to follow. The
MAC relay changes are internal to network nodes and may only break Ethernet
extension models. All the other changes are likely to produce compilation
errors.

3. IEEE 802.1q support

The old 802.1q support has been removed from the default EthernetInterface,
because it unnecessarily complicated the network interface and it was not
extensible.

The LinkLayerNodeBase base module has been extended with separate and optional
Ethernet and IEEE 802.1q protocol layers, where protocol modules have on instance
per network node. This results in a different structure from the default one
where the Ethernet protocol is part of the network interface. The advantage is
that various additional IEEE 802 protocols such as 802 LLC, 802 SNAP, 802.1q
and 802.1ae are better composable this way.

Several small layered protocol models and infrastructure components have been
added to support these IEEE 802 protocols. These include among others protocol
header inserters and checkers, protocol printers and dissectors, etc.

This change may break simulations that used the old IEEE 802.1q support. They
must be carefully investigated and updated to use the new model instead.

4. VLAN support

The VLAN support has been completely refactored to use separate modules for
filtering and mapping VLAN indications and requests on packets according to
a user-configurable policy. The new VlanIndFilter and VlanReqMapper modules
are part of a VLAN policy module of Ethernet switches by default.

This change may cause simulations to ignore certain parameters which are
expected to affect virtual interfaces and thus break existing simulations.

5. Virtual interfaces

The vlan submodule vector of network nodes inherited from LinkLayerNodeBase
has been renamed to virt. The original name suggested misleadingly that this
set of network interfaces were meant to be used exclusively for VLAN, but that
is not the case. The virtual interfaces, called VirtualInterface, can be used
for all kinds of protocol parameterization such as changing the source MAC
address.

This change may cause simulations to ignore certain parameters which are
expected to affect virtual interfaces.

6. Registering protocols and services

There was some confusion with respect to the expected module gates in the
arguments of the registerService() and registerProtocol() methods. Following
the OSI terminology, the registerService() method now takes the requestIn
and indicationOut gates, the registerProtocol() method takes the requestOut
and indicationIn gates as arguments. This change has been followed with
all affected modules.

Unfortunately, this change may break existing code silently, although not
very likely. The registration calls may provide the incorrect gates to the
MessageDispatcher modules, which in turn will dispatch the packets to the
wrong modules or not at all. Luckily, in the latter case, an error will be
thrown and the simulation terminates.

7. Mobility

All methods in the IMobility interface that returned a Coord or a Quaternion
data structure by value have been changed to return a const reference instead.
These methods, especially the getCurrentPosition() method, may be called quite
often, so avoiding the copying of said data structures increases performance.

This change can be followed easily by implementations, because in most cases
the values were already stored in the mobility modules. This change is not
expected to break existing models silently.

8. Radio medium analog model

Similarly to the IMobility interface change, several methods that returned
or received as an argument a Coord or a Quaternion data structure by value
has been changed to return or receive a const reference instead. Again, these
methods may be called quite often in wireless network simulations, so avoiding
the copying of these data structures increases performance.

This change has very little effect on the implementations, since in most cases
the values were already stored in the related object with a large enough dynamic
extent. This change is not expected to break existing models silently.

9. Queueing model

The IPacketQueue interface has been changed to use explicit enqueuePacket()
and dequeuePacket() methods instead of relying on the generic pushPacket()
and pullPacket().

This change required to updated all existing MAC models to use the new API.
Other 3rd party MAC modules have to be updated accordingly.

10. Renames

Several folders in the physicallayer folder have been moved below the newly
added wired and wireless folders, and renamed. Besides, all support modules have
been moved one level deeper into the common folders. This change helps new
users to find existing physical layer technologies more easily, because they
have their own folders right inside the wired and wireless folders. This change
separates the largely independent wired and wireless physical layer support
modules and implementations.

Similary to the above, several folders in the visualizer folder have been
moved below the newly added canvas and osg folders. This change is required
in order to be able to add separate features for canvas (2D) and OSG (3D)
visualizations.

The InterfaceEntry module that represents network interfaces has been renamed
to NetworkInterface. The old name was a left-over from the time when this
class was really an integral part of the InterfaceTable module. This is no
longer the case, thus the renaming makes perfect sense.

The Protocol::ieee8022 global protocol variable has been renamed, and split
into Protocol::ieee8022llc and Protocol::ieee8022snap.

The queueing API has been updated to reflect the new push/pull duality in
the naming convention as opposed to the old push/pop duality. For example,
the old packetPopped signal has been renamed to packetPulled, and the old
popPacket() method in the IPassivePacketSource has been renamed to pullPacket().

The IPacketQueueingElement C++ interface and the corresponding base class,
called PacketQueueingElementBase, has been renamed to IPacketProcessor and
PacketProcessorBase, respectively. The reason is that, although these classes
are part of the queueing API, they are more general and their original na...

INET 4.2.2

This release contains a fix to build properly on Windows with OMNeT++ 6.0 Preview 10.

INET 3.7.0

This release adds an IPsec model, improves on UDPBasicApp, and contains small bug fixes. It requires OMNeT++ 5.3 or later, or OMNeT++ 6.0 Preview 9 or 10.

IPsec:

The IPsec model implements basic RFC 4301 functionality: Authentication Header (AH) and Encapsulating Security Payload (ESP). Key exchange protocols are not modeled, but instead, security associations (SAs) are statically configured and remain in effect for the entire duration of the simulation.

The model does not perform actual cryptography. This was an explicit non-goal, as the purpose of the model is to study the effects of the network overhead of IPsec. As a consequence, encryption keys, certificates, and other cryptography-related data do not appear in the model's data structures. However, protocol overhead and a simple performance model to account for the runtime overhead of cryptography are included.

Further limitations:

• Transport mode only. Tunnel mode is not supported.
• Multicast traffic is not supported.
• The anti-replay mechanism is not implemented.
• DSCP-based SA selection is not implemented.

UDPBasicApp:

• Added sendScript parameter; sendInterval made optional. The change is backward compatible (existing fingerprints unchanged).

VoIPStream:

• Updated for avcodec-7:4.2.4

Other:

• Fixed a number of (previously hidden) subtle ownership problems.

INET 4.2.1

This release contains a compatibility fix to be able to build INET with OMNeT++ 6.0 Preview 9. It requires OMNeT++ 5.4.1 or later.

NOTE: OMNeT++ 6.0 Preview 5-8 will NOT work with this release. Use INET 4.2.0 with those versions or rather upgrade your OMNeT++ installation.

INET 3.6.8

This release contains a compatibility fix to be able to build INET with
OMNeT++ 6.0 Preview 9. It requires OMNeT++ 5.3 or later.

NOTE: OMNeT++ 6.0 Preview 5-8 will NOT work with this releasre. Use INET 3.6.7
with those versions or rather upgrade your OMNeT++ installation.

INET 4.2.0

This version includes a few important new features, some backward incompatible changes, a number of small improvements, and several bug fixes. This version requires OMNeT++ 5.5.1 or later.

Notable backward incompatible changes

1. Representation of radio signals

The multidimensional (in terms of space, time, and frequency) analog domain representation of radio signals in the physical layer has been substantially changed. The old multidimensional mathematical function implementation, which was originally inherited from MiXiM, has been replaced with a completely new implementation. The reason behind this change is that the old implementation had several non-trivial open bugs, it was often 10+ times slower than the equivalent scalar signal representation, and due to its iterator-based API and its eager computational nature, it was less composable and extensible.

The new implementation is capable of representing all kinds of radio signals such as OFDM, FHSS, UWB, etc. It also allows mixing these wireless technologies arbitrarily. The new API is more flexible in terms of composition, and it allows arbitrary extensions to be combined with existing representations.

The new implementation has better performance than the old one both in terms of memory usage and execution speed. Thanks to the usage of shared pointers, it scales well to large networks with a small memory footprint and is easy to maintain and use. It also has comparable execution speed to the equivalent scalar signal representation. Futhermore, it allows the visualization of the power spectral desnsity of individual signals and the transmission medium in Qtenv.

Simulation models which use the old C++ API will not compile, and need to be updated.

The transmitter timeGains and frequencyGains NED parameters, which determine the signal power over time and frequency, have been changed in the various dimensional radio models. The new syntax is more expressive and more user friendly. The changed interpretation of these NED parameters will cause an error in existing simulations that use it.

See the presentation from the OMNeT++ Community Summit 2019: https://summit.omnetpp.org/2019/assets/pdf/math.pdf

2. Queueing model

A new top-level source folder containing a new queueing model package has been added. The new queueing model provides reusable modules for various application areas. These modules can be used to build application traffic generators, queueing models for MAC protocols, traffic conditioning models for quality of service implementations, and so on.

The queueing model contains several different kinds of elements: sources, sinks, queues, buffers, filters, servers, classifiers, schedulers, etc. Some of the queueing elements were already present in INET, but most of them are written from scratch. The most important change is that the queueing model became synchronous by default, primarily in order to avoid event race conditions in complex queueing models, and also to increase performance by eliminating simulation events. The User's Guide has been extended with a relevant chapter.

This change results in compilation errors and NED errors in simulation models which use the old queueing model. You may look at changes to existing MAC protocols to see how to update your code.

3. MAC protocols and DiffServ

All MAC protocols have been updated to use the new queueing model for their transmission queues in a very similar way. All protocols have been extended with a replaceable queue submodule, even in the default case, so there's no internal queue anymore. Different queue length parameters have been removed from MAC modules, because complex transmission queues may have all sorts of parameters rendering the MAC queue length parameters useless.

The DiffServ implementation has also been updated to use the new queueing model.

These changes may cause existing models to silently produce different simulation results, because some module parameters such as txQueueLimit and queueLength MAC protocol parameters no longer exist.

4. Packet API

The interpretation of the Chunk API length parameter for negative values has been changed in the peek() and has() functions. The old version interpreted the value -1 as any length. The new version interprets negative values as any length up to the absolute value of the parameter. The change was required to properly implement the Chunk serialization API for all edge cases.

This change may result in incorrect behavior silently if the -1 parameter value was used explicitly. Generally, that is not expected to cause a problem because these APIs are not normally used in models.

The non-template versions of peekAtBack(), popAtBack(), and removeAtBack() in the Packet class has been changed to require the length parameter. The reason being that deserialization is only supported forwards, so there's no way of knowing the length when a raw packet is used.

This change may result in compilation errors in existing code.

5. IEEE 802.11 (WiFi)

The IEEE 802.11 model has been changed to have explicit modules for both the PendingQueue and the InProgressFrames. Futhermore, several submodules of the Hcf module have been moved to the Edcaf module to better reflect their usage.

Throughout the 802.11 model has also been extended with several new signals and statistics. The ACK handling mechanism in QoS mode has been fixed.

Several parts of the IEEE 802.11 frame have been renamed to be consistent with the naming scheme:

   Ieee80211DataFrame -> Ieee80211DataHeader
   Ieee80211DataOrMgmtFrame -> Ieee80211DataOrMgmtHeader
   Ieee80211ManagementHeader -> Ieee80211MgmtHeader
   Ieee80211ManagementFrame -> Ieee80211MgmtFrame
   Ieee80211Frame -> Ieee80211MacHeader
   Ieee80211OneAddressFrame -> Ieee80211OneAddressHeader
   Ieee80211TwoAddressFrame -> Ieee80211TwoAddressHeader
   Ieee80211ACKFrame -> Ieee80211AckFrame
   Ieee80211RTSFrame -> Ieee80211RtsFrame
   Ieee80211CTSFrame -> Ieee80211CtsFrame

Most simulations are not affected, because the external interface of the 802.11 MAC has not been changed. Nevertheless, simulations which go deeper in the direct parameterization of the 802.11 MAC submodules have to be updated.

6. Transmission medium

The storage mechanism of radios and transmissions has been moved from the radio medium module to the communication cache submodule. This allows the usage of different strategies for different kinds of networks. For example, a dynamic network where radios are created and destroyed dynamically can have better performance with a non-default mechanism.

This change results in compilation errors if the underlying C++ interfaces were implemented in user code.

7. Various renames

The carrierFrequency parameters have been renamed to centerFrequency in several modules where they were named incorrectly.

With the addition of the new Ospfv3 implementation, the old OSPF implementation has been renamed from Ospf to Ospfv2.

These changes may require updating the affected simulations.

Notable backward compatible changes

1. OSPF version 3

A new OSPF protocol implementation has been added which implements version 3 of the protocol. This feature is a contribution of Lukáš Galbička and Marcel Marek.

2. TCP/IP ECN

The TCP/IP model has been extended with partial support for Explicit Congestion Notification (ECN). This feature is a contribution of Marcel Marek and Mohammad HabibAllah.

3. TTL and ToS in sockets

The UDP and TCP socket options have been extended with time-to-live and type-of-service parameters. This feature is a contribution of Mani Amoozadeh.

4. Packet API

The Packet API has also been extended with a PF_ALLOW_EMPTY flag to support returning Empty chunks. This feature makes certain algorithms easier to write, because the user doesn't have to check for nullptr all over the place.

The PacketDissector::ICallback interface has been extended with a new callback called shouldDissectProtocolDataUnit() for the possibility to stop dissection for performance reasons.

5. Physical layer components

The physical layer dimensional model has been extended with a new NoiseSource and a new DimensionalBackgroundNoise module. The former is capable of generating noise periodically as a point source with optional mobility. The latter can be used to describe a non-isotropic background noise which changes over time and frequency.

6. Visualization of radio signals

The MediumCanvasVisualizer has been extended with the visualization of signal power spectrums, signal power spectrograms, and signal power maps. Spectrum figures display signal power density over frequency at a given position and moment of time. Spectogram figures display signal power density over time and frequency at a given position. Power map figures display signal power density over space at a given frequency and moment of time.

All three kinds of figures can be used to display a particular signal or the total power density of transmission medium. The new visualization is also capable of displaying the above for the currently transmitted or received signal automatically while simultaneously comparing it to the total interfering signals and noise using color coding. The visualization takes into account the directional selectivity of radio antennas.

A new "network node", called the Probe, allows the visualization of the total transmission medium power spectral density at any given location. The latest Qtenv supports dragging network nodes with Shift + left mouse click. This feature effectively allows the user to explore power spectral density in space by simply dragging a probe node.

See the following example videos:
https://www.youtube.com/watch?v=oyjX03MSi7s
https://www.youtube.com/watch?v=Oi1sq23IPYs
https://www.youtube.com...

INET 4.1.2

• Fixes to build with OMNeT++ 6.0 Preview 5

INET 3.6.7

This release contains a compatibility fix to be able to build INET with OMNeT++ 6.0 Preview 5. It requires OMNeT++ 5.5.1 or later.

INET 3.6.6

Minor fixes for Windows build related issues.

INET 4.1.1

This patch release contains only a minor change compared to INET 4.1 that allows it to be compiled with OMNeT++ 5.5.1 and 6.0 preview.