Ne SSi 2 Manual

FT
RA
Manual
Version 2.1.2
June 21, 2013

D
Editors:
Karsten Bsufka
Contributors: Rainer Bye

Jol Chinnow
Dennis Grunewald
Katja Luther
Arik Messerman
Stephan Schmidt
Leily Behnam Sani
Thomas Hauschild
Sebastian Linkiewicz
Thorsten Rimkus
Bianca Scheibel
Jakob Strafer
Technische Universitt Berlin

Institut fr Wirtschaftsinformatik und Quantitative Methoden
Fachgebiet Agententechnologien in betrieblichen Anwendungen und der Telekommunikation /
DAI-Labor
Sekretariat TEL 14
Ernst-Reuter-Platz 7
10587 Berlin
Telefon: +49 (0)30 314 74000
Telefax: +49 (0)30 314 74003
E-mail: info@nessi2.de
URL: http://www.dai-labor.de
Contents
1. Introduction 1
1.1. Related Work on Network and Security Simulation . . . . . . . . . . . 1
1.2. The Features of NeSSi2 . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1. Traffic Generation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.2. Protocol Stack and Socket-based API . . . . . . . . . . . . . . 4
1.2.3. Security Features . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Structure of the Manual . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Overview 7
2.1. Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Simulation Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Installation 11
3.1. NeSSi2
Simulation Environment . . . . . . . . . . . . . . . . . . . . . 11
3.1.1. Download and Installation . . . . . . . . . . . . . . . . . . . . 11
3.1.2. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.3. Launching the NeSSi2 Simulation Environment . . . . . . . . . 12
3.1.4. Troubleshooting . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2. NeSSi2 User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.3. Launching the NeSSi2 User Interface . . . . . . . . . . . . . . . 13
3.3. NeSSi2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.2. Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4. NeSSi2 Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Graphical User Interface 15

4.1. Simulation Components . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.1. Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2. Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3. Layouts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.4. Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.5. Profiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.7. Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
iii
4.1.8. Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1.9. Recorder Configurations . . . . . . . . . . . . . . . . . . . . . 17
4.2. GUI Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.1. NeSSi2 Explorer . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.2. Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.3. Routing Table . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.4. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.5. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2.6. Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.7. Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.8. Network Editor . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.9. Profile Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.10. Scenario Editor . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.11. Simulation Editor . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.12. Recorded Simulations . . . . . . . . . . . . . . . . . . . . . . 22
4.2.13. Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.14. Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5. NeSSi2 Repository 27
5.1. Background Information . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.2. Configuration and Preferences . . . . . . . . . . . . . . . . . . . . . . 28
5.2.1. Getting Started . . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.2.2. Default Repository Location . . . . . . . . . . . . . . . . . . . 29
5.2.3. Adding Repository Locations . . . . . . . . . . . . . . . . . . 29
5.2.4. Deleting Repository Locations . . . . . . . . . . . . . . . . . . 30
5.2.5. Modifying Repository Locations . . . . . . . . . . . . . . . . . 30
5.2.6. Download Options for the backend . . . . . . . . . . . . . . . 31
5.2.7. Manual Configuration . . . . . . . . . . . . . . . . . . . . . . 31
5.3. Uploading Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.4. Downloading Artifacts . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.4.1. Downloading Artifacts in the Frontend . . . . . . . . . . . . . 35
5.4.2. Downloading Artifacts in the Backend . . . . . . . . . . . . . . 37
5.5. Artifact Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6. Federated Simulation 41
6.1. Project with multiple Networks . . . . . . . . . . . . . . . . . . . . . . 41
6.2. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
7. Termination Conditions 45
7.1. Simulation Termination Condition . . . . . . . . . . . . . . . . . . . . 46
7.2. Replication Termination Condition . . . . . . . . . . . . . . . . . . . . 47
8. How to Create a Simulation: A Step by Step Tutorial 49

8.1. Create NeSSi2 Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
8.2. Create Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
8.3. Create Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.4. Create Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8.5. Create Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
8.6. Run Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
8.7. Evaluating Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . 58
8.7.1. Preparing Analyses with Third Party Tools . . . . . . . . . . . 58
9. Extending NeSSi2 : Application Tutorial 61

9.1. Setting up your Development Environment . . . . . . . . . . . . . . . . 62
9.1.1. Setting up the Target Platform . . . . . . . . . . . . . . . . . . 62
9.1.2. Creating a NeSSi2 Plug-in Project . . . . . . . . . . . . . . . . 62
9.2. Creating a NeSSi2 Application . . . . . . . . . . . . . . . . . . . . . . 65
9.2.1. First Steps of Creating an Application . . . . . . . . . . . . . . 65
9.2.2. Echo Applications . . . . . . . . . . . . . . . . . . . . . . . . 68
9.2.3. Event Recording . . . . . . . . . . . . . . . . . . . . . . . . . 72
9.2.4. Deployment of Applications . . . . . . . . . . . . . . . . . . . 74
A. Recommended Readings 75
A.1. Simulation Modeling and Analysis . . . . . . . . . . . . . . . . . . . . 75
B. Workflows 77
B.1. Create and Start a Simulation . . . . . . . . . . . . . . . . . . . . . . . 77
B.2. Create a NeSSi2 Project . . . . . . . . . . . . . . . . . . . . . . . . . . 77
B.3. Open NeSSi2 Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . 77
B.4. Create a Simple Network . . . . . . . . . . . . . . . . . . . . . . . . . 78
B.5. Create a Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
B.6. Create a Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
B.7. Create a Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
B.8. Run a Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
C. Entity Relationship Diagram for NeSSi2 databases 81
D. Installation of MySQL Server 83
E. Importing sample data into a MySQL database 87
F. Glossary 89
Index 92
Bibliography 94
List of Figures
1.1. Graphical User Interface of NeSSi2 . . . . . . . . . . . . . . . . . . . . 2

1.2. Core Architecture of NeSSi2 . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. NeSSi2 User Interface (Network Editing) . . . . . . . . . . . . . . . . . 7

2.2. Running Backend of NeSSi2 . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. NeSSi2 Project Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2. Some of the GUI Elements in the Network Editing Perspective . . . . . 18
4.3. The Routing Table View for a Network Node . . . . . . . . . . . . . . 19
4.4. The Properties View for a Network Edge . . . . . . . . . . . . . . . . . 19
4.5. The Problems View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.6. The Progress View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.7. The Statistics View . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.8. The Profile Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.9. The Scenario Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.10. The Simulation Editor . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.11. The Recorded Simulations view . . . . . . . . . . . . . . . . . . . . . 22
4.12. Graphical Depiction of Traffic in the Simulation Perspective . . . . . . 24
4.13. Example Settings for a MySQL Database . . . . . . . . . . . . . . . . 25
4.14. A Sample Recorder Configuration . . . . . . . . . . . . . . . . . . . . 26
5.1. The Dependency Hierarchy of NeSSi2 Components . . . . . . . . . . . 27

5.2. The Repository Preference Page . . . . . . . . . . . . . . . . . . . . . 28
5.3. Entering Information for a New Repository Location . . . . . . . . . . 30
5.4. Options for Dependency Resolution in the Backend . . . . . . . . . . . 31
5.5. Example Authentication Information in the Settings.xml . . . . . . . . 32
5.6. A List of the Artifacts for Uploading . . . . . . . . . . . . . . . . . . . 33
5.7. Entering Artifact Information for an Example File. . . . . . . . . . . . 34
5.8. Uploading an Artifact into a Repository. . . . . . . . . . . . . . . . . . 35
5.9. The Download Wizard . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.10. Browsing through a Repository . . . . . . . . . . . . . . . . . . . . . . 37
5.11. Viewing all Database Entries . . . . . . . . . . . . . . . . . . . . . . . 38
5.12. Viewing the Properties of a NeSSi2 Component. . . . . . . . . . . . . . 38
6.1. Available New Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . 41

6.2. Creating a New Network File . . . . . . . . . . . . . . . . . . . . . . . 41
6.3. Entering a Name and a Parent Folder for a Network File . . . . . . . . 42
6.4. The Network Configuration Page . . . . . . . . . . . . . . . . . . . . . 42
6.5. Configuration of the Network Mapping . . . . . . . . . . . . . . . . . 43
vii
7.1. The Simulation Configuration Page . . . . . . . . . . . . . . . . . . . . 45
7.2. Implementation of a Simulation Termination Condition . . . . . . . . . 46
7.3. Implementation of a Replication Termination Condition . . . . . . . . . 47
8.1. Overall NeSSi2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.2. The NeSSi2 Project Creation wizard. . . . . . . . . . . . . . . . . . . . 50
8.3. Adding Subnets to a Network . . . . . . . . . . . . . . . . . . . . . . . 50
8.4. A Simple Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5. A List of the Available Applications by Categories . . . . . . . . . . . 52
8.6. Existing Applications in a Profile . . . . . . . . . . . . . . . . . . . . . 52
8.7. The Scenario Creation Wizard . . . . . . . . . . . . . . . . . . . . . . 53
8.8. Manually Adding Profiles to Network Nodes . . . . . . . . . . . . . . 54
8.9. Adding Profiles to Network Nodes . . . . . . . . . . . . . . . . . . . . 54
8.10. The Simulation Configuration Tab in the Simulation Editor. . . . . . . . 55
8.11. The Network Configuration Tab in the Simulation Editor. . . . . . . . . 56
8.12. Viewing the Simulation Results . . . . . . . . . . . . . . . . . . . . . . 57
9.1. Setting the Target Platform Definition . . . . . . . . . . . . . . . . . . 62

9.2. Adding Dependencies to an Application Development Project . . . . . 63
9.3. Example pom.xml for a NeSSi2 Plug-in Project . . . . . . . . . . . . . 64
9.4. Basic NeSSi2 Application for the IP-Model . . . . . . . . . . . . . . . 65
9.5. Example of the Enum-Annotation . . . . . . . . . . . . . . . . . . . . 66
9.6. Applications in the NeSSi2 User Interface . . . . . . . . . . . . . . . . 67
9.7. Skeleton for the Echo Client Application . . . . . . . . . . . . . . . . . 68
9.8. The start Method of the Echo Client Application . . . . . . . . . . . 69
9.9. The handleEvent Method of the Echo Client Application . . . . . . 70
9.10. Skeleton for the Echo Server Application . . . . . . . . . . . . . . . . 71
9.11. The start Method of the Echo Server Application . . . . . . . . . . . 71
9.12. The handleIncomingPacket Method of the Echo Server Application 72
9.13. The sendEcho Method of the Echo Server Application . . . . . . . . 72
9.14. Constants for the Event Recording . . . . . . . . . . . . . . . . . . . . 73
9.15. Recorder Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 74
B.1. Overall Workflow in NeSSi2 . . . . . . . . . . . . . . . . . . . . . . . 77

B.2. The Workflow of Creating a NeSSi2 Project . . . . . . . . . . . . . . . 77
B.3. The Workflow of Opening the NeSSi2 Explorer . . . . . . . . . . . . . 78
B.4. The Workflow of Creating a Network . . . . . . . . . . . . . . . . . . 78
B.5. The Workflow of Creating a Profile . . . . . . . . . . . . . . . . . . . . 79
B.6. The Workflow of Creating a Scenario . . . . . . . . . . . . . . . . . . 79
B.7. The Workflow of Creating a Simulation . . . . . . . . . . . . . . . . . 80
B.8. The Workflow of Running A Simulation . . . . . . . . . . . . . . . . . 80
C.1. Entity Relationship Diagram for NeSSi2 Databases. . . . . . . . . . . . 81
D.1. Choose Typical Installation . . . . . . . . . . . . . . . . . . . . . . . . 83

D.2. Configure the MySQL Server . . . . . . . . . . . . . . . . . . . . . . . 84
D.3. Choose Standard Configuration . . . . . . . . . . . . . . . . . . . . . . 84
D.4. Install as Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
D.5. Password for Root Account . . . . . . . . . . . . . . . . . . . . . . . . 85
E.1. Command Prompt Before DragnDrop . . . . . . . . . . . . . . . . . 87

E.2. Command Prompt After DragnDrop . . . . . . . . . . . . . . . . . . 87
E.3. Setting the Schema Name . . . . . . . . . . . . . . . . . . . . . . . . . 88
ix
1. Introduction
In contemporary communication infrastructures, IP-based computer networks play a
prominent role. The deployment of these networks is progressing at an exponential rate
as different kinds of participants such as corporations, public authorities and individuals
rely on sophisticated and complex services and communication systems. With regard to
information security, this leads to new challenges as large amounts of data, which may
hold malicious content such as worms, viruses, or trojans, are transferred over open
networks. Network security measures dealing with these threats can be implemented
in the network itself as well as at hosts connected to access routers of the network.
The host-based approach has its merits, especially with respect to the scalability of a
resulting security framework; for example, placing security capabilities such as firewalls
or virus scanners on individual hosts does not inhibit the traffic traveling through the
network. However, as the hosts are generally not under the control of network operators,
there is no way of ensuring a certain network-wide security policy.
A consequence for network service providers (NSPs) striving to offer improved security
features to their customers as a value-adding feature is to devise a security framework
in which detection devices are placed within the network. Before doing so, the NSP
must take into account that it is not desirable to make frequent changes or experiment
with various security feature deployments in the network infrastructure of a production
system. For this reason, network operators can greatly profit from a network simula-
tion tool in which various features of the security architectures can be tested in order
to ensure maximum attack detection efficiency before the actual physical deployment.
The advantage over conventional testbeds is the low cost and ease at which tests can
be carried out. The presented Network Security Simulator NeSSi2 (see Figure 1.1) al-
lows NSPs to experiment with different network-centric security framework setups and
algorithms in order to evaluate and compare intrusion detection efficiency and opera-
tional costs. In this fashion, a devised security framework can be tested in a simulation
environment before the actual detection units are physically deployed in the network.
1.1. Related Work on Network and Security Simulation

In recent years, the research community has used various network simulation tools for
the verification of new algorithms, the investigation of design and interaction behav-
ior of newly developed protocols as well as the examination of performance issues
encountered in large-scale network architectures. The most popular general-purpose
software tool in the research community is the open-source network simulator ns2
[USC Information Sciences Institute, ]. ns2 performs network simulation using a dis-
crete event model. This approach has several advantages regarding application perfor-
1
1. Introduction
Figure 1.1.: Graphical user interface of NeSSi2 - Main Network Editor window
mance and scalability. These issues are discussed for example in [Nicol et al., 2005] and
[Liu et al., 2001]. Discrete simulation allows very cost-efficient exploration and exper-
imentation with real-life network topologies and architectures. In many areas involving
network analysis, ns2 is a powerful tool; however, it also poses certain limitations to the
user. Concerning the aspect of simulation efficiency for large networks, ns2 does not
support out-of-the-box a parallel execution model. It does not support generic sockets,
but protocols have to be rewritten for the usage in ns2. Moreover, the script language
interface is not intuitive to use for novice users. Alternatives to ns2 are for example the
QualNET simulator [Scalable Network Technologies Inc., ] or the Georgia Tech Net-
work Simulator GTNetS [Riley, 2003], which, in contrast to ns2, also offers parallel
execution support for large-scale simulation.
Most important of all, these simulators have limitations in standard support of real-
world network security evaluation. A lot of work has been done in the limited area of
worm simulation, as described extensively by Wei et al. [Wei et al., 2005]. In this work,
the authors note that existing simulators are mostly single-machine tools and hence do
not scale to model realistic attack mechanisms in large-scale real-world networks. They
propose a distributed approach termed PAWS, which is nevertheless not a comprehen-
sive tool but limited to worm simulation only. Another security evaluation tool is RINSE,
which is described by Liljenstam et al. in [Liljenstam et al., 2006]. It focuses on sup-
porting real-time large-scale simulations and allows for realistic emulation of CPU and
memory effects within the simulation. However, there is no mention of application-level
simulation capabilities in RINSE. The same drawback exists in the solution presented
in [Yun et al., 2005], although it allows model-driven attack tree-based simulation in a
2
1.2. The Features of NeSSi2
reusable object-oriented software architecture.

NeSSi2 aims to fill the gap by offering simulation and evaluation features specifically
tailored to meet the needs of security experts and network administrators. This target
group will be able to test and evaluate the performance of commonly available security
solutions as well as new research approaches. As a distinguishing feature to the previous
tools described above, NeSSi2 provides extensive support of complex application-level
scenarios on top of a faithful simulation of the TCP/IP protocol stack. Simulated net-
works are modeled to reflect real-world network topologies by supporting subnet-layer
modeling and different node types with varying capabilities (Core and Access subnets,
wireless networks etc.). In particular, NeSSi2 adheres to a modular design pattern and
fosters the integration of third-party applications via a standardized plugin interface.
Furthermore, it provides a comprehensive Detection API for the integration and evalua-
tion of simulated as well as external detection units. In particular, special common attack
scenarios are supported and can be simulated, worm-spread scenarios and botnet-based
DDoS attacks are only two of the example scenarios supported by NeSSi2 . In addition,
customized profiles expressing the node behavior can be applied within the simulation.
The application layer simulation capabilities in NeSSi2 are provided by distributed soft-
ware agents, introducing another layer of abstraction. In order to maintain scalability,
a parallel execution model is used in conjunction with a discrete event model. In this
context, the agent platforms are running on multiple parallel machines and connect in-
dependently to a database server from which simulation results can be retrieved in an
asynchronous and concurrent fashion. The graphical user interface allows for real-time
inspection and configuration of scenarios.

NeSSi2 is designed to extend conventional network simulation tool features by sup-
porting detailed examination and testing opportunities of security-related network al-
gorithms, detection units and frameworks. The main focus of NeSSi2 is to provide a
realistic packet-level simulation environment as a testbed for the development of new
detection units as well as existing ones. We use detection unit as an abstract term for
any algorithm or tool employed for the purpose of detecting malicious activity such as
intrusion or service degradation attempts.
NeSSi2 has been designed as a modular application with the focus on extensibility. In
particular, NeSSi2 provides out-of-the-box support for various protocols of the TCP/IP
stack; a selection of these is described in Section 1.2.2. These features provide the basis
for designing, incorporating and simulating detection units.
1.2.1. Traffic Generation
Network traffic in the form of IP packets, complete with header and body, can be gen-
erated by different means. Implementing the TCP/IP protocol stack, NeSSi2 features
an application layer module which is based on standard Java socket implementations.
3
1. Introduction
NeSSi2 incorporates several application level protocols (HTTP, SMTP, etc.) and sup-
ports static and dynamic routing protocols which can be selected by the user. At the
moment, static and dynamic protocols are implemented. A static routing protocol cen-
trally computes the shortest paths as the network is loaded and each time the topology
changes. The resulting routing tables are subsequently loaded onto the individual net-
work nodes. On the other hand, IS-IS (Intermediate-System-to-Intermediate-System)
has been implemented as a link-state protocol, which relies on a decentralized algorithm
during which routers exchange information about their link states and gather topology
information locally. In an iterative fashion, the routing tables at the individual nodes
are updated through control message exchange. NeSSi2 can also easily be extended to
support a variety of other applications (see Section 1.2.2).
For this purpose, it is necessary to implement, besides the application, the previously
described action with the required parameter. In case of a DDoS application, this would
be source and destination port, the attacked IP address as well as the packet frequency.
Through this, own enhancements can be easily configured, deployed in a network and
simulated with NeSSi2 .
1.2.2. Protocol Stack and Socket-based API
The TCP/IP reference model is the de-facto standard for Internet communication. Due
to its importance, NeSSi2 also offers an implementation for it. The routers as well as
the end devices in the simulation contain a Network Layer; end devices also exclusively
have a Transport and an Application Layer. At the Network Layer, IPv4 is realized
with the key features global addressing, routing and fragmentation support. Moreover,
TCP/IP model implementation allows containing several protocols in each layer; hence,
we also provide IPv6 support in NeSSi2 . For the fault management, TTL (Time to live)
and header checksums supported and the ICMP protocol has been implemented for
failure notification. Network Layer communication is realized directly on the drop-tail
queues that are located at the network interfaces.
On the next level, the Transport Layer is comprised of UDP and TCP. TCP in NeSSi2
offers a reliable and in-order delivery of data. Sockets represent the interface to the
Application Layer, i.e., applications can set up several stream sockets as well as the
corresponding server sockets. In this fashion, third-party Java libraries can easily be
integrated in the simulation by substituting Java sockets with NeSSi2 sockets. As a
proof-of-concept, the JavaMail API 1 has been successfully adapted in NeSSi2 . All
applications that are run in NeSSi2 follow a common interface that abstracts from their
specific behavior but allows a standardized way of executing them. Currently, the HTTP,
SMTP and IRC protocols are integrated in NeSSi.
Generated traffic in NeSSi2 can also be exported to files in the pcap2 format in order to
inspect the data with standard traffic inspection tools such as wireshark3 . Several tests
have been conducted with the traffic exported from NeSSi2 , verifying that the generated
1 http://java.sun.com/products/javamail
2 http://www.tcpdump.org
3 http://www.wireshark.org
4
traffic is well-formed. Wireshark is able to reconstruct the application data stream with-
out errors if all corresponding IP packets are in the exported file. The generated traffic
can be analyzed either offline, for example with the aforementioned tools, or online
within the application itself, for example by displaying a graphical summary (cf. Figure
1.1).
1.2.3. Security Features

In the previous sections, we described the basic network model and traffic generation
features of NeSSi2 as well as other aspects regarding general network simulation. The
distinguishing feature of NeSSi2 is the focus on network security framework and al-
gorithm evaluation. Figure 1.2 provides a conceptual view on NeSSi2 the Network
Security Simulator. The bottom layer shows some of the important technologies that
NeSSi2 uses. This includes the JIAC agent framework used for representation of the
different entities in the simulation, EMF for the network data model and Eclipse RCP as
the platform-independent, plugin-based execution environment. On top of the bottom
layer, several concepts realized in NeSSi2 can be found. These are the aforementioned
general network simulation components like traffic modeling via node profiles, a paral-
lel execution model, discrete event simulation and the visualization.
Figure 1.2.: NeSSi is comprised of several components presented in the middle layer. The bottom
layer depicts the main technologies NeSSi2 relies upon.
In this section, we presume that a network topology and background traffic has been
created, as described in the previous sections. We will now highlight the security simu-
lation capabilities of NeSSi2 that can be added to this basic setup in a four-step process.
The simulation setup in NeSSi2 is not only comprised of network creation and attach-
ment of traffic profiles, but additionally security related settings can be configured.
When a security framework composed of several detection units is to be tested, pro-
files can also be used in NeSSi2 to simulate attacker behavior and attack patterns. Ac-
cordingly, NeSSi2 provides out-of-the box support for various attack scenarios such as
bot networks initiating DDoS attacks. Here, infected end device nodes, zombies, are
controlled by the bot net commander via the Internet Relay Chat application. The com-
mander is capable of initiating different kinds of DDoS attacks like the SYN Flooding
or UDP Storm. To this end, the attacker connects to an IRC communication server and
sends attack commands to a chat channel all the bots are listening to. As a result, the
bots execute the desired attack.
5
1. Introduction
Besides, worm propagation schemes are supported. Here, the behavior of the SQL
Slammer worm and the Blaster worm have been realized exemplarily in NeSSi2 . In
general, a worm propagation scheme as well as the SIR model (Susceptible Infected
Recovered) as an epidemiological model is included in NeSSi2 . The worm propagations
scheme can be configured in different ways: on the one hand there exist configuration
files defining the number of initial propagators and where in the network the outbreak
should take place. Additionally, the spreading scheme, i.e. which IP addresses to attack
and delays in between, can be set.
On the other hand, the worm application model itself can either be extended or a new one
can seamlessly be integrated via the application interface provided in NeSSi2 (cf. 1.2.2).
In the second step, newly developed or pre-configured detection units can be deployed
on a set of links in the simulation. Therefore, analogous to the traffic profiles, detection
profiles can be created. Those detection profiles consist of one or more detection units
and can be deployed on end devices, links or routers.
1.3. Structure of the Manual

Section 2 of the manual will provide you with a high-level overview of NeSSi2 and its
features. Section 3 will explain in detail how to install and configure the essential mod-
ules of NeSSi2 . The NeSSi2 User Interface is explained in chapter 4, starting with an
the simulation components of NeSSi2 , followed by an introduction to the different GUI
elements. Chapter 5 explains the NeSSi2 simulation repository and how the configura-
tions for accessing the repository can be made. How to step up federated simulations
is described in chapter 6. Chapter 7 explains how different termination conditions for
simulation execution can be configured. Chapter 8 contains a step by step tutorial on
creating and executing simulations using the NeSSi2 User Interface and NeSSi2 Back-
end.
Chapter 9 of this manual the extensibility features of NeSSi2 will be introduced. This
part addresses users who want to contribute their own applications into NeSSi2 .
The remainder of the manual contains appendices, which presents recommended read-
ings (appendix A) for creating simulation studies in the area of network security and
also provides detailed in instruction on how to use MySQL as a database for NeSSi2 .
Additionally general workflows in NeSSi2 are summarized.
6
2. Overview
The design of a packet-level discrete-event simulator is a challenging task. In order
to handle the inherent complexity, NeSSi2 has been structured into three distinct com-
ponents, the Graphical User Interface, the simulation backend and the result database.
Each of these modules may be run on separate machines depending on the computa-
tional requirements; furthermore, this modular design facilitates network security re-
searchers using NeSSi2 to easily exchange network topologies, scenario definitions and
simulation results via remote repositories. In the following sections, we will describe
each of these modules in turn and delineate the workflow in NeSSi2 , beginning with the
creation of a network from scratch up to the analysis of the simulation results.
2.1. Graphical User Interface

The graphical user interface (GUI) of NeSSi2 has two use cases: On the one hand, results
of running or terminated ed simulations can be visualized in here. On the other hand,
it is the component that allows the creation and modification of network topologies and
scenarios (which describes the behavior).
Figure 2.1.: NeSSi2 User Interface (Network Editing)
The core modules of the user interface are built on Eclipse, especially the resource
modules for files and folders. This allows the user to cluster all projects in a workspace.
The basic concept of a NeSSi2 project is that in consists of a single network-file which
contains the static topology information and multiple scenario files which contain the
dynamic information for the behavior of nodes during a simulation. The components of
7
2. Overview
NeSSi2 will be described in detail in Chapter 4. Figure 2.1 shows the network editing
features of NeSSi2 .
2.2. Simulation Backend
The actual simulation is performed on a machine with hardware dedicated solely to this
purpose, the simulation backend. At the Berlin Institute of Technology for example, the
NeSSi2 simulation backend runs on a Sun XFire 4600 blade server (8 blades, 8 cores
per blade). Once a simulation is submitted for execution, the simulation backend parses
the desired simulation parameters (which event types to log, how many runs to execute
etc.), creates a corresponding simulation environment, sets up the database connection
and schedules the simulation to run as soon as the necessary processing resources are
available. The running backend of NeSSi2 can be seen in Figure 2.2
Figure 2.2.: Running Backend of NeSSi2
NeSSi2 is built upon the JIAC framework [Fricke et al., 2001]. JIAC is a service-centric
java-based middleware architecture based on the agent paradigm. Within NeSSi, agents
are used for modeling and implementing the network entities such as routers, clients,
and servers. The underlying JIAC agent framework provides a rich and flexible ba-
sis for implementing and testing of various security deployments and algorithms in
NeSSi2 . Moreover, building upon an agent framework allows combining the partial
knowledge of the agents residing in the network in a cooperative approach for identi-
fying and eventually eliminating IP-based threats. For example, this may be achieved
by monitoring the structure of the encountered IP traffic and the behavior of potentially
compromised target systems. For an illustrative example where we successfully utilized
the agents cooperative features, refer to Section 1.2.3. Although the software agents
provide powerful application-level capabilities, their complexity unfortunately also af-
fects the scalability of the simulation. NeSSi2 mitigates this problem by building upon
a parallel-execution model.
8
2.3. Database
2.3. Database
In NeSSi2 , we refer to a scenario where we generate traffic via pre-defined profiles (cf.
Section 4.1.6) on a single network over a certain amount of time as a simulation. The
accurate reproduction of a simulation enables users to use different detection methods
or various deployments of detection units for the same traffic data set. This allows
the comparison of performance and detection efficiency of different security framework
setups.
For these purposes, we use a distributed database in which the traffic generated during
a simulation is stored. For each simulation, the agents log the traffic and detection data
and send it to the database that occurs in a simulated scenario between a start and end
time. The data types to be logged are specified by the user in the simulation parameters.
The network model is saved in an XML file. This network file is stored and annotated
with a version number based on its hash code in order to link a network uniquely to a
simulation. Additionally, attack related events can be stored in the database for evalua-
tion purposes. Those events are explained in greater detail in Section 8.7.
Due to the modular design of the database component, the actual implementation of the
database is up to the user. This can be comfortably managed via the graphical user inter-
face, where the location of the database, database user name, password and the database
driver can be specified. NeSSi2 has been tested extensively with a MySQL database
server, but depending on the users preferences, this can easily be substituted by another
module (for example PostgreSQL). The event types to log are specified independent of
the underlying implementation via XML-based log4j logger repository settings where
multiple appenders can be configured. For example, for simple scenarios the user can
simply write the results to a text file if he so desires.
9
3. Installation
The following chapter describes in detail how to install the NeSSi2 User Interface, the
NeSSi2 Simulation Environment and additional required software.
General requirements for installing NeSSi2 are:
Java Runtime Environment Version 1.7 or newer
MySQL Database Management System1
The NeSSi2 User Interface and the NeSSi2 Simulation Environment have been tested
with Windows, Linux2 (Ubuntu 8.10-11.10 / 32 and 64 bit) and Mac OS X 10.5.x .
3.1. NeSSi2 Simulation Environment
The backend is the component of NeSSi2 that in fact executes the simulations. It gener-
ally does not need to reside on the same host as the frontend.
3.1.1. Download and Installation
To install the NeSSi2 Simulation Environment you have to:

1. Download the latest NeSSi2 Simulation Environment version from http://
www.nessi2.de
2. Create a folder for the NeSSi2 Simulation Environment. We refer to this folder
later as NESSI2_SE_HOME.
3. Extract the ZIP file into the created folder.
3.1.2. Configuration
There are three kinds of files that can be used to configure the NeSSi2 Simulation Envi-
ronment.
First, the JIAC TNG node and agent files3 can be modified to customize the agent be-
havior and capabilities of the NeSSi2 Simulation Environment. These files are located
in the folder NESSI2_SE_HOME/agents.
1 http://www.mysql.com
2 Intel processors and GTK libraries
3 See http://www.jiac.de for more information on JIAC TNG and agent configuration.
11
3. Installation
Second, the log level and other log configurations4 can be changed by modifying the
file: NESSI2_SE_HOME/log4j.properties.
Third, additional NeSSi2 Plug-Ins can be placed in the folder:
NESSI2_SE_HOME/applications.
Usually, the only configuration that is required is installing additional NeSSi2 Plug-Ins.
All other configurations can be left at default.
3.1.3. Launching the NeSSi2 Simulation Environment
The NeSSi2 Simulation Environment is started by executing the nessi2 script (.bat
on Windows-based systems and the .sh on unix-based systems) which is located in the
NESSI2_SE_HOME folder.
3.1.4. Troubleshooting
For simulation of large networks it can be necessary to adapt the memory parameters in
the start script to the following settings:
-Xms512M
-Xmx1G
3.2. NeSSi2 User Interface

The NeSSi2 User Interface is needed to create network topologies, profiles, scenarios
and simulations and to manage and monitor running simulations.
To install the NeSSi2 User Interface, you have to:

1. Download the latest NeSSi2 User Interface version for your operating system from
http://www.nessi2.de
2. Create a folder for the NeSSi2 User Interface. We refer to this folder later as
NESSI2_UI_HOME.
3. Extract the ZIP file into the created folder.
In general, there is no need to configure the NeSSi2 User Interface before starting it but,
same as every Eclipse RCP based application, it is possible to modify a configuration
4 see http://logging.apache.org/log4j/ for description of the log4j framework and the
configuration options.
12
3.3. NeSSi2 Database
file for the exectuable, e.g. to increase the memory assigned to the application. In case
of the NeSSi2 User Interface the file is called NeSSi2.ini.
Other customizable settings can be configured within the NeSSi2 User Interface. These
settings can be found in section 4.2.14 (NeSSi2 User Interface preferences).
3.2.3. Launching the NeSSi2 User Interface
Simply start the NeSSi2 User Interface executable, e.g. nessi2.exe on Windows.
3.3. NeSSi2 Database
NeSSi2 requires a database to record simulation results. The network topology, sce-
narios and simulation information are stored along with the measured values, so the
NeSSi2 User Interface can be used for visualization. This includes statistical charts of
the measured values per device, link or the whole network on the one hand, as well as
simulation replay on the other hand.
At the moment, only MySQL is supported as recording database, but we are confident
of adding support for other database management systems in the future.
To set up a database for NeSSi2 , you will have to follow the following steps:
1. Install the MySQL database management system (see Appendix D on how to

install MySQL under Microsoft Windows).
2. Create a password-protected database user with root permissions to create new
database schemas. You may also want to enable this permission for other hosts
than just the localhost.
3. Do not forget to flush the new privileges (cf. http://dev.mysql.com/doc/
refman/5.5/en/flush.html for more information).
4. Start the NeSSi2 User Interface.
5. Open the Preferences and under the NeSSi2 tab, configure the hostname, username
and password for the database connection.
6. Enter a name for the database schema. If no database schema with that name
exists, the schema and all its tables will be created.
To get started you probably want to import the sample simulation data available at
http://www.nessi2.de. An instruction on how to import the data into the MySQL
database properly can be found in appendix E.
13
3. Installation
Please refer to your database management system documentation for configuration guide-
lines. An example for MySQL on Windows XP is given in appendix D. In particular
it is important that the maximum allowed packet size is sufficient for all the networks,
because the data for each network is sent in one statement. The size of the network
data depends on the number of nodes and links in the network, but more important on
the number of custom icons used. Custom icons are embedded in the network data, so
the more different icons are used, the more binary data has to be embedded and hence
the size of the network file grows. Setting the value to 2050 MB should be sufficient
for almost all use cases. We also experienced much better recording performance with
MyISAM tables rather than InnoDB tables. So the default database engine should be
changed to MyISAM as well.
In MySQL, these values can be modified e.g. in the administration section of the MySQL
Workbench5 .
A description of how to set up NeSSi2 to use the created database is given in Sec-
tion 4.2.14.
3.4. NeSSi2 Repository

The download and upload operations of the NeSSi2 repository features are based on
Maven Plugins. Therefore it is required that Maven is installed before the repository
features are used.
Note: At least maven 3.0.5 or higher is required.
. The 2.x versions of maven are
not sufficiant.

Download the latest Maven version from http://maven.apache.org/download.
html. A guide on how to set up Maven can also be found on the same page for different
platforms.
Note: For linux export the PATH variable. in ~/.profile not in ~/.bashrc. Otherwise
the maven binary can not be found.
5 http://mysql.com/downloads/workbench/
14
4. Graphical User Interface
Creating, editing and configuring NeSSi2 components, such as network topologies and
profiles, can be done in NeSSi2 s graphical user interface. The UI is an application based
on the Eclipse Rich Client Platform (RCP1 ), making NeSSi2 compatible with a variety
of operating systems.
The NeSSi2 User Interface components can be divided into two distinct categories: the
simulation components, which conclude a NeSSi2 project and will be discussed in sec-
tion 4.1. The other category is the RCP GUI elements such as views, editors and per-
spectives, which will be introduced in 4.2.
4.1. Simulation Components

In this section, GUI components that are part of a NeSSi2
project are introduced. Note that this section only describes
what these components are and what purpose they fulfill. How
these components can be created and configured is described
in section 8.
Components which are required for running a simulation are
collected in a NeSSi2 project. Figure 4.1 illustrates how a
project is structured. A project consists of a root folder, some
predefined sub folders and some files created by the user. The
root folder is named after the project, whereas the sub fold-
2
Figure 4.1.: NeSSi2 Project ers are named after the element types they contain. NeSSi
Explorer project files include the following types: networks, appli-
cations, profiles, scenarios, simulations, recorder configura-
tions and the optional templates. Each of these components will be described in the
following subsections. The paradigm behind NeSSi2 foresees the separation of static
topology information from dynamic behavioral information, with the goal of enhancing
the re-usability of previously created elements. This shapes up NeSSi2 projects to have
a structure as described above.
Note: It is strongly recommended to store the project components in their corre-
sponding folders. Otherwise, these component . will not be recognized as such by
the GUI.
4.1.1. Mode
NeSSi2 modes determine which types of network topologies and applications are sup-
ported. The mode included in default NeSSi2 implementation is IP-mode and it allows
1 The Eclipse Foundations page for RCP: http://www.eclipse.org/home/categories/rcp.php
15
for the execution of IP-based simulations. NeSSi2 , however, is designed to support mul-
tiple modes at the same time.
4.1.2. Networks
Networks consist of nodes and edges. A network is independent of any other compo-
nents. Networks are located in the root of every project folder. An empty network is
automatically generated when a new project is created and, by default, will have the
same name as the project. A NeSSi2 project may contain more than just one network, so
that federated simulations may be created and evaluated. See chapter 6 for more details
on federated simulations.
4.1.3. Layouts
Layouts describe the position of each network component. The layouts are stored in a
separate file with the .layout extension. Same as the network files, these files are located
in the root of every project and have the same name as the network they belong to. If a
layout file is missing, the corresponding network will not be displayed correctly.
4.1.4. Applications
Applications are used for determining the behavior of a node during a simulation. Appli-
cations are actually classes contained in JAR files created using Maven. Due to NeSSi2
architecture, which prescribes a separation between user interface and simulation back-
end, the JARs containing application classes need to be provided to user interface and
backend separately. The application JARs on user interface side are located in a folder
named applications within the installation location of NeSSi2 . On the backend
side, the applications are located in a folder with the same name as in frontend, which
is located in the installation path of the backend. Applications may also be configured
by some parameters through the user interface.
While applications are not explicitly listed the in a project (see figure 4.1), they are in
fact the core component which specifies the dynamical behavior of a node at runtime.
A tutorial for creating NeSSi2 applications can be found in chapter 9.
Note: Applications depend on their mode. to function properly. Thus, if a required
mode is missing, the corresponding applications will fail.
4.1.5. Profiles
Profiles in the NeSSi2 context are used to collect applications as a unit, which can be
deployed onto nodes. Each profile contains a collection of applications with corre-
sponding configuration parameters. An application can be included in a profile multiple
times. The profiles are stored in Profiles folder of each project and have .profile file
extension and an XML-based content.
16
4.1. Simulation Components
4.1.6. Scenarios
A scenario defines which profiles are deployed on each node of the network topology.
Multiple profiles may be deployed on the same node simultaneously. Analogous to the
profiles, the scenarios are stores in the Scenarios directory of each project with .scenario
file extension and XML-based content.
4.1.7. Simulations
As the core element of simulation execution, simulations are the components that can be
launched from within the user interface and evaluated in the backend. Simulation files
have .simulation file extension and XML-based content and are located in Sessions
folder of a project.
The duration of a simulation execution is determined by two parameters, namely repli-
cations and ticks. Replications specify how many times a scenario is to be executed,
whereas ticks are the time units by which runs are measured. A simulation can be con-
figured to have a fixed number of ticks and replications. Alternatively, the so called
termination conditions can be used to specify these parameters dynamically during a
simulation execution, so that the simulation will be interrupted when certain constraints
are fulfilled. See chapter 7 for more details on termination conditions.
Node mappings, which are required for federated simulations (see chapter 6) and record-
ing configurations (see section 4.1.9), are also configured in the simulation file.
4.1.8. Templates
Templates are used for defining alternative graphical representations for network nodes.
A template encapsulates a normal node or a sub net of NeSSi2 along with additional
information such as icons, a name and a description.
When creating network topologies, NeSSi2 offers a variety of nodes, distinguished only
by their icons and labels. If predefined nodes are not sufficient for the user (e.g. a device
with a specific icon is required) she or he can create additional templates.
Note: A Template has no specific logic contained; it serves merely as a graphical
. behave differently if they are using
representation for the user. Nodes will NOT
alternative templates
4.1.9. Recorder Configurations
Recorder configurations specify the event types that are to be recorded during the sim-
ulation execution in NeSSi2 Backend onto the database. The default configurations can
be found in Recordings/Examples folder of each NeSSi2 project. Recorder con-
figurations are based on log4j 2 . Please refer to the log4js homepage for more details.
2 http://logging.apache.org/log4j/
17
4.2. GUI Elements

The RCP based NeSSi2 GUI Elements can be divided into three groups:
Views: Views are used to display data of a certain type. The data can also be
edited in a view. Changes are applied instantaneously.
Editors: Editor windows contain the main data of interest. In NeSSi2 , this data
would be graphical representation of networks and sub nets. Changes made to
the data in a view will require the user to explicitly select "save" in order for the
changes to commit.
Perspectives: Perspectives are used to bundle thematically related views and edi-
tors, so that the presented interface contains essential elements while hiding func-
tionality which are unrelated to the current task.
In this section we will first introduce the NeSSi2 specific views and editors, followed by
an introduction to NeSSi2 perspectives in section 4.2.13.
Figure 4.2.: Some of the NeSSi2 GUI elements in the Network Editing Perspective. 1: NeSSi2 Explorer,
2: Network editor, 3: Outline, 4 : Properties, 5: Problems, 6: Progress, 7: Routing Tables
4.2.1. NeSSi2 Explorer

The NeSSi2 Explorer (figure 4.2, number 1) is a view which displays the contents of
all NeSSi2 projects located in the workspace as a tree. It has similar functionality as a
system file browser. Files and folders may be created, deleted and relocated in this view.
Most importantly, by selecting an element such as a scenario, and entering its context
18
4.2. GUI Elements
menu, user will have access to the elements specific actions, e.g. "Deploy Profiles" or
"Upload Artifact".
4.2.2. Outline
Outline (figure 4.2, number 3) displays a list of all the network nodes and sub nets in hi-
erarchical manner. Selections made in this view affect the selections in its corresponding
editor. Only in combination with the Network or Scenario editor will this view contain
valid data.
4.2.3. Routing Table
Similar to Outline, this view will only dis-

play data when a node in the network is
selected. This can only be case when the
Network Editor or the Scenario editor is
open. This view displays the respective
routing table of a selected node.
As can be seen in figure 4.3, this views
Figure 4.3.: The Routing Table View for a Network contains IP addresses of the gateway, sub
Node net mask and hop count for each reach-
able target machine.
4.2.4. Properties
The Properties view (figure 4.2, number 4) displays and

allows the editing of a number of properties for the se-
lected network element.
Among other information, device name and device type
are displayed for nodes. For network links the follow-
ing attributes may be changed: the bandwidth, latency
and maximum transfer unit (MTU) for the source and
destination network interfaces. Figure 4.4 demonstrates
how the properties look like for a network edge.
Figure 4.4.: The Properties View

for a Network Edge
4.2.5. Problems
When creating and modifying simulation components in a NeSSi2 project, the NeSSi2
Project Builder runs in the background and verifies these modifications. When incon-
sistencies or conflicts occur (e.g. files are missing), errors and warnings indicating these
events are shown in the Problems view (see figure 4.5).
19
Figure 4.5.: The inconsistency in a project is marked red in the NeSSi2 Project Explorer. The Problem
view shows a detailed description of the problem.
4.2.6. Progress
The Progress view shows the status of jobs running

in the background. These Jobs include periodi-
cally checking the connections to the database and
the simulation backend, or the polling of data from
the database so that the simulation results can be
displayed. Figure 4.6 demonstrates how the jobs
are displayed in this view. Figure 4.6.: The jobs running in the
background are displayed in the Progress
view.
4.2.7. Statistics
Figure 4.7.: The recorded events for nodes and edges can be viewed in the Statistics view.
The recorded events for each nodes, edges and networks can be viewed in the Statistics
view. In order to do so, the respective node or edge has to be selected. For displaying
events recorded for the network (global events), a click on the background of the net-
work in Simulation Editor suffices. As can be seen in figure 4.7, this view shows a list of
the recorded events. Selecting these events will include them in the statistics. Using the
buttons located on the top right side of this view, the appearance of displayed chart can
be changed. The statistics can be viewed as lines, bars, areas and the unstacked charts.
The interval for the displayed values can also be adjusted. Additionally, the option of
displaying the data in a cumulative matter can also be toggled.
20
4.2. GUI Elements
4.2.8. Network Editor
Creating and editing networks is done in Network Editor (see figure 4.2, number 2)
which can be accessed by double-clicking on any network file. By using the palette,
which is located on the right side of the editor, nodes and edges can be added to the
network. These network elements can also be relocated or removed at any time.
4.2.9. Profile Editor
Using Profile Editor, applications can be added to a profile and configured (see figure
4.8). By pressing "Add..." button, a dialog containing a list of all available applications
sorted into categories, will be displayed. The Profile editor can be entered by double
clicking on any existing profile. This editor displays a list of the applications associated
with the currently selected profile. By selecting each application, the configuration
parameters will be made visible, so that they can be adjusted. Changes made to a profile
using Profile Editor should be explicitly saved in order for the modifications to take
effect.
Figure 4.8.: Profiles can be edited and configured using the Profile editor.
4.2.10. Scenario Editor
Using Scenario Editor, profiles can be deployed on the network edges. This editor can
be accessed by double clicking on any scenario file in NeSSi2 Project Explorer. Scenario
Editor has a very similar appearance to Network Editor. It basically displays the network
associated with a scenario, so that profiles can be deployed on each network node. The
difference is that no changes can be made to the network structure in Scenario Editor.
After profiles have been deployed on a node, a list of the profiles will be displayed as
tooltip for each node.
21
Figure 4.9.: Scenarios can be edited and configured using the Scenario Editor. The deployed profiles
are displayed as tooltips for each node.
4.2.11. Simulation Editor
Simulations can be viewed and edited in Simulation Editor. This editor can be accessed
by double clicking a simulation file in NeSSi2 Project Explorer.
This editor consists of two tabs:
Simulation Configuration which is used to add scenarios to a simulation and to
configure termination conditions (see chapter 7).
Network Configuration which is used to create node mappings in the case of fed-
erated simulations (see chapter 6).
Figure 4.10.: Configuring a simulation in the Simulation Editor.
4.2.12. Recorded Simulations
The Recorded Simulations view displays

a list of all recorded simulations found in
the database, which are named after their
simulation file. The timestamp of when a
Figure 4.11.: The Recorded Simulations view

22
4.2. GUI Elements
simulation was initiated is also recorded

in each entry. The sub-entries of each
simulation is a list of every replication, which in turn contains the name of the scenarios
and their corresponding networks.
4.2.13. Perspectives
The graphical frontend of NeSSi2 allows user to create and edit network topologies,
attach runtime information, and schedule them for execution at the simulation backend.
On the other hand, it allows for the visualization of recorded simulation information,
which are retrieved from the database server. This constitutes two distinct use cases:
pre- and post-simulation visualization. For this reason, two perspectives are contained in
the NeSSi2 User Interface: the Network Editing Perspective and the Network Simulation
Perspective. Each of these perspectives are introduced below.
Network Editing Perspective
This perspective is used by default for creating and editing network components. Net-
work Editing Perspective comprises a main network editor window grouped with a va-
riety of different views which provide additional information corresponding to the ele-
ment currently selected in the network editor. Figure 4.2 illustrates the Network Editing
Perspective. The GUI components involved in this perspective are NeSSi2 Explorer,
Outline, Routing Table, Properties, Problems, Progress,Network Editor, Profile Editor,
Scenario Editor and Simulation Editor.
Simulation Perspective
Network Simulation Perspective contains a set of related views which allow the visual-
ization of simulation results. This perspective consists of Recorded Simulations, Statis-
tics, Running Simulations, Properties, Progress, Simulation Editor and Outline. Upon
connecting to the database server, the available simulation results are depicted in a tree
structure annotated with the date of the execution in Recorded Simulations view. The
desired simulation can be selected, and the corresponding simulation results are down-
loaded for display in the Simulation Editor. The main editor window contains network
topology associated with the selected simulation; however, no network elements may
be edited or deleted here. In the menu bar, user can step forward and backward through
the simulation to inspect the state of the network at desired tick using the forward and
backward buttons.
In the main network window, the status of network elements is visualized by different
means. For example, link widths and colors will change depending on the type and
amount of traffic on the link, while devices which have failed (for example due to a
successful attack) will appear grey.
The Properties view displays detailed information for the current tick (for example,
routing tables may change over time), while the Statistics view contains graphical infor-
23
Figure 4.12.: Graphical depiction of traffic in the network simulation perspective
mation of logged events for the selected network element e.g. a graphical representation
of the packets on a given link, sorted by protocol type.
4.2.14. Preferences
Before a simulation can be executed, user will have to configure the database settings
for front end considering the fact that the default settings point to a location which is
not writable. Optionally, database connections may also be configured for backend,
although this will not be necessary in most cases.
Connect the UI with the Back End
The name of the host running the simulation backend has to be determined in GUI pref-
erences (Window Preferences NeSSi2). The default setting for this is localhost.
Database Configuration for the Front End
In NeSSi2 s Database Settings (Window Preferences NeSSi2 ) a database type has to

be selected beforehand. NeSSi2 currently only supports MySQL. The user name, pass-
word, and host name on which MySQL-Server-Instance is running on (only hostname
or IP-address is needed) have to be specified and a database schema name has to be
defined. If the schema does not exist in the database, NeSSi2 will create it. An example
24
4.2. GUI Elements
Figure 4.13.: Example settings for a MySQL database in the NeSSi2 preference page
setting is depicted in figure 4.13
Database Configuration of the Back End
The backend gets its configuration from the recorder settings XML file, which is spec-
ified when a simulation is created. However, default database connection settings from
frontend preferences will be used when the database connection settings are missing
(see 4.2.14). Different settings for front- and backend can be configured by editing the
configuration file as follows:
Expand the nodes of NeSSi2 Project and choose Recording Examples.
Copy default_recorder.xml to Recording directory as a backup copy
of the original file.
Open default_recorder.xml.
Uncomment "DBAppender" definition block and set the appropriate values for the
parameters.
Figure 4.14 illustrates a sample configuration. For further information about backend
configuration files refer to the Apache log4j documentation.
25
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd">

<log4j:configuration xmlns:log4j=http://jakarta.apache.org/log4j/>

<appender name="DBAppender" class="de.dailab.nessi.recording.db.common.DBAppender">

