INET 4.0 Released
Rudolf Hornig
Dear INET Users,
we are very happy to announce the new 4.0 release of the INET Framework. This release is the culmination of more than 2 years of work where we have heavily refactored the architecture of the INET Framework. We feel, that the internals of INET are now much better organized, more expandable and usable. We invite you to download and use the new INET Framework for your new projects and we actively encourage all current projects to migrate to the new version. We are here to help you with your migration tasks. Admittedly, migration is not trivial, but there’s an ‘INET 4.0 Migration Guide’ to help with the task under the ‘doc/misc’ folder.
With the new INET 4.0 release, the development of the old INET 3.x branch is stopped. In the code repository, the master branch has been moved and now tracks the 4.x code base (which previously was tracked by the integration branch) and the old 3.x code is available now on the v3.x branch. The integration branch will cease to exist and will be deleted soon.
In addition to the new code base, we have spent a lot of time with creating new tutorials and examples (and even more is coming soon... We encourage everyone to join this effort.) The documentation of the INET Framework has been updated, too. You can access the rewritten User's Guide (for causal INET users) and the Developer's Guide (for model developers) on the web. In the future, we plan to merge all INET related documentation into a single website for better navigation and accessibility.
The main changes of the new INET 4.0 major stable release are:
Packet API
The INET Packet API has been completely redesigned to supports efficient construction, sharing, duplication, encapsulation, aggregation, fragmentation, and serialization of packets.
The new Packet API also adds many other useful features such as a detailed packet printer, a packet dissector, a packet filter based on packet data, packet tags for cross-layer communication, region tags for attaching metadata to packet data, and queuing and buffering packet data.
The new Packet API also makes implementing communication protocols easier. The resulting code looks more similar to the real world implementation. Supporting emulation is pretty much trivial when implementing communication protocols.
For more details on how to use the new Packet API, see the ‘INET Developer’s Guide’.
Network node architecture
The internal structure of network nodes has been changed considerably. With the new architecture, applications can directly talk to any protocol down to the link layer, and protocols don’t have to deal with dispatching packets and commands to other protocols. Cross-layer communication is directly supported in both downward and upward directions.
For more details on how to use the new architecture, see the ‘INET User’s Guide’.
Documentation
The somewhat outdated ‘INET Framework for OMNeT++ Manual’ has been reworked and split into the ‘INET User’s Guide’ and ‘INET Developer’s Guide’. Several new detailed showcases have been added and many have been updated, they are available on the INET website.
Socket API
The Socket API has been redesigned and uniformized. All sockets can be used with similar callback interfaces. All callback functions receive the socket object as a parameter to allow handling multiple sockets concurrently.
New raw Ipv4Socket and Ipv6Socket classes have been added to directly access the IPv4 and IPv6 protocols from applications.
Module type parameters
All string NED module parameters, which were used to specify submodule types, have been replaced with the standard OMNeT++ typename parameter. This reduces the confusion caused by having two different configuration options for the same task. The typename parameter is also simpler and more generic in the sense that it allows configuring the module type for submodule vector elements.
The replacement of the EthernetInterface queueType and the Ieee80211Interface agentType parameters requires the applications which use them to be updated. The queueType parameter had effect on the dataQueueType of the EtherQosQueue, which is no longer true. The agentType parameter depended on the mgmtType parameter, which is also no longer true. These parameters must be set separately.
NED units
With the new OMNeT++ 5.4 release, INET supports the automatic conversion of non-linear units such as dBm, dBW to W, dB to ratio, etc. All 0/0 and +-1/0 parameter value assignments have been replaced with nan and +-inf respectively.
Various renames
Renamed several modules, submodules, classes, interfaces, etc. to be consistent with the INET naming conventions:
- GenericNetworkProtocol module -> NextHopForwarding
- generic folder -> nexthop
- gnp submodule -> nextHop
- InterfaceEntry get/setNextHopProtocolData functions -> get/setNextHopData
- Protocol::gnp global variable -> Protocol::nextHopForwarding
NextHopDatagram class -> NextHopForwardingHeader
- RsvpRouter module -> RsvpMplsRouter
- LdpRouter module -> LdpMplsRouter
- Rsvp module -> RsvpTe.
- rsvp_te folder -> rsvpte
- Protoco::rsvp global variable -> rsvpte.
Packet error representation
The physical layer error models have been extended with a corruption mode parameter. The available corruption modes are: packet, chunk, byte, or bit level. The parameter determines on what level the error model introduces errors into a packet.
In many protocols, various corruption modes don’t lead to different outcome. Nevertheless, this change allows implementing IEEE 802.11 A-MPDU aggregation with support to only dropping the individual subframes which are received incorrectly.
IEEE 802.11
Thanks to Alfonso Ariza Quintana, the 802.11/ac (VHT PHY) modes have been added to physical layer. Futhermore, the necessary 5GHz bands with 20, 40, 80, and 160 Mhz bandwidth have also been added.
The 802.11 mode lookup mechanism has been extended with bandwidth and number of spatial streams parameters, and the mechanism has also been relaxed to allow specifying more already supported bitrates (e.g. 86.7 Mbps with 0.1 Mbps precision).
Fixed bug when a packet was received from another Ap and sent up incorrectly. Fixed ACK frame duration bug reported by Raphael Elsner. Fixed exploded frame transmitter address in MsduDeaggregation. Fixed length field wrap around for large packets. Fixed center frequency calculation in Ieee80211ArithmeticalBand.
Emulation
The whole emulation support, including the ExternalInterface compound module, the Ext simple module, and the corresponding cSocketRtScheduler have been redesigned and heavily refactored. The new C++ scheduler class is called RealTimeScheduler and it is completely independent of the external interfaces.
The new scheduler still provides real time simulation execution, but it also allows for using the POSIX select mechanism to support I/O operations with file descriptors. The external interface hooks into this mechanism to read raw packets via PCAP. Futhermore, the new external interface implementation uses dedicated raw sockets to send packets.
Lifecycle and scenario management
The LifecycleController module has been removed because the module did not have and is not expected to have any parameters in the future. Therefore the LifecycleController module is no longer needed in the network for the lifecycle operations to work. The corresponding LifecycleController C++ class with the actual functionality remains there.
The ScenarioManager scripting has been extended with the following shortcuts for the lifecycle operations: <shutdown module="hostA"/>, <startup module="hostA"/>, <crash module="hostA"/>
RIP
Thanks to the contributions of Mani Amoozadeh the RIP protocol has been refactored to store the protocol specific route data in the routing table instead of an internal data structure. The protocol has also been extended with new hold-down timer and triggered update parameters.
Fixed sending updates on interface which is down.
Other notable changes
- The Ethernet model has been extended with 200 Gbit and 400 Gbit modes.
- The antenna directional selectivity computation in wireless medium analog models has been fixed.
- Several missing protocol dissectors and protocol printers have been added.
- All protocol specific header serializers have been moved to the folder of their respective communication protocol.
- In order to support more recent OSG Earth versions, the osgEarth::ObjectLocatorNode has been replaced with GeoTransform and osg::PositionAttitudeTransform.
- We now have a setenv script in the root of the inet folder that must be sourced with '. setenv' (just like with omnet++). After sourcing that script you can start any examples by going into the examples folder and simply typing inet or inet_debug.
- The default directory name for the project is now inet4 to avoid collision with older INET 3.x based projects.