-
Notifications
You must be signed in to change notification settings - Fork 519
Expand file tree
/
Copy pathWHATSNEW
More file actions
5611 lines (4172 loc) · 254 KB
/
WHATSNEW
File metadata and controls
5611 lines (4172 loc) · 254 KB
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.6 (February 2026) — feature release
------------------------------------------
This is a new feature release in the INET 4.x branch. Highlights include new
protocol implementations for QUIC, Ethernet 10BASE-T1S, IPsec, and MRP; major
refinements to the clock model; a reimplementation of IEEE 802.1AS (gPTP); and
an important refactoring of the wireless physical layer's analog domain. The
release continues to focus on improving correctness, accuracy, modularity, and
long-term maintainability while addressing several long-standing limitations.
Requires OMNeT++ 6.2 or later.
For the full list of additions, removals, and changes (features, modules, packet
chunks/tags, signals, statistics, and C++ classes), see ChangeLog in the src
folder.
For further questions, detailed explanations, and guided exploration of INET
concepts and features, a dedicated AI-powered wiki is now available at
https://deepwiki.com/inet-framework/inet
Notable backward-incompatible changes include the following:
1. Clock model refinement
The clock and oscillator models were substantially reworked to improve
accuracy, correctness, and robustness. Clock time to simulation time mapping
and clock-interval to oscillator-tick conversions were rewritten for
mathematical correctness, with stricter consistency checks. Accuracy was
improved using precise arithmetic and new scaling utilities (e.g.,
NumberNear1 and SimTimeScale). The design anticipates future 128-bit
simulation time support.
The updated model now accumulates fractional oscillator compensation for more
accurate timing. The clock's nominal tick interval must be explicitly
configured, as it no longer defaults to the simulation time resolution. The
drifting oscillator model was extended with a configurable frequency
compensation factor, distinct from the clock's step-based compensation
mechanism.
The architecture was modularized to allow multiple clocks to share a single
physical oscillator via the clock's oscillatorModule parameter. SettableClock
now includes an underlying free-running clock submodule to support
simulations that mix synchronized and unsynchronized time. A clock servo
model was added, including the IClockServo module interface and the
StepClockServo module for implementation.
Clock event handling was also refined: overdue events are now processed
immediately, in clock-time order, and newly scheduled events are inserted at
the lower bound of the corresponding simulation-time interval, preserving
stable ordering. Clock time to simulation time conversion methods now accept
explicit lower-bound arguments to ensure robust tie-breaking between adjacent
ticks.
Clock and oscillator documentation was significantly expanded and formalized
to reflect the stricter semantics of the new implementation.
This change is backward incompatible in that clock-based simulations may
produce slightly different statistical results due to the improved
correctness and accuracy of the model.
2. IEEE 802.1AS (gPTP) protocol reimplementation
Large parts of the protocol were reimplemented using formal state machines
for both peer delay measurement and time synchronization. Standards
conformance was improved, including correct handling of grandmaster and
neighbor rate ratios. The peer delay and time synchronization processes now
maintain separate state for requester/responder and sender/receiver roles.
The new model introduces a dedicated clock servo submodule for updating local
time. Peer delay measurements now use an exponential moving average for
improved stability and are performed using the unsynchronized local clock to
avoid interference during active time synchronization.
For improved standards compliance, message timestamping now occurs at
transmission start and reception start rather than at completion. As a
result, simulations must use physical layer modules that emit explicit
start-of-transmission and start-of-reception signals, such as the
StreamingTransmitter and DestreamingReceiver modules.
Due to the high precision required for time synchronization, accurately
modeling a 1 ppm clock drift with a nominal 10 ns tick interval requires very
fine time granularity. gPTP simulations therefore typically require
femtosecond (fs) simulation time resolution, which can be enabled via the
simtime-resolution configuration option.
This change is backward incompatible in that simulations using gPTP may
produce slightly different statistical results due to the improved
correctness and accuracy of the model.
3. Ethernet module renames
Existing Ethernet MAC modules were renamed to use the MacPhy suffix (e.g.
EthernetMacPhy, EthernetCsmaMacPhy) to reflect that they combine MAC and PHY
functionality in a single module. This resolves naming conflicts introduced
by the new dedicated EthernetCsmaMac and EthernetCsmaPhy modules, which
provide a modern, state-machine-based implementation of the individual layers
and are primarily used by the new Ethernet 10BASE-T1S model.
These changes are backward incompatible for simulations that directly
reference the old module names.
4. Wireless physical layer refactoring
The wireless physical layer was significantly refactored to simplify how the
analog representation of radio signals is selected. Instead of using separate
module types, radio and medium modules now use a signalAnalogRepresentation
parameter (unitDisk, scalar, or dimensional) to control their behavior.
Responsibility for computing reception success was partially moved from
receiver modules to their analog model submodules. To reflect broader
applicability, much of the former UnitDisk-specific implementation was
replaced by generic components, resulting in modules such as GenericRadio,
GenericTransmitter, and GenericReceiver, while UnitDisk remains available as
an analog domain representation.
Specific wireless technologies, including IEEE 802.11, IEEE 802.15.4, and
APSK, were refactored to align with the new architecture and can now be used
with the unitDisk signal analog representation.
5. CRC, FCS, and Checksum
Frame Check Sequence (FCS) is now used consistently for link-layer protocols
(e.g. Ethernet, IEEE 802.11), replacing the generic CRC terminology.
Accordingly, crcMode parameters in MAC and radio modules were renamed to
fcsMode. In the TCP/IP stack, the term checksum is now used explicitly for
16-bit one’s-complement sums, and crcMode was renamed to checksumMode.
The underlying implementations were modernized as well. New algorithms
(CRC32C, CRC16-IBM, CRC16-CCITT) were added, generic and configurable CRC
utilities were introduced, and protocol-specific handling was improved—most
notably, SCTP now uses a dedicated CRC32C implementation. These changes
improve standards compliance, verification reliability, and flexibility while
preserving existing behavior by default.
Note that these changes are backward incompatible for simulations that
explicitly configure the old crcMode or fcsMode parameters.
Notable backward compatible changes are the following:
1. 10BASE-T1S Ethernet physical layer
A 10BASE-T1S Ethernet model was added, implementing Physical Layer Collision
Avoidance (PLCA) in accordance with IEEE 802.3cg. The PLCA Reconciliation
Sublayer provides deterministic access to the shared medium by assigning
transmit opportunities (TOs) to nodes in a round-robin manner, effectively
eliminating the collisions typical of CSMA/CD and enabling efficient
half-duplex communication.
Unlike traditional point-to-point Ethernet topologies, 10BASE-T1S supports a
multidrop bus (mixing segment) in which multiple nodes can be daisy-chained
on a single twisted pair without a switch. The model introduces new modules
such as EthernetCsmaMac, EthernetPlca, and EthernetCsmaPhy; users should use
EthernetPlcaNode for hosts, EthernetPlcaInterface for network interfaces, and
EthernetMultidropLink for connectivity.
Several example simulations were added to demonstrate the new functionality.
The 10BASE-T1S protocol implementation was contributed by a generous industry
partner.
2. QUIC transport protocol
An implementation of the QUIC transport protocol was added, designed to be
structurally modular, and suitable for performance and protocol-level
experimentation. It models connection-oriented QUIC over UDP with explicit
connection and socket management, supports the full handshake including 0-RTT
connection establishment, and provides stream-based data transfer with
configurable per-stream and connection-level flow control.
The model includes congestion control with selectable algorithms (e.g.
NewReno), loss detection and retransmission with correct handling of
ACK-eliciting and non-ACK-eliciting frames, and Path MTU Discovery with
optional DPLPMTUD and ICMP Packet Too Big processing. It ensures correct byte
ordering and in-order delivery, uses randomized initial destination
connection IDs with robust lifecycle management, and supports clean
connection teardown with explicit close handling and delayed destruction
after CONNECTION_CLOSE.
Validation simulations are integrated into the fingerprint and validation
test framework. Overall, the QUIC model provides a solid and extensible
foundation for simulating modern UDP-based transport protocols and for
comparing their behavior against TCP under controlled conditions.
The QUIC protocol implementation was contributed by Timo Völker.
3. IPsec protocol
The IPv4 model was extended with a comprehensive IPsec implementation to
support secure network communication. The model supports both Authentication
Header (AH) and Encapsulating Security Payload (ESP), with an emphasis on
standards compliance, including correct AH header lengths and proper
placement of ESP trailers within encrypted payloads.
The implementation supports UDP traffic and multicast communication, enabling
a wide range of secured network scenarios. It also includes protocol-specific
packet dissectors and packet printers to allow inspection and analysis of
protected traffic.
The IPsec protocol implementation was contributed by Marcel Marek.
4. Media Redundancy Protocol (MRP)
Media Redundancy Protocol (MRP) was added to provide high-availability
Ethernet ring redundancy. It improves network reliability by managing
redundant paths in ring topologies, preventing loops, and enabling fast
recovery after link failures.
The EthernetSwitch module now includes MRP components such as the core
protocol logic, redundancy-aware forwarding, a specialized MAC forwarding
table, and support for interconnecting multiple rings or redundant segments.
The implementation follows the relevant standards, using a specific multicast
MAC address for protocol communication and supporting all major MRP message
types for topology monitoring and change detection.
Additional signals and statistics were added to improve observability, and
the implementation was validated under extreme conditions (e.g. very high
packet error rates) to ensure robust recovery behavior.
The MRP protocol implementation was contributed by Daniel Zeitler
5. TCP auto-read mode
The TCP modules were extended with an explicit read mode to support proper
TCP flow control. Previously, all TCP sockets operated in auto-read mode,
where received data was immediately delivered to the application, effectively
disabling flow control.
When explicit read mode is enabled by setting autoRead to false in
TcpOpenCommand, applications must issue read requests, similar to real socket
read() calls. TCP then delivers buffered or newly arrived data up to a
specified byte limit, reducing the advertised window as data arrives and
increasing it again only when buffer space is freed by read requests.
Auto-read mode remains the default for backward compatibility and continues
to advertise the full configured window.
Read requests are represented by TcpReadCommand, and a new request may be
issued only after the previous one has been satisfied. In addition, delivery
of the TCP_I_PEER_CLOSED indication after a FIN is now delayed until all
buffered data has been read by the application.
6. AODV gateway
AODV has been extended to support routing toward external IP networks via a
statically configured gateway. By defining the new gatewayAddress parameter,
nodes can now handle traffic destined for external addresses by automatically
initiating route discovery for the specified gateway. Once the route to the
gateway is discovered, external packets are queued and forwarded accordingly.
A showcase was added demonstrating AODV support for routing traffic to
external networks via a statically configured gateway, featuring a wireless
ad hoc network communicating with a wired Ethernet host through a gateway
router.
7. GPSR multiple network interfaces
The GPSR (Greedy Perimeter Stateless Routing) protocol was updated to support
simultaneous use of multiple network interfaces, with refactored logic and
data structures to track neighbors on a per-interface basis. Beacons are now
sent on all configured interfaces, neighbor information stores both position
and interface ID, and packet forwarding correctly uses the interface
associated with the selected neighbor for greedy or perimeter routing. The
internal tables were reorganized by removing unused functionality, renaming
PositionTable to GpsrPositionTable, and introducing GpsrNeighborTable.
8. Extended host OS support
The new ExternalEnvironment, ExternalProcess, and ExternalApp modules provide
a framework for integrating host OS applications into simulations by managing
their execution and setup. ExternalEnvironment handles host configuration via
shell commands and is integrated as an optional submodule within NodeBase,
while ExternalApp offers a high-level interface to run programs like web
servers or routing daemons automatically along with the simulation.
To facilitate host OS isolated emulation, the framework introduces an
UnsharedNamespaceInitializer class for creating separate host OS user and
network namespaces. A dedicated INITSTAGE_EXTERNAL ensures external devices
like TAP interfaces are opened only after the environment is fully prepared.
9. Queueing model
New utility classes have been introduced to replace raw interface pointers
with managed references for packet sources and sinks. These classes are
PassivePacketSinkRef, ActivePacketSinkRef, PassivePacketSourceRef, and
ActivePacketSourceRef, they manage references to components for both push-
and pull-based interfaces. Most modules now treat connected sources and sinks
as optional, enabling these modules to also connect to non-queueing elements.
Classifiers and schedulers have been extended to enable pulling packets from
them and pushing packets to them, respectively. Typically, however, they are
used the other way around, with packets being pushed into classifiers and
pulled from schedulers.
Several new modules and module interfaces have also been added. For example,
the QueueBasedTokenGenerator allows the QueueFiller module to generate
traffic that prevents a queue from ever becoming empty.
Statistics collection has been improved across multiple modules. For example,
many modules now provide a packetLifeTime statistic; previously, only the
bit-based average lifetime (meanBitLifeTimePerPacket) was tracked. The
packetLifeTime statistic measures how long a packet stays in the system, from
entry to exit. Unlike the older meanBitLifeTimePerPacket, it is a simple
per-packet time delta rather than a bit-weighted average, making it easier to
interpret, analyze (e.g. histograms, min/max), and align with standard
metrics such as end-to-end delay.
In addition, passive packet sinks have been extended with optional statistics
to detect duplicate, out-of-order, and missing packets based on packet name
index suffixes. To name a few additional statistical changes, the
MultiTokenBucketMeter and MultiTokenBucketClassifier modules now record
separate statistics for each individual token bucket they contain, and the
SlidingWindowRateMeter and ExponentialRateMeter modules now provide
packetRate and dataRate statistics.
10. Protocol support
Several smaller modules have been added to support various protocol features.
For example, the GroupEligibilityTimeMeter and GroupEligibilityTimeTable
modules were added to support asynchronous traffic shaping with scheduler
groups in TSN simulations. The GroupEligibilityTimeMeter provides shared
eligibility times for streams within the same group, while
GroupEligibilityTimeTable maintains group state and mappings; they are
typically connected via Ieee8021qFilter to enforce shared eligibility
behavior.
New specialized modules were added to handle Ethernet Frame Check Sequence
(FCS) separately, including EthernetFcsHeaderInserter, which inserts Ethernet
FCS headers, and EthernetFcsHeaderChecker, which checks and strips Ethernet
FCS headers.
Added modules to support the EtherType Protocol Discrimination (EPD) header
used by IEEE 802 LLC implementations.
11. Visualizers
The RoutingTableCanvasVisualizer has been extended with a lazy update
mechanism that refreshes visualizations only when needed, greatly improving
performance. Support for multicast routing tables has been added, along with
new filtering parameters to control multicast group, source address, and
source node visualization.
The ChannelCanvasVisualizer is a new module for displaying channel activity.
12. Packet serializers
An Ieee802154MacHeaderSerializer has been added to support the binary
representation of the IEEE 802.15.4 protocol. In addition, new serializers
were introduced for non-standard INET specific protocols or technologies:
GenericPhyHeaderSerializer, ShortcutPhyHeaderSerializer, and
ShortcutMacHeaderSerializer.
The ApskPhyHeaderSerializer was updated to serialize and deserialize the
protocol field using InetPhyProtocolGroup. This change eliminates fingerprint
instability caused by serializing internal protocol IDs into the binary
representation.
A StreamBufferChunkSerializer was added to enable serialization of frames
transmitted using Ethernet cut-through switching.
13. RIP routing tutorial
This tutorial introduces the fundamentals of the Routing Information Protocol
(RIP) through a series of progressively complex examples. Starting from
static routing baselines, the tutorial demonstrates basic RIP operation with
route discovery and convergence, then advances to dynamic scenarios including
network failures, recovery mechanisms, and loop prevention techniques. Key
distance-vector concepts such as split horizon, triggered updates, route
poisoning, and the count-to-infinity problem are explored through hands-on
examples.
14. OSPF tutorial
A new multi-step tutorial covers the OSPF (Open Shortest Path First) routing
protocol in detail. Beginning with basic single-area configurations featuring
adjacency establishment and SPF-based route computation, it progresses
through DR/BDR election, link costs, and interface types, then advances to
hierarchical multi-area topologies with ABRs, summary LSAs, and external
route advertisements. Advanced topics including stub areas, virtual links,
and loopback interfaces are also demonstrated.
15. BGP routing tutorial
A comprehensive tutorial guides users through Border Gateway Protocol (BGP)
configuration and operation. The tutorial begins with basic E-BGP sessions
between autonomous systems with automatic next-hop resolution, then
progresses through I-BGP for distributing external routes within an AS, path
attributes (AS_PATH, NEXT_HOP, LOCAL_PREF), and multi-hop E-BGP with loopback
interfaces. Route redistribution with IGPs (RIP and OSPF), AS configuration,
route aggregation, and policy-based filtering are also covered.
16. New showcases
The new tsn/combiningfeatures/fpandtas showcase presents a combined-feature
TSN scenario that demonstrates the simultaneous use of Frame Preemption and
Time-Aware Shaping (TAS).
The emulation/mininet showcase, based on the VoIP showcase, is now a
standalone demonstration of running INET applications within a Mininet
environment. It uses an AppContainer-based network structure to connect
simulated traffic with external Mininet components.
The emulation/webserver showcase demonstrates the ExternalApp and
ExternalEnvironment framework by running a Python-based HTTP server and a
wget client as real host OS processes. Network namespaces are used to isolate
these external applications while enabling communication through the
simulated network.
17. Documentation refinements
NED documentation received extensive improvements in consistency, coverage,
and technical accuracy. Brief descriptions were standardized for better
presentation in IDE tooltips, terminology and formatting were unified.
Documentation was added for many previously undocumented modules. Protocol
documentation was expanded and corrected, notably for TCP and gPTP. New or
refined material was added for Ethernet (including 10BASE-T1S) and wireless
physical layer components.
The User's Guide was revised to use more neutral, professional language. It
now includes new documentation on TCP flow control and the effects of the new
autoRead parameter. The Developer's Guide was expanded with additional
technical diagrams, including a new clock and oscillator model diagram.
Across the documentation, showcases and tutorials were enhanced with “Try It
Yourself” sections that provide concrete opp_env commands for interactive
experimentation.
18. Notable bug fixes and other changes
Added INET-specific SimpleModule, CompoundModule, and ModuleMixin as standard
bases to derive all modules from. They have a displayStringTextFormat
parameter that supports the old style format directives and also WATCH
variable references. Deriving new or existing modules from these bases is
optional.
Obsolete '#abstract-config = true' configuration options in INI files have
been systematically replaced with the now standard 'abstract = true'.
Improved robustness and timing accuracy of the RealTimeScheduler. Reduced
spurious overruns and improved behavior under host load.
Added a ModuleDump module that can print a module's hierarchy and parameters
for debugging and comparison across simulations. Optional ModuleDump
submodules were also added to NetworkBase, enabling partial or full network
dumps via command line or INI file configuration.
Added ChannelOwnerRecorder, a result recorder that records which module
currently owns a communication channel. Useful for debugging resource
contention and validating channel access behavior. Added a channelOwner
statistic to WireJunction module to record the owning network node in the
collision domain.
Added a SimulationCpuUsageMeasurer module that measures the CPU time used by
a simulation and records it as a scalar statistic. It can be used for
performance analysis and benchmarking simulations.
Added parameters to the MessageDispatcher module to allow directly
controlling the message dispatching mechanism, in contrast with the automatic
learning of protocol and interface registrations.
Improved EIGROP stability, cleanup, and modernization. Several bugs were
fixed to prevent dangling pointers, handle dynamic neighbor changes
correctly, and align IPv4 route removal with IPv6 behavior. Core code paths
were refactored to use modern C++ constructs, missing interface parameters
were added to improve configurability, and message definitions were
simplified, resulting in a more robust and consistent implementation.
Added a few new NED functions. seq() returns the next integer (starting from
0) associated with a given string key, enabling deterministic sequences
across evaluations. iterate() returns the next value from an array on each
evaluation, with the index tracked per context component path. The par()
function allows dynamic access to module parameters inside expressions.
All module parameters specifying filenames now support substitution, allowing
config name, experiment, iteration, run number, etc. to be referenced in the
values.
Added the DemuxAppFilter, a result filter that de-multiplexes signals by
their originating application module, making it easy to record
per-application statistics even when applications share a common path or
interface.
Added the DemuxRegexFilter, a result filter that uses regular expression
matching on signal metadata or packet names to route incoming data into
separate output streams, enabling flexible result categorization based on
naming conventions.
Added the InterarrivalTime result filter, which computes the time between
consecutive signals or packet arrivals for analyzing jitter, traffic
burstiness, and event timing.
Removed the default value "SSID" for the defaultSsid parameter in
Ieee80211AgentSta, requiring users to explicitly configure the SSID for
station associations.
The FlowMeasurementRecorder has been extended to support recording a
packetEvent JSON log file, which captures detailed packet-level events during
the simulation.
The SctpAssociation class is converted into a simple module.
Fixed Ethernet multicast delivery in TSN.
Fixed mCRC calculation for multi-fragment Ethernet frames.
The Python support libraries were extended with automatic simulation
comparison that identifies the divergence point.
Converted self-documentation feature into a compile-time option.
Removed all per-folder ChangeLog files that summarized local changes, since
they are no longer useful with current AI tools.
Several additional issues reported on GitHub have also been fixed.
INET-4.5 (April 2023) - Stable
------------------------------
This is a new minor stable release within the INET 4.x branch. The main feature
of this release is the ability to concurrently run multiple simulations within
the same process (requires OMNeT++ 7.0 preview 2 or later), along with an extended
Ethernet cut-through switching functionality.
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 or later.
For a complete list of all added, removed, and changed folders, NED modules, packet
chunks, packet tags, statistics, C++ classes, and signals please refer to the ChangeLog
file in the src folder.
Notable backward incompatible changes are the following:
1. Ethernet cut-through switching
The Ethernet cut-through switching implementation has been extended to work
with all TSN traffic filtering and TSN traffic shaping methods. Previously
it was not possible to combine these features. For a packet that was forwarded
using cut-through switching, the otherwise configured traffic shaping and
traffic filtering methods in the switch were completely bypassed.
The new implementation allows processing the incomplete packet in the switch
while the packet buffer is being filled up by the incoming interface. All
Ethernet headers are available and the packet length is known, so traffic
filtering and traffic shaping can take place the same way it does for
store-and-forward packets.
For more information, see the showcase at:
https://inet.omnetpp.org/docs/showcases/tsn/cutthroughswitching/doc/index.html
This change doesn't require the modification of simulation models, but it may
significantly change the statistical results of simulations that use traffic
filtering or traffic shaping with cut-through switching.
2. Clock model
The RandomDriftOscillator module has been refactored to have a more useful
parameterization. The module has an initial random drift rate parameter that
represents the inaccuracy of device production. Besides, the module uses a
random walk process for an additional drift rate change that represents the
voltage and temperature dependent inaccuracy of the device.
Please note that the gPTP time synchronization change (described later) makes
the RandomDriftOscillator module more useful than the previously widely used
ConstantDriftOscillator module because the first time synchronization can now
completely eliminate the effects of a constant drift.
This change requires the modification of simulation models that use the
RandomDriftOscillator module because the parameterization has been changed.
3. Time-Sensitive Networking
The credit-based shaper has been changed to stop accumulating credits when the
corresponding time-aware shaper (same traffic category) transmission gate is
closed. Additionally, the credit-based shaper can also stop accumulating
credits when the implicit guard band of the time-aware shaper is active.
The time-aware shaper already provides an implicit guard band before each time
a gate is closing according to the gate schedule. This guard band is defined
by the following rule: no packet is allowed to pass the gate unless the packet
can be transmitted completely before the gate closes.
This change doesn't require the modification of simulation models, but it may
significantly change the statistical results of simulations that use both the
credit-based shaper and the time-aware shaper for the same traffic category.
4. Running simulations concurrently (experimental)
INET has been changed to support running multiple simulations concurrently
within a single process. Previously this was not possible, partly because
OMNeT++ itself didn't support concurrent simulation execution, but also
because INET contained several global variables. Please note that this is
an experimental feature in both OMNeT++ and INET.
In order to provide this feature, global variables have been either eliminated,
or replaced with simulation shared variables, or marked with the 'const'
qualifier signifying that their values cannot be changed, or marked with the
'OPP_THREAD_LOCAL' macro to store their values separately for each thread.
This change may require the modification of simulation models if they directly
access some of the modified global variables. Additionally, simulation models
that have their own global variables must be updated to support running
simulations concurrently.
This feature requires using OMNeT++ 7.0 preview 2 or later. For more information,
see the https://omnetpp.org/download/preview page.
Notable backward compatible changes are the following:
1. Clock model
The clock model has been extended with an oscillator compensation parameter.
This parameter can be used to reduce the effect of an inaccurate oscillator
on clock time. Time synchronization mechanisms can often estimate the clock
speed differences and set this parameter to reduce the clock time difference
that would arise over time from clocks running at different speeds.
2. IEEE 802.1-AS (gPTP)
The gPTP time synchronization protocol has been extended to also compensate
for a drifting oscillator. Previously time synchronization only set the clock
time but it didn't account for the clock speed differences between the master
and the slave clock.
This change can result in an order of magnitude smaller maximum clock time
difference between the master and slave clocks over the period of two time
synchronization events.
3. Queueing model
The behavior of complex queueing models depends among others on the execution
order of timers. Previously the scheduling priority for such timers were not
configurable, so the user could not control the order of their execution. This
limitation could prevent getting the desired behavior from the combination
of certain modules. For example, a packet server may need to wait for all
gates to open or close before using the scheduler to process the next packet
at the same simulation time.
Several queueing modules have been extended with additional parameters to
control the scheduling priority of timers. This gives fine grained control
over the order of timer events, that affects how the modules can be combined
into more complex behavior.
Additionally, the active packet source and packet sink modules that generate
or consume traffic periodically have been extended with initial offset parameters.
4. IEEE 802.11
The 802.11 model contains several policy modules that can be replaced by the
user to customize the model behavior. For example, the fragmentation policy
decides when and how frames should be fragmented. Unfortunately, previously
several policy modules were not replaceable using only INI file parameter
assignments. This limitation has been fixed.
All policy submodules have been replaced with submodules having parameterized
module types and corresponding module interfaces, making it easy to replace
policy submodules using only INI files. Additionally, the documentation of
several 802.11 modules and module interfaces have been refined.
5. Protocol element
The generic protocol elements library have been extended with a protocol
independent cut-through implementation. The new modules provide an example
of how this mechanism can be implemented and allows teaching and researching
this topic.
6. Notable bug fixes and other changes
The protocol encapsulation requests and protocol dispatching mechanism between
applications, IP, Ethernet, and other protocols have been refactored to use a
uniform implementation through utility functions. This provides the user with
a more flexible network node architecture where the protocol encapsulation can
be decided on a per packet basis.
Fixed exponent in the calculation of dielectric obstacle loss.
Fixed getReceptionStartTimeVariables method of Z3GateScheduleConfigurator.
Fixed processing of Ethernet control frames.
Fixed emitting linkBrokenSignal when transmitted packet is not acknowledged.
The IPv4NetworkConfigurator log output has been improved.
INET-4.4 (May 2022) - Stable
----------------------------
This is a new minor stable release of the INET 4.x branch. The highlight of this
release is the implementation of several Time-Sensitive Networking (TSN) features.
Also, INET is now fully licensed under LGPL (see later for details).
Experimental Python support has been added for running simulations concurrently
and optionally on an SSH cluster. This is mostly useful for running parameter
studies, automated testing and optimizing parameters.
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 or later.
For a complete list of all added, removed, and changed folders, NED modules, packet
chunks, packet tags, statistics, C++ classes, and signals please refer to the ChangeLog
file in the src folder.
Notable backward incompatible changes are the following:
1. Network interfaces
The queue modules are placed back inside the network interface compound module
as direct submodules, reverting back a previous change in INET 4.2 version.
In the INET 3.x versions, the network interface queue submodules were part
of the network interface compound modules, and they were directly connected
to other submodules within the network interface using connections and gates.
This structure was not ideal when a packet could be immediately served by the
MAC layer, because the queue recorded a zero simulation time increase in the
queue length. The problem was especially difficult to get around when compound
packet queues were used. In order to fix this issue, we decided to move the
MAC layer queues (as simple submodules) under the MAC layer compound module.
Having this structure allowed the MAC modules to completely bypass the queue
modules if the queueing of the packet was not necessary.
Unfortunately, this change turned out to be bad for various reasons. The most
important is that the queue needs to communicate with the module it is connected
to. For example, a complex compound queue which can delay packets needs to notify
the connected module, in this case of the MAC module, when a packet becomes ready
to be pulled. So once again, we decided to move the queues back where they were
before, outside of the MAC modules. Of course, the original queue length hazard
problem still had to be solved, but as it turned out that problem had to be solved
anyway.
This change may require the modification of simulation models, because the queue
module parameter assignments (referring to the old module positions) may have no
effect any more. This change can break existing simulations silently producing
different results.
2. Network nodes
The addition of Time-Sensitive Networking features required to further extend
the network node architecture by adding a separate bridging layer compound
module between the L2 and L3 layers. This new module is optional and it can
be present in both Ethernet switches and standard hosts.
The VLAN policy module has been moved into the new bridging layer in order
to correctly combine with the TSN stream features.
This change requires updating the VLAN policy module parameter assignments,
otherwise simulations may silently produce different results.
3. Packet filter expressions
Several INET modules (packet filters, packet classifiers, packet schedulers,
various visualizers, etc.) use packet filter expressions to differentiate
packets. In earlier INET versions, the packet filter expressions were limited
to only access certain parts of the packet: name, length, kind, one protocol
header at a time. Perhaps the most important such limitation was that it was
not really possible to combine conditions for different protocol headers.
The new packet filter expression syntax is more general while it retains the
often useful simple pattern matching mechanism for packet names. The generic
NED expression syntax supports the more complicated cases, where filtering for
packet content and packet meta-data is needed. It also allows the combination
of conditions for different protocol headers that was not possible before.
This change may require the modification of simulation models, because packet
filter expressions are not backward compatible. This change can break existing
simulations silently producing different results.
The User's Guide contains a separate chapter describing the packet filter
expressions with several examples.
4. Signals and statistics
Several signals and statistics have been renamed and several others are split
into multiple different ones. This change was necessary in order to have a
more coherent naming and also to have more fine-grained results. The most
important affected modules are the flow measurement recorder and the queueing
model elements. See the ChangeLog file under the src folder for more details.
This change may require the modification of analysis files, because the results
may be different. This change can break existing analysis files silently producing
different diagrams.
Notable backward compatible changes are the following:
1. Time-Sensitive Networking
Several new modules have been added to provide new features of Time-Sensitive
Networking.
An existing implementation of the gPTP time synchronization protocol has been
ported and merged into the INET framework. The protocol has been extended with
the support of multiple time synchronization domains. The clock model has been
extended to allow changing the active time domain to simulate failover. Please
note that the actual mechanism that detects the time synchronization failure
is not yet provided, so right now only manual failover can be simulated.
The new traffic shaping feature provides modules for time-aware shaping,
credit-based shaping, asynchronous shaping, and also various combinations
of them. These modules are usually part of the network interfaces in the
complex queueing mechanism of Time-Sensitive Networking.
The per-stream filtering feature provides modules for token-bucket-based
traffic metering, transmission eligibility time calculation, and a form
of statistical traffic metering. These modules are usually part of the
ingress traffic filter of the bridging layer.
The frame replication and elimination feature provides modules for stream
identification, stream splitting/merging, and stream encoding/decoding as
part of the bridging layer.
All of the above TSN features are described in detail in the User's Guide
and the respective NED files. Besides, there are several new showcases that
demonstrate the individual TSN features and a few combinations.
2. Ethernet model
The old Ethernet (non-TSN) network interface infrastructure has been changed.
The FCS protocol header insertion has been moved from the Ethernet MAC layer
module to the Ethernet protocol layer module. The Ethernet protocol layer was
already separated from the network interface and moved to separate module in
network nodes in the previous INET version. This change makes it possible to
use the old and the new TSN capable Ethernet models interchangeably.
3. Link-layer network-wide automatic configuration
Several new network-wide automatic configurator modules have been added.
One such network configurator module configures all MAC address tables (aka.
MAC forwarding information databases) automatically in all Ethernet switches
by discovering the network topology and finding the shortest paths between
all network node pairs. This configurator can be used instead of manually
configuring the Ethernet switches or instead of using an automatic spanning
tree protocol such as STP or RSTP.
There are several newly added gate scheduling configurators. They can configure
the gate schedules of time-aware shapers for all traffic categories in all
network interfaces of all network nodes. The resulting schedules are such that
the required end-to-end latency and jitter limits are met for all configured
streams. The following gate scheduling configurators are available:
- simple eager configurator
- Z3 SAT-solver-based configurator (requires installation of external library)
- TSNsched-based configurator (requires installation of external tool)
Another network level configurator that is used in Time-Sensitive Networking
is the stream redundancy configurator. This module configures the stream merger
and stream splitter modules in all network nodes such that all redundant traffic
paths are used. The redundant streams make the network resilient to various
node and/or link failures.
Finally, there is the so called failure protection configurator that is used
in Time-Sensitive Networking. This module configures the network using the
stream redundancy, and optionally the gate scheduling configurators, to meet
the complex node and/or link failure protection requirements of all traffic
streams by figuring out the necessary redundant paths.
4. Processing delay
A simple packet processing delay mechanism has been added to the TSN network
interface and also to the bridging layer. This allows one to simulate a very
simple packet processing delay for incoming and outgoing packets, and also for
packets that are forwarded by the bridging layer.
5. Queueing model and protocol elements
The queueing model have been extended with various token bucket meters and
classifiers. The model also allows one to create chained token buckets where
the overflowing tokens go to another bucket. Meters simply attach meta data
to packets while classifiers push packets to different gates, both based
on the state of the token buckets. These modules are currently used in TSN
per-stream traffic filtering.
Several new generic protocol support elements have been added. There are several
new modules, currently used in TSN frame replication, for stream identification,
stream splitting/merging, stream encoding/decoding. There are a few other new
modules, currently used in TSN asynchronous shaping, for transmission eligibility
time metering, filtering, and queueing.
A new interactive packet gate has been added that allows the user to directly
control the gate's open/closed state from Qtenv and experiment interactively.
Please note that in OMNeT++ 6.0 version of Qtenv the simulation may stop more
than once in the same event. This is called pause points, and it happens every
time a packet is passed from one module to another using to queueing model
elements, the protocol support modules, or the INET packet processing API.
6. Applications
A new simple out-of-band clock synchronizer application has been added. This
module can be used to synchronize clocks in the whole network without actually
sending any time synchronization packets.
New IEEE 802.2 LLC protocol-specific applications have been added. These allow
to send IEEE 802.2 LLC packets directly from the application layer.
7. Packet chunks, tags and serializers
New packet chunks have been added for the IEEE 802.1r protocol.
Several new packet tags have been added: PcpReq/PcpInd, StreamReq/StreamInd,
SequenceNumberReq/SequenceNumberInd, ResidenceTimeTag, EligibilityTimeTag,
CreditGateTag, EnapsulationProtocolReq/EnapsulationProtocolInd. The purpose
and usage of these tags can be found at the relevant modules.
New packet chunk serializers have been added for the IEEE 802.1as and IEEE
802.1r tags. This allows recording of PCAP traces in TSN simulations.
8. Signals and statistics
Several new signals and statistics have been added. The most notable newly
added statistics are the measurement of the transmission duration, the signal
propagation time, and the packet residence time. The latter being the duration
the packet spends in individual network nodes. For a complete list of signal
and statistic changes see the ChangeLog in the src folder.
9. Project features
Several new project features have been added. The IEEE 802.1as and the IEEE
802.1r features are used in Time-Sensitive Networking. Another feature is
added for the Microsoft Z3 SAT-solver-based gate schedule configurator, it
requires the installation of an external library.
Finally, there is a new feature for an automatic simulation model self documenter.
This feature allows one to observe the simulations while they are running and
to collect several categories of information about what the simulation modules
are doing. The result can be automatically included in the generated NED
documentation.
10. Visualization
New visualizers have been added that display some aspects of the Time-Sensitive
Networking configuration. One visualizer displays the gate schedule for the
time-aware shapers for multiple network interfaces in multiple network nodes.
Another visualizer displays the redundant traffic paths configured in the
stream splitting and stream merging components.
11. Examples
Several new Time-Sensitive Networking specific examples have been added
under the showcases/tsn folder. The new examples cover the topic of time
synchronization, traffic shaping, gate scheduling, per-stream filtering,
frame replication, frame preemption, cut-through switching, and several
combinations of these features.
Another set of new examples, found under the showcases/measurement folder,
have been added to demonstrate how to do some widely used communication
network measurements. There are examples for datarate, throughput,
utilization, end-to-end delay, jitter, queueing time, residence time,
transmission time, propagation time and various packet-flow-specific
measurements.
12. Experimental Python support
A new experimental Python package has been added that allows the automation
of running and testing multiple simulations concurrently and also optionally
on an SSH cluster. The automated testing covers smoke, fingerprint, sanitizer,
statistical, and several other tests. The inet_python_repl shell script starts
the Python interpreter and loads the required OMNeT++/INET Python packages.
The main entry points are run_simulations, run_smoke_tests, run_fingerprint_tests,
and several other run_* functions, there's also an optimize_simulation_parameters
function. There are also shell scripts (called inet_run_*) that can be used in
the simulation folders directly.
This package will be officially supported in the next OMNeT++/INET release.
13. Documentation
The User's Guide has been extended with new chapters. One new chapter is
about the new Time-Sensitive Networking features. It gives an overview of
the available modules and how to use them. Another new chapter is about the
new packet filter expression syntax. It gives a brief description of the
syntax and provides several examples.
14. Licensing and code formatting
The whole INET Framework has been re-licensed under the LGPL. The vast majority
of INET components were already licensed under LGPL. All other components that
were not, and where we could not reach the original authors, or they did not
agree with the new license, have been moved into a separate INET-GPL project.
As of today, the new INET-GPL project (https://github.com/inet-framework/inet-gpl)
contains the following old INET components:
- TCP NSC
- packetdrill
- HTB queue and scheduler
- HTTP tools
All source files have been changed with respect to license headers. The longer
license header variants have been replaced with a standard one-liner SPX license
reference.
15. Notable bug fixes and other changes
Fixed packet level region tag updating when packet contents are changed.
Fixed copying region tags in fragmentation, defragmentation, aggregation, and deaggregation.
Fixed the hazards in queue length statistics that allowed the length to go
below 0 or above the queue capacity for zero simulation time.