</appender>


<logger name="de.dailab.nessi" additivity="false">
<level value="DEBUG"/>
<appender-ref ref="DBAppender"/>
</logger>


<logger name="de.dailab.nessi.network.DummyConnection" additivity="false">
</logger>


<logger name="de.dailab.nessi.layer.InternetLayer" additivity="false">
</logger>


<logger name="NetworkLogger" additivity="false">
</logger>
</log4j:configuration>
Figure 4.14.: recorder_settings.xml for configuring the backend of NeSSi2
26
5. NeSSi2 Repository
This chapter describes the repository related features of NeSSi2 . These features include
mainly the ability of deploying the simulation components of NeSSi2 into a remote
repository and retrieving them as needed.
The NeSSi2 repository is a remote Maven repository for storing the NeSSi2 simulation
components. How artifacts can be deployed into such a repository is described in section
5.3. How the components can be retrieved from a repository is explained in section 5.4.
It is strongly recommended to configure the repository options as described in section
5.2 before attempting to use the repository features. Some Background information
about the download and upload operations is provided in section 5.1.
Since Maven plugins are used in the background for the artifact deployment and retrieval
operations, Maven has to be installed along with the NeSSi2 User Interface in order for
these features to work. Please refer to chapter 3 for details on installing Maven.
5.1. Background Information
Figure 5.1.: The dependency hierarchy of NeSSi2 components
As mentioned in chapter 4.1, each NeSSi2 simulation consists of many components,

such as profiles, applications and scenarios. The components in a project depend heavily
on each other because of the fact that almost every project component references one
or more of the other components. As an example, when an application component
is missing, every profile component which references this application will be invalid.
Figure 5.1 illustrates the dependency hierarchy of NeSSi2 components.
The upload and download features of NeSSi2 are designed with respect to these de-
pendencies. This means uploading/downloading a NeSSi2 component will require the
27
transfer of other components which have references to it and as a result, the whole up-
load/download process is rarely restricted to a single download/upload operation.
In order for NeSSi2 components to be compatible with a Maven repository, each com-
ponent requires some additional Maven attributes such as ArtifactID, GroupID and Ver-
sion. These attributes ensure that every component within a project can be uniquely
identified.
5.2. Configuration and Preferences

The repository preference page serves as a central management tool for configuring
repository locations and authentication profiles. As Maven-based plugins, the upload
and download mechanisms acquire the repository locations from an XML-file called
settings.xml, which is located in USER_HOME/.m2 folder by default. The repos-
itory preference page parses and displays the content of settings.xml and serves as
a tool for editing it.
Each repository location in settings.xml is uniquely distinguished by an ID and a
URL. In addition, some additional attributes for each repository are stored as well for
authentication purposes, such as a username coupled with password or a private key
coupled with an optional pass phrase.
This section describes how the options in the preference page can be adjusted.
5.2.1. Getting Started

The repository preference page can be accessed in NeSSi2 User Interface by the follow-
ing menu sequence: Window Pre f erences NeSSi2 Repository
Figure 5.2.: The repository preference page, used for managing repository locations.
Upon opening the repository preference page, providing that settings.xml exists,
28
its content will be parsed and displayed. If such file doesnt exist, a dialog window will
ask for a confirmation to create a default settings.xml.
The settings-file, which is currently being used, is displayed on top of the page (see
section 1 in Figure 5.2). The "Browse..." button enables the user to select a custom
settings-file. Note that settings-file can have a custom name. It is however necessary,
that the extension of settings-file is of type XML, otherwise it will not be shown as a
valid settings-file in the file browser.
The field that is marked as local repository indicates the location of the local repository
on the file system. This field merely serves as information and can not be edited.
The local repository is where Maven keeps a copy of the downloaded artifacts.
Assuming that an artifact is available in local
. repository, Maven will be able to
resolve required artifacts during a build process, even when remote repositories
are not accessible.
Section 3 in Figure 5.2 displays the repository locations defined in setting.xml in
addition to the predefined repository locations. These predefined locations are: nessi2-
intern-release, nessi2-intern-snapshot and nessi2-extern. By clicking on each reposi-
tory ID, the details of the repository location will be displayed in section 4 in Figure
5.2.
Note: Changes made to repository locations . will be saved into the settings-file
only after the user clicks on "Apply" or "OK" button (section 5 in Figure 5.2).
5.2.2. Default Repository Location

Among the available repository locations, the user can set one to be the default repos-
itory location (section 2 in Figure 5.2). This default repository will be automatically
selected in the NeSSi2 User Interface for uploading/downloading artifacts. However
repository location can still be changed before these operations.
There are two default repository locations which can be specified, "Default Snapshot
Repository" and "Default Release Repository". Default snapshot repository defines the
default repository, where missing artifacts of type snapshot will be downloaded from by
the simulation backend, whereas the default release repository defines respectively the
default repository, where missing artifacts of type release will be downloaded from by
the NeSSi2 Backend.
Note: Only repository locations, which have. a URL may be set as default reposi-
tories.
5.2.3. Adding Repository Locations

To add a repository location, click on "Create New..." button, which is located on the
bottom of section 3 in Figure 5.2. The User may then specify the attributes of the
repository location in this dialog window (see Figure 5.3).
Since the ID of every repository location has to be unique, when a specified ID already
29
Figure 5.3.: Entering information for a new repository location.
exists, a warning message will be displayed on top of the dialog window. In addition, a
URL must also be specified. This, however, does not have to be unique.
Optionally, authentification information can be specified for each repository location.
To do this, the "Use Authentication" check box must be enabled. Maven supports two
authentication methods : either a user name with corresponding password, or a private
key. To use a private key as authentication, user has to specify the path to the private
key. An optional pass phrase can also be specified in addition to the private key.
Upon clicking "OK" button, the a repository location will be added to the list of avail-
able repository locations. To finalize the creation of the new repository location, press
"Apply" or "OK" in repository preference page (section 5 in Figure 5.2).
5.2.4. Deleting Repository Locations
In order to delete an entry from the list of repository location, select the repository
location ID (section 3 in Figure 5.2) and press "Remove" button (section 4 in Figure
5.2). To confirm the deletion process, press "Apply" or "OK" button (section 5 in Figure
5.2).
Note: Predefined repository locations can not be deleted. If user tries to delete
. associated with the repository location
these entries, the authentication information
will be deleted.
5.2.5. Modifying Repository Locations
In order to edit the information of a repository location, select the repository location ID
(section 3 in Figure 5.2) and press "Modify" (section 4 in Figure 5.2). This action will
open a dialog window where the existing information of the selected repository location
can be adjusted. Upon pressing the "OK" button in the dialog window, the changes will
be saved temporarily. To finalize the modifications, press "Apply" or "OK" in repository
preference page (section 5 in Figure 5.2). This will cause the modifications to be written
into the associated settings-file.
30
. locations cannot be changed.

Note: ID and URL of predefined repository
5.2.6. Download Options for the backend

In order to access the preferences for downloading simulation components in the NeSSi2
Backend use the following menu sequence: Window Pre f erences NeSSi2
Repository Backend Options
To enable the download of missing application JARs in the backend, "Use repositories
for downloading missing JARs in the backend" check box must be enabled (Figure 5.4).
When enabled, the user is able to choose a number of the available repository location
for dependency resolution in the backend. Before running the simulation, backend will
check whether all of the required application JARs are available. If they are not avail-
able, the NeSSi2 backend will connect to the chosen repositories and try to download
the missing JARs.
Figure 5.4.: The selected repositories will be used for dependency resolution in the NeSSi2 Backend
5.2.7. Manual Configuration

The Maven settings file can also be configured manually using any given editor. Only
changes to repository IDs, repository URLs and authentication information for reposi-
tory will be complied. Options such as default repository ID and download configura-
tions for the backend are not stored in this file and can only be configured in repository
preference page of NeSSi2 User Interface.
Figure 5.5 illustrates how the repository information, which is registered by NeSSi2 User
Interface, should be stored. Authentication information for the corresponding repository
is stored under servers tag, with ID being the unique identifier. Furthermore, the same
ID will be used to describe the URL of a repository stored in the repositories section of
31
<servers>
<server>
<id>siteServer</id>
<privateKey>/path/to/private/key</privateKey>
<passphrase>optional; leave empty if not used.</passphrase>
</server>
<server>
<id>example</id>
<username>username</username>
<password>password</password>
</server>
</servers>
.
.
.
<profiles>
<profile>
<id>NeSSi Profile</id>
<repositories>
<repository>
<id>example</id>
<url>http://repositories.example.com</url>
</repository>
</repositories>
</profile>
</profiles>
Figure 5.5.: An example of how the authentication information and repository IDs are stored in the
settings.xml
NeSSi Profile. Note that only repository locations, which are stored in this profile, will
be processed. Other profiles will be ignored.
5.3. Uploading Artifacts
Uploading NeSSi2 simulation components (also called artifacts in the Maven context)
can be done with the help of Upload Wizard provided in NeSSi2 User Interface. Upload-
ing artifacts using this wizard is restricted to NeSSi2 components with the file extensions
.*network, .simulation, .scenario and .profile. In order to access the upload wizard, se-
lect a component in project explorer view and select "Upload Artifact..." action from
the components context menu.
By pressing "Next" and "Back" button, user can switch between wizard pages. The
number of wizard pages in Upload Wizard can vary heavily, depending on the number
of dependencies that a component may have. These pages can be categorized into three
types of pages; one for each step of artifact deployment process as following:
Step1 - Dependency Acquirement: The dependencies of selected artifact will be com-
puted by the wizard. All components which need to be uploaded are summarized and
listed to be reviewed by user (see Figure 5.6). The components are categorized and
sorted according to their types. The highest-ranking component in NeSSi2 component
hierarchy (see Figure 5.1), which can be directly uploaded, is the simulation entity while
the lowest-ranking component is the profile.
32
5.3. Uploading Artifacts
Figure 5.6.: The first page of the upload wizard: Creating a list of the artifacts that are to be uploaded.
Note: Uploading application JARs as single entities is not possible. Hence, to

upload an application JAR, at least one application
. inside the JAR needs to be
included in a profile. The application JAR can then be uploaded as a dependency
of the profile.
Step2 - Entering artifact information: The number of pages in this step is equal to the
number of artifacts that are to be uploaded. For each component, with the exception of
application JARs, the mandatory Maven attributes ArtifactID, GroupID, Version as well
as the optional Description have to be provided (see Figure 5.7) in a separate page. The
name and the corresponding icon of the artifact are displayed on the top of the page.
Note: There is a restriction to the characters that the user can enter for each
field. Only alphanumeric characters, with. the addition of underline, minus, back-
slash and dot, are allowed. User will not be able to continue to the next page un-
less all of the fields respect this restriction.
To simplify this process of providing information needed by Maven, a number of small

features were integrated, such as:
The AritfactID will be automatically set as the name of the component file. An
exception to this case are application JARs. In that case, the Maven attributes are
set according to the information in application JARs already existing POM. This
information can not be edited during the upload process.
The Version of the artifact will be automatically set to 1.0.0-SNAPSHOT.
Note: When deploying into a snapshot. repository, the Version must contain
the String SNAPSHOT. Otherwise the uploading attempt will fail.
When entering a GroupID for an artifact, the GroupID from a previous page will
be copied to the next page (for the next artifact).
The NeSSi2 artifact database (see chapter 5.5) will be checked for the availability
33
Figure 5.7.: Entering artifact information for an example simulation file.
of every artifact. If the database contains information about an artifact, i.e. if

the artifact has been previously uploaded or downloaded, its attributes will be
copied from the database into the wizard page. This feature will be prioritized
over previously mentioned features. If information needed by Maven is available
in the database, features mentioned aboved will not be activated.
Note: It is mandatory for each artifact to contain its file extension in the Artifac-
tID, to ensure that the artifact can clasify correctly during the download process.
.
Furthermore, if user is uploading Application JARs, it is important to make sure
that the GroupID of the artifact is set to "contributions", otherwise it will not be
recognized as such when downloaded.
Step3 - The actual artifact deployment takes place in this final step of Upload Wiz-
ard. In this step, a list of all available repository locations is provided, with the default
repository locations being initially selected (see Figure 5.8). The default repository lo-
cations can be configured in repository preferences (see section 5.2). The URL of a
repository can still be edited before uploading, but changes made at this point will not
be saved.
By pressing "Upload" button, the artifact deployment will begin with an invocation of
a corresponding Maven plugin. The output will be displayed in output section of this
page. When an upload process is successfully executed, the entered artifact information
as well as the upload date will be stored into the NeSSi2 artifact database. These actions
are repeated for every artifact which has to be uploaded. As a result, output consists of
section-wise build reports.
If an error occurs during an upload process, a message dialog is displayed, warning
about the possible occurrence of a failure. The upload process will be interrupted. In
34
5.4. Downloading Artifacts
Figure 5.8.: Uploading an artifact into a repository. At the top: a repository location can be chosen from
a list. At the bottom side: the output from the plug-in can be viewed.
this case user will have the option to retry the upload process, or to end the wizard
entirely.
5.4. Downloading Artifacts

Downloading artifacts can be done in the NeSSi2 User Interface as well as in the NeSSi2
Backend. The following two subsections will describe both of these options.
5.4.1. Downloading Artifacts in the Frontend
NeSSi2 artifacts can be downloaded in the NeSSi2 User Interface from remote reposi-
tories by using the download wizard, which can be accessed through "Download Arti-
fact..." action in the context menu of any projects sub folder.
Upon starting the wizard, the default repository location specified in preference page is
selected.
There are two options available to specify an artifact which has to be downloaded. The
first option is by entering the mandatory Maven attributes manually in the specified
fields. This method is useful if artifact attributes are already known. However, the
download process will fail if the artifact is not available in the repository. The second
option is by browsing through the repository and choosing the desired artifact. For
this purpose, one of the available repository locations needs to be chosen. Afterwards,
user will have to press "Browse..." button (see Figure 5.9), which will open a dialog
containing the summarized content of the selected repository in a tree-wise structure
35
Figure 5.9.: The download wizard after the wizard has successfully downloaded an artifact and its
dependencies.
(see Figure 5.10). The branches of the tree are GroupIDs of the artifacts, whereas the
leaves are ArtifactIDs and Versions of the artifacts available in the repository. However,
due to index file updating delays of remote repositories, the displayed tree may not be
up to date. If the desired artifact is not displayed in the tree, press the "repository"
hyperlink. By clicking this link, the default system browser will open the repositorys
URL. Using the system browser, the repository can be explored and the artifact attributes
may be entered into download wizard manually.
Pressing "Download" button is going to invoke a corresponding Maven plugin. Output
of this invocation will be displayed in the bottom section of the wizard dialog (see Fig-
ure 5.9). During the download process, a progress bar and a label will display the
downloads state overall. When an error occurs, a dialog informing about the error will
be displayed and even if the download was not successful, the download wizard will not
be closed, thus enabling user to retry the download process. This may be the case if,
e.g. the download process failed due to incorrect entries of artifact attributes.
Additionally, it is possible to create a new project as a placeholder for the artifacts which
will be downloaded. This can be achieved by clicking "Create a new Project for this
artifact" check box (see Figure 5.9). Selecting this check box enables a text field where
user can specify a name for the new project. Otherwise, the artifacts will be downloaded
into the project where the download wizard was initially started.
In order for NeSSi2 User Interface to be able to register newly downloaded application
JARs, a restart of NeSSi2 User Interface is inevitable. When a new application JAR
36
5.5. Artifact Database
Figure 5.10.: Browsing through a repository within the NeSSi2 User Interface
has been downloaded, a dialog will be displayed, suggesting user to restart NeSSi2 User
Interface. Pressing "Restart" button will restart NeSSi2 User Interface.
Note: Not restarting the frontend after new application JARs have been down-
loaded will result in errors when trying to. load profiles and run simulations that
depend on the new application JARs.
5.4.2. Downloading Artifacts in the Backend

NeSSi2 Backend can be configured to check for local availability of the required appli-
cation JARs before simulation is started. If any JAR is missing, NeSSi2 Backend will
connect to default repository, specified in the preference page (see section 5.2.6), and
attempt to resolve the missing JARs.

