Simulation of Different Protocols using cnet Network Simulator

The cnet network simulator enables experimentation with various layers of OSI/ISO
networking model using various protocols in different networks consisting of point-to-
point links and IEEE 802.3 Ethernet segments. In the making of this paper I have mainly
worked with three different protocols − two of these work with the data link layer and one
works with the network layer. While working with the project I have tried to analyze the
efficiency of different protocols using various measures like efficiency (bytes AL/PL)
against different variables ( i.e. time, maximum / minimum message size, number of
transmitted, received and corrupted frames against variable frame size, average delivery
time against variable frame size.

But before going into these discussions, first here is a simple overview of − cnet
simulation model, topology files, and global, node and link attributes.

1.1 The cnet simulation model

cnet supports a model of networking in which nodes are connected by either point-to-
point links or Ethernet segments. Nodes may be either hosts or routers; introductory
protocols will only use hosts and point-to-point links. Hosts are like workstations, with
each having an Application Layer which generates messages for delivery to the
Application Layers on other hosts. Hosts never generate messages for themselves, and
routers never generate messages at all.

The cnet simulation model appears in the following diagram:

Each node, from 2 to hundreds, is connected to other nodes by one or more

physical point-to-point links or IEEE 802.3 Ethernet segments. Links are numbered
within each node from 0 to the number of physical links that the node has. Link number 0
is always the node's LOOPBACK link, which simply delivers anything transmitted to it

1
straight back to the same host. The first ``real'' link is number 1 and every node will have
a link number 1. Each node's link attributes may be accessed, at runtime, via elements of
the C structure variables linkinfo[1], linkinfo[2], and so on.

cnet itself provides each node with an Application Layer and a Physical Layer. In
addition, a hidden Error Layer resides above the Physical Layer, and causes transmitted
data frames to become corrupted or lost according to specified probabilities. (Note: The
standard OSI/ISO model does not provide an Error Layer!)

Perhaps surprisingly, the nodes initially have very little knowledge of the network.
Nodes do not know how many other nodes there are, what the other nodes are called, nor
the attributes of any nodes or links other than their own. All inter-node communication
necessary to learn this information must traverse the Physical Layer.

1.2 Protocol layers

cnet protocols are written from the point of view of each node, that is, we imagine that we
are writing our protocols inside each node. We have the ability to write all of the interior
protocols (or student protocols) between the Application and Physical Layers (and even
to rewrite these two layers if we need). The protocols may be as simple or as complex as
desired, and should follow a layered approach to isolate distinct responsibilities. For
example:

• a network of only 2 nodes will only need a single layer between the Application
and Physical Layers (usually termed the Data-Link Layer). This protocol will
simply have the responsibility of reliably moving frames across the single
bidirectional link between the two nodes.
• a network consisting of more than two nodes, will (ideally) require an additional
layer between the Application and Data-Link Layers (usually termed the Network
Layer) to manage packet routing, possibly congestion- and flow-control, and
message fragmentation (and possibly some other responsibilities).
• a network in which the nodes may crash or the links may be severed will (ideally)
require an additional layer between the Network and Application Layers (usually
termed the Session Layer) to ensure that old packets that have been ``floating''
around the network between crashes are not considered as part of the current
communication sequence, and
• a network in which we are conscious of limited bandwidth and security may
require an additional layer between the Session and Application Layers (usually
termed the Presentation Layer) to provide compression and/or encryption of our
data before it is transmitted.

Of course, these ideas and the responsibilities of each layer are not peculiar to cnet
protocols and are very well motivated and described in many undergraduate textbooks on
data communications and computer networking. However, cnet supports these ideas by
not getting in the way, by not imposing particular methodologies or data structures on
your protocols.

2
 Protocols are written using an event-driven programming style as if we were writing
the protocols as part of an operating system's kernel. As well as handling network-related
events, a traditional operating system must handle other events for its file-system,
devices, and to let user-level processes execute. For this reason, our protocols must
execute as quickly as possible, and then relinquish control to cnet (as if an operating
system) to permit other activities. cnet is unaware of your using one or ten interior layers
- cnet only provides the highest and lowest layers, and an application programming
interface (API) to interact with these layers.

1.3 Topology files

cnet accepts (many) command line options to control its execution. However, more
important is cnet's use of a topology file to define the attributes and connections in each
network simulation. Consider the following topology file which defines a 2 node network.
An implementation of the stopandwait protocol is being developed to provide a reliable
data-link layer protocol over the single point-to-point link. cnet keywords are presented in
bold font.

If necessary, the topology file is first preprocessed by the C-preprocessor,

enabling the use of #include, #define and conditional ``compilation'' directives if
required. Simple /* C and C++ style comments */ are also supported.

/* A simple 2 node point-to-point network topology */

compile = "stopandwait.c"

messagerate = 500ms,
propagationdelay = 700ms,
probframecorrupt = 3,

host Perth {
ostype = "palm"
x=100, y=100
messagerate = 1000ms,

link to Melbourne
}
host Melbourne {
ostype = "linux"
east of Perth

link to Perth
{ probframeloss = 2 }
}

/*(Image of this topology can be found in page 10.)*/

Global attributes may be defined in each topology file and affect the execution of
the whole simulation. They may not be redefined on a per-node or per-link basis. In the
above topology, the global attributes of bgimage and drawframes are defined.

3
 Node attributes and link attributes declared before any nodes are also considered
as global attributes - these will be the defaults unless redefined locally within a node or
link definition. Local attributes are declared in a new ``block'', by opening a curly bracket
(as in C). In the topology in the previous page, the default messagerate (the rate at
which the Application Layer will generate a new message for delivery) is 500ms. This
becomes the default messagerate for all nodes, but node Perth later declares its own
(local) messagerate as 1000ms. (Image of this topology can be found in page .)

The following topology defines a single segment Ethernet-based network of 6

nodes. The segment is named Lab1 and will be drawn at the indicated co-ordinates on
the topology map. Each node is connected to the segment by its Network Interface Card
(NIC); each NIC's address, as a string of hexadecimal characters, introduces each node's
connection to the segment. Although not shown in this example, each node could also
define its own local node attributes between the { } characters.

/* A simple 6 node Ethernet-based network topology */

compile = "ethertest.c"

minmessagesize = 100bytes
maxmessagesize = 1000bytes
messagerate = 1s

ethernet Lab1 {

x=100, y=200

nicaddr 00:90:27:62:58:84 host budgie { }

nicaddr 00:90:27:41:B0:BE host kanga { }
nicaddr 00:A0:C9:AF:9E:81 host quokka { }
nicaddr 00:0A:27:7D:41:C6 host emu { }
nicaddr 00:90:27:62:83:F5 host koala { }
nicaddr 00:90:27:34:B6:D8 host wombat { }
}

These two topology examples define small networks, one a simple wide-area
network, and the other a single segment Ethernet-based network. cnet permits any
combination of wide-area networks and Ethernet segments to be defined in the same
topology file. One or more nodes, typically routers of type NT_ROUTER, may have
connections to a combination of wide-area networks and IEEE 802.3 Ethernet segments.

1.4 Global, Node and Link attributes

1.4.1 Global attributes

Global attributes affect the execution of the whole simulation, and may not be redefined
on a per-node or per-link basis. The global attributes are not accessible to the protocol's C
code at runtime.

4
Global attribute Datatype Meaning Examples
provides the name of a GIF-format
image file to be centered on the
simulation's main window. The
bgimage string bgimage = "australia1.gif"
image file is sought via the
CNETPATH environment variable if
necessary
The global drawframes attribute
requests that frames traversing the
Physcial Layer be drawn under
certain conditions. By specifying a
drawframes Boolean special event handler, Data Link drawframes = true
Layer protocols in a 2-node network
may request that their frames be
drawn using different colours and
lengths.
requests that each link's
costperbyte attribute value be
displayed on the simulation's main
showcostperbyte Boolean showcostperbyte = false
window over each link. The use of
showcostperframe overrides
that of showcostperbyte.
requests that each link's
costperframe attribute value be
displayed on the simulation's main
showcostperframe Boolean showcostperframe = true
window over each link. The use of
showcostperframe overrides
that of showcostperbyte.
requests that the trace of execution
be mirrored in the named file when
tracefile string the -t option is given. Warning - tracefile = "appl-trace"
trace files can grow very large (to
several megabytes), very quickly.

1.4.2 Node attributes

The initial values of node attributes (global or per-node) may be specified in cnet's
topology files. Some node attributes may be modified while the simulation is running.
Node attributes include the rate of new message generation, minimum and maximum
message sizes, whether or not to trace all node activity, and the expected rates of node
failure and repair.

Node attribute Datatype Meaning Examples

the unique network
address integer address = 238
address of each node
a compilation string to
declare the sourcefile compile = "protocol.c stats.c -
compile string
names containing the lm"
protocols for each node

5
 (locally overrides the -C
option)
the rate at which the
Application Layer can messagerate = 10000usecs
messagerate time
generate new messages messagerate = 2s
for delivery
the minimum size of
minmessagesize = 100bytes
minmessagesize bytes messages generated by the
minmessagesize = 4KB
Application Layer
the maximum size of
messages generated by the
maxmessagesize = 200bytes
maxmessagesize bytes Application Layer
maxmessagesize = 8KB
(bounded by
MAX_MESSAGE_SIZE
the expected time between nodemtbf = 60000s
nodemtbf time
node hardware failures nodemtbf = 1000s
the expected time taken to nodemttr = 5000s
nodemttr time
repair a hardware failure nodemttr = 100s
the name of the operating
system that runs on the
node (only used to set the
node's icon). Possible
ostype string ostype = "linux"
values are bsd, hurd, irix,
linux, macintosh, nextstep,
os2, solaris, or winnt.
Gimmick.
the output file for each
node. When used as a
global attribute, outputfile
is used as a filename
outputfile string prefix (as with the -o outputfile = "output"
option). When used
locally, outputfile
indicates the complete
filename
provide one or more
white-space separated
command-line arguments
to be passed to the node's
rebootargs string rebootargs = "-fast -nostats"
EV_REBOOT handler.
(locally overrides any
arguments passed on
cnet's own command-line)
the ANSI-C function to
call when the node
rebootfunc string rebootnode = "reboot_function"
reboots (locally overrides
the -R option)
a Boolean indicating if
trace Boolean event tracing is required trace = true
(overrides the -t option)

6
 Boolean attribute
requesting that a node's
winopen Boolean winopen = false
window be opened on
startup
screen coordinates of the
winx, winy integer node's window under winx = 100, winy = 200
Tcl/Tk
coordinates of either a
node's icon, or the left-
x, y integer hand end of an Ethernet x = 80, y = 120
segment on the main
window

The compile attribute indicates which C source files are to be compiled and
executed by cnet. In the example topology file, above, an instance of the source code in
the single file stopandwait.c will be executed by each of Perth and Melbourne. Each node
will have its own copy of all variables declared in the file stopandwait.c (globals, static
globals, locals and static locals).

1.4.3 Link attributes

The Physical Layer delivers frames between nodes on unreliable, bidirectional links. The
initial values of link attributes (global or per-node) may be specified in cnet's topology
files. Some link attributes may be modified while the simulation is running. Link
attributes include the propagation delay between endpoints, the probabilities of frame loss
and corruption, the link bandwidth, the expected rates of link failure and repair, the
transmit buffer size, and relative costs of frame transmission (these last few only concern
more detailed protocols).

Link attribute Datatype Meaning Examples

bandwidth = 1000000bps
bandwidth datarate the bandwidth along a link
bandwidth = 56Kbps
the cost per byte along this
costperbyte cents costperbyte = 1c
link
the cost per frame along this
costperframe cents costperframe = 5c
link
the expected time between linkmtbf = 60000s
linkmtbf time
link hardware failures linkmtbf = 1000s
the expected time taken to
linkmttr = 5000s
linkmttr time repair a link hardware
linkmttr = 100s
failure
the probability that a frame
probframecorrupt probability on this link will be probframecorrupt = 3 /* 1 in 8 */
corrupted
the probability that a frame
probframeloss probability on this link will be lost probframecorrupt = 4 /* 1 in 16 */
altogether
propagationdelay time the propagation delay along propagationdelay = 200usecs

7
 a link propagationdelay = 1s
the maximum number of
bytes that may be written to transmitbufsize = 8KB
transmitbufsize bytes
a link in each call to transmitbufsize = 200bytes
CNET_write_physical

1.5 Simulation of Different Protocols in Data Link Layer and Network

Layer

1.5.1 Simulation in Data Link Layer

I have tested two different protocols, Ethertest and Stop and Wait ARQ, in two different
networks.

1.5.1.1 Ethertest

Ethertest is a simple prtocol of communication via a single Ethernet segment (shown in

the next page) where hosts communicate with each other using their NIC addresses. To
avoid the need for a physical->logical address discovery protocol, like ARP, each NIC
addresse is set to globally known values. Then the messages are simply transmit to the
required destination+link and everyone except the destination host discards the message.

8
Efficiency graph against variable message size
100
90

Efficiency (bytes AL/PL)

80
70
60
50
40
30
20
10
0
36

50

00

00

00
15

25

40

60

80

10

12

14
Maximum Msg. Size (Min msg size = 36bytes)

100
90
Efficiency (bytes AL/PL)

80
70
60
50
40
30
20
10
0
36
50
100
200
300
400
500
600
700
800
900
1000
1100
1200
1300
1400
1450
Minimum Message Size( Max. msg. size = 1450 bytes)

The first graph above shows how the efficiency (bytes AL/PL) curve increases as we set
the minimum message size to 36 bytes and varies the maximum message size between 36
bytes to 1450 bytes.

The second graph shows opposite behavior from the first one as we keep the
maximum message size fixed to 1450 bytes and varies the minimum message size
between 36 bytes to 1450 bytes.

The protocol does not run when we set either of the values to 1500 bytes.

The graphs depicts that the protocol works most efficiently when the lower bound
of the message size is around 36 bytes and the upper bound is around 1450 bytes.

I have also generated graphs showing the number of transmitted frames, received
frames and corrupted/collided frames vs. variable message sizes. But the graphs show
inconsistency in the statistics. One of the graph with lesser inconsistency is shown in the
next page.

9
 F. Transmitted F. Received F. Corrupt/Collission

400000
350000
300000
250000
200000
150000
100000
50000
0
36 50 150 250 400 600 800 1000 1200 1400
Min. Msg. Size (Max. Msg. Size = 1450 bytes)

Look, at the beginning the number of received frames is higher than the
transmitted frames, which is impossible. This could be because of some bugs in the
coding.

1.5.1.2 Stop-and-Wait Protocol

The second protocol I have worked with is Stop-and-Wait protocol. I have simulated this
protocol over a point-to-point link (shown below). In analyzing the efficiency of this
protocol I have taken the help of efficiency (AL/PL) curve. I have also used average
delivery time as a measure of protocol efficiency.

Two points should noted before we go any further –

1. It is currently written so that only one node (number 0) will generate
and transmit messages and the other (number 1) will receive them.
2. This protocol employs only data and acknowledgement frames -
piggybacking and negative acknowledgements are not used.

I have simulated the protocol for various fixed message sizes and generated their
efficiency curves (shown in the next page).

10
 Efficiency of 'stop and wait' protocol at different
message size

120

100
50 bytes
Efficiency (bytes AL/PL)

200 bytes
80 500 bytes
800 bytes
60 1000 bytes
1200 bytes
40 1400 bytes
1600 bytes
2000 bytes
20

0
1
30
59
88
117
146
175
204
233
262
291
320
349
378
407
436
465
Time (second)

From the graph we can see that when the message size has been fixed to 50 bytes
the average efficiency is the lowest. As we increase the message size it starts increasing
and reaches the highest value when the message size is 1600 bytes. After that it falls
again.

The reason behind this is at low message size the channel uses only few percent of
its capacity and the queue of the host is not filled up and the probability of frame
corruption or collision is low. But as the message size starts increasing the queue at the
hosts starts to fill up and the channel gets busy for longer periods and the probability of
frame corruption and collision increases. Hence, considering the probability of frame
corruption and collision the host takes more time to deliver a frame successfully.

Another phenomenon from the curves is visible that as the efficiency of the
protocol is high at the beginning and it decreases over time. The higher the frame size the
higher the protocol efficiency at the beginning. It is because efficiency (AL/PL) is the
ratio of the message in bytes generated by application layer and traversing the physical
medium. Hence the bigger the message size the higher the efficiency. But the bigger the
messages got the higher the probability of frame corruption and collision. As a result, the
efficiency decreases over time.

Besides efficiency (AL/PL) curve, average delivery time is also a desirable

measure of protocol efficiency. The lower the average delivery time the higher the
protocol efficiency.

11
 Here I have shown a sample curve (below) of how the average delivery time
increases as the message size is increased. From the figure we see that when the message
size equals 50 bytes the average delivery time is the highest. Then it starts decreasing and
from 500 bytes to 1400 bytes it fluctuates rapidly between 6450s to 6800s. Then it starts
increasing slowly after 1400 bytes.

Average Delivery Time vs. Message Size

7000000
Average Delivery Time
(micro second)

6800000

6600000

6400000

6200000
50 200 500 800 1000 1200 1400 1600 2000
Message Size

The reason behind high average delivery time at lower message size is that the
propagation time of a message and its acknowledgement is relatively high when message
size is small.

1.5.2 Simulation in Network Layer

In the network layer I have worked mainly with a routing protocol named flooding3. So
named, because it employs one of the network layer flooding algorithms.

At first I have tested two different flooding algorithms, flooding1 and flooding3,
on a WAN network connected by point-to-point links as shown below. The network
consists of 8 hosts, 0 routers and 9 links.

12
 When flooding1 algorithm, a simple flooding algorithm, was applied on this
network the efficiency (bytes AL/PL) reaches up to 2.79% after 343 frames are delivered
successfully.

When flooding3 algorithm was applied over the same network to deliver the same
number of frames it achieved a efficiency (bytes AL/PL) of 63.12% over this period. The
comparison is shown in the graph below.

Efficiency (Flooding1 vs Flooding3)

Flooding1 Flooding3

70
Efficiency (bytes

60
50
AL/PL)

40
30
20
10
0
1
19
37
55
73

91
109
127
145
163

181
199
217
235
253

271
289
307
325
343
Tim e (second)

The reason behind the huge difference between the efficiency measure of these
two algorithms lies in the fact how they send a packet to a particular destination. The first
protocol (flooding1) applies a basic flooding algorithm. It sends a packet to all directions
whenever it needs to send one. But the second protocol (flooding3) applies a routing table
algorithm. At the beginning every host sends a packet to all directions. But as it starts to
learn the best route of delivery it modifies its network table entry. This protocol also
modifies the maximum hop count as it learns the best route, therefore reducing the
number traversing packets in the medium.

I have also simulated flooding3 protocol for different topologies. A comparison of

efficiency improvement over time is presented below over a simple network (consists of 8
hosts connected by 9 links), and a large and complex network (consists of 35 hosts
connected by 43 links).

Efficiency rising time for different topologies

Flooding3 for World Flooding3 for Australia

70
Efficiency (bytes

60
50
AL/PL)

40
30
20
10
0
1
20
39
58
77
96

115
134
153
172
191
210
229

248
267
286
305
324
343

Tim e (second)

13
 When the protocol is applied over the network of 8 hosts with all the links having
the same attributes the efficiency rises above 65% in less than 6 minutes. But when it is
applied over the network consisting of 35 hosts and different link attributes the protocol
efficiency reaches about 19% over the period.

I have also tested the protocol for variable message size. But the efficiency curve
(not shown here) shows almost a constant characteristic. The reason behind that is
probably lies in the fact that network layer does not control the task of flow control and
framing, and this protocol assumes a reliable data link layer.

Conclusion

References
[1] Forouzan, Behrouz A., Data communications and networking, 2007(Fourth edition),
Tata-McGrawHill, Delhi.
[2] Stallings, William, Data and computer communications, 2007 (Eighth edition),
Prentice-Hall India, Delhi.
[3] cnet website, www.csse.uwa.edu.au/cnet

14