Student Network Design Projects Using OPNET

J. Potemans, J. Theunis, M. Teughels, E. an !il and ". an de #a$elle

Katholieke Universiteit Leuven, ESAT-TELEMIC
Kasteelpark Arenberg 10, -!001 Leuven, elgiu"
E-"ail# $an%pote"ans&esat%kuleuven%a'%be
"%stract
To provide students with a practical knowledge of networking,
the K.U.Leuven offers hands-on design projects that
complement theoretical courses. Master students in Electrical
Engineering focusing on telecommunications, design a
network for a specific service in a specific environment using
!"ET.
#uring the academic $ear %&&&-%&&', these students worked
on one of the following topics( voice traffic on leased lines,
)o*! on an Ethernet, or file sharing on an office L+". Each
project consisted of four parts( traffic load measurements,
anal$tic performance calculations, simulations, and a practical
la, implementation. The simulations, which were performed
in !"ET Modeler, are discussed in this paper.
TELEM*- participates in the !"ET Universit$ !rogram for
research and educational projects.
&ntroduction
.raduate education in the field of networking is far from
evident in our present-da$ *-T societ$. "ew inventions and
technologies are developed in rapid succession. "etworks
constantl$ grow in si/e and comple0it$. More and more people
and companies connect to the information highwa$. 1ow can
the content of electrical engineering programs keep up2
*n addressing this 3uestion, the TELEM*- 4Tele-
communications and Microwaves5 research group of the
Electrical Engineering department 4E6+T5 at the K.U. Leuven,
7elgium organi/es hands-on design projects. These projects
are supplementar$ to the advanced lectures on networking,
taught in the final Master8s $ear. The$ provide students not
onl$ a clear understanding of networking, ,ut also practical
design skills.
9eal-life networking pu//les are presented to the students.
The su,jects dealt with during the academic $ear %&&&-%&&'
are the following( adding voice traffic to the e0isting leased
line ,etween two remote campuses of the universit$, offering
)o*! services on a student dorm network, and file sharing on
the L+" of our research group. !revious topics e0amined are
the impact of videoconferencing on the universit$:s ,ack,one
network, )o*! replacing the *6#" network of our research
group, and ca,le access networks using the #-6*- protocol.