Along the growing number of artifacts, maintaining an overview of uploaded and down-
loaded artifacts can become a challenge. To overcome this problem, a database holding
artifacts information has been arranged to support the upload and download process.
The database used for storing NeSSi2 artifacts information is an instance of db4o1 , an
open source object database. The db4o instance used in NeSSi2 will be referred to as
artifact database. As an instance of db4o, the artifact database is a single file located
in the NESSI2_UI_HOME and is called NeSSi2_ ArtifactsDB.db. Information which
is saved for each NeSSi2 artifact is the full path to the artifact files, the corresponding
Maven attributes, as well as the latest date when the artifact was uploaded or down-
loaded.
To be able to view the artifact information of a certain file, enter the context menu of
that file in NeSSi2 project explorer and choose "View Artifact Property" menu item. This
1 http://www.db4o.com/
37
Figure 5.11.: Viewing all database entries within the NeSSi2 User Interface
will open a dialog window containing information about the selected artifact (see Fig-
ure 5.12). If the selected artifact has no registered Maven attributes, the corresponding
fields will be marked as "Not Available".
There are two ways of accessing the whole contents of the database: One is by clicking
the database symbol ( ) located in NeSSi2 s main toolbar. The other option is by
selecting the following menu sequence: Repository View Local DB Contents. Either
one of these actions will open a dialog containing a table which represents all of the
database entries (see Figure 5.11). The table consists of several columns and each of
them represents an attribute of the artifact.
Note: User can reset the database at any. time by deleting NeSSi2_ Arti-
factsDB.db file from NESSI2_UI_HOME folder.
Figure 5.12.: Viewing the properties of a NeSSi2 component.
To simplify the process of locating a certain artifact, each column of the table can be
sorted alphabetically by clicking on the columns title. Additionally, a simple search
function is integrated on the top of this dialog window (see Figure 5.11). The search
38
function examines certain fields of the database entries for specified Strings. To ensure
a more accurate search, select "Case Sensitive" check box, which enables the search for
case sensitive Strings. The search can also be limited to a specific column of the table.
39
6. Federated Simulation
This chapter describes how federated simulations can be created in NeSSi2 . The func-
tionalities that are involved with federated simulations are the creation of multiple net-
works in a project, the mapping of nodes between these networks and, associating a
scenario with a network. These and other functionalities will be described in the fol-
lowing sections.
6.1. Project with multiple Networks
Figure 6.1.: A list of all wizards that enable the creation of new files and resources.
This section explains how multiple networks can be created for a project. There are two
ways how this can be achieved: one is by using the main menu bar and the other way is
by using a projects context menu.
To create a network over the menu bar select File New Other... and a dialog
containing all related wizards will open (see figure 6.1). This wizard displays a list of
the various files, which can be created in a NeSSi2 project.
Figure 6.2.: Creating a new network file by a right clicking a the project
41
6. Federated Simulation
Selected the "IP Network" from the list, contained in the NeSSi2 folder. This option is
highlighted in figure 6.1. By clicking Next the "New Network Wizard" will open (see
figure 6.3). In this wizard you can choose the project to which the new network will
be added, and also the name of the network. By pressing the "Finish" button, a new
empty network file will be created in the selected project and automatically opened in
the Network Editor. The new network file can then be edited.
Figure 6.3.: Entering a name and a parent folder for a network file in the "New Network Wizard"
The other alternative for creating a new network file, is by right clicking on the project
and selecting New IP Network, as is shows in figure 6.2. This will cause for the "New
Network Wizard" to open, same as the alternative discussed above.
What is also important in this context is that, when creating scenarios, you will be asked
to select a network to associate with this scenario. For including the created networks
in the a simulation, you must assign each network to a separate scenario.
6.2. Mapping
In federated simulations a node can be contained in multiple networks, and is therefore
able to communicate with its counterpart. This section describes how different nodes
from different networks can be combined for the purpose of federated simulations.
Figure 6.4.: The network configuration page in the Simulation editor
42
6.2. Mapping
In NeSSi2 , nodes contained in one networks can be mapped to nodes of other networks
which are contained in the same project and in the same simulation. This is done in the
Network Configuration Page of the simulation editor (figure 6.4).
Figure 6.5.: The dialog for the network mapping configuration
In this page, a list of all networks, which are contained in the scenarios of the current
simulation are displayed. When more than one network is selected in the list, the Show
Network Mapping button will be enabled. Upon pressing this button, the dialog for
configuring the mappings will open(figure 6.5).
In this dialog, all subnets and nodes form the previously selected networks are displayed.
On selecting at least two nodes from different networks, the Combine Nodes button
will be enabled. Using this button a mapping of the selected nodes will be created.
In addition, this mapping will be displayed in the list of existing mappings. When a
mapping is created, a global ID will be generated for the mapped nodes. These IDs are
displayed in the mappings list before the nodes names. If an item from the mappings list
is selected, the Separate Nodes button will be enabled. Using this button, you can undo
the selected mapping, causing for the global ID to be deleted. To submit the changes to
the editor, the OK button must be pressed. However, for saving the node mapping, you
will have to save the simulation file explicitly in the simulation editor.
43
7. Termination Conditions
This chapter describes how simulations terminate and how to apply specific termination
conditions, so that simulations will automatically end when these conditions are ful-
filled. Furthermore, this chapter also includes a guide to implementing new termination
conditions.
A simulation in NeSSi2 has two control options: the number of replications and the
number of time units of a replication. Accordingly, there are two types of termination
conditions: the simulation termination conditions and the replication termination con-
ditions. In the simulation conditions the number of replications of a simulation can be
defined. The replication conditions define the number of time units of a replication.
Figure 7.1.: The Simulation configuration page in the simulation editor
Figure 7.1 illustrates the simulation configuration page, in which the termination condi-
tions for a simulation can be set. If a termination condition field is selected, the config-
uration parameters of the condition will be displayed in right side of the page. Similar
as with applications, these configuration options can be defined using annotations in the
conditions source code. The valid annotations for options are the same as the ones for
the applications. See chapter 9 for a list of the valid annotations.
In the following two sections, it will be demonstrated how a new condition can be im-
plemented using an existing example. The example implementation for the simulation
condition is the class FixedRunsSimulation and for the replication condition it is
the FixedTicksReplication class.
45
7.1. Simulation Termination Condition

F igure 7.2 demonstrates an example implementation of a simulation termination condi-
tion. This example is already included in NeSSi2 . This condition terminates a simulation
after a defined number of replications.
1 package de.dailab.nessi.api.termination.impl;
2
3 import de.dailab.nessi.api.applications.annotations.Description;
4 import de.dailab.nessi.api.applications.annotations.IntegerOption;
5 import de.dailab.nessi.api.termination.AbstractSimulationTerminationCondition;
6
7 @Description("This termination condition simulates a fixed number of replications.")
8 public class FixedRunsSimulation
9 extends AbstractSimulationTerminationCondition {
10
11 @IntegerOption("Number of Replications")
12 private int numberRep = 1;
13
14 private int currentReplication = 0;
15
16 private final static String NAME = "Fixed Number of Runs";
17
18 @Override
19 public void addReplicationTerminationResults(Object newValue) {
20 this.currentReplication++;
21 }
22
23 @Override
24 public boolean isSatisfied() {
25 if (this.currentReplication >= this.numberRep) {
26 return true;
27 }
28 return false;
29 }
30
31 public static String getName() {
32 return NAME;
33 }
34
35 }
Figure 7.2.: The example implementation of a simulation termination condition
This class extends the AbstractSimulationTerminationCondition class

and must overwrite the following two methods:
addReplicationTerminationResults(Object newValue) is called
after a replication is simulated. The newValue object is the result of the used
replication termination condition. When simulating multiple scenarios, this method
will not be called before all replication conditions of the scenarios are fulfilled.
isSatisfied() will be called after the previous method was called. The
method must return true if no additional replications must be simulated. This
will cause for the simulation to terminate.
The method getName() is used to specify an alternative name of the class, which will
represent the class in the user interface. If this method does not exist in the class, the
simple class name will be used in the user interface. In this example, the simple name
is FixedRunsSimulation.
46
7.2. Replication Termination Condition
7.2. Replication Termination Condition

Figure 7.3 illustrates an example implementation of a replication termination condition.
1 package de.dailab.nessi.api.termination.impl;
2
3 import java.util.LinkedList;
4 import java.util.Map;
5
6 import de.dailab.nessi.api.applications.annotations.Description;
7 import de.dailab.nessi.api.applications.annotations.IntegerOption;
8 import de.dailab.nessi.api.termination.AbstractReplicationTerminationCondition;
9
10 @Description("This termination condition allows a fixed simulation length "
11 + "with the defined number of ticks.")
12 public class FixedTicksReplication
13 extends AbstractReplicationTerminationCondition {
14
15 private static final String NAME = "Fixed Run Length";
16 @IntegerOption("Number of Ticks")
17 private int numberTicks = 1000;
18
19 @Override
20 public boolean isSatisfied(Map<String, LinkedList<Object>> newValues, int tick) {
21 if (tick >= this.numberTicks) {
22 return true;
23 }
24 return false;
25 }
26
27 @Override
28 public Object getResult() {
29 return null;
30 }
31
32 @Override
33 public void reset() {
34 return;
35 }
36
37 public static String getName() {
38 return NAME;
39 }
40
41 }
Figure 7.3.: The example implementation of a replication termination condition
This termination condition is already included in NeSSi2 . This conditions terminates a

replication after a defined number of time units (also called ticks) are simulated. This
class extends the AbstractReplicationTerminationCondition class and it
must overwrite the following three methods.
isSatisfied(Map<String, LinkedList<Object newValues, int
tick) is called after a time unit was simulated. The method must return true
if no additional time units must be simulated. This will cause for the replication
to terminate.
getResult() will be called after the replication was terminated. It can be used
to return the calculated result of the replication.
reset() will be called after the method getResult() and resets the condi-
tion to the initial state, so that a new replication can be simulated independent
47
from the previous replication.

The method getName() is used to specify an alternative name of the class, which will
represent the class in the user interface. If this method does not exist in the class, the
simple class name will be used in the user interface. In this example, the simple name
is FixedTicksReplication.
48
8. How to Create a Simulation: A Step
by Step Tutorial
This chapter contains a detailed description of how a simulation can be created and de-
ployed in the NeSSi2 User Interface. Figure 8.1 shows the steps necessary for creating
a simulation. Each step will be introduced in own section respectively. Note that this
chapter demonstrates only a simple example. More complicated procedures and config-
urations (e.g. node mappings) are described in separate chapters. Make sure that you
have successfully installed and configured NeSSi2 and its required components before
going through this tutorial.
Create Create Create

Start Create Profile
NeSSi Project Network Scenario
Create Run
End
Session Simulation
Figure 8.1.: Overall NeSSi2 workflow for creating and launching a simulation.
Note: A video tutorial of creating simulations

. can be found on the NeSSi2 home-
page.
8.1. Create NeSSi2 Project

As a first step a NeSSi2 project has to be created using the NeSSi2 project creation
wizard. This wizard can be accessed in two ways in the NeSSi2 GUI. One way is by
the following menu sequence: File New IP Network (Project). The other way is
by accessing the context menu in the NeSSi2 Project Explorer and selecting New IP
Network (Project).
By using any of the methods, the Project creation wizard will be displayed (see figure
8.2). In this dialog, a name has to be entered for the project.
By pressing "Finish" a project will be created, which can be viewed in the NeSSi2 Project
Explorer. A newly created project has some folders and a network file with the same
name as the project.
49
8. How to Create a Simulation: A Step by Step Tutorial
Figure 8.2.: The NeSSi2 Project Creation wizard.
The next step towards creating a simulation is creating content for the auto-generated
network, which is discussed in the following section.
8.2. Create Network

For adding content to the created network, double click on the network. This will cause
for the network to be opened in the Network Editor (see 4.2.8). The nodes and edges
of each network are grouped in subnets. Hence, the first step of creating a network
is defining some subnets for the network. The available subnet types are listed in the
palette located on the right side of the Network Editor (see figure 8.3). Via drag and drop
you can add the subnets to the network. The location of the subnets can be changed
anytime. For selecting a single network, choose the Select tool from the palette. For
simultaneous selection of multiple subnets, use the Marquee tool from the palette.
Figure 8.3.: Adding subnets to a network in the Network Editor
The names of the subnets will be automatically generated. You can change the name of
the subnet in the Properties view (see section 4.2.4), by changing the value of the field
Name.
50
8.3. Create Profile
Note that each added subnet will be listed in the Outline view located by default on the
right side of the Network Editing perspective. By selecting an element in the Outline,
the element will also be selected in the Network Editor and vice versa.
Note: You can open views by selecting Window Show View myView in the
main menu. Perspectives can be opened by . selecting Window Open Perspective
myPerspective in the main menu.
The next step after adding subnets to the network is to add content to the subnets. In
order to do so, double click on a subnet. This will cause for a new tab to be opened
in the Network Editor. Same as with the subnets, the palette will display a list of the
available nodes and edges. By dragging and dropping nodes, they will be added to the
network. For connecting nodes, you will have to select one of the links found in the
Connections part of the palette and than clicking on the nodes that you want to connect.
Figure 8.4 shows an example of how the contents of a subnet could look like.
Figure 8.4.: A simple network of nodes and edges in a subnet. Using the Connect to Subnet option
subnets can be connected to one another.
Naturally you will also want to connect the subnets to each other. In this case, you
will have to select an network element (usually the routers) and enter its context menu.
Select Connect to Subnet, then select the subnet you want to connect to (see Figure 8.4).
This will cause for the network device to appear in both subnets. By double clicking on
such a network elements, you can switch between its containing subnets.
Note: A device can be connected to several . subnets simultaneously.
After a network has been created, you can continue with adding dynamic behaviour to
the network nodes. This is described in the following section.
8.3. Create Profile

A profile is basically a container for a set of applications (see Section 4.1.4). A profile
can be created in two ways. One is by accessing the context menu in the NeSSi2 Project
51
Explorer and selecting New Profile. The other way is by the using the menu sequence
File New Profile in the main menu. This will open a dialog where a name has to
be entered for the profile. By pressing "Finish", the dialog will close and a file with the
.profile extension will be created in the Profiles folder of the project. Now, applications
may be added to the profile.
Figure 8.5.: The dialog containing a list of all available applications, divided into categories.
By pressing the Add... button in the newly created profile, a dialog containing a list of
the available applications will open. As illustrated in Figure 8.5, the applications are
sorted into categories. Note that an application may belong to several categories, so it
may appear in the list several times. The search field on top of the application list can
be used to filter applications according to their name. When selecting an application,
if available, a description of the application and its configurable parameters will appear
on the right side of the dialog. By pressing OK, the dialog will close and the selected
application will be added to the profile.
Figure 8.6.: The list of application that exist in a profile. The configuration parameters for each applica-
tion is shown on the right side of the editor.
In the profile editor, you can configure the application that you have added to the profile.
When clicking on an application name, the parameters will be become visible. Depend-
52
8.4. Create Scenario
ing on the application, different configuration parameter will be displayed (see Fig-
ure 8.6)
Once the profiles have been created, they need to be mapped into the network nodes.
This is done by creating scenarios, which will be explained in the following section.
8.4. Create Scenario

A scenario is the mapping of profiles onto the nodes of a specific network. Same as with
creating profiles, the Scenario Creation wizard may be accessed through NeSSi2 Project
Explorers context menu (New Scenario) or through the main menu (File New
Scenario). A name has to be entered for the scenario. In addition, a list of the networks
available in the project will be displayed, as illustrated in Figure 8.7 and one of these
networks has to be chosen as the network associated with this scenario.
Figure 8.7.: A list of the available networks will be displayed in the scenario creation wizard from which
one network maybe chosen to be associated with the scenario.
By pressing Finish, the Scenario Editor will open, and display the network that is asso-
ciated with the scenario.
Note: Only one network can be associate. with a scenario. For federated simula-
tions, you will have to define a scenario for each network.
Profiles can be added to the nodes in two ways. One is by manually selecting one or
multiple nodes in the Scenario editor and selecting Set Profiles from the nodes context
menu. This will open a dialog, where can add or remove profile to and from the selected
nodes (see Figure 8.8). By pressing the Add... button, another dialog will open, which
contains a list of all available profiles, from which the desired profiles may be chosen
by selecting the profiles name and pressing OK. Pressing Finish in the main dialog will
finalize the changes.
Another method of adding profiles is by using the Profile Deployment Wizard. This wiz-
ard can be accessed by selecting a scenario in the NeSSi2 Project Explorer and selecting
Deploy Profiles from its context menu. This wizard allows you to simultaneously de-
53
Figure 8.8.: Manually adding profiles to network nodes
ploy profiles to every node of the network and/or to filter specific nodes and then add
profiles to them. Figure 8.9 illustrates how this wizard looks like.
Figure 8.9.: Adding profiles to network nodes using the Profile Deployment Wizard. The tab-area
(highlighted in red) can be double clicked to add a filter to the nodes.
By double clicking on the tab-area, which is highlighted by the red frame, a dialog will
open where you can add a string for filtering the respective nodes. In this example, this
string is "client", which filters all the nodes that contain this string as a part of their
name. By pressing OK, a new tab with the title "client" is added to the tabs. By default
a tab called All Devices is included in this wizard, which contains all the nodes found in
a network. By pressing the Add... button, you may select the profiles you would like to
deploy to the nodes from the list of all available profiles. Removing profiles is done by
selecting a profile and pressing the remove button.
54
8.5. Create Simulation
Note: As a general rule, a profile can only

