forked from inet-framework/inet
-
Notifications
You must be signed in to change notification settings - Fork 1
/
__TODO
417 lines (330 loc) · 19.3 KB
/
__TODO
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
TODO: DHCP Client should work multiple interfaces, but works with only one.
TODO: UDP: add a parameter: used protocol number, default value is UDP.
It's useful for UDP-like protocols, e.g. MANET
TODO: revise ethernet/eth-index.ned! e.g it writes about autoconfiguration, and probably half of it is obsolete
TODO: examples/ospfv2/areas does not work: the UDP apps in H3 keep sending, but never receive answer; seems like
sent packets cannot even leave H3 (they are queued up in ARP, due to "address resolution pending")
TODO: TCP,UDP,SCTP: Need revision for PORT_ANY usage:
What will the PORT_ANY value: -1 or 0.
Where do replace from PORT_ANY to a valid port: in TCPSocket or in
TCPConnection::process_OPEN_ACTIVE/process_OPEN_PASSIVE
Check it in other protocols.
TODO: Int128/Uint128 code revision / optimisation
Optimise *= and other operators/functions.
TODO: IPv4 misfeature: in IPv4::handleMessageFromHL(cPacket *msg), if the packet is already
an IP datagram, then it does not encapsulate the packet but just routes it!
Problem: HL cannot control whether it wants IP to route the packet or tunnel (encapsulate) it!!
TODO: fix typos: recived, broadCast
TODO: TCPSegment, UDPPacket: use uint16_t for ports, uint32_t for sequence numbers, etc; also in the code!!!
hint: first replace it somewhere with a type that CANNOT be cast to integer types, then let compile errors propagate the type change everywhere
TODO: StandardHost: do we need tcpType, udpType, sctpType? why not just <default("UDP")>, <default("SCTP")>, etc? they are conditional anyway!
TODO: make copyright headers uniform....
TODO: set up nightly builds:
- should report build errors/warnings;
- should run etc/runallexamples and report the results (runtime errors, fingerprint mismatches, etc)
TODO: execute etc/runallexamples, and fix errors (last run: May 2008)
TODO: implement missing models:
Qeueing (we have: FIFO, RED): CBQ, WFQ, RIO, Round Robin, Fair queueing Round Robin
Suggested by VR:
Wired: Circuit Switch, ATM(AAL2/AAL5,CBR/VBR/ABR), IP over ATM, PNNI, MPLS, DiffServ
Wireless: Adhoc routing:FSR/DSDV/ZRP/TORA/LENMMAR;Adhoc MAC:802.11, WTRP,
TDMA; QoS supports for cross-layer design
and also, Group Mobility, etc.
TODO: derive BGPRouter from OSPFRouter that should be derived from Router
TODO: is the namId needed at StandardHost level? Possibly implement namtrace as a plugin?
TODO: port NAM trace writer to use signals mechanism
TODO: Add ThruputMetering channel (NED definition)
TODO: provide default for RoutingTable.routingTableFile once xmlinline() is implemented in omnet.
TODO: integrate models:
HIPSim++, MobileWiMAX, ...
TODO: PPP, Ethernet: should use signals (ModelChangeNotification) to detect if channel path breaks
TODO: implement node failure/recovery by using signals mechanism
TODO: pcap file recording using signals mechanism
TODO: VideoStrmReq problem on IPv6:
"Error in module (UDP) P62.server.udp (id=21): User error: (UDPPacket)VideoStrmReq arrived from lower layer without control info"
TODO: check if SCTP in StandardHost6 (IPv6) is working properly
BUG: if SCTPServer.echoFactor not 0, then will a runtime error:
"Error in module (SCTP) P5.server.sctp (id=22): User error: stream with id 2 not found."
Network: IPv4; 1 server, 1 router, 10 client
TODO: labelling:
- add labels l2pkt/l3pkt/l4pkt to upper layer input/output of L1/L2/L3 protocols or modules?
i.e. NIC's upperLayerIn could be tagged as l3pkt, and IP's ifOut also as l3pkt
- add @labels(node,configurator,!configurator) to FlatNetworkConfigurator and similar "singleton" modeules,
to make them unique?
- change the @labels(PPPFrame) label on pppg[] gates of hosts/routers to something slightly different
(e.g. @labels(PPPFrame/pk)) so that PPPInterface does not appear in the palette on network level?
TODO: finish making gate names consistent! around the SCTP and RTP modules
TODO: PingApp is strange; it should send payload+controlInfo instead of ICMP packet,
the word ping should not occur in ICMP code, move identifier, sequence number from PingPayload into ICMPControlInfo
TODO: eliminate ARP overhead for PPP interfaces;
TODO: UDPSocket::Callback::socketDatagramArrived() - change arg cMessage* to cPacket*
TODO: examples\wireless\hosttohost: Readme mentions some "attached Excel sheet" which is missing!!!
TODO: toplevel package legyen "org.omnetpp.inet"
TODO: MTU patch from Irene Rungeler
TODO: add SCTP to the whatsnew file
- MAKE IT POSSIBLE TO USE DIFFERENT TYPES FOR EACH ELEMENT OF "LIKE" SUBMODULE VECTORS!
In StandardHost etc, change
udpApp[numUdpApps]: <udpAppType> like IUDPApp;
to
udpApp[numUdpApps]: <> like IUDPApp;
TODO:
- failure/recovery (replacing with failed router is problematic!)
- gate labelling for the NED editor
-----------------------
add support for integrating the TIREM module?
http://www.alionscience.com/index.cfm?fuseaction=products.view&productid=19
"TIREM predicts radio frequency propagation loss over irregular terrain and seawater for
ground-based and air-borne transmitters and receivers. TIREM is commercially
available as a DLL and as a module in leading commercial M&S tools."
-----------------------
mailing list post on 2008-11-17 "INET Framework accuracy":
A really interesting paper is the technical report "Towards Comparable
Network Simulators", from Pengfei Di, Yaser Houri, Kendy Kutzner and Thomas
Fuhrmann [see url below]. They measure 802.11 throughput with ns2 and
OMNeT++ INET Fw, and come to the conclusion that they are hard to compare,
due to differences in the radio model and MAC parameterization. Then they go
on to wrap ns2's 802.11 model into an OMNeT++ simple module, and with that,
the OMNeT++ simulation (not too surprisingly) shows excellent correspondence
with the ns2 simulation :)
http://i30www.ira.uka.de/research/documents/p2p/2008/towards_comparable_netw
ork_simulations.pdf
The paper is excellent work, and literally cries for follow-ups:
1. INET's radio model is pluggable, and as the report authors describe it,
the ns-2 radio model seems to be quite simple (i.e. propdelay is a constant
and does not depend on distance). Thus, it should be possible to reimplement
ns-2's radio model in OMNeT++ with not too much effort (and contribute it to
INET) and re-run the experiments with it.
2. OTOH I'm wondering, why not test the radio model and the 802.11MAC
operation *separately*? I.e. write an ideal radio (ber==0 always) and test
different 802.11 MAC models over that in all scenarios; then have more
realistic radio models and test them with simple (contention-free) 802.11
setups
3. INET 802.11MAC model parameterization could be adjusted so that it's
possible to set it up with *exactly* the same parameters as ns-2.
4. the authors ported ns-2's 802.11 model into OMNeT++; wonder if this code
is publicly available, or is there any plan to release it? there certainly
would be value in doing that.
-----------------------
TODO: eliminate cast after dup(), like (AirFrame*)airframe->dup()
TODO: IRoutingTable6, ITED, etc!
TODO routingTable optimizations from Gamer!
TODO: Document: decide interfaceId vs interfacePointer! issue: IPRoutingDecision contains interfaceID.
if we change it to pointer, messages that are underway in the host during a deleteInterface()
may crash!!! solution: use a vector inside InterfaceTable, and let each deleteInterface()
leave a hole in it?
-----------------------
- move "q=queue" too into the default display string
- add gate @labels
- rename TCPBasicClientApp to TCPRequestReplyClientApp ?
- ethernet: ditch autoconfig and zero-datarate channels, use deliverOnReceptionStart and 10/100/1000Mbps channels!
-----------------------
TODO rename the following TED.h methods to begin with a verb:
unsigned int linkIndex(IPAddress advrouter, IPAddress linkid)
unsigned int linkIndex(IPAddress localInf)
IPAddress peerRemoteInterface(IPAddress peerIP)
IPAddress primaryAddress(IPAddress localInf)
-----------------------
cache gate IDs to speed up sending
-----------------------
put all c++ code into "inet" namespace
- networklayer\extras\FailureManager.cc: contains obsolete, hardcoded module type names!
- factor out common part of hosts/routers etc, and use subclassing
- remove channelInstaller
- examples: add fingerprints!
- create a new executable demo for Windows
--------
- get quagga to work
--------
- add IdealRadio, DistanceBasedRadio, GilbertElliotRadio.
in DistanceBasedRadio: decouple transmission range from interference range
(ie use 2 different module parameters)
--------
- model link failures, via isDown() method of InterfaceEntry. L2 modules
should understand isDown(), and FailureManager should be enhanced with
linkdown/linkup commands. See email on list archive on 9/17/2006 10:34 AM
--------
- create NetworkInterfaces/Base subdirectory: AirFrame, WirelessMacBase,
ChannelAccess, etc.
--------
- Ieee80211Mac to fire TxNotifDetails when Ack arrives for a frame. Mgmt layer
to use this notification to learn when ProbeRequest or AssociationResponse
has been transmitted.
--------
- ChannelControl: grid; instead of having pMax parameter, it should ask all
radios and collect pMax from them! (or, directly the range!)
--------
- radio models: when calculating the probability of bit errors, snirMIN is
assumed for the whole duration of the frame! This means that if snir
changes along the packet duration, we overestimate the probability of
bit error. (there should be proper integration there)
--------
- IReceptionModel:
- improve it to be able to accomodate antenna gain: calculation function
should take node positions, antenna directions (maybe this should be in
some IDirectionalReceptionmodel, plugging into some AbstractDirectionalRadio?)
- allow for implementing "good/bad channel"-type radio models (Gilbert-Elliot)
e.g. containsBadChannelState(starttime, endtime)
- allow the radio model to add extra noise over time, or modify received power
over time, e.g. using functions like
PowerList calculateReceivedPower(...)
PowerList ambientNoise(...)
(maybe this should be some IDetailedReceptionModel, plugging into
a specialized version of AbstractRadio?)
--------
- AbstractRadio: consider: don't sent up the packet if there're bit errors,
just fire some specific radio state change notification! would simplify the
Ieee80211Mac state machine a lot!
--------
- tummiepiggy's TCP bug ("TCP_S_FIN_WAIT_1 timeout" on mailing list)
--------
- quagga/socketmsg: use base/bytearraymessage instead
--------
- implement ICMP rate limiting, see e.g bsd.mod/netinet/ip_icmp.c, badport_bandlim()
- ICMP options: stopOnError (bool param), UDPBadPortSendICMP (bool param)
--------
- problem with NetworkConfigurator + RSVP's FailureManager: after deleting/recreating
LSR, configured IP addresses and host routes to PPP peers get lost.
Solution: implement failure/recovery with NF_FAILURE and NF_RECOVERY notifications!
--------
- check in Quagga documentation
- rename Daemon to QuaggaDaemon
--------
- "ack" in LinkStateMsg redundant? (never read)
Q: what is the TELinkInfo.state flag?
Q: what is UnResvBandwidth[8] indexed with? what is [4] and [7] that gets printed?
--------
- MPLS examples: there's heaps of ICMP errors coming from UDP ("port unreachable")
--------
- BUG: UDP ephemeral port setting: if chosen & stored in UDP, sending further dgrams need to look it up from the SockDesc...
--------
- reading routing files: it doesn't make sense to be able to manually set MULTICAST on an interface
- create example network with both Ethernet and PPP
- IP/IPv6: implement tunnelling
- revise fragmentation in IP
- added userId to TCPCommand -- rewrite TCPSocketMap to make use of userId
- socket must be inserted into map before bind(), so that a userId can be assigned
- what about incoming connections? how to assign userId to them?
IF IT CANNOT BE DONE: remove userId from TCP!!!!
- TCP/UDP: unspec port should be 0 not -1!!!
- NAM trace: doesn't record drops, because DropTailQueue doesn't send notifications
- there's no IPAddress::getPrefix() and getSuffix() (like IPv6Address has)
- apps: add startTime param; IPAddressResolver should only be invoked at startTime not in initialize()!
- TCP tests fail now (TCPDump has changed)
- if a node pings itself, that'll be "destination unreachable" -- fix it
- Eth: restore original conn color when transmission ends
- "headerLength" param in snrEval???
- IPv4 configurator: should fill in next hop addresses too, not only interface (esp with Ethernet)
- IPv4: make it usable with ad-hoc models
- notifboard: switch to the context of the client before calling its receiveNotification()
- todo for omnetpp-3.2:
- add handleParameterChange() to apps (needed for Scenario Manager!)
- use new opp_msgc features? (kind=..., length=...etc)
----------------------
- ExtInterface performance optimization: I am not sure how long the pointer from
pcap_next() is valid [until the next such call perhaps?], but it might be possible
to spare the allocation of the ExtFrame and the cost of copying the bytes into it
inside cSocketRTScheduler::receiveWithTimeout(). I mean, the notification message
could just directly contain the ptr from pcap_next(), plus caplen; so the ExtInterface
module could directly deserialize from the pcap buffer (and also spare copying the
bytes out of ExtFrame). There is no concurrency problem, because events are processed
in strict timestamp order, the notification message has the same timestamp as the
external event, and receiveWithTimeout() is only invoked again when time has passed
that timestamp (``if (timeval_greater(targetTime, curTime))'' line in getNextEvent()).
This could improve the packet rate the simulation can handle in real time.
----------------------
- MPLS models: "gateway" field of routing entries gets lost after TED::rebuildRoutingTable
----------------------
- ICMP: shouldn't we unify ICMP and ICMPv6...? at least types and codes?
ICMPv6 uses different type&code numeric values but this is only of interest
if we want to do emulation
- instead of sending up ICMP packet to UDP & TCP: create an ICMPErrorInfo, and
IP (IPv6) would attach that to the bogus datagram, with message kind IP_I_ICMP_ERROR.
(win: IP/ICMP dependencies can then be removed from TCP and UDP in makemakefiles!!!)
- ErrorHandling is not used anymore! do we need to send a copy of ICMP errors to the
ICMP module itself as well?
- TCP: how to handle ICMP error reports?
-----------------------
- MPLS/LDP/RSVP:
- document! ScenarioManager commands, XML file formats, unimplemented features
- Quagga ospfd: could it serve as OSPF_TE??
- mpls models use interface NAME - why?
-----------------------
- OSPFv2 TODO:
- should use the proper IPAddress class, not its own one...
- OSPFTimer class only contains a timerKind() -- is this class necessary at all...?
- rename ifIndex (SetIfIndex, GetIfIndex, etc) to interfaceId AND change default value to -1!
- OSPFRouting::LoadInterfaceParameters: interfaceType is contained in InterfaceEntry, it's redundant to read it from XML!
- try to reduce size of configuration. If Zebra can do it...
-----------------------
into the ipv6 doc:
"
Currently, IPv6 support consists of several modules. The IPv6 module
implements IPv6 datagram handling (sending, forwarding etc). It relies on
RoutingTable6 to get access to the routes. RoutingTable6 also contains the
neighbour discovery data structures (dest cache, neighbour cache, prefix
list -- the latter effectively merged into the route table). Interface
configuration (address, state, timeouts etc) is held in the InterfaceTable,
in IPv6InterfaceData objects attached to InterfaceEntry as its ipv6()
member.
The module IPv6NeighbourDiscovery implements all tasks associated with
neighbour discovery and stateless address autoconfiguration. Its data
structures are in RoutingTable6 (dest cache, neighbour cache, prefix list).
Neighbour discovery packets are only sent and processed by this module --
when IPv6 receives one, it forwards the packet to IPv6NeighbourDiscovery.
The rest of ICMPv6 (ICMP errors, echo request/reply etc) is implemented in
the module ICMPv6, just like with IPv4. ICMP errors are sent into
IPv6ErrorHandling, which the user can extend or replace to get errors
handled in any way they like.
"
-----------------------
TCP:
Slow Start should be applied every time TCP starts to send "after a
sufficiently long idle period".
"Idle" could be interpreted as when the send queue is empty (there's nothing
to send), and there's no unacknowledged data (i.e. previously sent segments
have all been acknowledged). But what is "sufficiently long"? I guess that
should be measured in RTT rather than absolute time (secs). So maybe we
should say 5*RTT is "sufficiently long"?
-----------------------
802.11 bugs: see mailing list...
-----------------------
FlatNetworkConfigurator: assigns the same address to all interfaces of a router.
This is not the usual way things are done on the internet. But if we assign
different addresses, which addr to use in the routing tables etc?
-----------------------
VOJTA:
-make connect work without bind (autoassign local address based on
destination, currently unspecified address is sent and SYN+ACK will not
be sent back (at least for 127.0.0.1, I didn't check for others))
-----------------------
from http://www.freesoft.org/CIE/Course/Section3/10.htm:
# Per-interface assignment. IP addresses are assigned on a per-interface basis,
so a host might possess several IP addresses if it has several interfaces.
For example, a host with both Ethernet and serial interfaces would have an
IP address for each. This is an important consequence of prefix-based
addressing. An IP address doesn't really refer to a host, it refers to an
interface.
If a host is known by multiple addresses, then every service on this host
can be referred to by multiple names! Addressing this host requires picking
one of these. Since the packet is addressed to the interface and not the host,
path information is introduced into the address. The exact ramifications of
this effect depend heavily on the network design. In particular, careless
design can result in a host becoming reachable by one address but not by
another. The simplest solution to this problem is to select the host's most
reliable interface and advertise its IP address as the host's primary IP
address.
==> current FlatNetworkConfigurator is shit? how to do address assignment?
see also:
"The Network Administrators' Guide" http://www.tldp.org/LDP/nag/node1.html
"IP 101: All About IP Addresses" http://www.networkcomputing.com/netdesign/ip101c.html
- according to this: network numbers and interface addresses don't necessarily
have to do anything with each other! may look COMPLETELY different
from http://www.networkcomputing.com/netdesign/ip101.html:
The important thing to realize is that while a routing table keeps track of
network numbers, no one assigns a network number to any piece of equipment.
Every interface of a router or host connected on the network must have an IP
address and a subnet mask defined (many pieces of equipment will assign a
default subnet mask if none is applied). From this IP address and subnet mask,
the network number is derived by the IP stack and tracked in the routing table.
Q: if routing tables contain network numbers, are IP addresses of router
interfaces also addressable?