The assignment consisted of different parts. +fter a stud$ of
the pro,lem, students determined the current network load
statistics. This task included measuring packets on the specific
e0isting network infrastructure and anal$/ing call records.
!recautions were taken to avoid violating users8 privac$.
7oth anal$tical calculations ,ased on simplified models and
simulations are used to determine the ;ualit$ of 6ervice 4;o65
the network can offer.
The students < %= in total < were grouped in teams of two 4one
group of three5. Each team worked on one of the three
su,jects( voice traffic on leased lines, )o*! on a shared
Ethernet or file sharing on an ffice L+".
Teams working on the same su,jects had slightl$ different
assignments. These teams were encouraged to cooperate
where possi,le. *n addition, students were coached ,$ a team
of assistants, each responsi,le for one part of the assignment.
Each team was allowed '>& hours for the project and re3uired
to produce a results report.
*n this paper, we will focus on the use of the !"ET Modeler
for simulations in the projects. *n ?'@ we comment on the other
parts of the assignment.
Aor each su,ject detailed in this paper, we summari/e the
results of one team. Be start with an outline of the pro,lem
followed ,$ a description of the simulations. Be go deeper
into the simulated network topolog$ and the definitions of the
different tasks and applications. !ossi,le pro,lems and
difficulties encountered are also mentioned. The paper
concludes with an evaluation of the projects and simulations.
More information on the design projects, together with all
reports 4including previous projects:5, can ,e found on the
homepage ?%@.
oice tra'c on leased lines
*n this section we summari/e the results o,tained in ?C@. The
complete report can ,e found on ?%@ together with the reports
of two other groups working on the same su,ject.
Problem outline
The universit$ in Leuven 4K.U.Leuven5 has a smaller campus
in Kortrijk 4KUL+K5. More than '&& kilometers apart, the
campuses are interconnected ,$ a % M,ps full-duple0 leased
line.
(
Up to the time of the networking pu//le that this paper
documents, this % M,ps line was used onl$ to transmit data
traffic.
+t the ,eginning of the project, 7elgium still had several
phone /ones. !hone calls to the same or a neigh,oring /one
were charged at local rate, while long distance calls were
charged a su,stantiall$ higher rate. Transmitted via the leased
line, the universit$:s calls ,etween its two campuses, in
Leuven and in Kortrijk, would ,e for free. +nalogousl$, calls
from the Kortrijk campus to the Leuven area would ,e Dlocal
callsE for ,illing purposes. *n addition, students e0amined
where to add other !!s 4!oints of !resence5 to cover the
complete Alemish part of 7elgium and to convert it into one
,ig phone /one. This wa$, all calls from universit$ to a
destination in this ,ig /one, would ,e charged at local rate.
f course, an$ possi,le cost savings would have to ,e
weighed against new costs in hardware, leased lines, etc.
Solution
*t was resolved that to cover the complete Alemish part of
7elgium, two e0tra !!s would ,e necessar$( one in .ent and
one in Tongeren. To minimi/e the leasing cost 4distance5, .ent
was connected to Kortrijk, while Tongeren was connected to
Leuven. The resulting topolog$ is mapped in Aigure '.
+ router was placed in each !!. The effective routing
capacit$ of each router was adjusted in the attri,utes menu
4'&&.&&& pFs in Leuven, G&.&&& in Kortrijk, >&&& pFs in .ent
and Tongeren5. 6erial lines were linked to the routers( % M,ps
,etween Leuven and Kortrijk, ' M,ps ,etween Kortrijk and
.ent, and, finall$, '%H K,ps ,etween Leuven and Tongeren.
*t was also decided as a condition, that all traffic has to ,e
transmitted in packets over this network infrastructure.
To o,tain a realistic load, students anal$/ed call traces from
the universit$ and parameteri/ed necessar$ statistics( the
interarrival time ,etween the calls 4I.G' s5 and the length of
the calls 4%%'.H s5 during ,us$ hours. 7oth measurements were
used as mean values of e0ponential distri,utions.
*n order to add voice traffic to the network, an Ethernet
workstation was connected to each router. Aor simplicit$, each
!! was studied without modeling the voice gatewa$ and
!+7J.
Two voice profiles were defined( one for voice calls
originating from Leuven and another one for voice calls
originating from Kortrijk.
The weighing ta,le in Aigure % shows the destination
preference for the voice profile in Leuven.
The predefined )oice over *! application model was used to
generate voice traffic. Aigure C and G show how the measured
call duration and the interarrival time could ,e configured for
use in simulations.
1owever, the network infrastructure still had to carr$ normal
data traffic, just as it alwa$s had. "ot onl$ the load of the line
,ut also the total load of the routers had to ,e figured in, for
determining the network:s ;o6. 6tudents used 6"M! re3uests
to measure the num,er of packets and ,$tes transmitted
through each router port.
The measured data traffic on the leased line ,etween Leuven
and Kortrijk was simulated ,$ an interaction ,etween an
Ethernet workstation in Leuven 4kuldata%5 and an Ethernet
server in Kortrijk 4serverKkulakK%5. Each time the server
)
(igure !# Con)guration o* the 'all +uration
(igure ,# -eights *or the Leuven voi'e
pro)le
(igure 1# Si"ulation topolog.
received > re3uest packets, it answered with % response
packets. This ratio represented the difference in amount of
traffic in ,oth directions.
The average packet si/e was calculated from the
measurements( GGG ,$tes going from Leuven to Kortrijk and
'LG ,$tes in the other direction. The students assumed an
e0ponential distri,ution for ,oth packet si/es. The average
inter-re3uest time was &.' s, and assumed to ,e e0ponentiall$
distri,uted. Aigure > and I show the configuration of the client
and the server, respectivel$.
To simulate the other load of the routers in Leuven and
Kortrijk, a workstation-server pair was added ,oth in Leuven
and Kortrijk. The total num,er of packets 4re3uests and
responses5 e3ualed the total load of the router measured with
6"M!, minus the num,er of packets that were transmitted on
the % M,ps leased line.
To keep within the scope of this paper, we will focus on the
link ,etween Leuven and Kortrijk. The complete results are
availa,le in ?C@.
Aigure = and H show the traffic load 4in packetsFs and ,itsFs5
and the dela$ in ,oth directions, respectivel$.
*
(igure /0# Tra1ela.2' loa+ bet3een Leuven
an+ Kortri$k
(igure 4# Con)guration o* the server
(igure 0# Tra2' loa+ bet3een Leuven an+
Kortri$k
(igure 5# Con)guration o* the interarrival
ti"e
(igure 6# Con)guration o* the 'lient
(igure /# 1ela. bet3een Leuven an+ Kortri$k
The dela$ values indicated an accepta,le level of voice
3ualit$. The network was not overloaded ,$ the addition of
voice traffic.
o&P on a shared Ethernet
This section offers an overview of the results o,tained in ?G@.
The complete report can ,e found on ?%@, together with the
reports of three other groups working on the same su,ject.
Problem outline
6tudents living in a universit$ dorm can access Kotnet 4the
student network infrastructure5 from their room via a shared
Ethernet connection. n each floor of the dorm there is one
pu,lic telephone, which students can use to dial or receive
calls. #uring ,us$ hours, this single phone cannot service
demand ade3uatel$ for '' students per floor. +dding more
telephone lines is an e0pensive operation. Therefore, the
universit$ wanted to know how it could use the computer
network to offer )o*! services to each student room.
Aor management and securit$ reasons, the universit$ wanted
to place the necessar$ servers and gatewa$ in a central place
called Ludit. *n this project, students tried to determine
whether these )o*! services could ,e offered to the students of
the Blok5 dorm. Aigure L shows the path the voice traffic of
Blok5 had to follow to reach the gatewa$ at Ludit.
Solution
7ecause the dela$s from the different switches proved to ,e
negligi,le compared to the router-,ased dela$s, all switches
were omitted from the simulations. +lso the gatewa$ could ,e
disregarded ,ecause it added a constant dela$.
*n our model, a,out >& !-s were connected to the hu, in
Blok5. To reduce simulation time, onl$ C !-s and a server
were used to generate the complete traffic load.
ne !- represented the internal data traffic, another the
e0ternal data traffic, while the third was used for voice traffic.
The simulated topolog$ is depicted in Aigure '&.
Aor each traffic stream, a different task was defined. 7ecause
of memor$ limitations, no distinction in packet si/e classes
could ,e made for a specific stream. Ta,le ' provides an
overview of the different tasks.
source destination interre3.
time 4s5
si/e
4,$tes5
' blok5 server
kulnet
>.>e-C '''I
% blok5bar barbara '.&= e-C 'C&=
C rest kotnet server
kulnet
%.CHe-G '''I
G blok5back blok5 >.>e-C '''I
> kotnetback rest kotnet '.C>e-G '''I
Table 1# Task +e)nitions
Two profiles were defined( one for data traffic and one for
voice traffic. The voice application settings are listed in ta,le
%.
-odec . =%C.'
Arames per packet G
Arame si/e C& ms
Lookahead si/e = ms
#6! processing '
-oding rate I.C K,ps
+
(igure 7# (ro" Blok5 to the voi'e gate3a.
(igure 10# Si"pli)e+ topolog. *or si"ulations
Table ,# 8oi'e-appli'ation settings
*nitiall$, to ,aseline the current situation, students ran
simulations without voice. The traffic sent and received ,$ the
blok5bar !- is plotted in Aigure ''. +t the application la$er
LC& pFs were sent to barbara while onl$ 'H% pFs were sent at
the *! la$er. This discrepanc$ was caused ,$ a saturated
Ethernet( The application sent more packets than the network
could transport.
Blok5bar was not configured to receive traffic. The values in
Aigure '' result from T-! acknowledgements, which were
generated each time a packet was transmitted successfull$.
Aigure '% shows Ethernet dela$, collision count, and
utili/ation, respectivel$. The Ethernet is overloaded.
Therefore, it was concluded that adding voice traffic to the
e0isting infrastructure was not feasi,le during peak traffic
loads.
6tudents performed simulations in two other cases( one with a
single active voice call and one with three simultaneous calls.
Aigure 'C gives the end-to-end dela$ and the variation on this
dela$ for one active call. The Ethernet collision count and the
utili/ation in this case can ,e found in Aigure 'G.
,
(igure 11# Tra2' sent an+ re'eive+ b.
blok5bar
(igure 15# Ethernet per*or"an'e
para"eters *or one a'tive 'all
(igure 1!# 8oi'e en+-to-en+ +ela. an+
variation on this +ela. *or one a'tive 'all
(igure 1,# Ethernet per*or"an'e
para"eters 3ithout voi'e tra2'
The voice application end-to-end dela$ does not include the
dela$ of the gatewa$, the codecs, or the soundcards. These still
have to ,e added to the average end-to-end dela$ of >C ms.
This wa$, the total dela$ amounted to appro0imatel$ '>& ms.
To determine the dela$ of the voice stream, a latenc$ of '%&
ms ,etween two packets had to ,e taken into account. This
increased the dela$ to %=& ms, which is a,ove the ma0imum
allowed %>C ms.
#ue to the high Ethernet utili/ation, a large num,er of voice
4U#!5 packets would ,e lost, resulting in ver$ poor ;o6.
-learl$, a num,er of technical interventions 4e.g. an upgrade
to switched Ethernet5 would ,e needed to provide )o*!
services to students in their dorm rooms.
-ile sharing on an O'ce !"N
*n this section, we summari/e how the students in ?>@ dealt
with the office network optimi/ation pro,lem. Their complete
report can ,e found on ?%@, together with the reports of five
other groups who produced different solutions to the pro,lem.
Problem outline
The aim of this project was to optimi/e file sharing on the
network of the TELEM*- research group. Aile sharing ena,les
users to access files and directories located on remote
computers and to use those files and directories as if the$ were
local.
The central component of the network in this stud$ was an
Ethernet switch. 6even workstations were attached to this
switch( Loebas, Zulte and Kastaar act as file server, Duchesse
as application server, while Toine, Blondine and Hercule were
com,ined servers. +lso three hu,s M with L, '' and 'L !-s
attached M were connected to the switch.
The students had to e0amine a dedicated server configuration.
+ specific server could onl$ ,e used for a specific task( file
serving or application serving. The "etwork Aile 6erving
4"A65 protocol version % was used. ther groups focussed on
"A6 version C, or the 6erver Message 7lock 46aM7a5
protocol.
Solution
The students chose the slower machines 4Loebas, Zulte and
Kastaar5 as file servers, and the faster machines 4Toine,
Blondine and Hercule5 as application servers.
The !-s on the hu,s communicated with the application
servers or with machines outside TELEM*-, not with each
other. Most of the internal traffic originated from J''
application interactions. The dela$ on a hu, domain was
assumed to ,e negligi,le compared to the dela$ induced ,$ the
servers. Therefore, three !-s were configured to simulate the
total traffic to and from the three hu,s. Aigure '> shows the
simulated network topolog$. +ll links were '& M,ps half-
duple0 Ethernet connections, e0cept for the link ,etween the
switch and 1ercule, which was a '&& M,ps half-duple0
Ethernet connection.
The J'' traffic was modeled using the predefined Dremote
loginE application. Two applications were defined with re3uest
packets of IG ,$tes and response packets of C&& and '>'H
,$tes. The necessar$ parameters were adjusted to o,tain the
right ratio of occurrence.
+ profile was configured to o,tain the correct distri,ution of
traffic among the application servers and the sink PC. The
latter represented the machines outside TELEM*-. 7ased on
the assumption that each hu, caused the same traffic load, one
profile was enough for the three !-s.
Traffic from outside TELEM*- caused ,$ students was
modeled accordingl$. nl$ one remote login application was
.
(igure 16# Si"ulate+ o2'e LA9 topolog.
needed since onl$ two packet si/es were measured( re3uests of
IG ,$tes and responses of '%&& ,$tes.
"A6 traffic ,etween the file servers and the application servers
was modeled ,$ defining a task that transmitted a file of L&&
K,$tes. This task ena,led the client to send a re3uest packet of
%'I ,$tes. +fter a processing time for reading from the hard
disk, the server answered with a response packet of G&LI ,$tes
4which is divided into smaller packets for transmission over
the Ethernet5. This process of re3uest - reading from hard disk
- response was repeated %%& times to get a total file si/e of L&&
K,$tes. The time ,etween the re3uests and the time ,etween a
re3uest and a response depended on the power of the
application server and file server. The "A6 application was
used ,$ the C application servers ,$ defining C profiles.
The inter-repetition time ,etween two file transfers was
assumed to ,e e0ponentiall$ distri,uted, and was different for
the C servers ,ecause each server re3uested a different amount
of "A6 data. +lso, the destination preferences differed.
The highest dela$ caused ,$ the network itself was located at
the Ethernet. Aigure 'I shows that the average dela$ was onl$
C%& Ns, which is small compared to the dela$ induced ,$ the
file servers.
The average traffic that the application servers received from
the file servers is plotted in Aigure '=.
The load of Hercule was a,out = times higher than Blondines
and a,out C times higher than Toines.
Aigure 'H shows the time re3uired to receive a file of L&&
K,$tes. 6ince a file transfer is defined as one task, it is the
time needed to complete this task.
The average time was 'G.' s, with a peak of %C.= s. The
difference with the Ethernet dela$ indicates that the file
servers caused the ,ottleneck in the s$stem.
Conclusion
*n this paper we presented the simulations students performed
in the framework of a design project. .etting ac3uainted with
!"ET Modeler re3uired a good deal of time and effort from
the students. + lot of creative pro,lem solving was needed,
/
(igure 14# Ethernet +ela. on a hub
(igure 10# Average tra2' appli'ation servers
re'eive *ro" )le servers
(igure 1/# Ti"e nee+e+ to sen+ a )le
o* 700 Kb.tes%
,ut the results are 3uite satisfactor$. 6tudents gained a lot of
insights into networking ,$ using !"ET Modeler.
References
?'@ O. Theunis, O. !otemans, M. Teughels, +. )an de -apelle and E.
)an Lil, D!roject #riven .raduate "etwork Education,E Proceedings
of the nternational Conference on !et"orking
C!#$%, -olmar, Arance, pp. =L&<H&%, %&&'.
?%@ 1omepage of the network design projects(
http(FFwww.esat.kuleuven.ac.,eFPCirteleF1%CLF
?C@ A. #upont, .. -astermans and !. Le$s, D!oint to point
connections( )oice over *! as an alternative for inter/onal calls,E
internal student report 4can ,e downloaded from ?%@5, %&&&.
?G@ *. #8hooghe and 6. #8hoore, DL+"-!+7JE, internal student report
4can ,e downloaded from ?%@5, %&&&
?>@ !. Oonckheere and 1. )anhaute, DAA*-E L+"E, internal student
report 4can ,e downloaded from ?%@5, %&&&.
0