. be deployed on the same node once.
The same application however can be included in a profile several times.
The Distribution Behaviour combo box offers additional deployment options. There are
three such options available:
Append Profiles: This options simply adds the profiles to the selected nodes.
However, this method avoids duplicate profiles, so that profiles will not be added
twice if the node already contains the profile that is to be deployed.
Replace Existing Profiles: By using this option, all of the available profiles on
the selected nodes will be removed and replaces by the new ones.
Keep Existing Profiles: With this option, the profiles will only be deployed on
nodes that have no profiles assigned to them yet. Nodes that already contain
profiles will not be effected by this deployment method.
In addition, a distribution percentage can be selected for each node type in the second
column of the profiles table. As can be seen in Figure 8.9, in this example the percentage
of the Client.profile is set to 60%. This means that when this profile is deployed on a
network with 10 client nodes, only 6 of them will actually have this profile deployed.
This feature can be used to randomly distribute profiles on a specific number of nodes.
By pressing the Finish button, the profiles will be deployed. In the next and final step of
the simulation creation process, the simulation object will be created. This is described
in the following section.
8.5. Create Simulation

A simulation specifies the scenarios that are to be simulated and the duration of a simu-
lation. Analogous to the creation of profiles and scenarios, a simulation can be created
in NeSSi2 Project Explorer by selecting New Session or by selecting File New
Session the main menu.
Figure 8.10.: The Simulation Configuration Tab in the Simulation Editor.
Simulation files are displayed in the Simulation Editor. This Editor consists of two tabs:
Simulation Configuration and Network Configuration.
55
In the Simulation Configuration tab (see Figure 8.10), the options for the simulation can
be configured. In the top left of the editor, in the "Simulation Termination" section, the
number of replications (a.k.a runs) can be specified. By pressing the select button, you
can chose a termination condition from the list of the available ones. Once a termination
condition has been chosen, its configuration parameters will appear on the right side of
the dialog. In this example, the options for the "Fixed Number of Runs" is an integer
that explicitly specifies the number of times that the scenarios will be simulated. Note
that for this example we will only consider the termination condition with a fixed length.
For the variable termination conditions see Chapter 7.
In the "Replication Termination" part, scenarios can be added to the simulations. In
addition, a replication termination condition must also be specified for each scenario in-
dividually. Same as with the "Simulation Termination", the options for the termination
condition will be displayed in the right side of the Simulation Editor. In this exam-
ple The only parameter that can be configured for the "Fixed Run Length" termination
condition, is the number of ticks, which specifies the duration of a replication.
Note: Only one scenario corresponding to a specific network can be added to a
single simulation. This property prohibits. the multiple usage of the a scenario in a
simulation. Use additional simulations, if you want to simulate the same network
with different scenarios.
In the Recording Configuration, the path to the XML containing the recording con-
figurations can be specified. By default, the path is set to Recording/Examples/de-
fault_recorder.xml. In this example it is not required that this option is changed.
Figure 8.11.: The Network Configuration Tab in the Simulation Editor.
The Network Configuration tab (see Figure 8.11) offers additional options for the net-
works behaviour, in particular node mappings in case of federated simulation. Node
mappings are explained in detail in Chapter 6 and are not included in this chapter.
The Simulation Handler defines the general behaviour of a specific network type by
defining the abstraction level. The handler also controls at which point the applications
will be loaded and how the different components interact with each other. The Network
Meta Information object, which corresponds to the Simulation Handler, provides the
related necessary information, such as the network name, scenario name, etc. You will
not need to change these two configuration fields in order to run NeSSi2 simulations.
56
8.6. Run Simulation
In the Description field, you have the option of adding a textual description to the sim-
ulation.
After the simulation has been successfully created, it can be executed as is shown in the
next section.
8.6. Run Simulation

In order for the simulation to be executed successfully, make sure that the NeSSi2 Back-
end is running and that the database is configured correctly.
For executing a simulation, select the simulation file in the NeSSi2 Project Explorer and
select the "Launch Simulation" action from the simulations context menu. This will
send the simulation to the NeSSi2 Backend for execution. Outputs from the NeSSi2
Backend can be viewed in the console where the backend is running. In the GUI, a dia-
log will appear, which proposes switching to the Simulation Perspective. By confirming,
the Simulation Perspective will open, where the results of the simulation execution can
be viewed.
Figure 8.12.: Viewing the results of the simulation execution in the Simulation Perspective.
You will have to select the executed simulation replication from the list displayed in
the Recorded Simulations view, which is located by default on the left side of the Sim-
ulation perspective (see Figure 8.12). This will cause for an editor to open where the
network may be viewed. By using the play buttons in the icons bar the simulation can
be reviewed. The speed of the simulation execution can be adjusted using the playback
buttons. When a packet is sent through a network link, the link will become green. De-
pending on the amount of the packets sent, the link my become wider. When a network
57
device or link is selected, the values logged for that network element can be viewed in
the Statistics view.
Note: depending on the number of nodes and the length of the simulation, the
time required for the polling of simulation. results form the database may vary
heavily.
8.7. Evaluating Simulations

NeSSi2 allows the simulation of various security scenarios. Additionally, there is a huge
diversity in network security evaluation metrics. Here, the developer of a detection algo-
rithm respectively of a special security infrastructure set-up may not only be interested
in detection rates, but also in the economical assessment of a scenario. Hence, the gath-
ering of simulation results and the evaluation needs to be very flexible. Here, we apply
an event-based approach, the so-called Meta Attack Events. Already included events
incorporate dropped packets, infected flows, compromised machines, unavailable ser-
vices etc. Those events are stored in the database at runtime. Events belonging to the
same attack refer to a global identifier to differentiate between the impacts of different
attacks. The database associates those events with a time stamp in the simulation as well
as a device and/or transmitted packets related to that specific event.
The main evaluation component in NeSSi2 is the statistics view which uses JFreeChart1
to visualize recorded simulation events. These charts are flexible and can be configured
in many ways. Series of recorded events can be shown as an area-, bar- or line charts,
moreover the series can be stacked and/or cumulated. Furhtermore individual series can
be shown or blinded out according to the needs of the user.
On the other hand, there is the replay mechanism for recorded simulations. This allows
the user to interactively review the entire simulation, as it visualizes, per tick, every
component of the topology (i.e. nodes or edges) according to the events that happened
during the simulation. The replay mechanism can either run straight forward where it
visualizes each tick of the simulation continuously or it can visualize a single tick of
interest.
8.7.1. Preparing Analyses with Third Party Tools
Sometimes, the built-in chart view does not suffice for visualizing the data of interest
in an adequate way. When data should be rendered with other tools like gnuplot or
spreadsheet programs, the data must be exported to csv files (comma separated value),
which can then be used to further process or visualize the results.
Data export can be realized with SELECT . . . INTO OUTFILE statements2 .
The entity relationship diagram in Figure C.1 shows how the tables are logically con-
nected with each other.
1 http://www.jfree.org/jfreechart/
2 See http://dev.mysql.com/doc/refman/5.5/en/select.html for more details
58
8.7. Evaluating Simulations
Hence, assuming nessi2Example as the name of the database schema, one

could export all datasets for the events Packets Sent of all scenarios belonging
to the run with the id 1 with the following SQL statement:
SELECT FROM n e s s i 2 . m e a s u r e i n t mi
LEFT JOIN n e s s i 2 . e v e n t t y p e e t ON e t . i d =mi . e.v e n t T y p e _ i d
LEFT JOIN n e s s i 2 . s c e n a r i o r u n s ON s . i d =mi . s c e n a r i o R u n I d
LEFT JOIN n e s s i 2 . s i m u l a t i o n r u n sim ON sim . i d = s . s i m u l a t i o n R u n I d
WHERE sim . s i m u l a t i o n I d =63346 AND sim . runNo =1 AND s . s c e n a r i o N o =0
AND e t . l a b e l LIKE " P a c k e t s S e n t "
INTO OUTFILE "D : / e x p o r t . c s v " ;
Note: This statement can be adapted to most needs by changing the name of the
database schema, the identifier of the run,. the label of the event type, as well as
the filename accordingly.
Note: Observe that slashes are used as the

. path separator even on Windows sys-
tems since backslashes needed to be escaped!
59
9. Extending NeSSi2: Application
Tutorial
In this NeSSi2 tutorial we develop a server application that answers echo requests from
various client applications distributed to sub-networks within in a larger network.
The goal of this tutorial is to introduce the basic steps required to extend NeSSi2 with
additional applications that are not provided by NeSSi2 itself. This tutorial will also
demonstrate how to record custom simulation events to a database.
This tutorial is structured as follows. Section one describes setting up a development
environment using Maven1 and Eclipse2 . The second section provides an example of
how to implement a client application that sends requests to a server. In the third section
an example application will be implemented which is able to receive requests from
clients and answers them. Finally, the fifth section describes how to create and run a
simulation with the developed client and server applications.
This tutorial assumes a basic knowledge of Java, Maven and Eclipse. Please refer to the
documentation of those products for further information.
1 http://maven.apache.org
2 http://www.eclipse.org
61
9. Extending NeSSi2 : Application Tutorial
9.1. Setting up your Development Environment

To develop a NeSSi2 application you need at least Java JDK 1.7. Furthermore, for this
tutorial we will use Maven 3.0.5 and Eclipse 3.8 in an edition, which includes the Plug-
in Development Environment (PDE) e.g. Eclipse SDK or Eclipse Classic 3 . If you do
not have those versions yet, please download and install them.
9.1.1. Setting up the Target Platform
In order to enable the dependency resolution of the project, you will need to set the
target platform for Eclipse using the following steps:
1. Download the NeSSi2 target definition form the following link: http://sourceforge.
net/projects/nessi2/files/nessi2/2.1.1-beta/nessi.target-2.
1.1.target/download
2. Open Eclipse and open the target definition: File Open... and select the down-
loaded .target file. This will open the target definition in an editor.
3. Select "Set as Target Platform" from the upper right corner of the editor (see
figure 9.1). This will load the target platform and may take a few minutes.
Figure 9.1.: Setting the target platform definition for developing NeSSi2 applications
9.1.2. Creating a NeSSi2 Plug-in Project
NeSSi2 application projects are Eclipse Plug-in projects. In order to create a new project,
you can simply use the example project found on sorceforge 4 as a template, or you can
follow the next steps to create a new project from scratch.
3 In http://www.eclipse.org/downloads/compare.php an overview of all Eclipse edi-
tions and their feature is provided.
4 http://sourceforge.net/projects/nessi2/files/nessi2/2.1.1-beta/
example-NeSSi2-Application.zip/download
62
9.1. Setting up your Development Environment
For creating a new project, select File New Project.... From the category Plug-in
Development choose Plug-in Project and follow the project creation wizard for config-
uring and creating a new project.
Since the NeSSi2 applications are built using Maven, you will need to create a POM
file for your project. Right click on your project and select New File. Name the file
pom.xml. Copy the contents of Figure 9.3 to your pom.xml. You should however change
the artifactId, groupId, version and the optional description tags. These tags are used as
identifier for your project. Please refer the Maven manual for further information about
each tag.
In order to develop NeSSi2 applications, you will need to add a NeSSi2 plug-in as a
dependency to your project. To this end, open the MANIFEST.MF file from the META-
INF folder of your project. Delete any existing dependencies. Switch to the Dependcies
Tab. Press the Add... button in the Required Plug-ins section (see figure 9.2). Search for
nessi.ip.handler and add it to the dependencies list. This may cause errors in the auto
generated test classes. Since those classes are not required, you can delete them. Now
you are ready to develop your own applications.
Figure 9.2.: Adding Dependencies to an Application Development Project
63
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd">
<modelVersion>4.0.0</modelVersion>


<groupId>org.example</groupId>
<artifactId>test.foo.application</artifactId>
<version>1.33.7</version>
<description>Some foo applications</description>
<packaging>eclipse-plugin</packaging>
<name>${project.artifactId}</name>
<properties>
<tycho-version>0.17.0</tycho-version>
</properties>
<repositories>
<repository>
<id>dai-open</id>
<url>http://repositories.dai-labor.de/extern/content/repositories/
dai-open/</url>
</repository>
<repository>
<id>dai-open-p2</id>
<url>http://repositories.dai-labor.de/extern/content/unzip/p2-releases/
de/dailab/nessi/nessi.repository/2.1.1/nessi.repository-2.1.1.zip-unzip</url>
<layout>p2</layout>
</repository>
</repositories>
<build>
<plugins>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>tycho-maven-plugin</artifactId>
<version>${tycho-version}</version>
<extensions>true</extensions>
</plugin>
<plugin>
<groupId>org.eclipse.tycho</groupId>
<artifactId>target-platform-configuration</artifactId>
<version>${tycho-version}</version>
<configuration>
<target>
<artifact>
<groupId>de.dailab.acs</groupId>
<artifactId>nessi.target</artifactId>
<version>2.1.1</version>
</artifact>
</target>
</configuration>
</plugin>
</plugins>
</build>
</project>
Figure 9.3.: Example pom.xml for a NeSSi2 plug-in project
64
9.2. Creating a NeSSi2 Application

A NeSSi2 application is basically a class that extends the class Application. In this
tutorial we will demonstrate how to implement applications that produce Internet Proto-
col (IP) based traffic. Therefore we will use the class AbstractIPApplication, so
that it already contains the necessary logic for sending and receiving IP-based packets.
9.2.1. First Steps of Creating an Application

A basic application, which contains no functionality is illustrated in figure 9.4.
1 package de.dailab.nessi.tutorial;
2
3 import de.dailab.nessi.core.api.annotations.Category;
4 import de.dailab.nessi.core.api.annotations.Name;
5 import de.dailab.nessi.core.api.events.Event;
6 import de.dailab.nessi.ip.api.applications.CategoryLabels;
7 import de.dailab.nessi.ip.api.protocols.Packet;
8 import de.dailab.nessi.ip.handler.AbstractIPApplication;
9
10 @Name(value = "Example Application")
11 @Category(values = { CategoryLabels.UNCATEGORIZED })
12 @Description("A basic example application")
13 public class ExampleApplication
14 extends AbstractIPApplication {
15
16 @IntegerField("An example integer value")
17 int exampleInt = 0;
18
19 @Override
20 public boolean start() {
21 return super.start();
22 }
23
24 public void handleIncomingPacket(Packet packet) {
25 super.handleIncomingPacket(packet);
26 }
27
28 @Override
29 public void handleEvent(Event e) {
30 super.handleEvent(e);
31 }
32 }
Figure 9.4.: Basic NeSSi2 Application for the IP-Model
This application overwrites the three most important methods in the NeSSi2 application
context:
start() will be called at the beginning of a simulation so that the application
can initialize objects and complete necessary tasks, such as registering ports or
events.
handleEvent(Event event) will be called during a simulation when a
previously scheduled event occurs and needs to be processed.
handleIncomingPacket(Packet packet) will be invoked when another
application has sent a packet to this application (works only if the port has been
registered before).
65
Applications sending packets in certain time intervals would normally register the first
event within the start method and re-register the event in the handleEvent method
with another tick value. This method can also be used to send packets. In contrast, ap-
plications that receive packets (e.g. Servers) would rather register a port during the ini-
tialization, since the port will be used to receive packets. If no port has been registered,
than the application will not be able to receive any packets at all.
In the application shown in figure 9.4, there is an integer variable defined which is
annotated with IntegerField. This is an example of how an application can be
configured using parameters via the NeSSi2 User Interface. The following annotations
can be used to configure a field of an application:
BooleanField for an underlying boolean-field
IntegerField for an underlying int-field
StringField for an underlying String-field
DoubleField for an underlying Double-field
EnumField for an underlying int-field. This annotation is used to select the index
of the selected element. An example is illustrated in figure 9.5.
1 // index constants for the labels in the enumeration

