forked from inet-framework/inet
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathWHATSNEW
4443 lines (3305 loc) · 198 KB
/
WHATSNEW
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Recent changes in the INET Framework
====================================
INET-4.3 (January 2021) - Stable
---------------------------------
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 are the following:
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 name
didn't capture this fact. Also, in several protocol implementations deriving
classes from the classes with the original names looked really weird.
All integral C++ type alias have been replaced with the standard variants.
For example, the int64 type alias has been replaced with int64_t.
These changes mostly result in NED errors and C++ compilation errors in the
simulation models which are affected, and they are easy to follow.
11. Removed models
The NetAnimTrace module has been removed. The visualization functionality it
provided has been replaced with the much more versatile and feature rich
visualizer modules.
The PacketDump class, which was used to provide a very basic human readable
string representation of the packet content, has been removed. The packet
printer API is a much more versatile and widely parameterizable way of
printing packets, and there's no reason to have two different ways of doing
the same thing.
The EtherBus module has been removed because it has been completely replaced
with the generic WireJunction module.
The Ieee8021qEncap module has been removed. This module was used in the Ethernet
network interfaces to provide IEEE 802.1q protocol support and VLAN networking.
These changes break existing simulation models with a compile time or runtime
error.
Notable backward compatible changes are the following:
1. Packet API
The Packet API has been extended with several new replace and update methods.
The replace methods allow replacing arbitrary parts of the packet content with
a single method call. The update methods allow updating arbitrary parts of the
packet content in place with a single method call. Similarly to the completeness
of these methods, the remove and insert methods have also been further extended.
Moreover, the Packet API has been extended with a packet level region tag
support. This allows attaching region tags to the data of packets similarly
to how chunks already allowed this. The main difference is that when data
is attached to chunks, then it must be in a form that can be shared among
multiple packets which share the same chunk throughout the network. For
example, the creation timestamp of coherent data fragments is such a data.
In contrast, the queueing time of coherent data fragments belongs to the
individual packets, and must be separately updated for different paths the
same data takes in the network.
The chunk API has been extended with a bit-level identity tracking of data.
In other words, it is now possible to determine if the data that shows up at
two different locations in the network, independently of whether these locations
are in the same network node or not, and also independently of how the data
is represented (field-based or binary), is the same data or not. This feature,
for example, is useful for end-to-end delay measurements and more accurate
path visualization.
A new chunk class, called EncryptedChunk, has been added to allow storing
encrypted data in a packet without actually encrypting the data. Internally,
the new chunk uses a shared reference to the encrypted chunk and the length
of the encrypted binary representation.
Efficient parsim support has been added to all classes of the Packet API,
including the Packet class itself, all chunk classes, and all tags.
The PacketProtocolTag has been extended with an extra front and back offset
that further specifies where the actual protocol is to be found within the
packet data. This feature is primarily useful to keep the associated protocol
of the packet up to date even while the packet is being constructed within a
protocol module. Doing so allows the packet printer and packet dissector to
understand a partially encapsulated, incomplete packet.
2. Clock model
Several new modules have been added to support the modeling of hardware clocks
and the related clock drift phenomena. The new modules can be found in a new
top level folder called clock. The clock model is an optional feature that
can be most conveniently used via the ClockUserModuleBase and ClockUserModuleMixin
classes.
Several modules have been extended with optional clock support: UdpBasicApp,
InterpacketGapInserter, TransmitterBase, PeriodicGate, etc. This feature has
been documented in the User's Guide.
3. Ethernet
A completely new modular Ethernet model has been added to the linklayer and
physicallayer folders. The three most prominent new features that are directly
supported are the Ethernet frame preemption, Ethernet cut-through switching,
and the gating mechanism in the Ethernet queues.
The new model contains of several smaller modules that allow the user to
combine them in more ways than before and also to customize their behavior.
The main purpose of this change was to provide support for Ethernet
Time-Sensitive Networking (TSN) features.
Following the changes in the OMNeT++ cDatarateChannel API, both existing
Ethernet MAC models that used the old forceTransmissionFinishTime() API have
been updated to use the new transmission update mechanism instead.
4. PPP
Similarly to the change in the Ethernet model, the PPP protocol implementation
has been changed to use the new transmission update API in place of the old
forceTransmissionFinishTime().
5. TCP
A new congestion control algorithm, called DCTCP, has been added by Marcel
Marek. Also, related to this change, the ECN support has been enhanced to be
customizable by congestion control algorithms.
6. Enhanced Interior Gateway Routing Protocol (EIGRP)
A new model of the routing protocol EIGRP with support for IPv4 and IPv6 has
been ported from ANSAINET 3.4.0 to INET. This is a large addition that adds a
lot of modules, some new network node types, and it also comes with several new
examples.
This model was contributed by Vladimir Vesely, Jan Bloudicek, Vit Rek, and Jan
Zavrel from the Brno University of Technology.
7. Packet flows and timing measurements
The concept of packet flows has been added to provide support for advanced timing
measurements. A packet flow is a logical classification of packets, identified
by a name, over the whole network and over the duration of the whole simulation.
Packets may have a PacketFlow tag attached to a region of data which describes
flow membership.
This feature allows making timing measurements between two or more arbitrary
end points in the network. The measurement can separate queueing time, processing
time, propagation time, transmission time, etc. on a per-bit basis efficiently.
It is also possible to collect all packet events (e.g queueing, processing,
transmission, propagation) and do arbitrary computations again on a per-bit
basis. This feature is provided by the FlowMeasurementStarter and FlowMeasurementRecorder
modules. The measurement data are collected on packets in various time tags
(e.g. QueueingTimeTag), which are updated by all related modules (e.g. PacketQueue).
8. Queueing model
The synchronous packet processing API has been extended with the support of
packet streaming between modules. This feature allows two modules within the
same network node to communicate synchronously (without sending asynchronous
messages) and process a packet bit by bit over a nonzero amount of time. The
related methods are called pushPacketStart(), pushPacketEnd(), pushPacketProgress(),
pullPacketStart(), pullPacketEnd(), and pullPacketProgress().
Several queueing model base classes have been refined and somewhat refactored
in order to better support the new feature. Also, many queueing model elements
have been extended with direct packet streaming support.
A few new queueing model elements have also been added that provide support
for the gating mechanism of Time-Sensitive Networking and for the preemption
mechanism of Ethernet. Some notable examples are PacketGate, PeriodicGate,
PreemptingServer, PreemptableStreamer, etc.
9. PCAP
The PCAP support has been extended with the more modern PCAPng file format.
This is the new default output file format for the PcapRecorder module. The
support for recording PCAP files has been extended to the network, network
node, and network interface level. The new format allows recording the network
interface and packet direction (outbound/inbound) for frames and also supports
mixing packet formats, making it possible to record the traffic of potentially
the whole network into a single file.
10. Socket processing
Several new modular socket command and packet processing components have been
added for Ethernet and IEEE 802.2 LLC protocols. There are modules for handling
the opening, configuration, and closing commands for sockets, others for maintaining
a table of open sockets (which can also be inspected in the runtime user interface),
and some for processing and duplicating the incoming packets for all open sockets.
11. Protocol elements library
Many small generic and reusable protocol implementation support components
have been added. These components include, among others, generic components for
packet fragmentation and defragmentation, aggregation and deaggregation, CRC and
FCS insertion and checking, and physical layer wired transmitter and receiver
models.
12. Visualizer
A new packet flow visualizer has been added, called PacketFlowCanvasVisualizer
and its OSG variant PacketFlowOsgVisualizer. They have also been included in
the integrated visualizer modules. The new visualizers display the packet flow
paths as polylines along with some basic statistics. This visualizer relies on
the newly introduced packet flow concept.
The spectrum and spectrogram visualization of the MediumCanvasVisualizer has
been further enhanced with better options and a more efficient implementation.
13. Printing formatted output
Support for producing formatted log output has been added with the new EV_FIELD
and other EV_ macros. The default str() method in several Packet API classes
(e.g. Packet, various Chunks, Signal) have been enhanced to provide better
textual representation in the log.
The IPrintableObject C++ interface has been moved to the common folder. It
has also been extended with template support for printing objects without
having to repeat a lot of code and with using the default shift operator.
14. Features (.oppfeatures):
Several new OMNeT++ features have been added and some old features have been
split. These changes can be found in the IDE on the INET project properties:
- Clock
- Clock examples
- EIGRP routing
- EIGRP routing examples
- Emulation showcase
- IEEE 802.1ae
- IEEE 802.1q
- IEEE 802.2
- Internet protocol examples
- Open MP support
- Physical layer common
- Physical layer wired common
- Physical layer wireless common
- Protocol support
- Protocol tutorial
- Queueing library
- Queueing tutorial
- Unit disk radio
- Virtual interface
- Visualization OSG (3D)
- Visualization OSG (3D) showcases
- Visualization canvas (2D)
- Visualization canvas (2D) showcases
- Visualization common
- Wireless noise source
15. Examples
Several new examples have been added:
- clock drift
- Ethernet frame preemption
- Ethernet cut-through switching
- gating mechanism in Ethernet queueing
- modular Ethernet interface
- DCTCP congestion algorithm
- timing measurement along packet flows
- video streaming using network emulation
- signal power spectral density visualization
A few examples have been substantially changed to follow other changes:
- IEEE 802.1d
- virtual LAN
16. Testing
The fingerprint testing script has been extended with support for computing
multiple different fingerprints and a separate fingerprint calculator option.
The updated fingerprint tests contain four separate fingerprint values for
each example simulation:
- detailed model behavior
- complete network byte order packet data and timing at the network level
- complete network packet length and timing at the network level
- graphics in the runtime user interface.
Several new fingerprint, module, and unit tests have been added for the new
clock model, the protocol support modules, and the new formatted output.
17. Documentation
A new chapter about the newly added clock model has been added to the User's
Guide. The Collecting Results chapter has been completed and also extended
with a new section that describes how to do timing measurements along packet
flows. The queueing model and emulation chapters of the User's Guide has been
updated to reflect the changes in the queueing model of this release.
18. Bug fixes
A bug in the TCP Nagle's algorithm has been fixed, see #558.
A bug related to using the latest avcodec libraries (e.g. Ubuntu 20.10) in
the VoIP streaming applications has been fixed.
The C++ numeric type selection/promotion support for unit specific binary
operators has been fixed to follow what C++ does with the standard types.
19. Code cleanup and formatting
The whole source tree has been cleaned up with respect to C++ code formatting,
indentation, header guards, whitespace, and so on. Moreover, all copyright
headers in the C++ source files have been updated to use the official GPL-2
and GPL-3 formats as suggested.
All markers (TBD, XXX, etc.) in the source code has been unified to use one
of the standard TODO, FIXME, and KLUDGE markers. These have well-defined
meaning and it makes finding them easier.
20. Other notable changes
A few new multi-dimensional mathematical functions have been added that can
be useful to represent signal power density in the physical layer. These new
functions are the Rasterized2DFunction, PeriodicallyInterpolated2DFunction,
LeftCurryingFunction and RightCurryingFunction.
In several places the std::min and std::max calls have been replaced with
inet::minnan, inet::maxnan that properly propagate NaN values.
The IProtocolRegistrationListener interfaces have been extended to allow
registering a protocol group or any protocol as a fallback for a service or
protocol available at a module gate.
A new OperationalMixin template base class has been added that allows using
the same behavior as the OperationBase where it was not applicable due to
it having a specific base class.
Several network base NED modules (NetworkBase, WiredNetworkBase, WirelessNetworkBase,
Ieee80211NetworkBase) have been added to support easier use of the typical
configurator, radio medium, visualizer, etc. network level submodules.
The module initialization stages have been extended with INITSTAGE_CLOCK and
INITSTAGE_NETWORK_LAYER_PROTOCOLS.
Several automatic weak shared module pointers have been added to so simplify
direct cross module communication via C++ method calls. The added classes are
called ModuleRef, ModuleRefByGate, and ModuleRefByParameter.
A new generic C++ compound module class has been added, called OmittedModule,
which allows optional submodules to be easily omitted by the user via INI
file parameters without unnecessarily complicating the parent compound module
structure with several conditionals due to optional connections.
Several packet serializers have been extended to be more complete in terms of
being able to serialize packets into network byte order. Most notable changes
are in the Ipv6HeaderSerializer, and the DsdvHelloSerializer.
The INET specific FingerprintCalculator class has been refactored and made
official. This fingerprint calculator supports computing a fingerprint that
contains all packet data and timestamps on the network.
The usage of transmissionStarted, transmissionEnded and receptionStarted,
receptionEnded signals have been extended to the new wired physical layer
models.
Many models have been updated to use the new scheduleAfter(), rescheduleAt(),
and rescheduleAfter() methods that were introduced in the OMNeT++ API.
The generic MessageDispatcher has been extended to support the new packet
streaming API. It has also been enhanced to have better circular connection
detection and error reporting.
All Enter_Method_Silent() calls have been replaced with Enter_Method() because
Qtenv has been extended with filter expressions for the method call animation,
which provides a better control.
INET-4.2 (January 2020) - Stable
--------------------------------
This is a new minor stable release of the INET 4.x branch. 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 are the following:
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 synax is more expressive and more user
friendly. The changed interpretation of these NED parameters will cause
an error in existing simultations 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. Variuos 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 are the following:
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/watch?v=TyYQ53hUrns
7. Visualization of street maps
The new OpenStreetMapSceneCanvasVisualizer allows displaying an arbitrary
street map file created by OpenStreetMap as the background of a compound
module. The configuration is simple: the visualizer takes the map filename
parameter and the geographic coordinate system takes longitude/latitude
parameters to specify the origin of the scene.
8. Applications parameterized with traffic generators
New generic TCP and UDP applications such as UdpApp, TcpClientApp, TcpServerApp
have been added with composable traffic source and traffic sink components.
One can implement new behavior by assembling queueing elements. For example,
new applications can be easily set up to simulate request-response based
client-server applications (see TcpRequestResponseApp), or a remote terminal
(see TelnetClientApp/TelnetServerApp).
9. Module initialization
A new named initialization stage, called INITSTAGE_ROUTER_ID_ASSIGNMENT, has
been added. The configuration of the router ID has been moved to this stage.
10. Packet serialization and emulation
New chunk serializers have been added for several protocols. Changed several
protocol field types and names in MSG files to be more correct. Fixed and
refactored CRC calculation, CRC mode parameters and handling, CRC insertion
and verification. Of course, the exact CRC calculation and verification are
still optional due to performance reasons.
These changes make the emulation support more feature complete. Most of the
example simulations are expected to work with serialized packets too. This
can be simply tested by running the fingerprint tests with the sendRawBytes
parameters of network interfaces set to true.
11. Regression testing with fingerprint calculation
A special fingerprint calculator (NetworkCommunicationFingerprintCalculator)
has been added, which is capable of computing a simulation fingerprint using
the timing and binary contents of packets sent between network nodes. This
feature allows easier regression testing for some simulation models if the
exchanged packets are expected to stay the same. This kind of fingerprint
ignores all internal details of how the network nodes operate.
12. Documentation
The User's Guide has been extended with a new chapter on the newly added
queueing package. It has also been updated with respect to the new generic
applications.
A new queueing model tutorial has been added. This tutorial contains very
minimal explanation, it is rather provided to give a quick glance.
The tutorial is available at:
https://inet.omnetpp.org/docs/tutorials/queueing/doc
13. Other minor changes
Module shutdown operation has been refactored and extended in simulation
time to allow for graceful closing of TCP connections.
PCAP recording has been enhanced with automatic network type detection and
optional packet conversion.
New PRE and POST module initialization signals have been added for dynamic
module creation.
A new WeightedHistogramRecorder has been added which records histograms using
weighted double values.
The packet inspector has been enchanced to display the front, back, and data
parts of packets separately in Qtenv. Furthermore, packet tags and data tags
are also displayed in children mode.
All applications have been extended for CreationTimeTag to calculate end-to-end delay.
Several applications have been extended with ToS and DSCP parameters.
The ManetRouter has been extended with a parameterizable routingApp submodule.
The InterfaceEntry module base has been added to all interface modules.
The MAC protocol base classes have been merged into one.
Extended the <disconnect> and <set-channel-param> commands in ScenarioManager.
Added OpenMP support to allow parallel computation for physical signal visualization.
Added notifications about changing the InterfaceProtocolData set to InterfaceEntry.
Added TcpSocket::ReceiveQueueBasedCallback to make writing applications easier.
Fixed small packet and chunk length discrepancies in several protocols.
Fixed TCP SACK rexmit queue inconsistency by Luca Giacomoni.
Fixed several memory leaks.
Numerous other bug fixes and small improvements.
INET-4.1 (January 2019) - Stable
---------------------------------
This is a new minor stable release of the INET 4.x branch. It comes with some
backward incompatile changes, a few new features, a number of smaller improvements,
and many bug fixes. This version requires OMNeT++ 5.4.1 or later.
The backward incompatible changes are the following:
1. The module initialization stages have been refactored. All stages with numbers
in their names (e.g. INITSTAGE_LINK_LAYER_2) have been removed, because their
intended purpose was not clear, and they were often misused. Several new stages
have been added to replace the removed stages. The new stages have names which
express better the specific purposes they are used for (e.g. INITSTAGE_POWER,
INITSTAGE_GROUP_MOBILITY, INITSTAGE_NETWORK_INTERFACE_CONFIGURATION).
This change most likely results in compilation errors in simulation models
which use the affected initialization stages. It may also cause runtime errors
if the stage name has not been changed but its usage is slightly modified.
2. Individual protocol specific data structure fields of InterfaceEntry (e.g. the
ipv4Data field with type Ipv4InterfaceData stores IP address and netmask) have
been removed and replaced with a generic API. The new API allows storing any
number of arbitrary protocol specific data structures in the network interface
similarly to packet tags. All affected protocols have been updated.
This change always results in compilation errors in affected simulation models.
3. The old ExtInterface module (used for emulation) has been split into several
modules. There are separate modules for using simulated network interfaces from
the host OS, and also for using host OS network interfaces from the simulation.
The new external interfaces no longer rely on PCAP, they rather use host OS
raw sockets and TUN/TAP interfaces. Besides ethernet, the new version also
provides IEEE 802.11 network interface emulation. A new external UDP protocol
module is also added, which allows INET applications to be tested unmodified
on real networks using the UDP protocol of the host OS.
This change results in runtime errors in simulations which use the modified
models. Configuration of affected simulations have to be updated.
4. Replaced EulerAngles with Quaternion to represent orientation (and angular
velocity, and angular acceleration) in mobility models to avoid gimbal lock
and ambigous state representation. Euler angles are easy for human consumption
but they are generally considered a bad idea for representing 3D orientation.
This change always results in compilation errors in affected simulation models.
5. Moved MAC address parameters from MAC modules to the corresponding network
interface modules (e.g. EtherMac -> EthernetInterface). The reason is that
MAC address really belongs to the network interface and often management or
other network interface submodules need access to it.
This change results in runtime errors in simulations which use the modified
parameters. Configuration of affected simulations have to be updated.
The backward compatible changes are the following:
6. Many applications have been extended with support for lifecycle operations.
Applications can be started, stopped, and crashed individually using the same
ScenarioManager script which is also used to control the lifecycle operations
of network nodes. These applications also subclass from a common ApplicationBase.
Similarly to applications, network interfaces also support lifecycle operations,
they can be brought down and up using the ScenarioManager.
7. Two new protocol groups (for UDP and TCP) have been added which allow the
identification of application protocols based on port numbers. The application
protocols may not even be implemented in INET, yet they can still be identified
(e.g. when using emulation) and displayed in the Qtenv packet log window.
8. The PacketPrinter has been extended with a new type column which contains
the protocol specific packet type (e.g. ECHO_REQUEST for ICMPv4). The packet
type is contributed by the protocol specific packet printer. This feature helps
understanding packet logs in Qtenv. With the new version, the printer is also
capable of providing a reasonably good enough packet name for packets received
from external sources (e.g. an external network interface during emulation).
9. Modules that provide emulation support have been extended with a new host OS
network namespace parameter. This feature allows, for example, running multiple
linux BABEL daemons in their own network namespaces (with their own routing
tables etc.) and connecting each one to the same simulation which provides
mobility and wireless connectivity. For another example, it allows connecting
multiple docker containers running in separate network namespaces again to
the same simulation. Unfortunately, the network namespace feature is only
available on Linux at the moment.
10. Added two new socket classes, EthernetSocket and Ieee8022LlcSocket, which
allow applications to directly use the link layer protocols on a particular
network interface. For example, an application can send and receive ethernet
frames directly, bypassing network and transport layer protocols.
11. Added IEEE 802.1Q VLAN tag (C tag and S tag) support to ethernet interfaces.
Virtual ethernet networks can be statically configured using ethernet interface
parameters of switches and hosts. Additionally, all network nodes can have
any number of virtual network interfaces which can be configured to request
VLAN tagging. This feature allows using multiple different virtual networks
on the same physical network on a per-application basis.
12. Raphael Riebl contributed support for ether type discrimantion for IEEE 802.11p
networks in the 5.9 GHz band. The new modules provide both IEEE 802.11 EPD and
IEEE 802.11 LPD as required by the standard. The LLC module is automatically
selected based on the opMode and band parameters.
13. Mani Amoozadeh contributed several new features and fixed quite a few bugs
in BGP and OSPF wired routing protocols. Among others, BGP has been updated
related to split horizon, multi-hop EGBP, network interface mode parameters,
packet checksum calculation, packet serialization, and multiple additional
parameters to turn on/off individual protocol features. Similarly, OSPF has
also been updated related to BDR promotion, network interface mode parameters,
packet checksum calculation, and packet serialization. He also validated the
INET models by comparing simulation runs with the CISCO packet tracer tool
for many important use cases.
14. Other notable changes
Updated a few mobility models to provide better parameterization for 3D.
Added ClnsAddress and ClnsAddressType from ANSA project.
Added a new antenna model for rotationally symmetric antenna lobes.
Added linear and logarithmic antenna lobe visualization.
Extended IPv4 network configuration with support for configuring isolated networks.
Fixed several smaller issues related to 802.11 block acknowledgement and QoS recovery procedures.
Numerous other bug fixes and small improvements.
INET-4.0 (June 2018) - Stable
-----------------------------
This is the first stable release of the new INET 4.x branch. All originally
planned tasks have been completed. This version requires OMNeT++ 5.4.1 or later.
With the new INET 4.0 release, the development of the old INET 3.x branch is
stopped. Users are strongly encouraged to use the new INET 4.0 version for new
projects and also for migrating existing projects. Admittably, migration is not
trivial, but there's an 'INET 4.0 Migration Guide' to help with the task under
the 'doc/misc' folder.
The main changes of the new INET 4.0 major stable release are: