N2K Scalability Study by Simulation Using OPNET

Jun Wang
NCSA, University of Illinois at Urbana-Champaign
wangj@ncsa.uiuc.edu

1. Introduction
Fig. 1 illustrates a roadmap of modeling, simulating and analyzing N2K by using OPNET.
CENTRIXS will be used as the basis for our study. There are four major steps to achieve the
research goal key management scalability study:
Modeling CENTRIXS in OPNET;
Modeling N2K and PKI on top of CENTRIXS model in OPNET;
Analytical model and performance study;
Feedback/refinement to the N2K design.

Fig.1 Roadmap of modeling, simulating and analyzing N2K

2. Building simulation model for CENTRIXS in OPNET

2.1. Modeling individual nodes

1
At this step, we need to model individual routers, switches, hubs, workstations, laptops, links, etc.
Many of these individual components may be found in the OPNET node library. However, some of
them are special devices or are not in the library so that we need to develop them from scratch.

2.2. Modeling traffics: applications, application profiles, and tasks

We need to model different traffic patterns and application profiles based on the real data from
CENTRIXS. Different applications include email with attachments, multimedia conferencing, FTP,
HTTP Web browsing, etc.

2.3.1. FTP
The existing FTP application module in OPNET mimics FTP applications in the Internet. It has the
following major parameters: command mix (Get/Total ratio), inter-request time, file size, and type
of service (TOS). By choosing different values for these parameters, we can model different traffic
load and traffic pattern for FTP applications.

2.3.2. HTTP
The existing HTTP application module in OPNET simulates web-browser based access in the
Internet. It has the following major parameters: HTTP specification (HTTP 1.0 or 1.1), page
interarrival time, page properties (including object size, number of objects, and location etc.
parameters), server selection (including initial repeat probability and pages per server two
parameters), and TOS.

2.3.3. E-mail
This module simulates email access in the Internet. It includes the following major parameters:
send interarrival time, send group size, receive interarrival time, receive group size, email size,
TOS, etc. By configuring the email size parameter, we can mimic email accesses with attachments.

2.3.4. Streaming video

There is no existing application module for streaming video. One solution is to use the custom
application client/server modules in OPNET. The procedure is a little complicated and tricky.
Please refer to Section 2.3.9. for more detailed information.

2.3.5. Database access

It simulates database accesses in the Internet and has the following attributes: Transaction Mix
(Queries/total transactions), Transaction Interarrival Time, Transaction Size, TOS, etc.

2.3.6. Remote-login
This module can be used to model telnet, SSH, or some other types of remote login access in the
Internet. It has the following major attributes: Inter-Command Time, Terminal Traffic, Host Traffic,
TOS, etc.

2.3.7. Video conferencing

The existing video conferencing application module in OPNET only supports two-point
communication, i.e. only a pair of nodes can take part in one video conferencing session. The

2
session is two-way, i.e. each node sends its video stream to its peer and receives the video stream
from its peer at the same time.

2.3.8. Voice over IP

The Voice application module in OPNET can be used to model the voice-over-IP application
traffic in the Internet. The basic tunable parameters include: Silence Length, Talk Spurt Length,
Encoding Scheme, Voice Frames per Packet, ToS, Traffic Mix, etc.

2.3.9. Other applications: using custom application client/server module

2.3.9. A general procedure to model application traffics

First, add a node using the Application Config module. Then, under the Application
Definitions attribute, add each application we want as a row, including detailed parameter
configurations. Next, add a node using the Profile Config module. Under its Profile
Configuration attribute, add a profile (or multiple profiles) for each defined application. Finally, at
each specific application node (such as a FTP client), configure its related application parameters or
attributes. This step heavily depends on types of applications.

Note that if a custom application client/server is used, a task node (using the Task Config
module) must be used to define a specific task, before the task can be used for defining the
application and then the related profiles.

Also note that at the step of defining applications and profiles, only virtual node names are used.
These virtual node names (e.g. a virtual name for an FTP server) will be resolved at configuring
specific application client nodes (e.g. an FTP client node) under its Destination Preferences
attributes which create mappings between virtual names and actual names. Meanwhile, at an actual
server node that supports the associated application (e.g. the FTP server node), its Server Address
should be configured as its actual name. This actual name should match the actual name used at the
corresponding client node under the Destination Preferences attribute. The use of virtual names
provides a layer of abstraction, so that one profile can be used by multiple specific application
sessions.

2.3.10. Some special and useful modules