2 static final int INCOMING = 0, OUTGOING = 1;
3
4 @EnumField(name = "Flag", values = { "incoming", "outgoing" })
5 @Description("A flag that indicates the message type")
6 int flag;
7
8 @Override
10 switch (flag) {
11 case INCOMING:
12 // do something
13 case OUTGOING:
14 // do something else
15 }
16 }
Figure 9.5.: Example of the Enum-Annotation
It is important however, that the annotated field is not declared as static, otherwise
the different application instances will modify the same static variable, which may cause
in information loss and therefore the faulty behaviour of the application.
Note: Neither the visibility of annotated fields
. nor the existence of getters and
2
setters matter in NeSSi context.
There are also a number of annotations, that can be used to attach information to the
application. These annotations are listed below:
@Application: By using the this annotation in the ExampleApplication
class, a user-friendly synonym for the class name can be defined, which will be
displayed in the UI. This synonym is defined in the variable value of the applica-
tion annotation.
@Category: This annotation can be used to assign a number of categories to the
application. This expression will be used to sort the application in one or more
66
categories in the dialog for adding applications to a profile (see figure 9.6). The
category names are predefined in the Category class. If there are no categories
assigned to an application, the application will automatically have the category
Uncategorized.
@Description: In this annotation field, a description about the application and its
functionality can be added. This description can be viewed when adding applica-
tions to a profile (see figure 9.6).
Note: Although it is not needed to add the Application-annotation, it is rec-
ommended to do so, otherwise the application
. itself will be labeled as Default
Application in the user interface in addition to having the category Uncatego-
rized.
Figure 9.6.: The annotation fields are used in the NeSSi2 User Interface to display the application
proeprly
67
9.2.2. Echo Applications
For the scenario described in chapter 9, we need a client application that sends echo
requests in certain intervals and receives replies from the server(s), and a server appli-
cation that listens on a UDP port for echo requests and replies to them.
In the following subsections, we will go through these applications, starting with the
client application.
The Echo Client Application
At first, we will create a skeleton containing the methods that need to be overriden. We
will fill these methods with content one after the other. The skeleton is illustrated in
figure 9.7.
2
3 import org.apache.log4j.Logger;
4
6 import de.dailab.nessi.core.api.annotations.Description;
7 import de.dailab.nessi.core.api.annotations.IntegerField;
9 import de.dailab.nessi.core.api.events.Event;
11 import de.dailab.nessi.ip.api.protocols.Packet;
13
14 @Name(value = "Echo Client")
15 @Category(values = { CategoryLabels.BASIC_COMMUNICATION, CategoryLabels.CLIENT })
16 public class EchoClient
18
19 static final Logger logger = Logger.getLogger(EchoClient.class);
20
21 @IntegerField("Echo Server Port")
22 @Description("Echo Server Port number")
23 private int echoServerPort = 7;
24
25 @IntegerField("Client Port")
26 @Description("Port for the Echo Client")
27 private int echoClientPort = 8;
28
29 @Override
32 }
33
34 @Override
35 public void handleEvent(Event event) {}
36 }
Figure 9.7.: Skeleton for the Echo Client application
This application will show up as Echo Client in the NeSSi2 GUI and will be assigned
to the categories Basic Communication and Client, due to the defined values in the
Application-annotation in line 15.
We have also defined a port number, which will be used to receive packets by the ap-
plication (line 27), and another port to address the echo servers (line 23). Note that
68
these values have also been annotated, in order to make them configurable in the GUI.
The assigned values are only preset value, which means that they will be only used
if they are not otherwise specified in the GUI (see section 4.2). We also added the
@Description annotation, whose contents will show up as tooltips, when the mouse
cursor is hovered over the corresponding label in the Profile Editor.
Since we want our Application to take a specific action after a number of time units have
passed in the simulation, we need to override the handleEvent method. This method
will however never be triggered if we havent defined an initial event before. Therefore,
we need to schedule the initial event at the beginning of the simulation. To this end, we
have to override the start method.
1 @Override
3 getLayerHandler().getTransportLayer().registerUDPPort(echoClientPort, this);
4 getLayerHandler().addEvent(new TickedEvent(this, 10));
6 }
Figure 9.8.: The start method of the Echo Client application
The implementation of the start method is depicted in figure 9.8. In line 3, we register
the UDP port so that the application can receive packets on this port. The important
line for scheduling events, is line 4. Here, an initial event is created and scheduled
for execution in tick 10. Note that the event handling is automatically done by the layer
handler. Events for later ticks are scheduled when the actual event is handled. If we want
to execute only a certain number of events in specific time points of the simulation, we
could schedule them all in the start() method. However, since we want the client
application to keep on sending packets until the simulation is finished (and we do not
know when this will be), the first approach is more appropriate.
Finally, we need to return a boolean value, indicating whether the starting of the appli-
cation was successful or not. We simply pass the return value from the super class (line
5).
In order to make sure that a packet will be send to a server when the initial event is
triggered, we need to add some code to the handleEvent method, which is described
in the following subsection.
Event Handling Method
Figure 9.9 shows an implementation that sends echo requests to a random echo server
every 10th tick and records this event along with the tick number. This recording (lines
19 - 24) will be described in detail in the Event Recording section of this chapter.
First, we check whether the event that we received is useful for us or not. Since we only
understand TickedEvents, we silently return in cases where other events have been
passed (lines 3 - 5).
Next, we get the meta information object about the network from the layer handler
(line 8). The meta information object provides the functionality to retrieve a random IP
69
1 @Override
2 public void handleEvent(Event event) {
3 if (!(event instanceof TickedEvent)) {
4 return;
5 }
6
7 TickedEvent tickedEvent = (TickedEvent) event;
8 IIPNetworkMetaInf metaInf = getLayerHandler().getNetworkMetaInf();
9 IPv4Address addr = metaInf.getRandomIPv4AddressForApplication(EchoServer.class);
10 if (addr == null) {
11 Logger.getLogger(getClass()).error("No EchoServer was deployed!");
12 return;
13 }
14
15 byte[] message = "Hello World".getBytes();
16 getLayerHandler().getTransportLayer().sendUDPPacket(echoClientPort,
17 echoServerPort, addr, message);
18
19 int tick = getLayerHandler().getCurrentTick();
20 Node device = getLayerHandler().getDevice();
21 HbmRecordingInt eventRec = EventFactory.getIntegerEvent(tick, device,
22 EventLabels.ECHO_REQ_SENT, 1);
23 IRecorder recorder = getRecorder(EventLabels.class);
24 recorder.record(eventRec);
25
26 tickedEvent.setTick(tickedEvent.getTick() + 10);
27 getLayerHandler().addEvent(tickedEvent);
28 }
Figure 9.9.: handleEvent method of the Echo Client application
running a certain application. So we pick one of the (probably many) echo servers in
the network (line 9).
We create a byte array with the message, that is to be sent to the server and pass it to the
transport layer which then handles the packet transmission (lines 15 - 17). Source and
destination port numbers as well as the destination address are passed too.
Finally, we need to make sure, that the application keeps sending echo requests by
scheduling another event. We take the event that was passed to the handleEvent
method (line 7), set the tick to the new value and put it back to the schedule (line 26 and
27).
The Echo Server Application
Again, we will present a skeleton with the methods we need to override in the first
step and then fill these methods with code one after another. Let us have a look at the
skeleton first.
The skeleton of the class server application looks slightly different than the client skele-
ton (see figure 9.10).
Again, we have defined a port number which the server listens for incoming messages
(line 17). This value is made configurable via the GUI again by annotating it appropri-
ately. However, we do not want to schedule any events. Instead, we want to react on
received packets. Therefore we need to implement the handleIncomingPacket
method this time.
To initialize the application and to enable the receiving of packets, we need to implement
70
the start method. In the start method, which is shown in figure 9.11, we get the
transport layer object from the layer handler and register our application to retrieve
packets on the configured UDP port (line 3). Note that the Echo Client also must
register its UDP port (see figure 9.8 line 3) if the client wants to receive the response
from the server.
1
3
5 import de.dailab.nessi.core.api.annotations.Description;
6 import de.dailab.nessi.core.api.annotations.IntegerField;
10
11 @Name(value = "Echo Server")
12 @Category(values = { CategoryLabels.BASIC_COMMUNICATION, CategoryLabels.SERVER })
13 public class EchoServer
15
16 @IntegerField("Server Port")
17 @Description("Port for the Echo Server")
18 private int echoServerPort = 7;
19
20 @Override
23 }
24
25 @Override
26 public void handleIncomingPacket(Packet packet) {}
27 }
Figure 9.10.: Skeleton for the Echo Server application
Then we simply pass the return value from the super class again to indicate success or
failure of the application start (line 4). We are now able to receive Packets. The logic
for receiving and processing packets is described in following subsection.
1 @Override
3 getLayerHandler().getTransportLayer().registerUDPPort(echoServerPort, this);
5 }
Figure 9.11.: The start method of the Echo Server application
Packet Handling Method
Figure 9.12 shows an implementation that receives echo requests, reads the contents of
the message, reverses the order and sends a reply with this modified message as content
back to the sender.
First, we extract the IPv4 header and UDP header from the packet (line 3 and 4). Both
headers should not be null (lines 6 - 8). The echo requests are sent as UDP packets,
so there should be a UDP header and because a UDP packet is encapsulated by an IP
71
packet, there should be an IPv4 header (since IPv6 is not supported, yet). Then we let
the helper method sendEcho assemble the content of the reply (line 10) and send it
back to the original sender. The code of the helper method is shown in figure 9.13.
1 @Override
3 IPv4Header ipHeader = packet.findHeader(IPv4Header.class);
4 UDPHeader udpHeader = packet.findHeader(UDPHeader.class);
5
6 if (ipHeader == null || udpHeader == null) {
7 return;
8 }
9
10 sendEcho(packet.getPayload(), ipHeader.getSourceAddress(),
11 udpHeader.getSourcePort());
12
13 int tick = getLayerHandler().getCurrentTick();
14 Node device = getLayerHandler().getDevice();
15 getRecorder(EventLabels.class).record(EventFactory.getIntegerEvent(tick, device,
16 EventLabels.ECHO_REPLY_SENT, 1));
17 }
Figure 9.12.: The handleIncomingPacket method of the Echo Server application
In the sendEcho method, after the content of the reply packet has been assembled
(lines 2 - 8), the transport layer is ordered to send a packet with this content back to the
sender (line 9 and 10). The source and destination ports and the address of the original
sender are passed as well.
1 private void sendEcho(final byte[] msg, final IPv4Address addr, final int port) {
2 String answer;
3 if (msg == null) {
4 answer = "";
5 } else {
6 StringBuilder builder = new StringBuilder(new String(msg));
7 answer = builder.reverse().toString();
8 }
9 ITransportLayer transportLayer = getLayerHandler().getTransportLayer();
10 transportLayer.sendUDPPacket(echoServerPort, port, addr, answer.getBytes());
11 }
Figure 9.13.: The helper method sendEcho of the Echo Server application
Finally we will take a look on how the Echo Client and Server can record events to the
database, so that events can be visualized and analyzed with NeSSi2 .
9.2.3. Event Recording
NeSSi2 offers a flexible way of configuring events for recording to database. The first
step is to decide what we want to record. For this example we want to record the
following:
1. The number of packets transmitted over a link
2. The number of echo requests sent by an Echo Client
3. The number of echo replies sent by an Echo Server
72
The first event is easy to record, because NeSSi2 offers out of the box support for record-
ing this type of event. For the other two we needed to write an event type class in pre-
vious versions of NeSSi2 . Although it is still possible to do so, we strongly recommend
to use the new EventFactory for event creation which encapsulates the creation of
these event types. So instead of creating such an event type class, we create a class that
contains the labels for the events and let the EventFactory do the rest for us. The
labels provide human readable information about the event type. So for this example,
we create a class file with the following content:
2
3 public final class EventLabels {
4
5 public static final String ECHO_REQ_SENT = "Echo Request sent successfully";
6 public static final String ECHO_REPLY_SENT = "Echo Reply sent successfully";
7
8 }
9 }
Figure 9.14.: Constants for the Event Recording
In the next step we need to identify the locations in the code where we want to record
the other two events (Remember: The first event type is supported out of the box).
The ECHO_REQ_SENT event would be best recorded after the packet has been sent
in the handleEvent method of the EchoClient. For the actual recording we need a
recorder which can be retrieved by calling either getRecorder(String) or
getDefaultRecorder(). The recorder provides the method record(Object)
which is quite self-explanatory. Whilst in getRecorder(String), a name for
which the recorder should be retrieved must be specified, getDefaultRecorder()
retrieves the recorder for the name of this applications class. The name of the class
that we created before for the constants should be specified when retrieving a recorder
instance. Because this way, it is possible to enable or disable recording of certain groups
of events (one group per constants class) by modifying the recording configuration.
The usage of non-default recorders is encouraged, especially if different types of events
exist and recording should be turned on or off individually for groups of them. However,
in simple cases where only one constants class is used, the default recorder might be
sufficient as long as the constants are not shared with other applications.
In lines 19 24 from figure 9.9, we get the device, on which the application is installed
(line 20), as well as the current tick (line 19) and create an event object for recording
an ECHO_REQ_SENT event for this device at this certain tick (line 21 and 22). The
number of requests sent is 1. By using integer values rather than events without any
value, we are able to use aggregate functions in the chart of NeSSi2 s Statistics View
after the simulation has been executed. E.g. we could specify to aggregate values for a
certain number of ticks or we could view the values in a cumulative fashion to see the
total number of echo requests that have been sent until the beginning of each tick.
After retrieving the correct recorder for this type of event in line 23, the event object is
passed to the recorder that in turn writes the event to the database in line 24.
73
Before we are able to start a simulation that records the identified events, we have to
check the configuration of the log4j framework. In the default file, which is located in
Recording/Examples/default_recorder of any NeSSi2 project, the DBAppender is set
active for the whole recorder hierarchy (in log4j referred to as logger hierarchy). But
if you customized the configuration, you need to make sure that the DBAppender is
active for the constants class, e.g. by adding the following code fragment:
<logger name="de.dailab.nessi.tutorial.EventLabels"
additivity="false">
</logger>
Figure 9.15.: Recorder configuration for recording the echo example events
Make sure the DBAppender is configured within the file and refers to the class
de.dailab.nessi.recording.db.appender.DBAppender.
Similarly, we add recording to the echo server application, just after a reply has been
sent which can be seen in figure 9.12 lines 13 16.
9.2.4. Deployment of Applications

After You have finished developing your applications you need to deploy them to NeSSi2 .
This is done by the following steps:
1. Run mvn clean install in the projects folder
2. Change into the target-directory
3. Copy the generated .jar-file into the applications folder located in the directory
where you installed the NeSSi2 User Interface
4. Copy the generated .jar-file into the applications folder located in the directory
where you installed the Simulation Environment
5. Restart the Simulation Environment and NeSSi2 User Interface
After these steps you should be able to create a simulation using your applications.
74
A. Recommended Readings
A.1. Simulation Modeling and Analysis

Averill M. Law: Simulation Modeling & Analysis [Law, 2007]
Stewart Robinson: Simulation The Practice of Model Development and Use [Robinson, 2004]
75
B. Workflows
This chapter presents a short overview of common workflows in work with NeSSi2 , in
particular with the NeSSi2 User Interface. Chapter 4 will cover specific aspects of the
user interface in more detail.
B.1. Create and Start a Simulation

If you start from the beginning, the steps in figure B.1 are required to create and start a
simple simulation. Each of the steps will be detailed in following sections.
Create Create Create

Start Create Profile
NeSSi Project Network Scenario
Create Run
End
Session Simulation
Figure B.1.: Overall workflow of creating and executing a simulation in NeSSi2
B.2. Create a NeSSi2 Project

First of all you need to create one (or more) NeSSi2 project(s). Figure B.2 depicts the
required steps in detail.
Select File Select NeSSi Enter the name for

Start New Other Project lying the project and End
from the menu under NeSSi2 confirm with OK
Figure B.2.: The workflow of creating a NeSSi2 project
B.3. Open NeSSi2 Explorer

The NeSSi2 Explorer view may be opened in several ways. It is either opened directly
via the Show View dialog or by switching to one of the appropriate perspectives. The
77
B. Workflows
diagram in figure B.3 depicts this a little bit clearer.
Choose Network
Editor
Choose Window Open

Perspective Other
Choose Network
Editor
Start End
Choose NeSSi
Choose Window Show
Explorer under
View Other
NeSSi2
Figure B.3.: The workflow of opening the NeSSi2 explorer
B.4. Create a Simple Network

After creating NeSSi2 project, you can create a network. Figure B.4 shows the required
steps.
Open NeSSi Create NeSSi

Explorer Project
Expand project
Click into NeSSi
Is the NeSSi Does a NeSSi node and right
Start Explorer to set
Explorer visible? Project exist? click on
focus
Networks
Enter a name for Select New Place an Access

Select New
Right click the network and Access Network Network into the
New Network
Network confirm with Next from the palette of blank area of the
File
and Finish the opening view same view
Choose Select of Select New

Select File Save
the palette and Place routers, Connection and
from the menu or
double click the servers and clients connect a device with End
press CTRL+S to save
Access Networks in the same way the router by clicking
the changes
icon to open it on both of them
Figure B.4.: The workfolow of creating a simple network in NeSSi2
B.5. Create a Profile

Profiles contain a collection of applications that may be deployed together, e.g. to a
device. Figure B.5 shows how a profile is created.
78
B.6. Create a Scenario
Open NeSSi
Explorer
Is the NeSSi Expand the project Right click on Select Edit

Start
Explorer visible? node Profiles Profiles
Select the
Enter a name and
appropriate After clicking on
Enter a name for select the
Click on Create Applications from Next select
the profile Applications to
the list and Create Profile
assign
confirm with OK
Confirm with OK
End
and Finish
Figure B.5.: The workflow of creating a profile in NeSSi2
B.6. Create a Scenario
A scenario describes the configuration of a network. Several of them may be bun-

dled within a simulation. Figure B.6 describes the creation process of a scenario. The
Open NeSSi
Create Profile
Explorer
Expand
Expand the project
Is the NeSSi Networks and
Start node and its Are there any profiles?
Explorer visible? the specific
Profiles
network itself
Select the
Right click appropriate profiles
Enter a name for Right click on the
Scenarios and Select Distribute on the left side and
the scenario and scenario lying
select Create new Profiles click on the arrow
confirm with OK under Scenario
Scenario button to assign
them
Confirm with Finish End
Figure B.6.: The workflow of creating a scenario in NeSSi2
scenario cannot be simulated directly. You need to create a simulation containing the
scenario first.
79
B. Workflows
B.7. Create a Simulation

