—The present paper is the first coursework for the module cim238, Network Design and Management. The first network scenario, the Intranet, is about the evaluation of certain services according to the specific topology. A second scenario, the Extranet, will be deployed as network expansion and new services will be added. A third scenario, the Expansion, is about the evaluation of the expanded network topology and software components, as well. I use the Opnet It Guru academic edition for network and applications demand simulation.
The subject of the present essay is a simulation of the enterprise network of a healthcare company (. 1), the ATH Diagnostics, which is based in Athens and provides medical imaging and diagnostic services according to scenario of the coursework. The company keeps its headquarters in Athens, in two main installations, ATH, and ATH_2. Both main nodes include diagnostic services, so LANs that support medical services are included. ATH supports 150 users and ATH_2 supports 100 users. There in another node in Athens, ATH_1, which interconnects ATH and ATH_2 and supports up to 25 users. Two peripheral nodes, KIF in Kifisia and PER in Piraeus are connected through ATH node, and support up to 25 users each.
Company keeps a branch office in Thessaloniki, which supports up to 25 users. The backbone network is based on HellasPac, a frame relay technology, which is offered by the Hellenic Organization of Telecommunications (OTE). The company is going to be expanded, with a second floor in Thessaloniki, including 25 more users and a branch office in Sofia, Bulgaria, including 10 users. The simulation software, Opnet IT Guru academic edition, is limited to the number of simulated events (50 million maximum). For this reason the simulation is separated in two parts: The Intranet, where application servers in ATH node are tested including a worst case scenario, and the Extranet, where application servers in ATH_2 node are tested.
In the Extranet scenario a custom task is included, the image viewing application. It requires an additional server, the Radiology server, which is installed in ATH node. Because of the limitations of the backbone technology (frame relay) I have chosen not to include background traffic or additional traffic flows. Usually the corporate network is used for supporting services, such as VoIP telephony and video conference. Such services require dedicated bandwidth and QoS and it is probable to exceed the abilities of a Frame Relay PVC of 2 Mbps. It is very likely that several HellasCom lines (1920 kbps each) or digital leased PCM lines (E1 or more) are more suitable. Finally, a simulating time of 60 minutes is adequate to demonstrate network convergence .
II. Intranet Scenario
A. Scenario Conuration
The point of the Intranet scenario (intranet) is to test the ATH servers with the predefined profiles w, e and d. The profiles define searching (web browsing), medium e-mail downloading and medium database access, respectively (. 2). I have made the following modifications to global Profile Con:
* The operation mode has changed from serial (ordered) to simultaneous. The network has plenty of users which are served concurrently, so serial servicing is not quite realistic.
* The profile distribution has changed to avoid stereotype user behavior. From default uniform (100,110) distribution to distributions with minimum and maximum values: (110,150) for w, (80,120) for e and (130,170) for d, respectively.
1) Frame Relay Conuration.
Frame Relay is a layer-2 packet-switching protocol, oriented to interconnect terminals or local area networks (LAN) to wide area networks or WAN . Frame relay stacks data in variable size entities, called “frames”, without performing any error correction. The protocol provides permanent virtual circuits or PVCs among terminal points and the final user gets a permanent connection to a wider network with committed capacity. Some of the crucial parameters, which are declared in the contract between the customer and the telecom provider, are:
* The Committed Information Rate or CIR, which is the average rate (bps) at which the provider guarantees to transfer data over a time T = Bc/CIR.
* The Committed Burst Size or Bc, which is the maximum length of data (bits), transmitted during the time T.
* The Excess Burst Size or Be, which is the maximum uncommitted data that the network serves, during time T.
The following . 3 depicts the infrastructure of a typical frame relay network. In ATH Diagnostics simulation, the end routers (fr4_ethernet2_gtwy) are also considered to incorporate Frame Relay assembler-disassembler (FRAD) interfaces.
All the node routers have 4 Frame Relay and 2 Ethernet interfaces, but only one FR and one Eth IF are used. All FRADs of the remote routers have PVCs with CIR=256 kbps, Bc=256 bits and Be=0 bits, for incoming and outgoing connections except ATH1 router, where CIR=1024 kbps, Bc=1024 bits and Be=0 bits. I have changed also the line capacity of the FR connection between ATH router A and frame relay cloud to 1024 kbps, to have a better visual demonstration of the line utilization .
The following . 4 depicts a typical PVC setup, the KIF for the Kifisia node. The KIF virtual circuit interconnects the source FRAD, which is the router D of KIF node to router A of ATH node. The frame relay cloud serves as a ubiquitous FR medium, and offers FR connectivity to remote nodes with zero delay. The contract parameters are setup as described below:
2) Service Allocation
The next procedure is to allocate services to servers and clients . As already mentioned, the Intranet scenario uses only the ATH servers so I assign to every dedicated ATH server, the corresponding service. Therefore, on the email server, I select the application email on the attribute field Application: Supported Services. Respectively, I select the application web on the web server and the application db on the db server. The procedure is depicted in . 5 for the email server in ATH node.
It is clear that every user in every LAN of the topology uses the three services, web, email and db, so the w profile that contains the web application, the e profile that contains the email application and the d profile that contains the db application are selected on every LAN of the topology, for the entire LAN. The procedure is depicted in . 6 for the users of Kifisia node (KIF lan5).
Another step, which is necessary to setup on every LAN, is the attribute field of the Application: Destination Preferences. The symbolic name of every server which corresponds to the application, which is included in the active profile, should be included. Then, every symbolic name has to be assigned to the corresponding server name, as declared on the attribute filed of Server Address, of the specific server. The procedure is depicted in . 7 for the users of KIF lan5.
B. Scenario Evaluation
The Frame Relay PVCs constrain network traffic to predefined values, as the virtual circuits KIF, PER, ATH1 and ATH2 to 256 kbps and ATH to 1024 kbps. I have changed the lines among the FR routers and the FR cloud, from FR_T1 capacity to the nominal values that the specific PVC declares. Therefore, all remote lines have now capacities equal to 256 kbps except the line from ATH router A to FR cloud and the line from ATH_1 router B to FR cloud. By doing this, I can easily present the utilization each of the channels.
On every LAN (lan1, lan2, lan3, lan4 and lan5) I choose Individual Statistics and I select Response Time (sec) for client DB Entry, client DB Query, Client Email and Client Http. On the ATH servers I choose Individual Statistics and I select CPU Utilization (%) and Server Load (request/sec). The default settings for every network connection include line statistics so I choose Throughput (bps) and Utilization (%).
Furthermore, I choose Individual Statistics for the global network, and I select Response Time (sec) for the Web, the Email and the Database applications. The settings are similar like the conuration above, for LAN users. The global application response times are under evaluation for optimum performance, so it is necessary to keep these times under certain limit. A limit overflow indicates that a capacity upgrade is inevitable .
1) The KIF node
From the above statistics it is clear that the applications perform smoothly on the KIF LAN terminals and the throughput (incoming and outgoing) for the FR PVC is 108.4 and 50.6 kbps, far below the committed capacity, which is 256 kbps. The total utilization is low, 41.9 and 19.9 % respectively. Similar results emerge from the rest of the LANs with no considerable variations. This will be made clearer to global statistics section that follows.
2) The ATH Servers
As emerges from the simulation, CPU Utilization and Sever Load for the ATH servers (Web, Email and DB) remain low for the normal Intranet scenario. So I will omit the results, although I will use them in the comparative charts on the worst case scenario analysis.
3) Global statistics
From the diagrams below it is clear that all the applications perform globally well and the response times remain low, distinctly under the commonly accepted limits. From the following s, 12 and 13, I assume that the traffic flow remains within the capacity limits of the relative 10baseT line or the virtual circuit PVC. The link between ATH router A and FR cloud remains below 301.3 kbps (capacity of 1 Mbps). Also the utilization of each line remains low and the maximum value does not exceed 41.9 %, for the KIF incoming PVC traffic.
C. Worst Case Scenario
To evaluate network topology under Worst Case Scenario (intranet_wc) I presume that the LAN users perform web, email and db profiles with the highest load setups for each application. Therefore web uses image browsing, email uses high load downloading and db uses high load transactions (50% Queries). The operation mode remains Simultaneous and distributions remain as set at the previous scenario. Data acquisition settings remain the same like the precedent scenario. Finally, after the execution of Discrete Event Simulation (DES), the following results arise:
1) The KIF node
From the diagram in . 15 it is clear that the PVC KIF is highly congested and the assigned capacity of 256 kbps is deficient for the demanded traffic. This is depicted clearly in . 14, where the applications of lan5 exhibit high response times, especially the db transactions. The same behavior appears in PER node lan6 users, and in ATH_2 lan4 users, where the system yields the same or even higher response times.
2) The ATH node
In ATH node the three LANs (lan1, lan2 and lan3) perform well and the capacity of 10baseT (10 Mbps) seem enough for the generated traffic. The utilization of the FR line among router A and AMA FR cloud is 73.9% and 74.6%, for incoming and outgoing connections. The throughput is less than 800 kbps, respectively. Although these values look to be inside limits there is a serious indication that the bottleneck in peripheral nodes limits the traffic on the main line. Thus, if it is planned to upgrade all the PVC capacities, there should be an upgrade to the capacity of the line between ATH's router A and the provider, as well. As regards the server load, the Web server presents the bigger load comparing to the other servers, with CPU Utilization more than 83% and Throughput 158 requests/sec.
3) Global Statistics
The high response times are shown in . 16. However the low Http Page Response Time is not indicative, because the ATH LANs dominates. Thus, the Web application performs well and the remote nodes sub-function. The diagram, in . 17, depicts clearly the high utilization percentages. One of the highest congested lines is the FR line from router C of ATH_2 to FR cloud. In general, all PVC require immediate upgrade to higher capacities, and with its turn it will claim to upgrade the ATH Router A <-> FR cloud line capacity.
D. Worst Case Scenario Upgrade
In general, the upgrade method that I have followed is that I gave initially adequate capacity to the critical link between ATH router A and FR cloud. Then I have increased the capacity of peripheral PVCs in steps of 128 kbps, from the initial capacity of 256kbps, until the global applications response times felt again below the predefined limits . It is known that exist typical response times for web applications, according to user satisfaction ,. A rule of thumb is the following:
* Response times below 0.1 sec are considered as instantaneous.
* Response times below 1 sec are in considered to keep user attention uninterrupted.
* Response times above 10 sec and up to 15 sec are considered long delays and the user distracts his attention.
For the current simulation (intranet_wc_upg) I presumed as satisfactory response times below 1 sec for web page response time and email download response time and below 0.85 sec for database transactions (entries or queries). All the above limits are considered of 90th percentile. To achieve lower times it requires higher capacities and the total cost will inflate inexpediently. The Web server's CPU maximum utilization has found to be 100%, so I have added a second CPU and the utilization have fallen to 51% each. The DB server's utilization is 65% and Email server's 2.5%.
The PVCs capacities have increased up to the full FR line capacity (2 Mbps) each, and I have allocate FR_E1 lines everywhere except the high capacity link between ATH router A and FR network cloud, which I have allocate two FR_E1 lines (4 Mbps). All the LAN speeds remain at 10baseT, as they where found marginally adequate for the scenario needs. The following diagrams present the comparative global response times for web page and email downloading and data base transactions, respectively. The vertical axis is logarithmic to display correctly the smaller variations of the upgraded scenario.
The utilization of the lines between the nodes of the topology remains below 100%. The highest value (89.9%) belongs to the link between ATH's router A and AMA FR cloud, as depicted in the following diagram. This value is marginal, and higher utilization will yield response times above the predefined limits. However, to achieve lower values requires a higher capital investment. So I designate these values as a balance between performance and cost.
III. Extranet Scenario
A. Scenario Conuration
For the Extranet scenario (extranet) I consider steps that I have exhibited in the Intranet scenario as known, so I will omit them to save space. Therefore, I have done the allocation of services similarly as in the intranet scenario, with the application servers reside at the ATH_2 node. The applications declarations and the profile uniforms are the same as in the Intranet scenario. I choose all FR links between FR clouds to be the maximum capacity of a single FR link, which is 2 Mbps.
B. Scenario Evaluation
The FR PVCs (THES and ATH1) capacities are 256 kbps each. I choose for every LAN of the topology (lan4, lan7 and lan8) the statistics: Response Time for Web, Email and Database services. Statistics for global response time are selected, as well. I also choose, on every FR router, Throughput for every FR PVC which is in use, usually at the IF2 P0 port. After completion of DES, the following results appear:
1) The THES node
From the above diagrams it is clear that applications run smoothly on THES node and throughput is kept low, less than 90 kbps, which is far below the PVC capacity. I have similar results from the other nodes (ATH_2 and ATH_1).
2) The ATH_2 servers
The above diagram depicts the Server Load on ATH_2, for Database, Email and Web servers. It is also clear that the applications run smoothly.
3) Global Statistics
From the above diagrams in . 24 and 25 it is clear that throuput remains low in the entire topology and below the respecive line capacities.
C. Expansion Scenario
1) Topology Design
The company Expansion scenario (expansion) includes a second floor in Thessaloniki branch office and a new branch office in Sofia, Bulgaria. Therefore, at THES node I have added a second LAN, facilitating 25 more users (lan9), with the same services conuration as in Extranet scenario, and a node switch (switch C), which interconnects the two floor's LANs . I have included a FR cloud as well, whereby THES router F interfaces to provider's FR WAN. I have changed the capacity of THES PVC to 512 kbps, to double bandwidth for starters, due to the second LAN ,.
The above . 26 and 27 depict the new node topology for the expanded scenario. The added switch C is introduced to support future node expansion. Similarly I have created the SOF node. The subnet includes the lan10 serving 10 users, a FR router (fr4_ethernet2_gtwy) and a FR Network cloud, whereby SOF router G interfaces to provider's WAN.
I have constructed a PVC circuit, the SOF PVC, with setup as depicted in the following . The circuit interconnects SOF's router G with ATH_2 node's router C, through FR clouds. I have allocated the capacity of 256 kbps for starters. All the FR lines are E1 (FR_E1).
2) The Custom Application Setup
One of the deliverables is the creation of a custom application, the image view application, which I name Radiology_Images. I add a new server, the Radiology Server to ATH_2's server farm, together with the other application servers. The Radiology_Images is nothing more than a viewer, which when executed on the client side, downloads images (digitized x-rays) stored on the Radiology server. Every image is in jpeg format and has a standard size of 0.5 MB .
On every node, except ATH_1, and on every included LAN, there is one user (a doctor) which uses Radiology_Images application. First I have constructed a special task, the Download_Image task, which the custom application will use. The following . 32 depicts the steps that I have followed:
The task contain a single phase, the Image_View phase, with settings as depicted above. Something to mention is that the Response Packet Size is the downloaded image's size (512 KB), the Request Packet Size is the client's acknowledge (512 Bytes), the source in named client and the destination is the new Radiology Server.
The next step is to create the custom application, the Radiology_Images. The procedure is depicted clearly at . 32. The application contains the already declared task, the Downlad_Image.
Finally I have created a new profile, the Radiology profile. I have to mention that I have chosen a different distribution for Radiology, the uniform (60,110) and in the filed Duration (of the application) I have chosen End of Last Task instead of End of Profile, to enable more iteration during a profile execution and not just only one.
D. Expansion Evaluation
The final step that I have to perform prior to DES execution is the proper allocation of the Radiology profile. Therefore in every LAN, except the lan7 of node ATH1, which are: the lan4 of node ATH_2, lan8 and lan9 of node THES and the lan10 of node SOF, I include the profile Radiology to be executed for only one LAN user as depicted in the following :
Something important to mention is that I include the Radiology Server (Radiology_Server) on the Application: Destination Preferences and the symbolic name client on the Application: Destination Preferences field. The data acquisition selections remain similar as the preceding evaluations, except that I have now included the global Custom Application Response Time or the Requesting Client Response Time on the specific LANs. It is given that the Radiology_Images application response time is limited to 15 sec of 90th percentile.
1) The SOF node.
The following diagrams in . 35 and 36 depict the application response times for the Sofia branch office network, the lan10. A first deduction points that, although average response times for Web, Email and Database applications stabilize below limits, the custom application responds at long average times, above 100 sec with maximum values of 116 sec or more. This is not acceptable and it is urging to increase PVCs capacity to a wider limit.
2) Global Statistics
The following depicts the global custom application response time. It is clear that there is a long average response time (above 60sec). The Radiology_Images application is more demanding comparing to the standard applications and there should be an upgrade in the remote PVCs, these of SOF and THES nodes. The ATH_2 node's lan4 is not under restrictions as the remote LANs, thus its response time remain below maximum limits .
E. Expansion Upgrade
For the current simulation (expansion_upg) I presumed as satisfactory response times the values I have selected in the previous scenarios. I repeat that the maximum custom application response time is 15 sec (90th percentile). Similarly, I gave initially adequate capacity to the critical link between ATH_2 router C and FR cloud and I have increased the capacity of peripheral PVCs in steps of 128 kbps, from the initial capacity, until the global custom application response time felt below 15 sec.
The PVC capacities have increased up to the full FR line capacity each (2 Mbps), and I have allocated FR_E1 lines everywhere, including the link between ATH_2 router C and FR network cloud. The following diagram is the comparative global response time, for the custom application. The vertical axis represent the average time.
It is clear that the Radiology_Images application performs now very well, with average response times around 10 sec. The following . 40 displays the CDF curve of the global application response time. As the legend indicates, the probability for time less than or equal to 14.33 seconds is 0.916, or Pr[t≤14.33sec] = 91.6%. Similarly, CDF curves for Database Entry and Query response time gives Pr[t≤17msec] = 90%, Email download response time gives Pr[t≤169msec] = 90% and Web page response time gives Pr[t≤44msec] = 90%.
I conclude that the standard applications perform very well, due to the upgraded PVCs capacities, as shown in . 41. The throughput of the various links remains below maximum limits and the utilization remains low for the majority of them, as well. The . 42 presents the three maximum utilization percentages . The rest are below 10%.
The final part of the present coursework is the calculation of the overall load of the topology. As I have mentioned in the introduction chapter, ATH Diagnostics' corporate network has been separated in two parts, the Intranet and the Extranet, due to Academic Edition's limitations. The mutual part among these two topologies is the link between ATH_1 and ATH_2, which belongs to both topologies. So the answer to the question of the overall load is interpreted as the total throughput of this link or the addition of the throughput in the Intranet scenario (intranet) and the throughput in the Upgraded Expansion scenario (expansion_upg).
I select the View Results (Advanced) from the Results pull-down menu and I choose the button Create a graph of a statistic. From the emerged menu I select, for intranet and expansion_upg scenarios, the incoming and outgoing Throughput (in bps) for the ATH_1 <-> ATH_2 links in ATTIKI.ATHINA subnet. Then I select to show the adder diagram of the four combined graphs. The above . 43 displays the generated plot. As the legend displays, the maximum load is 310.304 kbps (at the 10.2 minute).
The overlaid plot of the average overall load indicates that the system is not yet stabilized and a longer simulation time would be preferable, if possible. If I select the worst case intranet scenario (intranet_wc) instead of the normal and follow the previous procedure, the overall load increases up to 1808.96 kbps. However, in the last scenario, the capacity of this link has been upgraded to E1, which is now 2 Mbps, so it is capable to carry the maximum overall load.
A lot of interesting deductions have emerged during the composition of the present coursework. The ATH Diagnostics' corporate network is expanding rapidly and, as long as new services are appended or the current services are upgraded, the network infrastructure should be subject to constant improvements. It is crucial that every planed network upgrade should be first simulated in a virtual environment like the Opnet IT Guru, and then to be deployed. So the system administrator minimizes the risk of an erroneous planning or even a global network failure. Instead, he is free to test as many alternative scenarios as possible, until the optimum solution appears.
The case of ATH Diagnostics is a kind of straight forward. The consecutive upgrades to the supported services demand equivalent upgrades to link capacities. Unfortunately, the selected infrastructure, the HellasPac offered by OTE, is an old technology and not very flexible. In the studied case of the Expansion scenario, all the PVCs have reach their maximum limits. If a more demanding application is to be deployed a second FR circuit will be required.
During the Expansion scenario it became clear that a demanding application, like the Radiology_Images, necessitated a great capacity upgrade. The cause was the extreme bursts of data flow between the Radiology server and the remote clients. Therefore a newer technology, faster and easier upgradable, like the IP VPN or Ethernet over OTE's MPLS network, would be preferable.
 J.A. Hoxmeier and C. DiCesare, “System response time and user satisfaction: An experimental study of browser-based applications,” in Proc. 2000 AMCIS Conf., pp. 140-145, Long Beach, California, USA.
 D.A. Menascé, “Load Testing, Benchmarking, and Application Performance Management for the Web,” in Proc. 2002 CMG Conf., pp. 271-281, Reno, Nevada, USA.
 Catholic University of Leuven, “ Academic OPNET Research and Educational Projects,” Dec. 2009; http://www.esat.kuleuven.be/telemic/networking/opnet.php
 Building Network Topologies, OPNET IT Guru Academic Edition 9.1.A Resources, 2008.
 Conuring Applications and Profiles, OPNET IT Guru Academic Edition 9.1.A Resources, 2008.
 Frame Relay Model User Guide, OPNET IT Guru Academic Edition 9.1.A Resources, 2008.
 C. Bouras, Public Networks and Network Interconnection, University Notes, University of Patras, Patras, Greece, 2008.