10Base_T_LAN or 100Base_T_LAN: It can be used for the scenario where a large number
of nodes (clients and/or servers) exist in a subnet (Ethernet).
INET_Cloud: It is very useful for modeling IP clouds. Some parameters, such as packet loss
rate, delay, etc., can be configured.
Firewall modules (e.g. ethernet2_slip8_firewall_adv): very useful in a scenario where
firewall is used for protection. The access control can be enforced by configuring its Proxy
Server Information attribute.

2.3. Building subnets

Based on the individual components we have built in the previous part, we build different subnets
of CENTRIXS in OPNET. Currently three major types of subnets are used in CENTRIXS. We
have built a preliminary model for the Type-1 subnet, which is most complex one among the three.

3
2.4. Building CENTRIXS
At this step, we need to integrate the individual components, subnets, traffic patterns, and
application profiles together to form the model for the entire CENTRIXS.

3. Current status
We have been working on the CENTRIXS simulation model for a couple of months. We have
managed to find/build most of the individual components in CENTRIXS. We have built a testbed
system in OPNET which consists of two Type-2 subnets. Different application profiles and traffic
patterns have also been developed. Based on the testbed, we have conducted several simulations
and some preliminary simulation results have been obtained to test the model. However, we also
encountered some problems during this process. For example, some detailed information needed
for modeling is still missing, and how to model some special devices, such as some IP encryption
devices or some special links, is not clear.

The five major achievements we have made so far are:

We have figured out how to model application traffics: using application configuration,
profile, task, etc. And we have built application traffics for: remote login, web-browsing,
videoconferencing, FTP, E-mail, database access, voice over IP.
We have found most of the node models that match or almost match the nodes (routers,
hubs, switches, etc.) used in CENTRIXS. Some modifications may have to be made later.
We have built a testing subnet (Type-1 subnet) consisting of both associated nodes and
traffics in CENTRIXS.
We are getting data: we have obtained some preliminary simulation results to verify the
subnet, including both the node models and the traffic profiles we have built.
We have built a simplified CENTRIXS that consists of two Type-1 subnets. Preliminary
simulation results are obtained to verify the modeling.

4. Problems
1) How to model the Internet cloud? Two possible ways:
a) Using multiple BGP routers to build an Internet cloud;
b) Using an existing IP cloud module: can set up the drop rate, etc, for example.

2) I don't have all the information. For example, link capacities among subnets (or domains).

3) OPNET uses a huge amount of memory if the simulated size goes up. Can cause thrashing
(actually has been observed).

5. Demonstration scenarios

5.1. Testing building blocks (nodes and traffic patterns)

4
We ran a simulation for 2000 seconds (simulated time) and it took 17m20s actual time (1040s),
which gives a simulated/actual ratio about 1.9.

5.2. Testing a Type-1 subnet

5
The following table summarizes how different applications are configured.

Obj (B)/
Application Int-arrvl (s) Term.(B/c) / Get/Total # Obj/ Frame (file) Size / Group size
Host (B/c) Page per Srv Rate (B/s)
Custom 0.375 / 900 160 5000 (S) /1024 (C)
Remote-login N(30,5) Exp(60) / --- --- --- ---
N(25,25)
HTTP Exp(60) --- --- 1 / 5 / Exp(10) --- ---
128x240pix (34560
Videoconf. 15 frame/s --- --- --- bytes) / 518,400 ---
B/s

6
 FTP Exp(120) --- 50% --- N(1E4,1E6) B ---
Email Exp(360) --- --- --- --- 3
Database Exp(12) --- --- --- 512 B ---
VoIP 1 frame / pkt --- --- --- --- G.729

We ran a simulation for 10000 seconds (simulated time) and it took 1h51m25s actual time (6685s),
which gives a simulated/actual ratio about 1.5. The simulation results are shown in the following
figure partially.

7
8
5.3. Testing a network with two Type-1 subnets

In this scenario, we build a network consisting of two Type-1 subnets. The following figure depicts
the setup of the two subnets connected by an Internet cloud. Note that node actual address in
OPNET has to be unique, otherwise, a compilation error will occur. For example, in the HQ
subnet, the FTP server has an actual name (TPAL address) FTP Server. Then, the FTP server in
the JTF subnet cannot use FTP Server as its actual name. I changed it to FTP Server JTF.
Likewise, I had to change the actual name for every server in the JTF subnet and change the
Destination Preferences under each client accordingly.

We ran a simulation for 2000 seconds (simulated time) and it took 41m43s actual time (2503s),
which gives a simulated/actual ratio about 0.8.

Next step: add cross-subnet traffic.