In a simulation, several scenarios are bundled. The number of ticks to simulate and the
number of simulations are configured within a simulation. How to create a simulation
is depicted in figure B.7.
Open NeSSi Create

Explorer Scenario
Expand the nodes Expand

Is the NeSSi to the Scenarios Networks and
Start Are there any scenarios?
Explorer visible? of the specific the specific
network network itself
Select the
Right click appropriate
Enter a name for Right click on the
Sessions and Select Configure scenarios on the left
the session and session lying
select Create new Sessions side and click on the
confirm with OK under Sessions
Session arrow button to add
them
Edit the column

Edit the column
Runs to match
Ticks to match the Select a recorder
the number of
number of ticks the configuration by End
simulations
simulation should clicking on ...
running with the
last
selected scenario
Figure B.7.: The workflow of creating a new simulation in NeSSi2
B.8. Run a Simulation

To run a simulation for a configured simulation, you need to select Launch Simulation
from the context menu of the simulation node within the NeSSi2 Explorer, see also figure
B.8
Expand
- project node, Right click on the
Start - Networks node session and select End
- node of the specific network Launch Session
- Sessions node
Figure B.8.: The workflow of running a simulation
80
C. Entity Relationship Diagram for
NeSSi2 databases
Figure C.1.: Entity Relationship Diagram for NeSSi2 databases. Notice, that measureint and measure-
globalint are listed as representatives, since they differ from measuredbl, measureglobaldbl and the
like only in the values datatype. An entry in the measureint table, e.g., refers to a component by its
identifier as well as the type of event and the scenario instance this value is related to. The latter three
are stored by reference in order to save disk space and enforce a fixed length for the table entries (so
no variable-length textfields in measureint). The scenario instance (scenariorun table) represents the
scenario in a certain simulation run. Each simulation run references the simulation it is part of. The
whole bunch of data that was sent to the simulation backend during the start of the simulation is stored
in the simulationdef table.
81
D. Installation of MySQL Server
By default the simulation data is recorded into a file on the local filesystem (using
SQLite). Although this is very nice for a quick start, you might encounter major per-
formance issues when the amount of collected data increases. This is why it is rec-
ommended to install a database management system like e.g. MySQL which can be
downloaded from http://www.mysql.com.
After you downloaded and started the mysql installer for the appropriate architecture
and operating system of your computer an installation dialog appears on screen. This
chapter will guide you through the installation under Windows Operating Systems.
Figure D.1.: Choose Typical Installation
83
D. Installation of MySQL Server
Then you click on the NEXT button several times until the dialog figure D.1 appears.
You should select TYPICAL and click on the NEXT buttons until you have the option
to CONFIGURE the server application which you should do (figure D.2).
Figure D.2.: Configure the MySQL Server
If you dont have special needs you should use the STANDARD CONFIGURATION
(figure D.3).
Figure D.3.: Choose Standard Configuration
84
Make sure the checkboxes for installing as Windows Service and including bin Direc-
tory in Windows PATH are both checked (figure D.4).
Figure D.4.: Install as service & include bin directory to PATH variable
In the next dialog you specify the password of the root user (twice). If you dont know
how to create additional users with limited privileges, you probably want to allow root
access from remote machines (figure D.5).
Figure D.5.: Password for root account & remote access
Because it is now possible to set custom pictures for devices and subnets (also back-
ground images for the latter), the network data might exceed the default maximum
packet size of MySQL. So it is a good idea, to set the value of max_allowed_packet
to 10M or even more. This can be done in either the MySQL Administrator, the
MySQL Workbench (which combines previously separated tools) or editing the my.cnf
or my.ini, respectively. If you use a mysql installation on a Unix like system that
uses a case-sensitive file system, you might experience problems. Setting the vari-
able lower_case_table_names to 1 for the mysqld process should solve the problem.
For further information see http://dev.mysql.com/doc/refman/5.1/de/
name-case-sensitivity.html.
85
E. Importing sample data into a
MySQL database
After the server process has started successfully, you probably want to import the sam-
ples from the NeSSi2 homepage. The easiest way is to open the command line tool and
type the text displayed in figure E.1. You need to use an account that has the privileges
to create new databases and tables.
Figure E.1.: Command Prompt Before DragnDrop
Then you drag and drop the extracted file (something like nessi2-examples-20090228.sql)
into the command prompt window. The full filename should now be appended at the
end of the line (figure E.2). Press RETURN and the data will be imported. This may
last several minutes.
Figure E.2.: After the file has been dragndropped into the Command Prompt window
After this process has finished, a database with the name demo was created and con-
tains all the data. So you must specifiy this schema in the database preferences pane in
the GUI (figure E.3 ).
87
E. Importing sample data into a MySQL database
Figure E.3.: Schema name has to be demo
88
F. Glossary
Application applications are installed on devices to add functionality. This is done by

scenarios.
Device Hardware node within the network, e.g. workstation, server and router.
Double Event Measured property of a certain network component at a certain point in
time within a simulation run expressed as integer value.
Double Type see Event Type
E.g. Bandwidth Usage
Event Event that occurs on a certain network component at a certain point in time and
does not provide any measured value.
Event Type Specifies the type of an event, is identified by an integer id and offers a
human readable label for GUI display, e.g. Packet Sent.
Global Double Event Measured property of the situation at a certain point in time dur-
ing simulation, expressed as double precision floating point number.
Global Double Event Type see Event Type
E.g. Infection Ratio
Global Event Event that does neither reference a certain network component nor pro-
vide a measured value.
Global Event Type see Event Type
E.g. Start of worm spreading (see malware)
Global Integer Event Measured property of the situation at a certain point in time dur-
ing simulation, expressed as integer number.
Global Integer Event Type see Event Type
E.g. Number of infected hosts
Host End device, such as server or workstation.
Infection The nesting of malware into the memory and/or storage of a device.
Integer Event Measured property of a certain network component at a certain point in
time within a simulation run expressed as integer value.
Integer Event Type see Event Type
E.g. Number of Sent Packets
Malware Malicious Software, such as worms, viruses, trojan horses etc.
Network Topology The topology of the network.
Network Component A specific component of type device, link or other.
Recording Process of saving information about the course of a certain simulation for
89
F. Glossary
later analysis. For usage with the NeSSi2 GUI this information has to be logged
to a database.
Run See Simulation Run.
Scenario Extends a network by installing applications on devices.
Simulation Several simulations may be specified to be batch-executed. This is called
a simulation. So, the user starts simulation and NeSSi2 internally starts its runs in
turn.
Simulation Run A single simulation of a specfied scenario. Several runs may be bun-
dled within a simulation as long as they simulate the same network.
90
Index
Application, 16, 6574, 78, 89 Preferences, see NeSSi2 User Interface

Preferences
Device, 89 Profile, 16
Create, see NeSSi2 User Interface
Eclipse, 7, 62
Recording, 89
JFreeChart, 58
Run, see Simulation Run
JIAC, see JIAC TNG
JIAC TNG Scenario, 13, 17
agent, 11 Create, see NeSSi2 User Interface
agent node, 11 Simulation, 13
log4j, 12
Run, see NeSSi2 User Interface
Maven, 62, 63 Simulation Environment, see NeSSi2 Sim-
MySQL, 14, 8388 ulation Environment
Simulation Event, 13
NeSSi2 Plug-In, 12, 62 Double, 89
NeSSi2 Simulation Environment, 1112 Event Type, 89
NeSSi2 User Interface, 1213, 77 Global, 89
Explorer, 77, 80 Integer, 89
Network Recording, see Recording
Create, 78 Value, 89
Profile Simulation Run, 80, 90
Create, 78
Project Template, 17
Create, 77
Scenario
Create, 79
Simulation
Create, 80
Run, 80
2
NeSSi Database, 1314, 2425, 8388
NeSSi2 Plug-In, 63
Network Component, 89
Network Topology, 13, 89
Plug-In, see NeSSi2 Plug-In
91
Bibliography
[Albayrak et al., 2008] Albayrak, S., Luther, K., Bye, R., Schmidt, S., Schmidt, A.-
D., and Bsufka, K. (2008). Autonomous Security Eine neuartige Architektur fr
netzwerkbasierte Intrusion Detection und Response. In Paulsen, C., editor, 15. DFN
Workshop Sicherheit in vernetzten Systemen, pages G1 G19. DFNCert Services
GmbH. ISBN:978-3-833-4-7381-4.
[Bloem et al., 2007] Bloem, M., Alpcan, T., Schmidt, S., and Basar, T. (2007). Malware
filtering for network security using weighted optimality measures. In Proc. of 2007
IEEE Multi-conference on Systems and Control. IEEE.
[Bye et al., 2008a] Bye, R., amtepe, S. A., Alpcan, T., and Sahin Albayrak (2008a).
CIMD Collaborative Intrusion & Malware Detection. SecureComm 2008.
[Bye et al., 2008b] Bye, R., Luther, K., amtepe, S. A., Alpcan, T., Sahin Albayrak,
and Yener, B. (2008b). Decentralized Detector Generation in Cooperative Intru-
sion Detection Systems. In Masuzawa, Toshimitsu; Tixeuil, S., editor, Stabilization,
Safety, and Security of Distributed Systems 9th International Symposium, SSS 2007
Paris, France, November 14-16, 2007 Proceedings, Lecture Notes in Computer Sci-
ence , Vol. 4838. Springer.
[Bye et al., 2008c] Bye, R., Schmidt, S., Luther, K., and Albayrak, S. (2008c).
Application-level simulation for network security. In Proceedings of the First In-
ternational Conference on Simulation Tools and Techniques for Communications,
Networks and Systems.
[Fricke et al., 2001] Fricke, S., Bsufka, K., Keiser, J., Schmidt, T., Sesseler, R., and
Albayrak, S. (2001). Agent-based telematic services and telecom applications. Com-
munications of the ACM, 44(4):4348.
[Kuhl et al., 2005] Kuhl, M. E., Steiger, N. M., Armstrong, F., and Joines, J. A., editors
(2005). Proceedings of the 37th Winter Simulation Conference, Orlando, FL, USA,
December 4-7, 2005. ACM.
[Law, 2007] Law, A. M. (2007). Simulation Modeling & Analysis. McGraw-Hill, 4th
edition.
[Liljenstam et al., 2006] Liljenstam, M., Liu, J., Nicol, D. M., Yuan, Y., Yan, G., and
Grier, C. (2006). RINSE: The Real-Time Immersive Network Simulation Environ-
ment for Network Security Exercises (Extended Version). SIMULATION, 82(1):43
59.
[Liu et al., 2001] Liu, B., Figueiredo, D., Guo, Y., Kurose, J., and Towsley, D. (2001).
A study of networks simulation efficiency: Fluid simulation vs. packet-level simula-
tion. In INFOCOM 2001. Twentieth Annual Joint Conference of the IEEE Computer
and Communications Societies. Proceedings. IEEE, volume 3, pages 12441253.
93
Bibliography
[Luther, 2006] Luther, K. (2006). Entwurf eines Knstlichen Immunsystems zur Net-
zwerkberwachung auf Basis eines Multi-Agenten-Systems. Masters thesis, Tech-
nische Universitt Berlin.
[Luther et al., 2007] Luther, K., Bye, R., Alpcan, T., Albayrak, S., and Mller, A.
(2007). A Cooperative AIS Framework for Intrusion Detection. In Proceedings
of the IEEE International Conference on Communications (ICC 2007).
[Nicol et al., 2005] Nicol, D. M., Liljenstam, M., and Liu, J. (2005). Advanced con-
cepts in large-scale network simulation. In [Kuhl et al., 2005], pages 153166.
[Riley, 2003] Riley, G. F. (2003). The Georgia Tech Network Simulator. In Proceed-
ings of the ACM SIGCOMM workshop on Models, methods and tools for repro-
ducible network research, pages 512. ACM Press.
[Robinson, 2004] Robinson, S. (2004). Simulation The Practice of Model Develop-
ment and Use. John Wiley & Sons, Ltd.
[Scalable Network Technologies Inc., ] Scalable Network Technologies Inc. Qualnet.
http://www.scalable-networks.com.
[Schmidt et al., 2007] Schmidt, S., Alpcan, T., Albayrak, S., and Mller, A. (2007). A
Monitor Placement Game for Intrusion Detection. In Proc. of CRITIS, 2nd Interna-
tional Workshop on Critical Information Infrastructures Security, Lecture Notes in
Computer Science. Springer. to appear.
[Schmidt and Kunegis, 2007] Schmidt, S. and Kunegis, J. (2007). Scalable bandwidth
optimization in advance reservation networks. In International Conference on Net-
works, (IEEE ICON 2007), Adelaide, Australia. to appear.
[USC Information Sciences Institute, ] USC Information Sciences Institute. NS-2
network simulator 2.31. http://www.isi.edu/nsnam/ns/doc/ns_doc.
pdf, last accessed on 07/15/2008.
[Wei et al., 2005] Wei, S., Mirkovic, J., and Swany, M. (2005). Distributed worm sim-
ulation with a realistic internet model. Principles of Advanced and Distributed Sim-
ulation, 2005. PADS 2005. Workshop on, pages 7179.
[Yun et al., 2005] Yun, J. B., Park, E. K., Im, E. G., and In, H. P. (2005). A scalable,
ordered scenario-based network security simulator. In Systems Modeling and Simu-
lation: Theory and Applications, volume 3389 of Lecture Notes in Computer Science
(LNCS), pages 487494. Springer-Verlag.
94

Ne SSi 2 Manual

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ne SSi 2 Manual

Uploaded by

Copyright:

Available Formats

FT

June 21, 2013

Contributors: Rainer Bye

Technische Universitt Berlin

4. Graphical User Interface 15

8. How to Create a Simulation: A Step by Step Tutorial 49

9. Extending NeSSi2 : Application Tutorial 61

C. Entity Relationship Diagram for NeSSi2 databases 81

D. Installation of MySQL Server 83

E. Importing sample data into a MySQL database 87

1.1. Graphical User Interface of NeSSi2 . . . . . . . . . . . . . . . . . . . . 2

2.1. NeSSi2 User Interface (Network Editing) . . . . . . . . . . . . . . . . . 7

4.1. NeSSi2 Project Explorer . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.1. The Dependency Hierarchy of NeSSi2 Components . . . . . . . . . . . 27

6.1. Available New Wizards . . . . . . . . . . . . . . . . . . . . . . . . . . 41

8.1. Overall NeSSi2 Workflow . . . . . . . . . . . . . . . . . . . . . . . . . 49

9.1. Setting the Target Platform Definition . . . . . . . . . . . . . . . . . . 62

B.1. Overall Workflow in NeSSi2 . . . . . . . . . . . . . . . . . . . . . . . 77

C.1. Entity Relationship Diagram for NeSSi2 Databases. . . . . . . . . . . . 81

D.1. Choose Typical Installation . . . . . . . . . . . . . . . . . . . . . . . . 83

E.1. Command Prompt Before DragnDrop . . . . . . . . . . . . . . . . . 87

1.1. Related Work on Network and Security Simulation

reusable object-oriented software architecture.

1.2. The Features of NeSSi2

1.2.1. Traffic Generation

1.2.2. Protocol Stack and Socket-based API

1.2.3. Security Features

1.3. Structure of the Manual

2.1. Graphical User Interface

Figure 2.1.: NeSSi2 User Interface (Network Editing)

2.2. Simulation Backend

Figure 2.2.: Running Backend of NeSSi2

3.1. NeSSi2 Simulation Environment

3.1.1. Download and Installation

To install the NeSSi2 Simulation Environment you have to:

3.1.3. Launching the NeSSi2 Simulation Environment

3.2. NeSSi2 User Interface

3.2.1. Download and Installation

To install the NeSSi2 User Interface, you have to:

3.2.3. Launching the NeSSi2 User Interface

3.3. NeSSi2 Database

3.3.1. Download and Installation

1. Install the MySQL database management system (see Appendix D on how to

3.4. NeSSi2 Repository

3.4.1. Download and Installation

4.1. Simulation Components

4.1.9. Recorder Configurations

4.2. GUI Elements

4.2.1. NeSSi2 Explorer

4.2.3. Routing Table

Similar to Outline, this view will only dis-

The Properties view (figure 4.2, number 4) displays and

Figure 4.4.: The Properties View

The Progress view shows the status of jobs running

4.2.8. Network Editor

4.2.9. Profile Editor

4.2.10. Scenario Editor

4.2.11. Simulation Editor

Figure 4.10.: Configuring a simulation in the Simulation Editor.

4.2.12. Recorded Simulations

The Recorded Simulations view displays

Figure 4.11.: The Recorded Simulations view

simulation was initiated is also recorded