INET Framework Manual
inet-manual
User Manual:
Open the PDF directly: View PDF 
.
Page Count: 157
| Download | |
| Open PDF In Browser | View PDF |
INET Framework for OMNeT++
Manual
Generated on June 21, 2012
OMNeT++ Manual –
Contents
Contents
iii
1 Introduction
1
1.1 What is INET Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2 About the documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3 Contents of this Manual
1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Using the INET Framework
3
2.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2 INET as an OMNeT++-based simulation framework . . . . . . . . . . . . . . . . . .
3
2.3 Creating and Running Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.4 Result Collection and Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.5 Setting up wired network simulations
. . . . . . . . . . . . . . . . . . . . . . . . .
5
2.5.1 Modeling Link and Node Failures . . . . . . . . . . . . . . . . . . . . . . . .
6
2.5.2 Specifying IP (IPv6) addresses in module parameters . . . . . . . . . . . . .
6
2.6 Setting up wireless network simulations . . . . . . . . . . . . . . . . . . . . . . . .
6
2.7 Setting up ad-hoc network simulations . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.8 Emulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.9 Packet traces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.10 Developing New Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3 Node Architecture
3.1 Overview
9
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
3.2 Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.3 The Notification Board
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.4 The Interface Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.4.1 Accessing the Interface Table . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.4.2 Interface Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.4.3 Interface Registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.4.4 Interface Change Notifications . . . . . . . . . . . . . . . . . . . . . . . . . .
15
iii
3.5 Initialization Stages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.6 Communication between protocol layers . . . . . . . . . . . . . . . . . . . . . . . .
16
3.7 Publish-Subscribe Communication within Nodes . . . . . . . . . . . . . . . . . . .
16
3.8 Network interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.9 The wireless infrastructure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.10 NED Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.10.1The @node Property . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.10.2The @labels Module Property . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.10.3The @labels Gate Property . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4 Point-to-Point Links
4.1 Overview
19
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.2 PPP frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.3 PPP module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.4 PPPInterface module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
5 The Ethernet Model
5.1 Overview
23
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.1.1 Implemented Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
5.2 Physical layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.2.1 EtherBus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.2.2 EtherHub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
5.3 MAC layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.3.1 EtherMACFullDuplex . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.3.2 EtherMAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.4 Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
5.4.1 MAC relay units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.4.2 EtherSwitch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.5 Link Layer Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.5.1 Frame types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
5.5.2 EtherEncap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.5.3 EtherLLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.5.4 EthernetInterface module . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.6 Ethernet applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.7 Ethernet networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.7.1 LargeNet model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
6 The Radio Infrastructure
6.1 Overview
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
37
7 The 802.11 Model
7.1 Overview
39
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
7.1.1 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
40
8 Node Mobility
8.1 Overview
41
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
8.2 Mobility in INET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
8.2.1 MobilityBase class . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
8.2.2 MovingMobilityBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
8.2.3 LineSegmentsMobilityBase . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
8.3 Implemented models
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
8.3.1 Deterministic movements . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
8.3.2 Random movements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
8.3.3 Replaying trace files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
8.4 Mobility scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
47
9 IPv4
9.1 Overview
51
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
9.1.1 INET modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
9.2 The IPv4 Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
9.2.1 IP packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
9.2.2 Interface with higher layer . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
9.2.3 Routing, and interfacing with lower layers . . . . . . . . . . . . . . . . . . .
56
9.2.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
9.2.5 Statistics
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
9.3 The RoutingTable module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
58
9.4 The ICMP module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
9.5 The ARP module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
61
9.6 The IGMP module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
9.6.1 Host behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
9.6.2 Router behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
64
9.6.3 Disabling IGMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
9.6.4 Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
9.7 The NetworkLayer module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
9.8 The NetworkInfo module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
9.9 Configuring IPv4 networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
9.9.1 IPv4NetworkConfigurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
9.9.2 FlatNetworkConfigurator . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
9.9.3 Old routing files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
9.10 Applications
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
9.10.1IP traffic generators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
9.10.2The PingApp application
75
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10 IPv6 and Mobile IPv6
10.1 Overview
77
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
11 The UDP Model
79
11.1 Overview
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
11.2 The UDP module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
11.2.1Sending UDP datagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
11.2.2Receiving UDP datagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
11.2.3Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
11.3 UDP sockets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
11.4 UDP applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
11.4.1UDPBasicApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
11.4.2UDPSink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
11.4.3UDPEchoApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
11.4.4UDPVideoStreamCli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
11.4.5UDPVideoStreamSvr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
11.4.6UDPBasicBurst . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
84
12 The TCP Models
87
12.1 Overview
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
12.1.1TCP segments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
87
12.1.2TCP connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
12.1.3Flow control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
12.1.4Transmission policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
91
12.1.5Congestion control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
93
12.2 TCP module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
12.2.1TCP packets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
96
12.2.2TCP commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
97
12.2.3TCP parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
12.2.4Statistics
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
98
12.3 TCP connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
12.3.1Data transfer modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
99
12.3.2Opening connections
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
12.3.3Sending Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
12.3.4Receiving Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
12.3.5RESET handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
12.3.6Closing connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
12.3.7Aborting connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
12.3.8Status Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
12.4 TCP algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
12.4.1DumbTCP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
12.4.2TCPBaseAlg . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
12.4.3TCPNoCongestion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
12.4.4TCPTahoe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
12.4.5TCPReno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
12.4.6TCPNewReno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
12.5 TCP socket . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
12.6 Other TCP implementations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
12.6.1TCP LWIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
12.6.2TCP NSC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
12.7 TCP applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
12.7.1TCPBasicClientApp
12.7.2TCPSinkApp
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
12.7.3TCPGenericSrvApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
12.7.4TCPEchoApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
12.7.5TCPSessionApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
12.7.6TelnetApp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
12.7.7TCPSrvHostApp
13 The SCTP Model
13.1 Overview
113
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
14 Internet Routing
14.1 Overview
115
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
15 Differentiated Services
15.1 Overview
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
117
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
15.1.1Implemented Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
15.2 Architecture of NICs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
15.2.1Traffic Conditioners . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
15.2.2Output Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
15.3 Simple modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
15.3.1Queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
15.3.2Droppers
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
15.3.3Schedulers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
15.3.4Classifiers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
15.3.5Meters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
15.3.6Markers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
15.4 Compound modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
15.4.1AFxyQueue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
15.4.2DiffservQeueue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
15.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
15.5.1Simple domain example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
15.5.2One domain example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
16 The MPLS Models
16.1 Overview
131
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
16.2 MPLS/RSVP/LDP Model - Implemented Standards . . . . . . . . . . . . . . . . . . 131
16.3 MPLS Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
16.4 LDP Message Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
16.4.1Label Request Message processing
. . . . . . . . . . . . . . . . . . . . . . . 133
16.4.2Label Mapping Message processing . . . . . . . . . . . . . . . . . . . . . . . 134
16.5 LIB Table File Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
16.6 The CSPF Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
16.7 The traffic.xml file . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
17 Applications
17.1 Overview
18 History
139
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
141
18.1 IPSuite to INET Framework (2000-2006) . . . . . . . . . . . . . . . . . . . . . . . . 141
References
143
Index
144
OMNeT++ Manual – Introduction
Chapter 1
Introduction
1.1
What is INET Framework
INET Framework contains IPv4, IPv6, TCP, SCTP, UDP protocol implementations, and several
application models. The framework also includes an MPLS model with RSVP-TE and LDP
signalling. Link-layer models are PPP, Ethernet and 802.11. Static routing can be set up
using network autoconfigurators, or one can use routing protocol implementations.
The INET Framework supports wireless and mobile simulations as well. Support for mobility
and wireless communication has been derived from the Mobility Framework.
1.2
About the documentation
This manual is acompanied by a Reference generated from NED and MSG files using OMNeT++’s documentation generator, and the documentation of the underlying C++ classes,
generated from the source files using Doxygen.
The C++ doc is generated in a way that it contains the full C++ source code as HTML pages.
It is syntax highlighted, and variable and class names are hyperlinked and cross-referenced,
which makes it convenient for exploring the code.
1.3
Contents of this Manual
todo...
1
OMNeT++ Manual – Introduction
2
OMNeT++ Manual – Using the INET Framework
Chapter 2
Using the INET Framework
2.1
Installation
To install the INET Framework, download the most recent INET Framework source release
from the download link on the http://inet.omnetpp.org web site, unpack it, and follow the
instructions in the INSTALL file in the root directory of the archive.
If you plan to simulate ad-hoc networks or you need more wireless link layer protocols than
provided in INET, download and install the INETMANET source archive instead. (INETMANET
aready contains a copy of the INET Framework.)
If you plan to make use of other INET extensions (e.g. HttpTools, VoipTools or TraCI), follow
the installation instructions provided with them. If there are no install instructions, check if
the archive contains a .project file. If it does, then the project can be imported into the IDE
(use File > Import > General > Existing Project into workspace); make sure that the project is
recognized as an OMNeT++ project (the Project Properties dialog contains an OMNeT++ page)
and it lists the INET or INETMANET project as dependency (check the Project References page
in the Project Properties dialog).
If the extension project contains no .project file, create an empty OMNeT++ project using
the New OMNeT++ Project wizard in File > New, add the INET or INETMANET project as
dependency using the Project References page in the Project Properties dialog, and copy the
source files into the project.
After installation, run the example simulations to make sure everything works correctly. The
INSTALL file also describes how to do that.
2.2
INET as an OMNeT++-based simulation framework
TODO what is documented where in the OMNeT++ manual (chapter, section title)
The INET Framework builds upon OMNeT++, and uses the same concept: modules that communicate by message passing. Hosts, routers, switches and other network devices are represented by OMNeT++ compound modules. These compound modules are assembled from
simple modules that represent protocols, applications, and other functional units. A network
is again an OMNeT++ compound module that contains host, router and other modules. The
external interfaces of modules are described in NED files. NED files describe the parameters
and gates (i.e. ports or connectors) of modules, and also the submodules and connections (i.e.
3
OMNeT++ Manual – Using the INET Framework
netlist) of compound modules.
Modules are organized into hierarchical packages that directly map to a folder tree, very
much like Java packages. Packages in INET are organized roughly according to OSI layers;
the top packages include inet.applications, inet.transport, inet.networklayer, and
inet.linklayer. Other packages are inet.base, inet.util, inet.world, inet.mobility
and inet.nodes. These packages correspond to the src/applications/, src/transport/,
etc. directories in the INET source tree. (The src/ directory corresponds to the inet package,
as defined by the src/package.ned file.) Subdirectories within the top packages usually
correspond to concrete protocols or protocol families. The implementations of simple modules
are C++ classes with the same name, with the source files placed in the same directory as the
NED file.
The inet.nodes package contains various pre-assembled host, router, switch, access point,
and other modules, for example StandardHost, Router and EtherSwitch and WirelessAP.
These compound modules contain some customization options via parametric submodule
types, but they are not meant to be universal: it is expected that you will create your own
node models for your particular simulation scenarios.
Network interfaces (Ethernet, IEEE 802.11, etc) are usually compound modules themselves,
and are being composed of a queue, a MAC, and possibly other simple modules. See EthernetInterface as an example.
Not all modules implement protocols. There are modules which hold data (for example RoutingTable), facilitate communication of modules (NotificationBoard), perform autoconfiguration of a network (FlatNetworkConfigurator), move a mobile node around (for example
ConstSpeedMobility), and perform housekeeping associated with radio channels in wireless
simulations (ChannelControl).
Protocol headers and packet formats are described in message definition files (msg files),
which are translated into C++ classes by OMNeT++’s opp_msgc tool. The generated message
classes subclass from OMNeT++’s cPacket or cMessage classes.
The internal structure of compound modules such as host and router models can be customized in several ways. The first way is the use of gate vectors and submodule vectors. The
sizes of vectors may come from parameters or derived by the number of external connections
to the module. For example, one can have an Ethernet switch model that has as many ports
as needed, i.e. equal to the number of Ethernet devices connected to it.
The second way of customization is parametric types, that is, the type of a submodule (or
a channel) may be specified as a string parameter. For example, the relay unit inside an
Ethernet switch has several alternative implementations, each one being a distinct module
type. The switch model contains a parameter which allows the user to select the appropriate
relay unit implementation.
A third way of customizing modules is inheritance: a derived module may add new parameters,
gates, submodules or connections, and may set inherited unassigned parameters to specific
values.
2.3
Creating and Running Simulations
To create a simulation, you would write a NED file that contains the network, i.e. routers,
hosts and other network devices connected together. You can use a text editor or the IDE’s
graphical editor to create the network.
Modules in the network contain a lot of unassigned parameters, which need to be assigned
4
OMNeT++ Manual – Using the INET Framework
before the simulation can be run.1 The name of the network to be simulated, parameter values
and other configuration option need to be specified in the omnetpp.ini file.2
omnetpp.ini contains parameter assignments as key=value lines, where each key is a wildcard pattern. The simulator matches these wildcard patterns against full path of the parameter in the module tree (something like ThruputTest.host[2].tcp.nagleEnabled), and
value from the first match will be assigned for the parameter. If no matching line is found, the
default value in the NED file will be used. (If there is no default value either, the value will be
interactively prompted for, or, in case of a batch run, an error will be raised.)
There are two kinds of wildcards: a single asterisk * matches at most one component name
in the path string, while double asterisk ** may match multiple components. Technically: *
never matches a dot or a square bracket (., [, ]), while ** can match any of them. Patterns
are also capable of expressing index ranges (**.host[1..3,5,8].tcp.nagleEnabled) and
ranges of numbers embedded in names (**.switch{2..3}.relayUnitType).
OMNeT++ allows several configurations to be put into the omnetpp.ini file under [Config ] section headers, and the right configuration can be selected via commandline options when the simulation is run. Configurations can also build on each other: extends= lines can be used to set up an inheritance tree among them. This feature
allows minimizing clutter in ini files by letting you factor out common parts. (Another ways of
factoring out common parts are ini file inclusion and specifying multiple ini files to a simulation.) Settings in the [General] section apply to all configurations, i.e. [General] is the root
of the section inheritance tree.
Parameter studies can be defined by specifying multiple values for a parameter, with the
${10,50,100..500 step 100, 1000} syntax; a repeat count can also be specified.
how to run;
C++ -> dll (opp_run) or exe
2.4
Result Collection and Analysis
how to anaylize results
how to configure result collection
2.5
Setting up wired network simulations
For an introduction, in this section we show you how to set up simulations of wired networks
using PPP or Ethernet links with autoconfigured static IP routing. (If your simulation involves
more, such as manually configured routing tables, dynamic routing, MPLS, or IPv6 or other
features and protocols, you’ll find info about them in later chapters.)
Such a network can be assembled using the predefined StandardHost and Router modules.
For automatic IP address assignment and static IP routing we can use the FlatNetworkConfigurator utility module.
ethg, pppg; automatically expand (++)
todo which modules are needed into it, what they do, etc.
how to add apps, etc
1 The
2 This
simulator can interactively ask for parameter values, but this is not very convenient for repeated runs.
is the default file name; using other is also possible.
5
OMNeT++ Manual – Using the INET Framework
2.5.1
Modeling Link and Node Failures
todo
Some modules have only one instance, at global network level:
FlatNetworkConfigurator assigns IP addresses to hosts and routers, and sets up static
routing.
ScenarioManager makes simulations scriptable. Modules can be made to support scripting
by implementing the IScriptable C++ interface.
ChannelControl is required for wireless simulations. It keeps track of which nodes are within
interference distance of other nodes.
2.5.2
Specifying IP (IPv6) addresses in module parameters
In INET, TCP, UDP and all application layer modules work with both IPv4 and IPv6. Internally
they use the IPvXAddress C++ class, which can represent both IPv4 and IPv6 addresses.
Most modules use the IPAddressResolver C++ class to resolve addresses specified in module
parameters in omnetpp.ini. IPAddressResolver accepts the following syntax:
• literal IPv4 address: "186.54.66.2"
• literal IPv6 address: "3011:7cd6:750b:5fd6:aba3:c231:e9f9:6a43"
• module name: "server", "subnet.server[3]"
• interface of a host or router: "server/eth0", "subnet.server[3]/eth0"
• IPv4 or IPv6 address of a host or router: "server(ipv4)", "subnet.server[3](ipv6)"
• IPv4 or IPv6 address of an interface of a host or router: "server/eth0(ipv4)", "subnet.server[3]/eth0(ipv6)"
2.6
Setting up wireless network simulations
todo which modules are needed into it, what they do, etc.
2.7
Setting up ad-hoc network simulations
todo which modules are needed into it, what they do, etc.
2.8
Emulation
2.9
Packet traces
Recording packet traces
Traffic generation using packet traces
6
OMNeT++ Manual – Using the INET Framework
2.10
Developing New Protocols
where to put the source files: you can copy and modify the INET framework (fork it) in the
hope that you’ll contribute back the changes; or you can develop in a separate project (create
new project in the IDE; mark INET as referenced project)
NED and source files in the same folder; examples under examples/; etc.
for details, read the OMNeT++ manual and the following chapters of this manual
todo...
7
OMNeT++ Manual – Using the INET Framework
8
OMNeT++ Manual – Node Architecture
Chapter 3
Node Architecture
3.1
Overview
This chapter describes the architecture of INET host and router models.
Hosts and routers in the INET Framework are OMNeT++ compound modules that are composed of the following ingredients:
• Interface Table (InterfaceTable). This module contains the table of network interfaces
(eth0, wlan0, etc) in the host. Interfaces are registered dynamically during the initialization phase by modules that represent network interface cards (NICs). Other modules
access interface information via a C++ class interface.
• Routing Table (RoutingTable). This module contains the IPv4 routing table. It is also
accessed from other via a C++ interface. The interface contains member functions for
adding, removing, enumerating and looking up routes, and finding the best matching
route for a given destination IP address. The IP module calls uses the latter function for
routing packets, and routing protocols such as OSPF or BGP call the route manipulation
methods to add and manage discovered routes. For IPv6 simulations, RoutingTable is
replaced (or co-exists) with a RoutingTable6 module; and for Mobile IPv6 simulations
(xMIPv6 project [TODO]), possibly with a BindingCache module as well.
• Notification Board (NotificationBoard). This module makes it possible for several
modules to communicate in a publish-subscribe manner. Notifications include change
notifications (“routing table changed”) and state changes (“radio became idle”).
• Mobility module. In simulations involving node mobility, this module is responsible for
moving around the node in the simulated “playground.” A mobility module is also needed
for wireless simulations even if the node is stationery, because the mobility module stores
the node’s location, needed to compute wireless transmissions. Different mobility models
(Random Walk, etc.) are supported via different module types, and many host models
define their mobility submodules with parametric type so that the mobility model can be
changed in the configuration ("mobility: like IMobility").
• NICs. Network interfaces are usually compound modules themselves, composed of a
queue and a MAC module (and in the case of wireless NICs, a radio module or modules). Examples are PPPInterface, EthernetInterface, and WLAN interfaces such as
Ieee80211NicSTA. The queue submodule stores packets waiting for transmission, and
9
OMNeT++ Manual – Node Architecture
it is usually defined as having parametric type as it has multiple implementations to
accomodate different needs (DropTailQueue, REDQueue, DropTailQoSQueue, etc.) Most
MACs also have an internal queue to allow operation without an external queue module,
the advantage being smaller overhead. The NIC’s entry in the host’s InterfaceTable is
usually registered by the MAC module at the beginning of the simulation.
• Network layer. Modules that represent protocols of the network layer are usually
grouped into a compound module: NetworkLayer for IP, and NetworkLayer6 for IPv6.
NetworkLayer contains the modules IP, ARP, ICMP and ErrorHandling. The IP module performs IP encapsulation/decapsulation and routing of datagrams; for the latter it
accesses the C++ function call interface of the RoutingTable. Packet forwarding can be
turned on/off via a module parameter. The ARP module is put into the path of packets
leaving the network layer towards the NICs, and performs address resolution for interfaces that need it (e.g. Ethernet). ICMP deals with sending and receiving ICMP packets.
The ErrorHandling module receives and logs ICMP error replies. The IPv6 network
layer, NetworkLayer6 contains the modules IPv6, ICMPv6, IPv6NeighbourDiscovery
and IPv6ErrorHandling. For Mobile IPv6 simulations (xMIPv6 project [TODO]), NetworkLayer6 is extended with further modules.
• Transport layer protocols. Transport protocols are represented by modules connected
to the network layer; currently TCP, UDP and SCTP are supported. TCP has several
implementations: TCP is the OMNeT++ native implementation; the TCP_lwip module
wraps the lwIP TCP stack [TODO]; and the TCP_NSC module wraps the Network Simulation Cradle library [TODO]. For this reason, the tcp submodule is usually defined
with a parametric submodule type ("tcp: like ITCP"). UDP and SCTP
are implemented by the UDP and SCTP modules, respectively.
• Applications. Application modules typically connect to TCP and/or UDP, and model the
user behavior as well as the application program (e.g. browser) and application layer
protocol (e.g. HTTP). For convenience, StandardHost supports any number of UDP, TCP
and SCTP applications, their types being parametric ("tcpApp[numTcpApps]: like TCPApp; udpApp[numUdpApps]: like UDPApp;
..."). This way the user can configure applications entirely from omnetpp.ini, and
does not need to write a new NED file every time different applications are needed in a
host model. Application modules are typically not present in router models.
• Routing protocols. Router models typically contain modules that implement routing
protocols such as OSPF or BGP. These modules are connected to the TCP and/or the
UDP module, and manipulate routes in the RoutingTable module via C++ function
calls.
• MPLS modules. Additional modules are needed for MPLS simulations. The MPLS module
is placed between the network layer and NICs, and implements label switching. MPLS
requires a LIB module (Label Information Base) to be present in the router which it
accesses via C++ function calls. MPLS control protocol implementations (e.g. the RSVP
module) manage the information in LIB via C++ calls.
• Relay unit. Ethernet (and possibly other) switch models may contain a relay unit, which
switches frames among Ethernet (and other IEEE 802) NICs. Concrete relay unit types
include MACRelayUnitPP and MACRelayUnitNP, which differ in their performance models.
• Battery module. INET extensions uses for wireless sensor networks (WSNs) may add
a battery module to the node model. The battery module would keep track of energy
consumption. A battery module is provided e.g. by the INETMANET project.
10
OMNeT++ Manual – Node Architecture
The StandardHost and Router predefined NED types are only one possible example of host/router
models, and they do not contain all the above components; for specific simulations it is a perfectly valid approach to create custom node models.
Most modules are optional, i.e. can be left out of hosts or other node models when not needed
in the given scenario. For example, switch models do not need a network layer, a routing table
or interface table; it may need a notification board though. Some NICs (e.g. EtherMAC) can be
used without and interface table and queue models as well.
The notification board (NotificationBoard) and the interface table (InterfaceTable) will
be described later in this chapter. Other modules are covered in later chapters, i.e. RoutingTable in the IPv4 chapter.
3.2
Addresses
The INET Framework uses a number of C++ classes to represent various addresses in the
network. These classes support initialization and assignment from binary and string representation of the address, and accessing the address in both forms. (Storage is in binary
form). They also support the "unspecified" special value (and the isUnspecified() method)
that corresponds to the all-zeros address.
• MACAddress represents a 48-bit IEEE 802 MAC address. The textual notation it understands and produces is hex string.
• IPAddress represents a 32-bit IPv4 address. It can parse and produce textual representations in the "dotted decimal" syntax.
• IPv6Address represents a 128-bit IPv6 address. It can parse and produce address
strings in the canonical (RFC 3513) syntax.
• IPvXAddress is conceptually a union of a IPAddress and IPv6Address: an instance
stores either an IPv4 address or an IPv6 address. IPvXAddress is mainly used in the
transport layer and above to abstract away network addresses. It can be assigned from
both IPAddress and IPv6Address, and can also parse string representations of both.
The isIPv6(), get4() and get6() methods can be used to access the value.
TODO: Resolving addresses with IPAddressResolver
3.3
The Notification Board
The NotificationBoard module allows publish-subscribe communication among modules
within a host. Using NotificationBoard, modules can notify each other about events
such as routing table changes, interface status changes (up/down), interface configuration
changes, wireless handovers, changes in the state of the wireless channel, mobile node position changes, etc. NotificationBoard acts as a intermediary between the module where the
events occur and modules which are interested in learning about those events.
NotificationBoard has exactly one instance within a host or router model, and it is accessed
via direct C++ method calls (not message exchange). Modules can subscribe to categories of
changes (e.g. “routing table changed” or “radio channel became empty”). When such a change
occurs, the corresponding module (e.g. the RoutingTable or the physical layer module) will
11
OMNeT++ Manual – Node Architecture
let NotificationBoard know, and it will disseminate this information to all interested modules.
Notification events are grouped into categories.
Examples of categories are:
NF_HOSTPOSITION_UPDATED, NF_RADIOSTATE_CHANGED, NF_PP_TX_BEGIN, NF_PP_TX_END,
NF_IPv4_ROUTE_ADDED, NF_BEACON_LOST, NF_NODE_FAILURE, NF_NODE_RECOVERY, etc. Each
category is identified by an integer (right now it’s assigned in the source code via an enum, in
the future we’ll convert to dynamic category registration).
To trigger a notification, the client must obtain a pointer to the NotificationBoard of the
given host or router (explained later), and call its fireChangeNotification() method. The
notification will be delivered to all subscribed clients immediately, inside the fireChangeNotification() call.
Clients that wish to receive notifications should implement (subclass from) the INotifiable
interface, obtain a pointer to the NotificationBoard, and subscribe to the categories they
are interested in by calling the subscribe() method of the NotificationBoard. Notifications
will be delivered to the receiveChangeNotification() method of the client (redefined from
INotifiable).
In cases when the category itself (an int) does not carry enough information about the notification event, one can pass additional information in a data class. There is no restriction
on what the data class may contain, except that it has to be subclassed from cObject, and
of course producers and consumers of notifications should agree on its contents. If no extra
info is needed, one can pass a NULL pointer in the fireChangeNotification() method.
A module which implements INotifiable looks like this:
class Foo : public cSimpleModule, public INotifiable {
...
virtual void receiveChangeNotification(int category, const cObject *details) {..}
...
};
Note: cObject was called cPolymorphic in earlier versions of OMNeT++. You may occasionally still see the latter name in source code; it is an alias (typedef) to cObject.
Obtaining a pointer to the NotificationBoard module of that host/router:
NotificationBoard *nb; // this is best made a module class member
nb = NotificationBoardAccess().get(); // best done in initialize()
TODO how to fire a notification
3.4
The Interface Table
The InterfaceTable module holds one of the key data structures in the INET Framework:
information about the network interfaces in the host. The interface table module does not
send or receive messages; other modules access it using standard C++ member function calls.
3.4.1
Accessing the Interface Table
If a module wants to work with the interface table, first it needs to obtain a pointer to it. This
can be done with the help of the InterfaceTableAccess utility class:
IInterfaceTable *ift = InterfaceTableAccess().get();
12
OMNeT++ Manual – Node Architecture
InterfaceTableAccess requires the interface table module to be a direct child of the host
and be called "interfaceTable" in order to be able to find it. The get() method never
returns NULL: if it cannot find the interface table module or cannot cast it to the appropriate
C++ type (IInterfaceTable), it throws an exception and stop the simulation with an error
message.
For completeness, InterfaceTableAccess also has a getIfExists() method which can be
used if the code does not require the presence of the interface table. This method returns
NULL if the interface table cannot be found.
Note that the returned C++ type is IInterfaceTable; the initial "I" stands for "interface".
IInterfaceTable is an abstract class interface that InterfaceTable implements. Using
the abstract class interface allows one to transparently replace the interface table with another implementation, without the need for any change or even recompilation of the INET
Framework.
3.4.2
Interface Entries
Interfaces in the interface table are represented with the InterfaceEntry class. IInterfaceTable provides member functions for adding, removing, enumerating and looking up
interfaces.
Interfaces have unique names and interface IDs; either can be used to look up an interface
(IDs are naturally more efficient). Interface IDs are invariant to the addition and removal of
other interfaces.
Data stored by an interface entry include:
• name and interface ID (as described above)
• MTU : Maximum Transmission Unit, e.g. 1500 on Ethernet
• several flags:
– down: current state (up or down)
– broadcast: whether the interface supports broadcast
– multicast whether the interface supports multicast
– pointToPoint: whether the interface is point-to-point link
– loopback: whether the interface is a loopback interface
• datarate in bit/s
• link-layer address (for now, only IEEE 802 MAC addresses are supported)
• network-layer gate index: which gate of the network layer within the host the NIC is
connected to
• host gate IDs: the IDs of the input and output gate of the host the NIC is connected to
Extensibility. You have probably noticed that the above list does not contain data such as
the IP or IPv6 address of the interface. Such information is not part of InterfaceEntry
because we do not want InterfaceTable to depend on either the IPv4 or the IPv6 protocol
implementation; we want both to be optional, and we want InterfaceTable to be able to
support possibly other network protocols as well.
13
OMNeT++ Manual – Node Architecture
Thus, extra data items are added to InterfaceEntry via extension. Two kinds of extensions
are envisioned: extension by the link layer (i.e. the NIC), and extension by the network layer
protocol:
• NICs can extend interface entries via C++ class inheritance, that is, by simply subclassing InterfaceEntry and adding extra data and functions. This is possible because NICs
create and register entries in InterfaceTable, so in their code one can just write new
MyExtendedInterfaceEntry() instead of new InterfaceEntry().
• Network layer protocols cannot add data via subclassing, so composition has to
be used. InterfaceEntry contains pointers to network-layer specific data structures. Currently there are four pointers: one for IPv4 specific data, one for IPv6
specific data, and two additional ones that are unassigned. The four data objects
can be accessed with the following InterfaceEntry member functions: ipv4Data(),
ipv6Data(), protocol3Data(), and protocol4Data(). They return pointers of the
types IPv4InterfaceData, IPv6InterfaceData and InterfaceProtocolData (2x), respectively. For illustration, IPv4InterfaceData is installed onto the interface entries by
the RoutingTable module, and it contains data such as the IP address of the interface,
the netmask, link metric for routing, and IP multicast addresses associated with the interface. A protocol data pointer will be NULL if the corresponding network protocol is not
used in the simulation; for example, in IPv4 simulations only ipv4Data() will return a
non-NULL value.
3.4.3
Interface Registration
Interfaces are registered dynamically in the initialization phase by modules that represent
network interface cards (NICs). The INET Framework makes use of the multi-stage initialization feature of OMNeT++, and interface registration takes place in the first stage (i.e. stage
0).
Example code that performs interface registration:
void PPP::initialize(int stage)
{
if (stage==0) {
...
interfaceEntry = registerInterface(datarate);
...
}
InterfaceEntry *PPP::registerInterface(double datarate)
{
InterfaceEntry *e = new InterfaceEntry();
// interface name: NIC module’s name without special characters ([])
e->setName(OPP_Global::stripnonalnum(getParentModule()->getFullName()).c_str());
// data rate
e->setDatarate(datarate);
// generate a link-layer address to be used as interface token for IPv6
InterfaceToken token(0, simulation.getUniqueNumber(), 64);
e->setInterfaceToken(token);
14
OMNeT++ Manual – Node Architecture
// set MTU from module parameter of similar name
e->setMtu(par("mtu"));
// capabilities
e->setMulticast(true);
e->setPointToPoint(true);
// add
IInterfaceTable *ift = InterfaceTableAccess().get();
ift->addInterface(e, this);
return e;
}
3.4.4
Interface Change Notifications
InterfaceTable has a change notification mechanism built in, with the granularity of interface entries.
Clients that wish to be notified when something changes in InterfaceTable can subscribe
to the following notification categories in the host’s NotificationBoard:
• NF_INTERFACE_CREATED: an interface entry has been created and added to the interface
table
• NF_INTERFACE_DELETED: an interface entry is going to be removed from the interface
table. This is a pre-delete notification so that clients have access to interface data that
are possibly needed to react to the change
• NF_INTERFACE_CONFIG_CHANGED: a configuration setting in an interface entry has
changed (e.g. MTU or IP address)
• NF_INTERFACE_STATE_CHANGED: a state variable in an interface entry has changed (e.g.
the up/down flag)
In all those notifications, the data field is a pointer to the corresponding InterfaceEntry object. This is even true for NF_INTERFACE_DELETED (which is actually a pre-delete notification).
3.5
Initialization Stages
Node architecture makes it necessary to use multi-stage initialization. What happens in each
stage is this:
In stage 0, interfaces register themselves in InterfaceTable modules
In stage 1, routing files are read.
In stage 2, network configurators (e.g. FlatNetworkConfiguration) assign addresses and
set up routing tables.
In stage 3, TODO...
In stage 4, TODO...
15
OMNeT++ Manual – Node Architecture
...
The multi-stage initialization process itself is described in the OMNeT++ Manual.
3.6
Communication between protocol layers
In the INET Framework, when an upper-layer protocol wants to send a data packet over
a lower-layer protocol, the upper-layer module just sends the message object representing
the packet to the lower-layer module, which will in turn encapsulate it and send it. The
reverse process takes place when a lower layer protocol receives a packet and sends it up
after decapsulation.
It is often necessary to convey extra information with the packet. For example, when an
application-layer module wants to send data over TCP, some connection identifier needs to
be specified for TCP. When TCP sends a segment over IP, IP will need a destination address
and possibly other parameters like TTL. When IP sends a datagram to an Ethernet interface
for transmission, a destination MAC address must be specified. This extra information is
attached to the message object to as control info.
Control info are small value objects, which are attached to packets (message objects) with
its setControlInfo() member function. Control info only holds auxiliary information for
the next protocol layer, and is not supposed to be sent over the network to other hosts and
routers.
3.7
Publish-Subscribe Communication within Nodes
The NotificationBoard module makes it possible for several modules to communicate in a
publish-subscribe manner. For example, the radio module (Ieee80211Radio) fires a "radio
state changed" notification when the state of the radio channel changes (from TRANSMIT to
IDLE, for example), and it will be delivered to other modules that have previously subscribed to
that notification category. The notification mechanism uses C++ functions calls, no message
sending is involved.
The notification board submodule within the host (router) must be called notificationBoard
for other modules to find it.
3.8
Network interfaces
todo...
3.9
The wireless infrastructure
todo...
16
OMNeT++ Manual – Node Architecture
3.10
NED Conventions
3.10.1
The @node Property
By convention, compound modules that implement network devices (hosts, routers, switches,
access points, base stations, etc.) are marked with the @node NED property. As node models
may themselves be hierarchical, the @node property is used by protocol implementations and
other simple modules to determine which ancestor compound module represents the physical
network node they live in.
3.10.2
The @labels Module Property
The @labels property can be added to modules and gates, and it allows the OMNeT++ graphical editor to provide better editing experience. First we look at @labels as a module property.
@labels(node) has been added to all NED module types that may occur on network level.
When editing a network, the graphical editor will NED types with @labels(node) to the top
of the component palette, allowing the user to find them easier.
Other labels can also be specified in the @labels(...) property. This has the effect that if
one module with a particular label has already been added to the compound module being
edited, other module types with the same label are also brought to the top of the palette. For
example, EtherSwitch is annotated with @labels(node,ethernet-node). When you drop
an EtherSwitch into a compound module, that will bring EtherHost (which is also tagged
with the ethernet-node label) to the top of the palette, making it easier to find.
module EtherSwitch
{
parameters:
@node();
@labels(node,ethernet-node);
@display("i=device/switch");
...
}
Module types that are already present in the compound module also appear in the top part of
the palette. The reason is that if you already added a StandardHost, for example, then you
are likely to add more of the same kind. Gate labels (see next section) also affect palette order:
modules which can be connected to modules already added to the compound module will also
be listed at the top of the palette. The final ordering is the result of a scoring algorithm.
3.10.3
The @labels Gate Property
Gates can also be labelled with @labels(); the purpose is to make it easier to connect modules in the editor. If you connect two modules in the editor, the gate selection menu will list
gate pairs that have a label in common.
TODO screenshot
For example, when connecting hosts and routers, the editor will offer connecting Ethernet
gates with Ethernet gates, and PPP gates with PPP gates. This is the result of gate labelling
like this:
module StandardHost
17
OMNeT++ Manual – Node Architecture
{
...
gates:
inout pppg[] @labels(PPPFrame-conn);
inout ethg[] @labels(EtherFrame-conn);
...
}
Guidelines for choosing gate label names: For gates of modules that implement protocols, use
the C++ class name of the packet or acompanying control info (see later) associated with the
gate, whichever applies; append /up or /down to the name of the control info class. For gates
of network nodes, use the class names of packets (frames) that travel on the corresponding
link, with the -conn suffix. The suffix prevents protocol-level modules to be promoted in the
graphical editor palette when a network is edited.
Examples:
simple TCP like ITCP
{
...
gates:
input appIn[] @labels(TCPCommand/down);
output appOut[] @labels(TCPCommand/up);
input ipIn @labels(TCPSegment,IPControlInfo/up);
output ipOut @labels(TCPSegment,IPControlInfo/down);
input ipv6In @labels(TCPSegment,IPv6ControlInfo/up);
output ipv6Out @labels(TCPSegment,IPv6ControlInfo/down);
}
simple PPP
{
...
gates:
input netwIn;
output netwOut;
inout phys @labels(PPPFrame);
}
18
OMNeT++ Manual – Point-to-Point Links
Chapter 4
Point-to-Point Links
4.1
Overview
The INET Framework contains an implementation of the Point-to-Point Protocol as described
in RFC1661 with the following limitations:
• There are no LCP messages for link configuration, link termination and link maintenance. The link can be configured by setting module parameters.
• PFC and ACFC are not supported, the PPP frame always contains the 1-byte Address
and Control fields and a 2-byte Protocol field.
• PPP authentication is not supported
• Link quality monitoring protocols are not supported.
• There are no NCP messages, the network layer protocols are configured by other means.
The modules of the PPP model can be found in the inet.linklayer.ppp package:
PPP This simple module performs encapsulation of network datagrams into PPP frames and
decapsulation of the incoming PPP frames. It can be connected to the network layer
directly or can be configured to get the outgoing messages from an output queue. The
module collects statistics about the transmitted and dropped packages.
PPPInterface is a compound module complementing the PPP module with an output queue.
It implements the IWiredNic interface. Input and output hooks can be configured for
further processing of the network messages.
4.2
PPP frames
According to RFC1662 the PPP frames contain the following fields:
19
OMNeT++ Manual – Point-to-Point Links
Flag
01111110
Protocol
8/16 bits
FCS
16/32 bits
Control
Address
00000011
11111111
Padding
Information
∗
∗
Flag
Inter-frame Fill
01111110
or next Address
The corresponding message type in the INET framework is PPPFrame. It contains the Information field as an encapsulated cMessage object. The Flag, Address and Control fields are
omitted from PPPFrame because they are constants. The FCS field is omitted because no CRC
computed during the simulation, the bit error attribute of the cMessage used instead. The
Protocol field is omitted because the protocol is determined from the class of the encapsulated
message.
The length of the PPP frame is equal to the length of the encapsulated datagram plus 7 bytes.
This computation assumes that
• there is no inter-octet time fill, so only one Flag sequence needed per frame
• padding is not applied
• PFC and ACFC compression is not applied
• FCS is 16 bit
• no escaping was applied
4.3
PPP module
The PPP module receives packets from the upper layer in the netwIn gate, encapsulates
them into PPPFrames, and send it to the physical layer through the phys gate. The PPPFrames
received from the phys gate are decapsulated and sent to the upper layer immediately through
the netwOut gate.
Incoming datagrams are waiting in a queue if the line is currently busy. In routers, PPP relies
on an external queue module (implementing IOutputQueue) to model finite buffer, implement
QoS and/or RED, and requests packets from this external queue one-by-one. The name of
this queue is given as the queueModule parameter.
In hosts, no such queue is used, so PPP contains an internal queue named txQueue to queue
up packets wainting for transmission. Conceptually txQueue is of inifinite size, but for better
diagnostics one can specify a hard limit in the txQueueLimit parameter – if this is exceeded,
the simulation stops with an error.
The module can be used in simulations where the nodes are connected and disconnected
dinamically. If the channel between the PPP modules is down, the messages received from the
upper layer are dropped (including the messages waiting in the queue). When the connection
is restored it will poll the queue and transmits the messages again.
The PPP module registers itself in the interface table of the node. The mtu of the entry can be
specified by the mtu module parameter. The module checks the state of the physical link and
updates the entry in the interface table.
The node containing the PPP module must also contain a NofiticationBoard component.
Notifications are sent when transmission of a new PPP frame started (NF_PP_TX_BEGIN), finished (NF_PP_TX_END) or when a PPP frame received (NF_PP_RX_END).
20
OMNeT++ Manual – Point-to-Point Links
The PPP component is the source of the following signals:
• txState state of the link (0=idle,1=busy)
• txPkBytes number of bytes transmitted
• rxPkBytesOk number of bytes received successfully
• droppedPkBytesBitError number of bytes received in erronous frames
• droppedPkBytesIfaceDown number of bytes dropped because the link is down
• rcvdPkBytesFromHL number of bytes received from the the upper layer
• passedUpPkBytes number of bytes sent to the the upper layer
These signals are recorded as statistics (sum, count and vector), so they can be analyzed after
the simulation.
When the simulation is executed with the graphical user interface the module displays useful
statistics. If the link is operating, the datarate and number of received, sent and dropped
messages show in the tooltip. When the link is broken, the number of dropped messages
is displayed. The state of the module is indicated by the color of the module icon and the
connection (yellow=transmitting).
4.4
PPPInterface module
The PPPInterface is a compound module implementing the IWiredNic interface. It contains
a PPP module and a passive queue for the messages received from the network layer.
The queue type is specified by the queueType parameter. It can be set to NoQueue or to a
module type implementing the IOutputQueue interface. There are implementations with QoS
and RED support.
In typical use of the PPP module it is augmented with other nodes that monitor the traffic
or simulate package loss and duplication. The PPPInterface module abstract that usage by
adding IHook components to the network input and output of the PPP component. Any number of hook can be added by specifying the numOutputHooks and numInputHooks parameters
and the types of the outputHook and inputHook components. The hooks are chained in their
numeric order.
21
OMNeT++ Manual – Point-to-Point Links
22
OMNeT++ Manual – The Ethernet Model
Chapter 5
The Ethernet Model
5.1
Overview
Variations: 10Mb/s ethernet, fast ethernet, Gigabit Ethernet, Fast Gigabit Ethernet, full duplex
The Ethernet model contains a MAC model (EtherMAC), LLC model (EtherLLC) as well as a
bus (EtherBus, for modelling coaxial cable) and a hub (EtherHub) model. A switch model
(EtherSwitch) is also provided.
• EtherHost is a sample node with an Ethernet NIC;
• EtherSwitch, EtherBus, EtherHub model switching hub, repeating hub and the old
coxial cable;
• basic compnents of the model: EtherMAC, EtherLLC/EtherEncap module types, MACRelayUnit (MACRelayUnitNP and MACRelayUnitPP), EtherFrame message type, MACAddress class
Sample simulations:
• the MixedLAN model contains hosts, switch, hub and bus
• the LargeNet model contains hundreds of computers, switches and hubs (numbers depend on model configuration in largenet.ini) and mixes all kinds of Ethernet technologies
5.1.1
Implemented Standards
The Ethernet model operates according to the following standards:
• Ethernet: IEEE 802.3-1998
• Fast Ethernet: IEEE 802.3u-1995
• Full-Duplex Ethernet with Flow Control: IEEE 802.3x-1997
• Gigabit Ethernet: IEEE 802.3z-1998
23
OMNeT++ Manual – The Ethernet Model
5.2
Physical layer
The nodes of the Ethernet networks are connected by coaxial, twisted pair or fibre cables.
There are several cable types specified in the standard.
In the INET framework, the cables are represented by connections. The connections used in
Ethernet LANs must be derived from DatarateConnection and should have their delay and
datarate parameters set. The delay parameter can be used to model the distance between
the nodes. The datarate parameter can have four values:
• 10Mbps classic Ethernet
• 100Mbps Fast Ethernet
• 1Gbps Gigabit Ethernet
• 10Gbps Fast Gigabit Ethernet
5.2.1
EtherBus
The EtherBus component can model a common coaxial cable found in earlier Ethernet LANs.
The nodes are attached at specific positions of the cable. If a node sends a packet, it is
transmitted in both direction by a given propagation speed.
The gates of the EtherBus represent taps. The positions of the taps are given by the positions parameter as a space separated list of distances in metres. If there are more gates then
positions given, the last distance is repeated. The bus component send the incoming message
in one direction and a copy of the message to the other direction (except at the ends). The
propagation delays are computed from the distances of the taps and the propagationSpeed
parameter.
Messages are not interpreted by the bus model in any way, thus the bus model is not specific
to Ethernet in any way. Messages may represent anything, from the beginning of a frame
transmission to end (or abortion) of transmission.
5.2.2
EtherHub
Ethernet hubs are a simple broadcast devices. Messages arriving on a port are regenerated
and broadcast to every other port.
The connections connected to the hub must have the same data rate. Cable lengths should
be reflected in the delays of the connections.
Messages are not interpreted by the EtherType hub model in any way, thus the hub model
is not specific to Ethernet. Messages may represent anything, from the beginning of a frame
transmission to end (or abortion) of transmission.
The hub module collects the following statistics:
• pkBytes handled packets length (vector)
• messages/sec number of packets per seconds (scalar)
24
OMNeT++ Manual – The Ethernet Model
5.3
MAC layer
The Ethernet MAC (Media Access Control) layer transmits the Ethernet frames on the physical
media. This is a sublayer within the data link layer. Because encapsulation/decapsulation is
not always needed (e.g. switches does not do encapsulation/decapsulation), it is implemented
in a separate modules (EtherEncap and EtherLLC) that are part of the LLC layer.
Network layer
6
?
LLC
MAC Relay
MAC
6
?
Physical layer
Nowadays almost all Ethernet networks operate using full-duplex point-to-point connections
between hosts and switches. This means that there are no collisions, and the behaviour of the
MAC component is much simpler than in classic Ethernet that used coaxial cables and hubs.
The INET framework contains two MAC modules for Ethernet: the EtherMACFullDuplex is
simpler to understand and easier to extend, because it supports only full-duplex connections.
The EtherMAC module implements the full MAC functionality including CSMA/CD, it can
operate both half-duplex and full-duplex mode.
Packets and frames
The environment of the MAC modules is described by the IEtherMAC module interface. Each
MAC modules has gates to connect to the physical layer (phys$i and phys$o) and to connect to the upper layer (LLC module is hosts, relay units in switches): upperLayerIn and
upperLayerOut.
When a frame is received from the higher layers, it must be an EtherFrame, and with all
protocol fields filled out (including the destination MAC address). The source address, if left
empty, will be filled in with the configured address of the MAC.
Packets received from the network are EtherTraffic objects. They are messages representing
inter-frame gaps (EtherPadding), jam signals (EtherJam), control frames (EtherPauseFrame)
or data frames (all derived from EtherFrame). Data frames are passed up to the higher layers
without modification. In promiscuous mode, the MAC passes up all received frames; otherwise, only the frames with matching MAC addresses and the broadcast frames are passed
up.
Also, the module properly responds to PAUSE frames, but never sends them by itself – however, it transmits PAUSE frames received from upper layers. See section 5.3 for more info.
25
OMNeT++ Manual – The Ethernet Model
Queueing
When the transmission line is busy, messages received from the upper layer needs to be
queued.
In routers, MAC relies on an external queue module (see OutputQueue), and requests packets
from this external queue one-by-one. The name of the external queue must be given as the
queueModule parameer. There are implementations of OutputQueue to model finite buffer,
QoS and/or RED.
In hosts, no such queue is used, so MAC contains an internal queue named txQueue to queue
up packets waiting for transmission. Conceptually, txQueue is of infinite size, but for better
diagnostics one can specify a hard limit in the txQueueLimit parameter – if this is exceeded,
the simulation stops with an error.
PAUSE handling
The 802.3x standard supports PAUSE frames as a means of flow control. The frame contains
a timer value, expressed as a multiple of 512 bit-times, that specifies how long the transmitter
should remain quiet. If the receiver becomes uncongested before the transmitter’s pause timer
expires, the receiver may elect to send another PAUSE frame to the transmitter with a timer
value of zero, allowing the transmitter to resume immediately.
EtherMAC will properly respond to PAUSE frames it receives (EtherPauseFrame class), however it will never send a PAUSE frame by itself. (For one thing, it doesn’t have an input buffer
that can overflow.)
EtherMAC, however, transmits PAUSE frames received by higher layers, and EtherLLC can be
instructed by a command to send a PAUSE frame to MAC.
Error handling
If the MAC is not connected to the network ("cable unplugged"), it will start up in "disabled"
mode. A disabled MAC simply discards any messages it receives. It is currently not supported
to dynamically connect/disconnect a MAC.
CRC checks are modeled by the bitError flag of the packets. Erronous packets are dropped
by the MAC.
Signals and statistics
Both MAC modules emits the following signals:
• txPk after successful data frame transmission, the data frame
• rxPkOk after successful data frame reception, the data frame
• txPausePkUnits after PAUSE frame sent, the pause time
• rxPausePkUnits after PAUSE frame received, the pause time
• rxPkFromHL when a data frame received from higher layer, the data frame
• dropPkNotForUs when a data frame received not addressed to the MAC, the data frame
26
OMNeT++ Manual – The Ethernet Model
• dropPkBitError when a frame received with bit error, the frame
• dropPkIfaceDown when a message received and the MAC is not connected, the dropped
message
• packetSentToLower before starting to send a packet on phys$o gate, the packet
• packetReceivedFromLower after a packet received on phys$i gate, the packet (excluding
PAUSE and JAM messages and dropped data frames)
• packetSentToUpper before sending a packet on upperLayerOut, the packet
• packetReceivedFromUpper after a packet received on upperLayerIn, the packet
Apart from statistics can be generated from the signals, the modules collects the following
scalars:
• simulated time total simulation time
• full duplex boolean value, indicating whether the module operated in full-duplex mode
• frames/sec sent data frames sent (not including PAUSE frames) per second
• frames/sec rcvd data frames received (not including PAUSE frames) per second
• bits/sec sent
• bits/sec rcvd
Note that four of these scalars could be recorded as the count and value of the txPkBytesSignal and rxPkBytesSignal signals resp.
Visual effects
In the graphical environment, some animation effects help to follow the simulation. The color
of the transmission channel is changed to yellow during transmission, and turns to red when
collision detected. The icon of disconnected MAC modules are grayed out.
The icon of the Ethernet NICs are also colored according to the state of MAC module: yellow
if transmitting, blue if receiving, red if collision detected, white in backoff and gray in paused
state.
5.3.1
EtherMACFullDuplex
From the two MAC implementation EtherMACFullDuplex is the simpler one, it operates only
in full-duplex mode (its duplexEnabled parameter fixed to true in its NED definition). This
module does not need to implement CSMA/CD, so there is no collision detection, retransmission with exponential backoff, carrier extension and frame bursting. Flow control works as
described in section 5.3.
In the EtherMACFullDuplex module, packets arrived at the phys$i gate are handled when
their last bit received.
Outgoing packets are transmitted according to the following state diagram:
27
OMNeT++ Manual – The Ethernet Model
TX_IDLE
PAUSE frame rcvd
PAUSE
pause time elapsed
PAUSE frame rcvd
frame rcvd from upper layer
pause time elapsed
queued msgs
tx finished
PAUSE frame rcvd
tx finished
no queued msgs
WAIT_IFG
96 bittime elapsed
tx finished
queued msgs, no PAUSE
TRANSMITTING
The EtherMACFullDuplex module records two scalars in addition to the ones mentioned
earlier:
• rx channel idle (%): reception channel idle time as a percentage of the total simulation time
• rx channel utilization (%): total reception time as a percentage of the total simulation time
5.3.2
EtherMAC
Ethernet MAC layer implementing CSMA/CD. It supports both half-duplex and full-duplex
operations; in full-duplex mode it behaves as EtherMACFullDuplex. In half-duplex mode
it detects collisions, sends jam messages and retransmit frames upon collisions using the
exponential backoff algorithm. In Gigabit Ethernet networks it supports carrier extension
and frame bursting. Carrier extension can be turned off by setting the carrierExtension
parameter to false.
Unlike EtherMACFullDuplex, this MAC module processes the incoming packets when their
first bit is received. The end of the reception is calculated by the MAC and detected by
scheduling a self message.
When frames collide the transmission is aborted – in this case the transmitting station transmits a jam signal. Jam signals are represented by a EtherJam message. The jam message
contains the tree identifier of the frame whose transmission is aborted. When the EtherMAC
receives a jam signal, it knows that the corresponding transmission ended in jamming and
have been aborted. Thus when it receives as many jams as collided frames, it can be sure that
the channel is free again. (Receiving a jam message marks the beginning of the jam signal, so
actually has to wait for the duration of the jamming.)
The operation of the MAC module can be schematized by the following state chart:
28
OMNeT++ Manual – The Ethernet Model
TX_IDLE
msg from upper
no burst
WAIT_IFG
msg from upper
in burst
tx finished
gap time elapsed
tx finished
next
TRANSMITTING
gap sent
no carrier
too many attempts
tx finished
next in burst
SEND_IFG
carrier detected
collision
collision
JAMMING
jam sent
BACKOFF
The module generates these extra signals:
• collision when collision starts (received a frame, while transmitting or receiving another one; or start to transmit while receiving a frame), the constant value 1
• backoff when jamming period ended and before waiting according to the exponential
backoff algorith, the constant value 1
These scalar statistics are generated about the state of the line:
• rx channel idle (%) reception channel idle time (full duplex) or channel idle time
(half-duplex), as a percentage of the total simulation time
• rx channel utilization (%) total successful reception time (full-duplex) or total successful reception/transmission time (half duplex), as a percentage of the total simulation
time
• rx channel collision (%) total unsuccessful reception time, as a percentage of the
total simulation time
• collisions total number collisions (same as count of collisionSignal)
• backoffs total number of backoffs (same as count of backoffSignal)
5.4
Switches
Ethernet switches play an important role in modern Ethernet LANs. Unlike passive hubs and
repeaters, that work in the physical layer, the switches operate in the data link layer and
routes data frames between the connected subnets.
While a hub repeats the data frames on each connected line, possibly causing collisions,
switches help to segment the network to small collision domains. In modern Gigabit LANs
each node is connected to the switch direclty by full-duplex lines, so no collisions are possible.
In this case the CSMA/CD is not needed and the channel utilization can be high.
29
OMNeT++ Manual – The Ethernet Model
5.4.1
MAC relay units
INET framework ethernet switches are built from IMACRelayUnit components. Each relay
unit has N input and output gates for sending/receiving Ethernet frames. They should be
connected to IEtherMAC modules.
Internally the relay unit holds a table for the destination address -> output port mapping.
When it receives a data frame it updates the table with the source address->input port. The
table can also be pre-loaded from a text file while initializing the relay unit. The file name
given as the addressTableFile parameter. Each line of the file contains a hexadecimal MAC
address and a decimal port number separated by tabs. Comment lines beginning with ’#’ are
also allowed:
01 ff ff ff ff 0
00-ff-ff-ee-d1 1
0A:AA:BC:DE:FF 2
The size of the lookup table is restricted by the addressTableSize parameter. When the table
is full, the oldest address is deleted. Entries are also deleted if their age exceeds the duration
given as the agingTime parameter.
If the destination address is not found in the table, the frame is broadcasted. The frame is not
sent to the same subnet it was received from, because the target already received the original
frame. The only exception if the frame arrived through a radio channel, in this case the
target can be out of range. The port range 0..numWirelessPorts-1 are reserved for wireless
connections.
The IMACRelayUnit module is not a concrete implementation, it just defines gates and parameters an IMACRelayUnit should have. Concrete inplementations add capacity and performance aspects to the model (number of frames processed per second, amount of memory
available in the switch, etc.) C++ implementations can subclass from the class MACRelayUnitBase.
There are two versions of IMACRelayUnit:
MACRelayUnitNP models one or more CPUs with shared memory, working from a single
shared queue.
MACRelayUnitPP models one CPU assigned to each incoming port, working with shared memory but separate queues.
In both models input messages are queued. CPUs poll messages from the queue and process them in processingTime. If the memory usage exceeds bufferSize, the frame will be
dropped.
A simple scheme for sending PAUSE frames is built in (although users will probably change
it). When the buffer level goes above a high watermark, PAUSE frames are sent on all ports.
The watermark and the pause time is configurable; use zero values to disable the PAUSE
feature.
The relay units collects the following statistics:
usedBufferBytes memory usage as function of time
processedBytes count and length of processed frames
droppedBytes count and length of frames dropped caused by out of memory
30
OMNeT++ Manual – The Ethernet Model
5.4.2
EtherSwitch
Model of an Ethernet switch containing a relay unit and multiple MAC units.
The duplexChannel attributes of the MACs must be set according to the medium connected
to the port; if collisions are possible (it’s a bus or hub) it must be set to false, otherwise it can
be set to true. By default it uses half duples MAC with CSMA/CD.
NOTE: Switches don’t implement the Spanning Tree Protocol. You need to avoid cycles
in the LAN topology.
5.5
5.5.1
Link Layer Control
Frame types
The raw 802.3 frame format header contains the MAC addresses of the destination and source
of the packet and the length of the data field. The frame footer contains the FCS (Frame Check
Sequence) field which is a 32-bit CRC.
MAC
MAC
destination source
6 octets
6 octets
Length
Payload
FCS
2 octets
46-1500
octets
4 octets
Each such frame is preceded by a 7 octet Preamble (with 10101010 octets) and a 1 octet SFD
(Start of Frame Delimiter) field (10101011) and followed by an 12 octet interframe gap. These
fields are added and removed in the MAC layer, so they are omitted here.
When multiple upper layer protocols use the same Ethernet line, the kernel has to know
which which component handles the incoming frames. For this purpose a protocol identifier
was added to the standard Ethernet frames.
The first solution preceded the 802.3 standard and used a 2 byte protocol identifier in place
of the Length field. This is called Ethernet II or DIX frame. Each protocol id is above 1536, so
the Ethernet II frames and the 802.3 frames can be distinguished.
MAC
MAC
destination source
6 octets
6 octets
EtherType Payload
2 octets
46-1500
octets
FCS
4 octets
The LLC frame format uses a 1 byte source, a 1 byte destination, and a 1 byte control information to identify the encapsulated protocol adopted from the 802.2 standard. These fields
follow the standard 802.3 header, so the maximum length of the payload is 1497 bytes:
MAC
MAC
destination source
6 octets
6 octets
Length
DSAP
SSAP
Control
Payload
FCS
2 octets
1 octets
1 octets
1 octets
43-1497
octets
4 octets
31
OMNeT++ Manual – The Ethernet Model
The SNAP header uses the EtherType protocol identifiers inside an LLC header. The SSAP and
DSAP fields are filled with 0xAA (SAP_SNAP), and the control field is 0x03. They are followed
by a 3 byte orgnaization and a 2 byte local code the identify the protocol. If the organization
code is 0, the local field contains an EtherType protocol identifier.
Length
DSAP
0xAA
SSAP
0xAA
Control
0x03
OrgCode
Local
Code
Payload
FCS
2 octets
1 octets
1 octets
1 octets
3 octets
2 octets
38-1492
octets
4 octets
MAC
MAC
destination source
6 octets
6 octets
The INET defines these frames in the EtherFrame.msg file. The models supports Ethernet II,
803.2 with LLC header, and 803.3 with LLC and SNAP headers. The corresponding classes
are: EthernetIIFrame, EtherFrameWithLLC and EtherFrameWithSNAP. They all class from
EtherFrame which only represents the basic MAC frame with source and destination addresses. EtherMAC only deals with EtherFrames, and does not care about the specific subclass.
Ethernet frames carry data packets as encapsulated cMessage objects. Data packets can be
of any message type (cMessage or cMessage subclass).
The model encapsulates data packets in Ethernet frames using the encapsulate() method
of cMessage. Encapsulate() updates the length of the Ethernet frame too, so the model doesn’t
have to take care of that.
The fields of the Ethernet header are passed in a Ieee802Ctrl control structure to the LLC
by the network layer.
EtherJam, EtherPadding (interframe gap), EtherPauseFrame?
5.5.2
EtherEncap
The EtherEncap module generates EthernetIIFrame messages.
EtherFrameII
5.5.3
EtherLLC
EtherFrameWithLLC
SAP registration
EtherLLC and higher layers
The EtherLLC module can serve several applications (higher layer protocols), and dispatch
data to them. Higher layers are identified by DSAP. See section "Application registration" for
more info.
EtherEncap doesn’t have the functionality to dispatch to different higher layers because in
practice it’ll always be used with IP.
Communication between LLC and Higher Layers
Higher layers (applications or protocols) talk to the EtherLLC module.
32
OMNeT++ Manual – The Ethernet Model
When a higher layer wants to send a packet via Ethernet, it just passes the data
packet (a cMessage or any subclass) to EtherLLC. The message kind has to be set to
IEEE802CTRL_DATA.
In general, if EtherLLC receives a packet from the higher layers, it interprets the message kind as a command. The commands include IEEE802CTRL_DATA (send a frame),
IEEE802CTRL_REGISTER_DSAP (register highher layer) IEEE802CTRL_DEREGISTER_DSAP
(deregister higher layer) and IEEE802CTRL_SENDPAUSE (send PAUSE frame) – see EtherLLC
for a more complete list.
The arguments to the command are NOT inside the data packet but in a "control info" data
structure of class Ieee802Ctrl, attached to the packet. See controlInfo() method of cMessage
(OMNeT++ 3.0).
For example, to send a packet to a given MAC address and protocol identifier, the application
sets the data packet’s message kind to ETH_DATA ("please send this data packet" command),
fills in the Ieee802Ctrl structure with the destination MAC address and the protocol identifier, adds the control info to the message, then sends the packet to EtherLLC.
When the command doesn’t involve a data packet (e.g. IEEE802CTRL_(DE)REGISTER_DSAP,
IEEE802CTRL_SENDPAUSE), a dummy packet (empty cMessage) is used.
Rationale
The alternative of the above communications would be:
• adding the parameters such as destination address into the data packet. This would be
a poor solution since it would make the higher layers specific to the Ethernet model.
• encapsulating a data packet into an interface packet which contains the destination
address and other parameters. The disadvantages of this approach is the overhead
associated with creating and destroying the interface packets.
Using a control structure is more efficient than the interface packet approach, because the
control structure can be created once inside the higher layer and be reused for every packet.
It may also appear to be more intuitive in Tkenv because one can observe data packets travelling between the higher layer and Ethernet modules – as opposed to "interface" packets.
EtherLLC: SAP Registration
The Ethernet model supports multiple applications or higher layer protocols.
So that data arriving from the network can be dispatched to the correct applications (higher
layer protocols), applications have to register themselves in EtherLLC. The registration is done
with the IEEE802CTRL_REGISTER_DSAP command (see section "Communication between
LLC and higher layers") which associates a SAP with the LLC port. Different applications have
to connect to different ports of EtherLLC.
The ETHERCTRL_REGISTER_DSAP/IEEE802CTRL_DEREGISTER_DSAP commands use only
the dsap field in the Ieee802Ctrl structure.
33
OMNeT++ Manual – The Ethernet Model
5.5.4
EthernetInterface module
The EthernetInterface compound module implements the IWiredNic interface. Complements EtherMAC and EtherEncap with an output queue for QoS and RED support. It also
has configurable input/output filters as IHook components similarly to the PPPInterface
module.
5.6
Ethernet applications
The inet.applications.ethernet package contains modules for a simple client-server application. The EtherAppCli is a simple traffic generator that peridically sends EtherAppReq
messages whose length can be configured. destAddress, startTime,waitType, reqLength, respLength
The server component of the model (EtherAppSrv) responds with a EtherAppResp message of
the requested length. If the response does not fit into one ethernet frame, the client receives
the data in multiple chunks.
Both applications have a registerSAP boolean parameter. This parameter should be set to
true if the application is connected to the EtherLLC module which requires registration of
the SAP before sending frames.
Both applications collects the following statistics: sentPkBytes, rcvdPkBytes, endToEndDelay.
The client and server application works with any model that accepts Ieee802Ctrl control info
on the packets (e.g. the 802.11 model). The applications should be connected directly to the
EtherLLC or an EthernetInterface NIC module.
The model also contains a host component that groups the applications and the LLC and
MAC components together (EtherHost). This node does not contain higher layer protocols,
it generates Ethernet traffic directly. By default it is configured to use half duplex MAC
(CSMA/CD).
5.7
Ethernet networks
5.7.1 LargeNet model
The LargeNet model demonstrates how one can put together models of large LANs with little
effort, making use of MAC auto-configuration.
LargeNet models a large Ethernet campus backbone. As configured in the default omnetpp.ini, it contains altogether about 8000 computers and 900 switches and hubs. This
results in about 165MB process size on my (32-bit) linux box when I run the simulation. The
model mixes all kinds of Ethernet technology: Gigabit Ethernet, 100Mb full duplex, 100Mb
half duplex, 10Mb UTP, 10Mb bus ("thin Ethernet"), switched hubs, repeating hubs.
The topology is in LargeNet.ned, and it looks like this: there’s chain of n=15 large "backbone"
switches (switchBB[]) as well as four more large switches (switchA, switchB, switchC, switchD)
connected to somewhere the middle of the backbone (switchBB[4]). These 15+4 switches make
up the backbone; the n=15 number is configurable in omnetpp.ini.
Then there’re several smaller LANs hanging off each backbone switch. There’re three types
of LANs: small, medium and large (represented by compound module types SmallLAN, MediumLAN, LargeLAN). A small LAN consists of a few computers on a hub (100Mb half duplex);
34
OMNeT++ Manual – The Ethernet Model
a medium LAN consists of a smaller switch with a hub on one of its port (and computers on
both); the large one also has a switch and a hub, plus an Ethernet bus hanging of one port of
the hub (there’s still hubs around with one BNC connector besides the UTP ones). By default
there’re 5..15 LANs of each type hanging off each backbone switch. (These numbers are also
omnetpp.ini parameters like the length of the backbone.)
The application model which generates load on the simulated LAN is simple yet powerful. It
can be used as a rough model for any request-response based protocol such as SMB/CIFS
(the Windows file sharing protocol), HTTP, or a database client-server protocol.
Every computer runs a client application (EtherAppCli) which connects to one of the servers.
There’s one server attached to switches A, B, C and D each: serverA, serverB, serverC and
serverD – server selection is configured in omnetpp.ini). The servers run EtherAppSrv.
Clients periodically send a request to the server, and the request packet contains how many
bytes the client wants the server to send back (this can mean one or more Ethernet frames,
depending on the byte count). Currently the request and reply lengths are configured in
omnetpp.ini as intuniform(50,1400) and truncnormal(5000,5000).
The volume of the traffic can most easily be controlled with the time period between sending
requests; this is currently set in omnetpp.ini to exponential(0.50) (that is, average 2 requests
per second). This already causes frames to be dropped in some of the backbone switches, so
the network is a bit overloaded with the current settings.
The model generates extensive statistics. All MACs (and most other modules too) write statistics into omnetpp.sca at the end of the simulation: number of frames sent, received, dropped,
etc. These are only basic statistics, however it still makes the scalar file to be several ten
megabytes in size. You can use the analysis tools provided with OMNeT++ to visualized the
data in this file. (If the file size is too big, writing statistics can be disabled, by putting
**.record-scalar=false in the ini file.) The model can also record output vectors, but this is
currently disabled in omnetpp.ini because the generated file can easily reach gigabyte sizes.
35
OMNeT++ Manual – The Ethernet Model
36
OMNeT++ Manual – The Radio Infrastructure
Chapter 6
The Radio Infrastructure
6.1
Overview
Blah blah blah
37
OMNeT++ Manual – The Radio Infrastructure
38
OMNeT++ Manual – The 802.11 Model
Chapter 7
The 802.11 Model
7.1
Overview
This chapter provides an overview of the IEEE 802.11 model for the INET Framework.
An IEEE 802.11 interface (NIC) comes in several flavours, differring in their role (ad-hoc
station, infrastructure mode station, or access point) and their level of detail:
1. Ieee80211Nic: a generic (configurable) NIC
2. Ieee80211NicAdhoc: for ad-hoc mode
3. Ieee80211NicAP, Ieee80211NicAPSimplified: for use in an access point
4. Ieee80211NicSTA, Ieee80211NicSTASimplified: for use in an infrastructure-mode
station
NICs consist of four layers, which are the following (in top-down order):
1. agent
2. management
3. MAC
4. physical layer (radio)
The physical layer modules (Ieee80211Radio; with some limitations, SnrEval80211, Decider80211 can also be used) deal with modelling transmission and reception of frames.
They model the characteristics of the radio channel, and determine if a frame was received
correctly (that is, it did not suffer bit errors due to low signal power or interference in the
radio channel). Frames received correctly are passed up to the MAC. The implementation of
these modules is based on the Mobility Framework.
The MAC layer (Ieee80211Mac) performs transmission of frames according to the CSMA/CA
protocol. It receives data and management frames from the upper layers, and transmits them.
The management layer performs encapsulation and decapsulation of data packets for the
MAC, and exchanges management frames via the MAC with its peer management entities
39
OMNeT++ Manual – The 802.11 Model
in other STAs and APs. Beacon, Probe Request/Response, Authentication, Association Request/Response etc frames are generated and interpreted by management entities, and transmitted/received via the MAC layer. During scanning, it is the management entity that periodically switches channels, and collects information from received beacons and probe responses.
The management layer has several implementations which differ in their role (STA/AP/ad-hoc)
and level of detail: Ieee80211MgmtAdhoc, Ieee80211MgmtAP, Ieee80211MgmtAPSimplified,
Ieee80211MgmtSTA, Ieee80211MgmtSTASimplified. The ..Simplified ones differ from the
others in that they do not model the scan-authenticate-associate process, so they cannot be
used in experiments involving handover.
The agent is what instructs the management layer to perform scanning, authentication and
association. The management layer itself just carries out these commands by performing
the scanning, authentication and association procedures, and reports back the results to the
agent.
The agent layer is currenly only present in the Ieee80211NicSTA NIC module, as an
Ieee80211AgentSTA module. The managament entities in other NIC variants do not have
as much freedom as to need an agent to control them.
By modifying or replacing the agent, one can alter the dynamic behaviour of STAs in the
network, for example implement different handover strategies.
7.1.1
Limitations
See the documentation of Ieee80211Mac for features unsupported by this model.
TODO further details about the implementation: what is modelled and what is not (beacons,
auth, ...), communication between modules, frame formats, ...
40
OMNeT++ Manual – Node Mobility
Chapter 8
Node Mobility
8.1
Overview
In order to accurately evaluate a protocol for an ad-hoc network, it is important to use a realistic model for the motion of mobile hosts. Signal strengths, radio interference and channel
occupancy depends on the distances between nodes. The choice of the mobility model can
significantly influence the results of a simulation (e.g. data packet delivery ratio, end-to-end
delay, average hop count) as shown in [CBD02].
There are two methods for incorporating mobility into simulations: using traces and synthetic
models. Traces contains recorded motion of the mobile hosts, as observed in real life system.
Synthetic models use mathematical models for describing the behaviour of the mobile hosts.
There are mobility models that represent mobile nodes whose movements are independent of
each other (entity models) and mobility models that represent mobile nodes whose movements
are dependent on each other (group models). Some of the most frequently used entity models
are the Random Walk Mobility Model, Random Waypoint Mobility Model, Random Direction
Mobility Model, Gauss-Markov Mobility Model, City Section Mobility Model. The group models
include the Column Mobility Model, Nomadic Community Mobility Model, Pursue Mobility
Model, Reference Point Group Mobility Model.
The INET framework has components for the following trace files:
• Bonn Motion native file format of the BonnMotion scenario generation tool.
• Ns2 trace file generated by the CMU’s scenario generator that used in Ns2.
• ANSim XML trace file of the ANSim (Ad-Hoc Network Simulation) tool.
It is easy to integrate new entity mobility models into the INET framework, but group mobility
is not supported yet. Therefore all the models shipped with INET are implementations of
entitiy models:
• Deterministic Motions for fixed position nodes and nodes moving on a linear, circular,
rectangular paths.
• Random Waypoint model includes pause times between changes in destination and
speed.
41
OMNeT++ Manual – Node Mobility
• Gauss-Markov model uses one tuning parameter to vary the degree of randomness in
mobility pattern.
• Mass Mobility models a mass point with inertia and momentum.
• Chiang Mobility uses a probabilistic transition matrix to change the state of motion of
the node.
8.2
Mobility in INET
In INET mobile nodes have to contain a module implementing the IMobility marker interface. This module stores the current coordinates of the node and is responsible for updating
the position periodically and emitting the mobilityStateChanged signal when the position
changed.
The p[0] and p[1] fields of the display string of the node is also updated, so if the simulation
run is animated, the node is actually moving on the screen. The current position of the node
can be obtained from the display string.
The radio simulations has a ChannelControl module that takes case of establishing communication channels between nodes that are within communication distance and tearing down
the connections when they move out of range. The ChannelControl module uses to mobilityStateChanged signal to determine when the connection status needs to be updated.
There are two possibilities to implement a new mobility model. The simpler but limited one is
to use TurtleMobility as the mobility component and to write a script similar to the turtle
graphics of LOGO. The second is to implement a simple module in C++. In this case the
C++ class of the mobility module should be derived from IMobility and its NED type should
implement the IMobility interface.
8.2.1
MobilityBase class
The abstract MobilityBase class is the base of the mobility modules defined in the INET
framework. This class allows to define a cubic volume that the node can not leave. The
volume is configured by setting the constraintAreaX, constraintAreaY, constraintAreaZ,
constraintAreaWidth, constraintAreaHeight and constraintAreaDepth parameters.
When the module is initialized it sets the initial position of the node by calling the initializePosition() method. The default implementation of this method sets the position from the
display string if the initFromDisplayString parameter is true. Otherwise the position can
be given as the initialX, initialY and initialZ parameters. If neither of these parameters
are given, a random initial position is choosen within the contraint area.
The module is responsible for periodically updating the position. For this purpose it should
send timer messages to itself. These messages are processed in the handleSelfMessage
method. In derived classes, handleSelfMessage should compute the new position and update the display string and publish the new position by calling the positionUpdated method.
When the node reaches the boundary of the constraint area, the mobility component has to
prevent the node to exit. It can call the handleIfOutside method, that offers the following
policies:
• reflect of the wall
• reappear at the opposite edge (torus area)
42
OMNeT++ Manual – Node Mobility
• placed at a randomly chosen position of the area
• stop the simulation with an error
8.2.2
MovingMobilityBase
The abstract MovingMobilityBase class can be used to model mobilities when the node
moves on a continous trajectory and updates its position periodically. Subclasses only need
to implement the move method that is responsible to update the current position and speed
of the node.
The abstract move method is called autmotically in every updateInterval steps. The method
is also called when a client requested the current position or speed or when the move method
requested an update at a future moment by setting the nextChange field. This can be used
when the state of the motion changes at a specific time that is not a multiple of updateInterval. The method can set the stationary field to true to indicate that the node reached
its final position and no more position update is needed.
8.2.3
LineSegmentsMobilityBase
The path of a mobile node often consist of linear movements of constant speed. The node
moves with some speed for some time, then with another speed for another duration and so
on. If a mobility model fits this description, it might be suitable to derive the implementing
C++ class from LineSegmentsMobilityBase.
The module first choose a target position and a target time by calling the setTargetPosition
method. If the target position differs from the current position, it starts to move toward the
target and updates the position in the configured updateInterval intervals. When the target
position reached, it chooses a new target.
8.3
Implemented models
8.3.1
Deterministic movements
StationaryMobility This mobility module does nothing; it can be used for stationary nodes.
StaticGridMobility Places all nodes in a rectangular grid.
LinearMobility This is a linear mobility model with speed, angle and acceleration parameters.
Angle only changes when the mobile node hits a wall: then it reflects off the wall at the
same angle.
z coordinate is constant movement is always parallel with X-Y plane
CircleMobility Moves the node around a circle parallel to the X-Y plane with constant speed.
The node bounces from the bounds of the constraint area. The circle is given by the cx,
cy and r parameters, The initial position determined by the startAngle parameter. The
position of the node is refreshed in updateInterval steps.
RectangleMobility Moves the node around the constraint area. configuration: speed, startPos, updateInterval
43
OMNeT++ Manual – Node Mobility
TractorMobility Moves a tractor through a field with a certain amount of rows. The following
figure illustrates the movement of the tractor when the rowCount parameter is 2. The
trajectory follows the segments in 1, 2, 3, 4, 5, 6, 7, 8, 1, 2, 3 . . . order. The area is configured
by the x1, y1, x2, y2 parameters.
(x1 , y1 )
-1
?
2
8
6
3
7
4?
6
6
-5
(x2 , y2 )
8.3.2
Random movements
RandomWPMobility In the Random Waypoint mobility model the nodes move in line segments. For each line segment, a random destination position (distributed uniformly over
the playground) and a random speed is chosen. You can define a speed as a variate from
which a new value will be drawn for each line segment; it is customary to specify it as
uniform(minSpeed, maxSpeed). When the node reaches the target position, it waits
for the time waitTime which can also be defined as a variate. After this time the the
algorithm calculates a new random position, etc.
GaussMarkovMobility The Gauss-Markov model contains a tuning parameter, that control
the randomness in the movement of the node. Let the magnitude and direction of speed
of the node at the nth time step be sn and dn . The next speed and direction is computed
as
sn+1 = αsn + (1 − α)s̄ +
p
dn+1 = αsn + (1 − α)d¯ +
p
(1 − α2 )dxn
(1 − α2 )sxn
where s̄ and d¯ are constants representing the mean value of speed and direction as
n → ∞; and sxn and dxn are random variables with Gaussian distribution.
Totally random walk (Brownian motion) is obtained by setting α = 0, while α = 1 results
a linear motion.
To ensure that the node does not remain at the boundary of the constraint area for a long
¯ modified as the node enters the margin area.
time, the mean value of the direction (d)
For example at the right edge of the area it is set to 180 degrees, so the new direction is
away from the edge.
MassMobility This is a random mobility model for a mobile host with a mass. It is the one
used in [Pea99].
"An MH moves within the room according to the following pattern. It moves
along a straight line for a certain period of time before it makes a turn. This
moving period is a random number, normally distributed with average of 5
seconds and standard deviation of 0.1 second. When it makes a turn, the
44
OMNeT++ Manual – Node Mobility
new direction (angle) in which it will move is a normally distributed random
number with average equal to the previous direction and standard deviation of
30 degrees. Its speed is also a normally distributed random number, with a
controlled average, ranging from 0.1 to 0.45 (unit/sec), and standard deviation
of 0.01 (unit/sec). A new such random number is picked as its speed when it
makes a turn. This pattern of mobility is intended to model node movement
during which the nodes have momentum, and thus do not start, stop, or turn
abruptly. When it hits a wall, it reflects off the wall at the same angle; in our
simulated world, there is little other choice."
This implementation can be parameterized a bit more, via the changeInterval,
changeAngleBy and changeSpeedBy parameters. The parameters described above correspond to the following settings:
changeInterval = normal(5, 0.1)
changeAngleBy = normal(0, 30)
speed = normal(avgSpeed, 0.01)
ChiangMobility Chiang’s random walk movement model ([Chi98]).
In this model, the state of the mobile node in each direction (x and y) can be:
• 0: the node stays in its current position
• 1: the node moves forward
• 2: the node moves backward
The (i, j) element of the state transition matrix determines the probability that the state
changes from i to j:
0
0.3
0.3
0.5
0.7
0
0.5
0
0.7
The ChiangMobility module supports the following parameters:
• updateInterval position update interval
• stateTransitionInterval state update interval
• speed: the speed of the node
ConstSpeedMobility ConstSpeedMobility does not use one of the standard mobility approaches. The user can define a velocity for each Host and an update interval. If the
velocity is greater than zero (i.e. the Host is not stationary) the ConstSpeedMobility
module calculates a random target position for the Host. Depending to the update interval and the velocity it calculates the number of steps to reach the destination and the
step-size. Every update interval ConstSpeedMobility calculates the new position on its
way to the target position and updates the display. Once the target position is reached
ConstSpeedMobility calculates a new target position.
This component has been taken over from Mobility Framework 1.0a5.
45
OMNeT++ Manual – Node Mobility
8.3.3
Replaying trace files
BonnMotionMobility Uses the native file format of BonnMotion.
The file is a plain text file, where every line describes the motion of one host. A line
consists of one or more (t, x, y) triplets of real numbers, like:
t1 x1 y1 t2 x2 y2 t3 x3 y3 t4 x4 y4 ...
The meaning is that the given node gets to (xk, yk) at tk. There’s no separate notation for
wait, so x and y coordinates will be repeated there.
Ns2Mobility Nodes are moving according to the trace files used in NS2. The trace file has
this format:
# ’#’ starts a comment, ends at the end of line
$node_() set X_ # sets x coordinate of the node identified by
$node_() set Y_ # sets y coordinate of the node identified by
$node_() set Z_ # sets z coordinate (ignored)
$ns at $time "$node_() setdest " # at $time start moving
towards , with
The Ns2MotionMobility module has the following parameters:
• traceFile the Ns2 trace file
• nodeId node identifier in the trace file; -1 gets substituted by parent module’s index
• scrollX,scrollY user specified translation of the coordinates
ANSimMobility reads trace files of the ANSim Tool.
The nodes are moving along linear segments described by an XML trace file conforming
to this DTD:
position_change (node_id, start_time, end_time, destination)>
node_id (#PCDATA)>
start_time (#PCDATA)>
end_time (#PCDATA)>
destination (xpos, ypos)>
xpos (#PCDATA)>
ypos (#PCDATA)>
Parameters of the module:
• ansimTrace the trace file
• nodeId the node_id of this node, -1 gets substituted to parent module’s index
NOTE: The ANSimMobility module process only the position_change elements and it
ignores the start_time attribute. It starts the move on the next segment immediately.
46
OMNeT++ Manual – Node Mobility
8.4
Mobility scripts
The TurtleMobility module can be parametrized by a script file containing LOGO-style
movement commands in XML format.
The module has these parameters:
• updateInterval time interval to update the hosts position
• constraintAreaX, constraintAreaY, constraintAreaWidth,
Height: constraint area that the node can not leave
constraintArea-
• turtleScript XML file describing the movements
The content of the XML file should conform to the following DTD (can be found as TurtleMobility.dtd in the source tree):
The file contains movement elements, each describing a trajectory. The id attribute of the
movement element can be used to refer the movement from the ini file using the syntax:
47
OMNeT++ Manual – Node Mobility
**.mobility.turtleScript = xmldoc("turtle.xml", "movements//movement[@id=’1’]")
The motion of the node is composed of uniform linear segments. The state of motion is
described by the following variables:
• position: (x, y) coordinate of the current location of the node
• speed, angle: magnitude and direction of the node’s velocity
• targetPos: target position of the current line segment. If given the speed and angle is
not used
• targetTime the end time of the current linear motion
• borderPolicy: one of
– reflect the node reflects at the boundary,
– wrap the node appears at the other side of the area,
– placerandomly the node placed at a random position of the area,
– error signals an error when the node reaches the boundary
The movement elements may contain the the following commands:
• repeat(n) repeats its content n times, or indefinetly if the n attribute is omitted.
• set(x,y,speed,angle,borderPolicy) modifies the state of the node.
• forward(d,t) moves the node for t time or to the d distance with the current speed. If
both d and t is given, then the current speed is ignored.
• turn(angle) increase the angle of the node by angle degrees.
• moveto(x,y,t) moves to point (x, y) in the given time. If t is not specified, it is computed
from the current speed.
• moveby(x,y,t) moves by offset (x, y) in the given time. If t is not specified, it is computed
from the current speed.
• wait(t) waits for the specified amount of time.
Attribute values must be given without physical units, distances are assumed to be given as
meters, time intervals in seconds and speeds in meter per seconds. Attibutes can contain expressions that are evaluated each time the command is executed. The limits of the constraint
area can be referenced as $MINX, $MAXX, $MINY, and $MAXY. Random number distibutions
generate a new random number when evaluated, so the script can describe random as well as
deterministic scenarios.
To illustrate the usage of the module, we show how some mobility models can be implemented
as scripts:
• RectangleMobility:
48
OMNeT++ Manual – Node Mobility
• Random Waypoint:
• MassMobility:
49
OMNeT++ Manual – Node Mobility
50
OMNeT++ Manual – IPv4
Chapter 9
IPv4
9.1
Overview
The IP protocol is the workhorse protocol of the TCP/IP protocol suite. All UDP, TCP, ICMP
packets are encapsulated into IP datagrams and transported by the IP layer. While higher
layer protocols transfer data among two communication end-point, the IP layer provides an
hop-by-hop, unreliable and connectionless delivery service. IP does not maintain any state
information about the individual datagrams, each datagram handled independently.
The nodes that are connected to the Internet can be either a host or a router. The hosts
can send and recieve IP datagrams, and their operating system implements the full TCP/IP
stack including the transport layer. On the other hand, routers have more than one interface
cards and perform packet routing between the connected networks. Routers does not need
the transport layer, they work on the IP level only. The division between routers and hosts is
not strict, because if a host have several interfaces, they can usually be configured to operate
as a router too.
Each node on the Internet has a unique IP address. IP datagrams contain the IP address of the
destination. The task of the routers is to find out the IP address of the next hop on the local
network, and forward the packet to it. Sometimes the datagram is larger, than the maximum
datagram that can be sent on the link (e.g. Ethernet has an 1500 bytes limit.). In this case
the datagram is split into fragments and each fragment is transmitted independently. The
destination host must collect all fragments, and assemble the datagram, before sending up
the data to the transport layer.
9.1.1
INET modules
The INET framework contains several modules to build the IPv4 network layer of hosts and
routers:
• IPv4 is the main module that implements RFC791. This module performs IP encapsulation/decapsulation, fragmentation and assembly, and routing of IP datagrams.
• The RoutingTable is a helper module that manages the routing table of the node. It
is queried by the IPv4 module for best routes, and updated by the routing daemons
implementing RIP, OSPF, Manet, etc. protocols.
51
OMNeT++ Manual – IPv4
• The ICMP module can be used to generate ICMP error packets. It also supports ICMP
echo applications.
• The ARP module performs the dynamic translation of IP addresses to MAC addresses.
• The IGMPv2 module to generate and process multicast group membership reports.
These modules are assembled into a complete network layer module called NetworkLayer.
This module has dedicated gates for TCP, UDP, SCTP, RSVP, OSPF, Manet, and Ping higher
layer protocols. It can be connected to several network interface cards: Ethernet, PPP, Wlan,
or external interfaces. The NetworkLayer module is used to build IPv4 hosts (StandardHost)
and routers (Router).
The implementation of these modules are based on the following RFCs:
• RFC791: Internet Protocol
• RFC792: Internet Control Message Protocol
• RFC826: Address Resolution Protocol
• RFC1122: Requirements for Internet Hosts - Communication Layers
• RFC2236: Internet Group Management Protocol, Version 2
The subsequent sections describe the IPv4 modules in detail.
9.2
The IPv4 Module
The IPv4 module implements the IPv4 protocol.
For connecting the upper layer protocols the IPv4 module has transportIn[] and transportOut[]
gate vectors.
The IP packets are sent to the ARP module through the queueOut gate. The incoming IP
packets are received directly from the network interface cards through the queueIn[] gates.
Each interface card knows its own network layer gate index.
The C++ class of the IPv4 module is derived from QueueBase. There is a processing time associated with each incoming packet. This processing time is specified by the procDelay module
parameter. If a packet arrives, when the processing of a previous has not been finished, it is
placed in a FIFO queue.
The current performance model assumes that each datagram is processed within the same
time, and there is no priority between the datagrams. If you need a more sophisticated performance model, you may change the module implementation (the IP class), and:
1. override the startService() method which determines processing time for a packet, or
2. use a different base class.
9.2.1
IP packets
IP datagrams start with a variable length IP header. The minimum length of the header is
20 bytes, and it can contain at most 40 bytes for options, so the maximum length of the IP
header is 60 bytes.
52
OMNeT++ Manual – IPv4
0
3
4
7
Version IHL
8
15 16
Flags
Protocol
23 24
31
Total Length
Type of Service
Identification
Time to Live
18 19
Fragment Offset
Header Checksum
Source Address
Destination Address
Options
Padding
The Version field is 4 for IPv4. The 4-bit IHL field is the number of 32-bit words in the
header. It is needed because the header may contain optional fields, so its length may vary.
The minimum IP header length is 20, the maximum length is 60. The header is always
padded to multiple of 4 bytes. The Type of Service field designed to store priority and
preference values of the IP packet, so applications can request low delay, high throughput,
and maximium reliability from the routing algorithms. In reality these fields are rarely set by
applications, and the routers mostly ignore them. The Total Length field is the length of
the whole datagram in bytes. The Identification field is used for identifying the datagram
sent by a host. It is usually generated by incrementing a counter for each outgoing datagram.
When the datagram gets fragmented by a router, its Identification field is kept unchanged
to the other end can collect them. In datagram fragments the Fragment Offset is the address
of the fragment in the payload of the original datagram. It is measured in 8-byte units, so
fragment lengths must be a multiple of 8. Each fragment except the last one, has its MF (more
fragments) bit set in the Flags field. The other used flag in Flags is the DF (don’t fragment) bit
which forbids the fragmentation of the datagram. The Time to Live field is decremented by
each router in the path, and the datagram is dropped if it reached 0. Its purpose is to prevent
endless cycles if the routing tables are not properly configured, but can be used for limiting
hop count range of the datagram (e.g. for local broadcasts, but the traceroute program
uses this field too). The Protocol field is for demultiplexing the payload of the IP datagram
to higher level protocols. Each transport protocol has a registered protocol identifier. The
Header Checksum field is the 16-bit one’s complement sum of the header fields considered
as a sequence of 16-bit numbers. The Source Address and Destination Address are the
IPv4 addresses of the source and destination respectively.
The Options field contains 0 or more IP options. It is always padded with zeros to a 32-bit
boundary. An option is either a single-byte option code or an option code + option length
followed by the actual values for the option. Thus IP implementations can skip unknown
options.
An IP datagram is represented by the IPv4Datagram message class. It contains variables
corresponding the fields of the IP header, except:
• Header Checksum omitted, modeled by error bit of packets
• Options only the following options are permitted and the datagram can contain at most
one option:
– Loose Source Routing
– Strict Source Routing
– Timestamp
– Record Route
53
OMNeT++ Manual – IPv4
The Type of Service field is called diffServCodePoint in IPv4Datagram.
Before sending the IPv4Datagram through the network, the IPv4 module attaches a
IPv4RoutingDecision control info. The control info contains the IP address of the next
hop, and the identifier of the interface it should be sent. The ARP module translate the IP
address to the hardware address on the local net of the specified interface and forwards the
datagram to the interface card.
9.2.2
Interface with higher layer
Higher layer protocols should be connected to the transportIn/transportOut gates of the
IPv4 module.
Sending packets
Higher layer protocols can send a packet by attaching a IPv4ControlInfo object to their
packet and sending it to the IPv4 module.
The following fields must be set in the control info:
• procotol: the Protocol field of the IP datagram. Valid values are defined in the IPProtocolId enumeration.
• destAddr: the Destination Address of the IP datagram.
Optionally the following fields can be set too:
• scrAddr: Source Address of the IP datagram. If given it must match with the address
of one of the interfaces of the node, but the datagram is not necessarily routed through
that interface. If left unspecified, then the address of the outgoing interface will be used.
• timeToLive: TTL of the IP datagram or -1 (unspecified). If unspecified then the TTL of
the datagram will be 1 for destination addresses in the 224.0.0.0 – 224.0.0.255 range.
(Datagrams with these special multicast addresses do not need to go further that one
hop, routers does not forward these datagrams.) Otherwise the TTL field is determined
by the defaultTimeToLive or defaultMCTimeToLive module parameters depending
whether the destination address is a multicast address or not.
• dontFragment: the Don’t Fragment flag of the outgoing datagram (default is false)
• diffServCodePoint: the Type of Service field of the outgoing datagram. (ToS is
called diffServCodePoint in IPv4Datagram too.)
• multicastLoop: if true, then a copy of the multicast datagrams are sent to the loopback
interface, so applications on the same host can receive it.
• interfaceId: id of outgoing interface (can be used to limit broadcast or restrict routing).
• nextHopAddr: explicit routing info, used by Manet DSR routing. If specified, then interfaceId must also be specified. Ignored in Manet routing is disabled.
The IP module encapsulates the transport layer datagram into an IPv4Datagram and fills in
the header fields according to the control info. The Identification field is generated by
incrementing a counter.
54
OMNeT++ Manual – IPv4
The generated IP datagram is passed to the routing algorithm. The routing decides if the datagram should be delivered locally, or passed to one of the network interfaces with a specified
next hop address, or broadcasted on one or all of the network interfaces. The details of the
routing is described in the next subsection (9.2.3) in detail.
Before sending the datagram on a specific interface, the IPv4 module checks if the packet
length is smaller than the MTU of the interface. If not, then the datagram is fragmented. When
the Don’t Fragment flag forbids fragmentation, an Destination Unreachable ICMP error
is generated with the Fragmentation Error (5) error code.
NOTE: Each fragment will encapsulate the whole higher layer datagram, although the
length of the IP datagram corresponds to the fragment length.
The fragments are sent to the ARP module through the queueOut gate. The ARP module
forwards the datagram immediately to point-to-point interface cards. If the outgoing interface
is a 802.x card, then before forwarding the datagram it performs address resolution to obtain
the MAC address of the destination.
Receiving packets
The IPv4 module of hosts processes the datagrams received from the network in three steps:
1. Reassemble fragments
2. Decapsulate the transport layer datagram
3. Dispatch the datagram to the appropriate transport protocol
When a fragment received, it is added to the fragment buffer of the IP. If the fragment was
the last fragment of a datagram, the processing of the datagram continues with step 2. The
fragment buffer stores the reception time of each fragment. Fragments older than fragmentTimeout are purged from the buffer. The default value of the timeout is 60s. The timeout is
only checked when a fragment is received, and at least 10s elapsed since the last check.
An IPv4ControlInfo attached to the decapsulated transport layer packet. The control info
contains fields copied from the IP header (source and destination address, protocol, TTL, ToS)
as well as the interface id through it was received. The control info also stores the original IP
datagram, because the transport layer might signal an ICMP error, and the ICMP packet must
encapsulate the erronous IP datagram.
NOTE: IP datagrams containing a DSR packet are not decapsulated, the unchanged IP
datagram is passed to the DSR module instead.
After decapsulation, the transport layer packet will be passed to the appropriate transport
protocol. It must be connected to one of the transportOut[] gate. The IPv4 module finds
the gate using the protocol id→ gate index mapping given in the protocolMapping string
parameter. The value must be a comma separated list of ”:” items.
For example the following line in the ini file maps TCP (6) to gate 0, UDP (17) to gate 1, ICMP
(1) to gate 2, IGMP (2) to gate 3, and RVSP (46) to gate 4.
**.ip.protocolMapping="6:0,17:1,1:2,2:3,46:4"
If the protocol of the received IP datagram is not mapped, or the gate is not connected, the
datagram will be silently dropped.
Some protocols are handled differently:
55
OMNeT++ Manual – IPv4
• ICMP: ICMP errors are delivered to the protocol whose packet triggered the error. Only
ICMP query requests and responses are sent to the ICMP module.
• IP: sent through preRoutingOut gate. (bug!)
• DSR: ??? (subsection about Manet routing?)
9.2.3
Routing, and interfacing with lower layers
The output of the network interfaces are connected to the queueIn gates of the IPv4 module. The incoming packets are either IP datagrams or ARP responses. The IP datagrams are
processed by the IPv4 module, the ARP responses are forwarded to the ARP.
The IPv4 module first checks the error bit of the incoming IP datagrams. There is a
headerlength/packetlength probability that the IP header contains the error (assuming 1 bit
error). With this probability an ICMP Parameter Problem generated, and the datagram is
dropped.
When the datagram does not contain error in the IP header, a routing decision is made. As a
result of the routing the datagram is either delivered locally, or sent out one or more output
interface. When it is sent out, the routing algorithm must compute the next hop of its route.
The details are differ, depending on that the destination address is multicast address or not.
When the datagram is decided to be sent up, it is processed as described in the previous
subsection (Receiving packets). If it is decided to be sent out through some interface, it
is actually sent to the ARP module through the queueOut gate. An IPv4RoutingDecision
control info is attached to the outgoing packet, containing the outgoing interface id, and the
IP address of the next hop. The ARP module resolve the IP address to a hardware address if
needed, and forwards the datagram to next hop.
Unicast/broadcast routing
When the higher layer generated the datagram, it will be processed in these steps:
1. If the destination is the address of a local interface, then the datagram is locally delivered.
2. If the destination is the limited broadcast address, or a local broadcast address, then
it will be broadcasted on one or more interface. If the higher layer specified am outgoing interface (interfaceId in the control info), then it will be broadcasted on that
interface only. Otherwise if the forceBroadcast module parameter is true, then it will
broadcasted on all interfaces including the loopback interface. The default value of the
forceBroadcast is false.
3. If the higher layer provided the routing decision (Manet routing), then the datagram will
be sent through the specified interface to the specified next hop.
4. Otherwise IP finds the outgoing interface and the address of the next hop by consulting
the routing table, and sends the datagram to the next hop. If no route found, then a
Destination Unreachable ICMP error is generated.
Incoming datagrams having unicast or broadcast destination addresses are routed in the
following steps:
56
OMNeT++ Manual – IPv4
1. Deliver datagram locally. If the destination address is a local address, the limited broadcast address (255.255.255.255), or a local broadcast address, then it will be sent to the
transport layer.
2. Drop packets received from the network when IP forwarding is disabled.
3. Forward the datagram to the next hop. The next hop is determined by looking up the
best route to the destination from the routing table. If the gateway is set in the route,
then the datagram will be forwarded to the gateway, otherwise it is sent directly to the
destination. If no route is found, then a Destination Unreachable ICMP error is sent
to the source of the datagram.
Multicast routing
Outgoing multicast datagrams are handled as follows:
1. If the higher layer set the multicastLoop variable to true, the IP will send up a copy of
the datagram through the loopback interface.
2. Determine the outgoing interface for the multicast datagram, and send out the datagram
through that interface. The outgoing interface is determined by the following rules:
(a) if the HL specified the outgoing interface in the control info, the it will be used
(b) otherwise use the interface of the route configured in the routing table for the destination address
(c) if no route found, then use the interface whose address matches the source address
of the datagram
(d) if the HL did not specify the source address, then use the first multicast capable
interface
(e) if no such interface found, then the datagram is unroutable and droppped
Incoming multicast datagrams are forwarded according to their source address (Reverse Path
Forwarding), i.e. datagrams are sent away from their sources instead towards their destinations. The multicast routing table maintains a spanning tree for each source network and
multicast group. The source network is the root of the tree, and there is a path to each LAN
that has members of the multicast group. Each node expects the multicast datagram to arrive
from their parent and forwards them towards their children. Multicast forwarding loops are
avoided by dropping the datagrams not arrived on the parent interface.
More specifically, the routing routine for multicast datagrams performs these steps:
1. Deliver a copy of the datagram locally. If the interface on which the datagram arrived
belongs to the multicast group specified by the destination address, it is sent up to the
transport layer.
2. Discard incoming packets that can not be delivered locally and can not be forwarded. A
non-local packet can not be forwarded if multicast forwarding is disabled, the destination
is a link local multicast address (224.0.0.x), or the TTL field reached 0.
3. Discard the packet if no multicast route found, or if it did not arrive on the parent
interface of the route (to avoid multicast loops). If the parent is not set in the route, then
the shortest path interface to the source is assumed.
4. Forward the multicast datagram. A copy of the datagram is sent on each child interface
described by multicast routes (except the incoming interface). Interfaces may have a
57
OMNeT++ Manual – IPv4
ttlThreshold parameter, that limits the scope of the multicast: only datagrams with
higher TTL are forwarded.
9.2.4
Parameters
The IPv4 module has the following parameters:
• procDelay processing time of each incoming datagram.
• timeToLive default TTL of unicast datagrams.
• multicastTimeToLive default TTL of multicast datagrams.
• protocolMapping string value containing the protocol id → gate index mapping,
e.g. “6:0,17:1,1:2,2:3,46:4”.
• fragmentTimeout the maximum duration until fragments are kept in the fragment
buffer.
• forceBroadcast if true, then link-local broadcast datagrams are sent out through each
interface, if the higher layer did not specify the outgoing interface.
9.2.5
Statistics
The IPv4 module does not write any statistics into files, but it has some statistical information
that can be watched during the simulation in the gui environment.
• numForwarded: number of forwarded datagrams, i.e. sent to one of the interfaces (not
broadcast), counted before fragmentation.
• numLocalDeliver: number of datagrams locally delivered. (Each fragment counted separately.)
• numMulticast: number of routed multicast datagrams.
• numDropped number of dropped packets. Either because there is no any interface, the
interface is not specified and no forceBroadcast, or received from the network but IP
forwarding disabled.
• numUnroutable: number of unroutable datagrams, i.e. there is no route to the destination. (But if outgoing interface is specified it is routed!)
In the graphical interface the bubble of the IPv4 module also displays these counters.
9.3
The RoutingTable module
The RoutingTable module represents the routing table. IP hosts and routers contain one
instance of this class. It has methods to manage the routing table and the interface table, so
one can achieve functionality similar to the route and ifconfig commands.
This is a simple module without gates, it requires function calls to it (message handling does
nothing). Methods are provided for reading and updating the interface table and the route
table, as well as for unicast and multicast routing.
58
OMNeT++ Manual – IPv4
Interfaces are dynamically registered: at the start of the simulation, every L2 module adds its
own interface entry to the table.
The route table is read from a file; the file can also fill in or overwrite interface settings. The
route table can also be read and modified during simulation, typically by routing protocol
implementations (e.g. OSPF).
Entries in the route table are represented by IPv4Route objects. IPv4Route objects can be
polymorphic: if a routing protocol needs to store additional data, it can simply subclass from
IPv4Route, and add the derived object to the table. The IPv4Route object has the following
fields:
• host is the IP address of the target of the route (can be a host or network). When an
entry searched for a given destination address, the destination address is compared with
this host address using the netmask below, and the longest match wins.
• netmask used when comparing host with the detination address. It is 0.0.0.0 for the
default route, 255.255.255.255 for host routes (exact match), or the network or subnet
mask for network routes.
• gateway is the IP address of the gateway for indirect routes, or 0.0.0.0 for direct routes.
Note that 0.0.0.0 can be used even if the destination is not directly connected to this
node, but can be found using proxy ARP.
• interface the outgoing interface to be used with this route.
• type DIRECT or REMOTE. For direct routes, the next hop address is the destination address, for remote routes it is the gateway address.
• source MANUAL, IFACENETMASK, RIP, OSPF, BGP, ZEBRA, MANET, or MANET2. MANUAL
means that the route was added by a routing file, or a network configurator. IFACENETMASK routes are added for each interface of the node. Other values means that the route
is managed by the specific routing daemon.
• metric the “cost” of the route. Currently not used when choosing the best route.
In multicast routers the routing table contains multicast routes too. A multicast route is
represented by an instance of the IPv4MulticastRoute class. The IPv4MulticastRoute
instance stores the following fields:
• origin IP address of the network of the source of the datagram
• originNetmask netmask of the source network
• group the multicast group to be matched the destination of the datagram. If unspecified,
then the route matches with
• parent interface towards the parent link in the multicast tree. Only those datagrams
are forwarded that arrived on the parent interface.
• children the interfaces on which the multicast datagram to be forwarded. Each entry
contains a flag indicating if this interface is a leaf in the multicast tree. The datagram is
forwarded to leaf interfaces only if there are known members of the group in the attached
LAN.
• source enumerated value identifying the creator of the entry. MANUAL for static routes,
DVRMP for the DVMRP routers, PIM_SM for PIM SM routers.
59
OMNeT++ Manual – IPv4
• metric the “cost“ of the route.
When there are several multicast routes matching the source and destination of the datagram,
then the forwarding algorithm chooses the one with the
1. the longest matching source
2. the more specific group
3. the smallest metric.
Parameters
The RoutingTable module has the following parameters:
• routerId: for routers, the router id using IPv4 address dotted notation; specify “auto”
to select the highest interface address; should be left empty “” for hosts
• IPForward: turns IP forwarding on/off (It is always true in a Router and is false by
default in a StandardHost.)
• forwardMulticast: turns multicast IP forwarding on/off. Default is false, should be
set to true in multicast routers.
• routingFile: name of routing file that configures IP addresses and routes of the node
containing this routing table. Its format is described in section 9.9.3.
WARNING: The routingFile parameter is obsolete. The prefered method for network
configuration is to use IPv4NetworkConfigurator. The old config files should be replaced with the XML configuration of IPv4NetworkConfigurator. Section 9.9.1 describes the format of the new configuration files.
9.4
The ICMP module
The Internet Control Message Protocol (ICMP) is the error reporting and diagnostic mechanism
of the Internet. It uses the services of IP, so it is a transport layer protocol, but unlike TCP
or UDP it is not used to transfer user data. It can not be separated from the IP, because the
routing errors are reported by ICMP.
The ICMP module can be used to send error messages and ping request. It can also respond
to incoming ICMP messages.
Each ICMP message is encapsulated within an IP datagram, so its delivery is unreliable.
0
7
Type
8
15
Code
31
Checksum
Rest of header
Internet Header + 8 bytes of Original Datagram
60
OMNeT++ Manual – IPv4
The corresponding message class (ICMPMessage) contains only the Type and Code fields. The
message encapsulates the IP packet that triggered the error, or the data of the ping request/reply.
The ICMP module has two methods which can be used by other modules to send ICMP error
messages:
• sendErrorMessage(IPv4Datagram*, ICMPType, ICMPCode) used by the network
layer to report erronous IPv4 datagrams. The ICMP header fields are set to the given
type and code, and the ICMP message will encapsulate the given datagram.
• sendErrorMessage(cPacket*, IPv4ControlInfo*, ICMPType, ICMPCode) used by
the transport layer components to report erronous packets. The transport packet will
be encapsulated into an IP datagram before wrapping it into the ICMP message.
The ICMP module can be accessed from other modules of the node by calling ICMPAccess::get().
When an incoming ICMP error message is received, the ICMP module sends it out on the errorOut gate unchanged. It is assumed that an external module is connected to errOut that
can process the error packet. There is a simple module (ErrorHandling) that simply logs the
error and drops the message. Note that the IPv4 module does not send REDIRECT, DESTINATION_UNREACHABLE, TIME_EXCEEDED and PARAMETER_PROBLEM messages to the
ICMP module, it will send them to the transport layer module that sent the bogus packet
encapsulated in the ICMP message.
NOTE: ICMP protocol encapsulates only the IP header + 8 byte following the IP header
from the bogus IP packet. The ICMP packet length computed from this truncated packet,
despite it encapsulates the whole IP message object. As a consequence, calling decapsulate() on the ICMP message will cause an “packet length became negative” error. To
avoid this, use getEncapsulatedMsg() to access the IP packet that caused the ICMP
error.
The ICMP module receives ping commands on the pingIn gate from the application. The ping
command can be any packet having an IPv4ControlInfo control info. The packet will be
encapsulated with an ICMPMessage and handed over to the IP.
If ICMP receives an echo request from IP, the original message object will be returned as
the echo reply. Of course, before sending back the object to IP, the source and destination
addresses are swapped and the message type changed to ICMP_ECHO_REPLY.
When an ICMP echo reply received, the application message decapsulated from it and passed
to the application through the pingOut gate. The IPv4ControlInfo also copied from the
ICMPMessage to the application message.
9.5
The ARP module
The ARP module implements the Address Resolution Protocol (RFC826). The ARP protocol is
designed to translate a local protocol address to a hardware address. Altough the ARP protocol
can be used with several network protocol and hardware addressing schemes, in practice they
are almost always IPv4 and 802.3 addresses. The INET implementation of the ARP protocol
(the ARP module) supports only IP address → MAC address translation.
If a node wants to send an IP packet to a node whose MAC address is unknown, it broadcasts
an ARP frame on the Ethernet network. In the request its publish its own IP and MAC
61
OMNeT++ Manual – IPv4
addresses, so each node in the local subnet can update their mapping. The node whose
MAC address was requested will respond with an ARP frame containing its own MAC address
directly to the node that sent the request. When the original node receives the ARP response,
it updates its ARP cache and sends the delayed IP packet using the learned MAC address.
The frame format of the ARP request and reponse is shown in Figure 9.5. In our case the
HTYPE (hardware type), PTYPE (protocol type), HLEN (hardware address length) and PLEN
(protocol address length) are constants: HTYPE=Ethernet (1), PTYPE=IPv4 (2048), HLEN=6,
PLEN=4. The OPER (operation) field is 1 for an ARP request and 2 for an ARP response. The
SHA field contains the 48-bit hardware address of the sender, SPA field is the 32-bit IP address
of the sender; THA and TPA are the addresses of the target. The message class corresponding
to the ARP frame is ARPPacket. In this class only the OPER, SHA, SPA, THA and TPA fields
are stored. The length of an ARPPacket is 28 bytes.
0
7
8
15
HTYPE
PTYPE
HLEN
PLEN
OPER
SHA
SPA
THA
TPA
Figure 9.1: ARP frame
The ARP module receives IP datagrams and ARP responses from IPv4 on the ipIn gate and
transmits IP datagrams and ARP requests on the nicOut[] gates towards the network interface cards. ARP broadcasts the requests on the local network, so the NIC’s entry in the
InterfaceTable should have isBroadcast() flag set in order to participate in the address
resolution.
The incoming IP packet should have an attached IPv4RoutingDecision control info containing the IP address of the next hop. The next hop can be either an IPv4 broadcast/multicast
or a unicast address. The corresponding MAC addresses can be computed for broadcast and
multicast addresses (RFC 1122, 6.4); unicast addresses are mapped using the ARP procotol.
If the hardware address is found in the ARP cache, then the packet is transmitted to the
addressed interface immediately. Otherwise the packet is queued and an address resolution
takes place. The ARP module creates an ARPPacket object, sets the sender MAC and IP
address to its own address, sets the destination IP address to the address of the target of
62
OMNeT++ Manual – IPv4
the IP datagram, leave the destination MAC address blank and broadcasts the packet on each
network interface with broadcast capability. Before sending the ARP packet, it retransmission
a timer. If the timer expires, it will retransmit the ARP request, until the maximum retry count
is reached. If there is no response to the ARP request, then the address resolution fails, and
the IP packet is dropped from the queue. Otherwise the MAC address of the destination is
learned and the IP packet can be transmitted on the corresponding interface.
When an ARP packet is received on the ipIn gate, and the sender’s IP is already in the
ARP cache, it is updated with the information in the ARP frame. Then it is checked that the
destination IP of the packet matches with our address. In this case a new entry is created with
the sender addresses in the ARP cache, and if the packet is a request a response is created
and sent directly to the originator. If proxy ARP is enabled, the request can be responded with
our MAC address if we can route IP packets to the destination.
Usually each ARP module maintains a local ARP cache. However it is possible to use a global
cache. The global cache is filled in with entries of the IP and MAC addresses of the known
interfaces when the ARP modules are initiated (at simulation time 0). ARP modules that are
using the global ARP cache never initiate an address resolution; if an IP address not found
in the global cache, the simulation stops with an error. However they will respond to ARP
request, so the simulation can be configured so that some ARPs use local, while others the
global cache.
When an entry is inserted or updated in the local ARP cache, the simulation time saved in the
entry. The mapping in the entry is not used after the configured cacheTimeout elapsed. This
parameter does not affect the entries of the global cache however.
The module parameters of ARP are:
• retryTimeout: number of seconds ARP waits between retries to resolve an IPv4 address
(default is 1s)
• retryCount: number of times ARP will attempt to resolve an IPv4 address (default is 3)
• cacheTimeout: number of seconds unused entries in the cache will time out (default is
120s)
• proxyARP: enables proxy ARP mode (default is true)
• globalARP: use global ARP cache (default is false)
The ARP module emits four signals:
• sentReq: emits 1 each time an ARP request is sent
• sentReplies: emits 1 each time an ARP response is sent
• initiatedResolution: emits 1 each time an ARP resolution is initiated
• failedResolution: emits 1 each time an ARP resolution is failed
These signals are recorded as vectors and their counts as scalars.
9.6
The IGMP module
The IGMP module is responsible for distributing the information of multicast group memberships from hosts to routers. When an interface of a host joins to a multicast group, it will
63
OMNeT++ Manual – IPv4
send an IGMP report on that interface to routers. It can also send reports when the interface
leaves the multicast group, so it does not want to receive those multicast datagrams. The
IGMP module of multicast routers processes these IGMP reports: it updates the list of groups,
that has members on the link of the incoming message.
The IIGMP module interface defines the connections of IGMP modules. IGMP reports
are transmitted by IP, so the module contains gates to be connected to the IP module
(ipIn/ipOut). The IP module delivers packets with protocol number 2 to the IGMP module.
However some multicast routing protocols (like DVMRP) also exchange routing information by
sending IGMP messages, so they should be connected to the routerIn/routerOut gates of
the IGMP module. The IGMP module delivers the IGMP messages not processed by itself to
the connected routing module.
The IGMPv2 module implements version 2 of the IGMP protocol (RFC 2236). Next we describe
its behaviour in host and routers in details. Note that multicast routers behaves as hosts too,
i.e. they are sending reports to other routers when joining or leaving a multicast group.
9.6.1
Host behaviour
When an interface joins to a multicast group, the host will send a Membership Report immediately to the group address. This report is repeated after unsolicetedReportInterval to
cover the possibility of the first report being lost.
When a host’s interface leaves a multicast group, and it was the last host that sent a Membership Report for that group, it will send a Leave Group message to the all-routers multicast
group (224.0.0.2).
This module also responds to IGMP Queries. When the host receives a Group-Specific Query
on an interface that belongs to that group, then it will set a timer to a random value between 0
and Max Response Time of the Query. If the timer expires before the host observe a Membership Report sent by other hosts, then the host sends an IGMPv2 Membership Report. When
the host receives a General Query on an interface, a timer is initialized and a report is sent
for each group membership of the interface.
9.6.2
Router behaviour
Multicast routers maintains a list for each interface containing the multicast groups that have
listeners on that interface. This list is updated when IGMP Membership Reports and Leave
Group messages arrive, or when a timer expires since the last Query.
When multiple routers are connected to the same link, the one with the smallest IP address
will be the Querier. When other routers observe that they are Non-Queriers (by receiving
an IGMP Query with a lower source address), they stop sending IGMP Queries until otherQuerierPresentInterval elapsed since the last received query.
Routers periodically (queryInterval) send a General Query on each attached network for
which this router is a Querier. On startup the router sends startupQueryCount queries
separated by startupQueryInterval. A General Query has unspecified Group Address field,
a Max Response Time field set to queryResponseInterval, and is sent to the all-systems
multicast address (224.0.0.1).
When a router receives a Membership Report, it will add the reported group to the list of
multicast group memberships. At the same time it will set a timer for the membership to
groupMembershipInterval. Repeated reports restart the timer. If the timer expires, the
64
OMNeT++ Manual – IPv4
router assumes that the group has no local members, and multicast traffic is no more forwarded to that interface.
When a Querier receives a Leave Group message for a group, it sends a Group-Specific Query
to the group being left. It repeats the Query lastMemberQueryCount times in separated by
lastMemberQueryInterval until a Membership Report is received. If no Report received,
then the router assumes that the group has no local members.
9.6.3
Disabling IGMP
The IPv4 NetworkLayer contains an instance of the IGMP module. IGMP can be turned off by
setting the enabled parameter to false. When disabled, then no IGMP message is generated,
and incoming IGMP messages are ignored.
9.6.4
Parameters
The following parameters has effects in both hosts and routers:
• enabled if false then the IGMP module is silent. Default is true.
These parameters are only used in hosts:
• unsolicitedReportInterval the time between repetitions of a host’s initial report of
membership in a group. Default is 10s.
Router timeouts are configured by these parameters:
• robustnessVariable the IGMP is robust to robustnessVariable-1 packet losses. Default is 2.
• queryInterval the interval between General Queries sent by a Querier. Default is 125s.
• queryResponseInterval the Max Response Time inserted into General Queries
• groupMembershipInterval the amount of time that must pass before a multicast router
decides there are no more members of a group on a network. Fixed to robustnessVariable * queryInterval + queryResponseInterval.
• otherQuerierPresentInterval the length of time that must pass before a multicast
router decides that there is no longer another multicast router which should be the
querier. Fixed to robustnessVariable * queryInterval + queryResponseInterval /
2.
• startupQueryInterval the interval between General Queries sent by a Querier on
startup. Default is queryInterval / 4.
• startupQueryCount the number of Queries sent out on startup, separated by the startupQueryInterval. Default is robustnessVariable.
• lastMemberQueryInterval the Max Response Time inserted into Group-Specific
Queries sent in response to Leave Group messages, and is also the amount of time
between Group-Specific Query messages. Default is 1s.
• lastMemberQueryCount the number of Group-Specific Queries sent before the router
assumes there are no local members. Default is robustnessVariable.
65
OMNeT++ Manual – IPv4
9.7
The NetworkLayer module
The NetworkLayer module packs the IP, ICMP, ARP, and IGMP modules into one compound
module. The compound module defines gates for connecting UDP, TCP, SCTP, RSVP and OSPF
transport protocols. The pingIn and pingOut gates of the ICMP module are also available,
while its errorOut gate is connected to an inner ErrorHandling component that writes the
ICMP errors to the log.
The component can be used in hosts and routers to support IPv4.
9.8
The NetworkInfo module
The NetworkInfo module can be used to dump detailed information about the network layer.
This module does not send or received messages, it is invoked by the ScenarioManager
instead. For example the following ScenarioManager script dump the routing table of the
LSR2 module at simulation time t = 2 into LSR2_002.txt:
The module currently support only the routing command which dumps the routing table.
The command has four parameters given as XML attributes:
• target the name of the node that owns the routing table to be dumped
• filename the name of the file the output is directed to
• mode if set to “a”, the output is appended to the file, otherwise the target is truncated if
the file existed
• compat if set to “linux”, then the output is generated in the format of the route -n
command of Linux. The output is sorted only if compat is true.
9.9
Configuring IPv4 networks
An IPv4 network is composed of several nodes like hosts, routers, switches, hubs, Ethernet
buses, or wireless access points. The nodes having a IPv4 network layer (hosts and routers)
should be configured at the beginning of the simulation. The configuration assigns IP addresses to the nodes, and fills their routing tables. If multicast forwarding is simulated, then
the multicast routing tables also must be filled in.
The configuration can be manual (each address and route is fully specified by the user), or
automatic (addresses and routes are generated by a configurator module at startup).
Before version 1.99.4 INET offered FlatNetworkConfigurator for automatic and routing
files for manual configuration. Both had serious limitations, so a new configurator has been
added in version 1.99.4: IPv4NetworkConfigurator. This configurator supports both fully
manual and fully automatic configuration. It can also be used with partially specified manual
configurations, the configurator fills in the gaps automatically.
66
OMNeT++ Manual – IPv4
The next section describes the usage of IPv4NetworkConfigurator, FlatNetworkConfigurator and old routing files are described in the following sections.
9.9.1
IPv4NetworkConfigurator
The IPv4NetworkConfigurator assigns IP addresses and sets up static routing for an IPv4
network.
It assigns per-interface IP addresses, strives to take subnets into account, and can also optimize the generated routing tables by merging routing entries.
Hierarchical routing can be set up by using only a fraction of configuration entries compared
to the number of nodes. The configurator also does routing table optimization that significantly decreases the size of routing tables in large networks.
The configuration is performed in stage 2 of the initialization. At this point interface modules
(e.g. PPP) has already registered their interface in the interface table. If an interface is named
“ppp[0]”, then the corresponding interface entry is named “ppp0”. This name can be used in
the config file to refer to the interface.
The configurator goes through the following steps:
1. Builds a graph representing the network topology.
2. Assigns IP addresses to all interfaces of all nodes.
3. Configure multicast group membership of the interfaces.
4. Adds the manual routes that are specified in the configuration file.
5. Adds the multicast routes that are specified in the configuration file.
6. Adds static routes to all routing tables in the network.
7. Optimizes the routing tables for size. This step could take much time, so it can be turned
off.
8. Optionally prints the results of the configuration process (network topology, addresses,
routing tables).
The module can dump the result of the configuration in the XML format which it can read.
This is useful to save the result of a time consuming configuration (large network with optimized routes), and use it as the config file of subsequent runs.
Network topology graph
The network topology graph is constructed from the nodes of the network. The node is a
module having a @node property (this includes hosts, routers, and L2 devices like switches,
access points, Ethernet hubs, etc.). An IP node is a node that contains an InterfaceTable
and a RoutingTable. A router is an IP node that has multiple network interfaces, and IP
forwarding is enabled in its routing table module. In multicast routers the forwardMulticast
parameter is also set to true.
A link is a set of interfaces that can send datagrams to each other without intervening routers.
Each interface belongs to exactly one link. For example two interface connected by a pointto-point connection forms a link. Ethernet interfaces connected via buses, hubs or switches.
67
OMNeT++ Manual – IPv4
The configurator identifies links by discovering the connections between the IP nodes, buses,
hubs, and switches.
Wireless links are identified by the ssid or accessPointAddress parameter of the 802.11
management module. Wireless interfaces whose node does not contain a management module
are supposed to be on the same wireless link. Wireless links can also be configured in the
configuration file of IPv4NetworkConfigurator:
puts wlan interfaces of the specified hosts into the same wireless link.
If a link contains only one router, it is marked as the gateway of the link. Each datagram
whose destination is outside the link must go through the gateway.
Address assignment
Addresses can be set up manually by giving the address and netmask for each IP node. If some
part of the address or netmask is unspecified, then the configurator can fill them automatically. Unspecified fields are given as an “x” character in the dotted notation of the address.
For example, if the address is specified as 192.168.1.1 and the netmask is 255.255.255.0,
then the node address will be 192.168.1.1 and its subnet is 192.168.1.0. If it is given as
192.168.x.x and 255.255.x.x, then the configurator chooses a subnet address in the range of
192.168.0.0 - 192.168.255.252, and an IP address within the chosen subnet. (The maximum
subnet mask is 255.255.255.252 allows 2 nodes in the subnet.)
The following configuration generates network addresses below the 10.0.0.0 address for each
link, and assign unique IP addresses to each host:
The configurator tries to put nodes on the same link into the same subnet, so its enough to
configure the address of only one node on each link.
The following example configures a hierarchical network in a way that keeps routing tables
small.
hosts="area11.lan1.*" address="10.11.1.x" netmask="255.255.255.x"/>
hosts="area11.lan2.*" address="10.11.2.x" netmask="255.255.255.x"/>
hosts="area12.lan1.*" address="10.12.1.x" netmask="255.255.255.x"/>
hosts="area12.lan2.*" address="10.12.2.x" netmask="255.255.255.x"/>
hosts="area*.router*" address="10.x.x.x" netmask="x.x.x.x"/>
hosts="*" address="10.x.x.x" netmask="255.x.x.0"/>
The element may contain the following attributes:
• @hosts specifies a list of host name patterns (e.g. "subnet.client*" or "host* router[0..3]"
or "area*.*.host[0]"). Only interfaces in the specified hosts are affected. The default value
is "*" that matches all hosts.
• @names specifies a list of interface name patterns (e.g. "eth* ppp0" or "*"). Only interfaces
with the specified names are affected. The default value is "*" that matches all interfaces.
68
OMNeT++ Manual – IPv4
• @towards specifies a list of host name patterns (e.g. "ap" or "server" or "client*"). Only
interfaces connected towards the specified hosts are affected. This works even if there’s
a switch between the configured host and the one specified here. For wired networks it
might be easier to specify this parameter instead of specifying the interface names. The
default value is "*".
• @address IP address of the interface (e.g. "192.168.1.1" or "10.0.x.x"). Unspecified parts
("x" characters in the address) will be filled automatically by the configurator. The default
value "" means that the address will not be configured.
• @netmask netmask of the subnet of the interface (e.g. "255.255.255.0" or "255.255.x.x"
or "255.255.x.0"). Unspecified part ("x" characters in the address) is filled automatically
by the configurator.
• @mtu the MTU of the interface. When unspecified the interface parameter is left unchanged.
Multicast groups
Multicast groups can be configured by adding elements to the configuration file. Interfaces belongs to a multicast group will join to the group automatically.
For example
adds all Ethernet interfaces of nodes whose name starts with “router” to the 224.0.0.5 multicast group.
The element has the following attributes:
• @hosts specifies a list of host name patterns. Only interfaces in the specified hosts are
affected. The default value is "*" that matches all hosts.
• @interfaces specifies a list of interface name patterns. Only interfaces with the specified names are affected. The default value is "*" that matches all interfaces.
• @address: one or more multicast address, that are added to the multicast groups of the
selected interfaces. E.g. "224.0.0.1 224.0.1.33".
Manual route configuration
The IPv4NetworkConfigurator module allows the user to fully specify the routing tables of
IP nodes at the beginning of the simulation.
The elements of the configuration add a route to the routing tables of selected nodes.
The element has the following attributes:
• @hosts specifies a list of host name patterns. Only routing tables in the specified hosts
are affected. The default value "*" means all hosts will be affected.
• @destination specifies the destination address of the route. Its value can be a dotted
IP address ("192.168.1.1"), the name of the destination node ("subnet.client[3]") or "*"
(meaning any destination, used with "/0" netmask). The default value is "*".
• @netmask specifies the netmask in the route. It can be given as dotted decimal notation
("255.255.255.0"), as prefix length ("/29") or as "*" (for default route). The default value
is "*".
69
OMNeT++ Manual – IPv4
• @gateway specifies the gateway (next-hop) address in the route. Its value can be an IP
address, a hostname ("subnet.router") or "*". When unspecified the interface parameter
must be specified. The default value is "*".
• @interface specifies the output interface name in the route (e.g. "eth0"). When unspecified the gateway parameter must be specified.
@metric specifies the metric in the route. The default value is 0.
Multicast routing tables can similarly be configured by adding elements
to the configuration.
• @hosts specifies a list of host name patterns. Only routing tables in the specified hosts
are affected.
• @source specifies the address of the source network. The default value is "*" that
matches all sources.
• @netmask specifies the netmask of the source network. The default value is "*" that
matches all sources.
• @groups list of IPv4 multicast addresses specifying the groups this entry applies to (e.g.
"225.0.0.1 225.0.1.2"). The default value is "*" that matches all multicast groups.
• @metric specifies the metric in the route.
• @parent specifies the name of the parent (incoming) interface. Only multicast datagrams
that arrived on the parent interface are forwarded. If unspecified, then the interface on
the shortest path towards the source of the datagram will be the parent interface of the
route.
• @children specifies the child (outgoing) interfaces as a list of interface name patterns:
– a name pattern (e.g. "ppp*") matches the name of the interface
– a towards pattern (starting with ">", e.g. ">router*") matches the interface by naming
one of the neighbour nodes on its link.
Multicast datagrams are forwarded to each child interface except the one they arrived in.
The following example adds an entry to the multicast routing table of router1, that intsructs
the routing algorithm to forward multicast datagrams whose source is in the 10.0.1.0 network and whose destinatation address is 225.0.0.1 to send on the eth1 and eth2 interfaces
assuming it arrived on the eth0 interface:
/3rdparty/README file to build it.
WARNING: Before generating the INET module, check that the opp_makemake call in the
make file (/Makefile) includes the -DWITH_TCP_NSC argument. Without
this option the TCP_NSC module is not built. If you build the INET library from the IDE,
it is enough to enable the TCP (NSC) project feature.
Parameters
The TCP_NSC module has the following parameters:
• stackName: the name of the TCP implementation to be used. Possible values are:
liblinux2.6.10.so, liblinux2.6.18.so, liblinux2.6.26.so, libopenbsd3.5.so,
libfreebsd5.3.so and liblwip.so. (On the 64 bit systems, the liblinux2.6.26.so
and liblinux2.6.16.so are available only).
108
OMNeT++ Manual – The TCP Models
• stackBufferSize: the size of the receive and send buffer of one connection for selected
TCP implementation. The NSC sets the wmem_max, rmem_max, tcp_rmem, tcp_wmem parameters to this value on linux TCP implementations. For details, you can see the NSC
documentation.
Statistics
The TCP_NSC module collects the following vectors:
• sent seq Sequence Number of the sent TCP segment
• sent ack Acknowledgment Number of the sent TCP segment
• rcvd seq Sequence Number of the received TCP segment
• rcvd ack Acknowledgement Number of the received TCP segment
Limitations
• Because the kernel code is not reentrant, NSC creates a record containing the global
variables of the stack implementation. By default there is room for 50 instance in this
table, so you can not create more then 50 instance of TCP_NSC. You can increase the
NUM_STACKS constant in num_stacks.h and recompile NSC to overcome this limitation.
• The TCP_NSC module does not supprt TCP_TRANSFER_OBJECT data transfer mode.
• The MTU of the network stack fixed to 1500, therefore MSS is 1460.
• TCP_C_STATUS command reports only local/remote addresses/ports and current window of the connection.
12.7
TCP applications
This sections describes the applications using the TCP protocol. Each application must implement the ITCPApp module interface to ease configuring the StandardHost module.
The applications described here are all contained by the inet.applications.tcpapp package. These applications use GenericAppMsg objects to represent the data sent between the
client and server. The client message contains the expected reply length, the processing delay, and a flag indicating that the connection should be closed after sending the reply. This
way intelligence (behaviour specific to the modelled application, e.g. HTTP, SMB, database
protocol) needs only to be present in the client, and the server model can be kept simple and
dumb.
12.7.1
TCPBasicClientApp
Client for a generic request-response style protocol over TCP. May be used as a rough model
of HTTP or FTP users.
The model communicates with the server in sessions. During a session, the client opens a
single TCP connection to the server, sends several requests (always waiting for the complete
reply to arrive before sending a new request), and closes the connection.
109
OMNeT++ Manual – The TCP Models
The server app should be TCPGenericSrvApp; the model sends GenericAppMsg messages.
Example settings:
FTP
numRequestsPerSession = exponential(3)
requestLength = truncnormal(20,5)
replyLength = exponential(1000000)
HTTP
numRequestsPerSession = 1 # HTTP 1.0
numRequestsPerSession = exponential(5)
requestLength = truncnormal(350,20)
replyLength = exponential(2000)
# HTTP 1.1, with keepalive
Note that since most web pages contain images and may contain frames, applets etc, possibly
from various servers, and browsers usually download these items in parallel to the main HTML
document, this module cannot serve as a realistic web client.
Also, with HTTP 1.0 it is the server that closes the connection after sending the response,
while in this model it is the client.
12.7.2
TCPSinkApp
Accepts any number of incoming TCP connections, and discards whatever arrives on them.
The module parameter dataTransferMode should be set the transfer mode in TCP layer. Its
possible values (“bytecount”, “object”, “bytestream”) are described in ...
12.7.3
TCPGenericSrvApp
Generic server application for modelling TCP-based request-reply style protocols or applications.
Requires message object preserving sendQueue/receiveQueue classes to be used
with TCP (that is, TCPMsgBasedSendQueue and TCPMsgBasedRcvQueue; TCPVirtualBytesSendQueue/RcvQueue are not good).
The module accepts any number of incoming TCP connections, and expects to receive messages of class GenericAppMsg on them. A message should contain how large the reply should
be (number of bytes). TCPGenericSrvApp will just change the length of the received message
accordingly, and send back the same message object. The reply can be delayed by a constant
time (replyDelay parameter).
12.7.4
TCPEchoApp
The TCPEchoApp application accepts any number of incoming TCP connections, and sends
back the messages that arrive on them, The lengths of the messages are multiplied by
echoFactor before sending them back (echoFactor=1 will result in sending back the same
110
OMNeT++ Manual – The TCP Models
message unmodified.) The reply can also be delayed by a constant time (echoDelay parameter).
When TCPEchoApp receives data packets from TCP (and such, when they can be echoed)
depends on the dataTransferMode setting. With "bytecount" and "bytestream", TCP passes
up data to us as soon as a segment arrives, so it can be echoed immediately. With "object"
mode, our local TCP reproduces the same messages that the sender app passed down to its
TCP – so if the sender app sent a single 100 MB message, it will be echoed only when all 100
megabytes have arrived.
12.7.5
TCPSessionApp
Single-connection TCP application: it opens a connection, sends the given number of bytes,
and closes. Sending may be one-off, or may be controlled by a "script" which is a series of
(time, number of bytes) pairs. May act either as client or as server, and works with TCPVirtualBytesSendQueue/RcvQueue as sendQueue/receiveQueue setting for TCP. Compatible with
both IPv4 ( IPv4) and IPv6.
Opening the connection
Regarding the type of opening the connection, the application may be either a client or a
server. When active=false, the application will listen on the given local localPort, and wait for
an incoming connection. When active=true, the application will bind to given local localAddress:localPort, and connect to the connectAddress:connectPort. To use an ephemeral port as
local port, set the localPort parameter to -1.
Even when in server mode (active=false), the application will only serve one incoming connection. Further connect attempts will be refused by TCP (it will send RST) for lack of LISTENing
connections.
The time of opening the connection is in the tOpen parameter.
Sending data
Regardless of the type of OPEN, the application can be made to send data. One way of
specifying sending is via the tSend, sendBytes parameters, the other way is sendScript. With
the former, sendBytes bytes will be sent at tSend. With sendScript, the format is " Source Exif Data:
File Type : PDF File Type Extension : pdf MIME Type : application/pdf PDF Version : 1.4 Linearized : No Page Count : 157 Page Mode : UseOutlines Warning : Duplicate 'Author' entry in dictionary (ignored) Author : Andras Varga and others Title : INET Framework Manual Subject : Keywords : INET, INETMANET, OMNeT++, manual Creator : LaTeX with hyperref package Producer : pdfTeX-1.40.10 Create Date : 2012:06:21 14:14:56+02:00 Modify Date : 2012:06:21 14:14:56+02:00 Trapped : False PTEX Fullbanner : This is pdfTeX, Version 3.1415926-1.40.10-2.2 (TeX Live 2009/Debian) kpathsea version 5.0.0EXIF Metadata provided by EXIF.tools