Manual Version 2.1.2

FT RA

D

Manual

Version 2.1.2 June 21, 2013

Editors: Karsten Bsufka

Contributors: Rainer Bye Joël Chinnow Dennis Grunewald Katja Luther Arik Messerman Stephan Schmidt Leily Behnam Sani Thomas Hauschild Sebastian Linkiewicz Thorsten Rimkus Bianca Scheibel Jakob Strafer

Technische Universität Berlin Institut für 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: [email protected] URL: http://www.dai-labor.de

Contents 1. Introduction

1

1.1. Related Work on Network and Security Simulation 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. Overview

7

2.1. Graphical User Interface . . . . . . . . . . . . . . . . . . . . . . . . . 2.2. Simulation Backend . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3. Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3. Installation

3.1.

7 8 9 11

NeSSi2

Simulation Environment . . . . . . . . . . . . 3.1.1. Download and Installation . . . . . . . . . . . 3.1.2. Configuration . . . . . . . . . . . . . . . . . . 3.1.3. Launching the NeSSi2 Simulation Environment 3.1.4. Troubleshooting . . . . . . . . . . . . . . . . 3.2. NeSSi2 User Interface . . . . . . . . . . . . . . . . . . 3.2.1. Download and Installation . . . . . . . . . . . 3.2.2. Configuration . . . . . . . . . . . . . . . . . . 3.2.3. Launching the NeSSi2 User Interface . . . . . . 3.3. NeSSi2 Database . . . . . . . . . . . . . . . . . . . . 3.3.1. Download and Installation . . . . . . . . . . . 3.3.2. Configuration . . . . . . . . . . . . . . . . . . 3.4. NeSSi2 Repository . . . . . . . . . . . . . . . . . . . . 3.4.1. Download and Installation . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

4. Graphical User Interface

4.1. Simulation Components . 4.1.1. Mode . . . . . . 4.1.2. Networks . . . . 4.1.3. Layouts . . . . . 4.1.4. Applications . . 4.1.5. Profiles . . . . . 4.1.6. Scenarios . . . . 4.1.7. Simulations . . .

1 3 3 4 5 6

11 11 11 12 12 12 12 12 13 13 13 14 14 14 15

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

15 15 16 16 16 16 17 17

iii

4.1.8. Templates . . . . . . . . 4.1.9. Recorder Configurations 4.2. GUI Elements . . . . . . . . . . 4.2.1. NeSSi2 Explorer . . . . 4.2.2. Outline . . . . . . . . . 4.2.3. Routing Table . . . . . . 4.2.4. Properties . . . . . . . . 4.2.5. Problems . . . . . . . . 4.2.6. Progress . . . . . . . . . 4.2.7. Statistics . . . . . . . . 4.2.8. Network Editor . . . . . 4.2.9. Profile Editor . . . . . . 4.2.10. Scenario Editor . . . . . 4.2.11. Simulation Editor . . . . 4.2.12. Recorded Simulations . 4.2.13. Perspectives . . . . . . . 4.2.14. Preferences . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . .

5.1. Background Information . . . . . . . . . . . . 5.2. Configuration and Preferences . . . . . . . . . 5.2.1. Getting Started . . . . . . . . . . . . . 5.2.2. Default Repository Location . . . . . . 5.2.3. Adding Repository Locations . . . . . 5.2.4. Deleting Repository Locations . . . . . 5.2.5. Modifying Repository Locations . . . . 5.2.6. Download Options for the backend . . 5.2.7. Manual Configuration . . . . . . . . . 5.3. Uploading Artifacts . . . . . . . . . . . . . . . 5.4. Downloading Artifacts . . . . . . . . . . . . . 5.4.1. Downloading Artifacts in the Frontend 5.4.2. Downloading Artifacts in the Backend . 5.5. Artifact Database . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

5. NeSSi2 Repository

27

6. Federated Simulation

6.1. Project with multiple Networks . . . . . . . . . . . . . . . . . . . . . . 6.2. Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Termination Conditions

7.1. Simulation Termination Condition . . . . . . . . . . . . . . . . . . . . 7.2. Replication Termination Condition . . . . . . . . . . . . . . . . . . . . 8. How to Create a Simulation: A Step by Step Tutorial

NeSSi2

17 17 18 18 19 19 19 19 20 20 21 21 21 22 22 23 24

8.1. Create Project . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2. Create Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3. Create Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27 28 28 29 29 30 30 31 31 32 35 35 37 37 41

41 42 45

46 47 49

49 50 51

8.4. 8.5. 8.6. 8.7.

Create Scenario . . . . . . . . . . . . . . . . . . . Create Simulation . . . . . . . . . . . . . . . . . . Run Simulation . . . . . . . . . . . . . . . . . . . Evaluating Simulations . . . . . . . . . . . . . . . 8.7.1. Preparing Analyses with Third Party Tools

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

9. Extending NeSSi2 : Application Tutorial

61

9.1. Setting up your Development Environment . . 9.1.1. Setting up the Target Platform . . . . 9.1.2. Creating a NeSSi2 Plug-in Project . . 9.2. Creating a NeSSi2 Application . . . . . . . . 9.2.1. First Steps of Creating an Application 9.2.2. Echo Applications . . . . . . . . . . 9.2.3. Event Recording . . . . . . . . . . . 9.2.4. Deployment of Applications . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

A. Recommended Readings

B. Workflows

Create and Start a Simulation Create a NeSSi2 Project . . . Open NeSSi2 Explorer . . . Create a Simple Network . . Create a Profile . . . . . . . Create a Scenario . . . . . . Create a Simulation . . . . . Run a Simulation . . . . . .

62 62 62 65 65 68 72 74 75

A.1. Simulation Modeling and Analysis . . . . . . . . . . . . . . . . . . . .

B.1. B.2. B.3. B.4. B.5. B.6. B.7. B.8.

53 55 57 58 58

75 77

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

77 77 77 78 78 79 80 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 . . . . . . . . . . . . . . . . . . . . 1.2. Core Architecture of NeSSi2 . . . . . . . . . . . . . . . . . . . . . . .

2 5

2.1. NeSSi2 User Interface (Network Editing) . . . . . . . . . . . . . . . . . 2.2. Running Backend of NeSSi2 . . . . . . . . . . . . . . . . . . . . . . .

7 8

4.1. NeSSi2 Project Explorer . . . . . . . . . . . . . . . . . . . . . 4.2. Some of the GUI Elements in the Network Editing Perspective 4.3. The Routing Table View for a Network Node . . . . . . . . . 4.4. The Properties View for a Network Edge . . . . . . . . . . . . 4.5. The Problems View . . . . . . . . . . . . . . . . . . . . . . . 4.6. The Progress View . . . . . . . . . . . . . . . . . . . . . . . 4.7. The Statistics View . . . . . . . . . . . . . . . . . . . . . . . 4.8. The Profile Editor . . . . . . . . . . . . . . . . . . . . . . . . 4.9. The Scenario Editor . . . . . . . . . . . . . . . . . . . . . . . 4.10. The Simulation Editor . . . . . . . . . . . . . . . . . . . . . . 4.11. The Recorded Simulations view . . . . . . . . . . . . . . . . 4.12. Graphical Depiction of Traffic in the Simulation Perspective . 4.13. Example Settings for a MySQL Database . . . . . . . . . . . 4.14. A Sample Recorder Configuration . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

15 18 19 19 20 20 20 21 22 22 22 24 25 26

5.1. The Dependency Hierarchy of NeSSi2 Components . . . 5.2. The Repository Preference Page . . . . . . . . . . . . . 5.3. Entering Information for a New Repository Location . . 5.4. Options for Dependency Resolution in the Backend . . . 5.5. Example Authentication Information in the Settings.xml 5.6. A List of the Artifacts for Uploading . . . . . . . . . . . 5.7. Entering Artifact Information for an Example File. . . . 5.8. Uploading an Artifact into a Repository. . . . . . . . . . 5.9. The Download Wizard . . . . . . . . . . . . . . . . . . 5.10. Browsing through a Repository . . . . . . . . . . . . . . 5.11. Viewing all Database Entries . . . . . . . . . . . . . . . 5.12. Viewing the Properties of a NeSSi2 Component. . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

27 28 30 31 32 33 34 35 36 37 38 38

6.1. 6.2. 6.3. 6.4. 6.5.

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

41 41 42 42 43

Available New Wizards . . . . . . . . . . . . . . . . . . Creating a New Network File . . . . . . . . . . . . . . . Entering a Name and a Parent Folder for a Network File The Network Configuration Page . . . . . . . . . . . . . Configuration of the Network Mapping . . . . . . . . .

vii

7.1. The Simulation Configuration Page . . . . . . . . . . . . . . . . . . . . 7.2. Implementation of a Simulation Termination Condition . . . . . . . . . 7.3. Implementation of a Replication Termination Condition . . . . . . . . .

45 46 47

8.1. 8.2. 8.3. 8.4. 8.5. 8.6. 8.7. 8.8. 8.9. 8.10. 8.11. 8.12.

Overall NeSSi2 Workflow . . . . . . . . . . . . . . . . . . The NeSSi2 Project Creation wizard. . . . . . . . . . . . . Adding Subnets to a Network . . . . . . . . . . . . . . . . A Simple Network . . . . . . . . . . . . . . . . . . . . . A List of the Available Applications by Categories . . . . Existing Applications in a Profile . . . . . . . . . . . . . . The Scenario Creation Wizard . . . . . . . . . . . . . . . Manually Adding Profiles to Network Nodes . . . . . . . Adding Profiles to Network Nodes . . . . . . . . . . . . . The Simulation Configuration Tab in the Simulation Editor. The Network Configuration Tab in the Simulation Editor. . Viewing the Simulation Results . . . . . . . . . . . . . . .

9.1. 9.2. 9.3. 9.4. 9.5. 9.6. 9.7. 9.8. 9.9. 9.10. 9.11. 9.12. 9.13. 9.14. 9.15.

Setting the Target Platform Definition . . . . . . . . . . . . . . . . . . Adding Dependencies to an Application Development Project . . . . . Example pom.xml for a NeSSi2 Plug-in Project . . . . . . . . . . . . . Basic NeSSi2 Application for the IP-Model . . . . . . . . . . . . . . . Example of the Enum-Annotation . . . . . . . . . . . . . . . . . . . . Applications in the NeSSi2 User Interface . . . . . . . . . . . . . . . . Skeleton for the Echo Client Application . . . . . . . . . . . . . . . . . The start Method of the Echo Client Application . . . . . . . . . . . The handleEvent Method of the Echo Client Application . . . . . . Skeleton for the Echo Server Application . . . . . . . . . . . . . . . . The start Method of the Echo Server Application . . . . . . . . . . . The handleIncomingPacket Method of the Echo Server Application The sendEcho Method of the Echo Server Application . . . . . . . . Constants for the Event Recording . . . . . . . . . . . . . . . . . . . . Recorder Configuration . . . . . . . . . . . . . . . . . . . . . . . . . .

62 63 64 65 66 67 68 69 70 71 71 72 72 73 74

B.1. B.2. B.3. B.4. B.5. B.6. B.7. B.8.

Overall Workflow in NeSSi2 . . . . . . . . . . The Workflow of Creating a NeSSi2 Project . . The Workflow of Opening the NeSSi2 Explorer The Workflow of Creating a Network . . . . . The Workflow of Creating a Profile . . . . . . . The Workflow of Creating a Scenario . . . . . The Workflow of Creating a Simulation . . . . The Workflow of Running A Simulation . . . .

. . . . . . . .

77 77 78 78 79 79 80 80

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

81

D.1. Choose Typical Installation . . . . . . . . . . . . . . . . . . . . . . . . D.2. Configure the MySQL Server . . . . . . . . . . . . . . . . . . . . . . . D.3. Choose Standard Configuration . . . . . . . . . . . . . . . . . . . . . .

83 84 84

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . .

. . . . . . . .

. . . . . . . . . . . .

49 50 50 51 52 52 53 54 54 55 56 57

D.4. Install as Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . D.5. Password for Root Account . . . . . . . . . . . . . . . . . . . . . . . .

85 85

E.1. Command Prompt Before Drag’n’Drop . . . . . . . . . . . . . . . . . E.2. Command Prompt After Drag’n’Drop . . . . . . . . . . . . . . . . . . E.3. Setting the Schema Name . . . . . . . . . . . . . . . . . . . . . . . . .

87 87 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 simulation 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) allows NSPs to experiment with different network-centric security framework setups and algorithms in order to evaluate and compare intrusion detection efficiency and operational 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 behavior 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 discrete 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 experimentation 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 Network 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 realworld 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 comprehensive 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 supporting 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 networks 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 evaluation 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 software 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 independently 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.

1.2. The Features of NeSSi2 NeSSi2 is designed to extend conventional network simulation tool features by supporting detailed examination and testing opportunities of security-related network algorithms, 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 generated 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 supports 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 centrally 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 network 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

1.2. The Features of NeSSi2

traffic is well-formed. Wireshark is able to reconstruct the application data stream without 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 algorithm 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 parallel 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 simulation 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 attachment of traffic profiles, but additionally security related settings can be configured. When a security framework composed of several detection units is to be tested, profiles can also be used in NeSSi2 to simulate attacker behavior and attack patterns. Accordingly, 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 commander 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 modules 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 configurations 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 Backend. 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 readings (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 components, the Graphical User Interface, the simulation backend and the result database. Each of these modules may be run on separate machines depending on the computational requirements; furthermore, this modular design facilitates network security researchers 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 basis 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 identifying 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 affects 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 evaluation 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 interface, 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 user’s 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 generally 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 Environment. First, the JIAC TNG node and agent files3 can be modified to customize the agent behavior 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 3 See

processors and GTK libraries 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.

3.2.1. Download and Installation 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.

3.2.2. Configuration 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, scenarios 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.

3.3.1. Download and Installation 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

3.3.2. Configuration Please refer to your database management system documentation for configuration guidelines. 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 20–50 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 Section 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.

3.4.1. Download and Installation 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 section 4.1. The other category is the RCP GUI elements such as views, editors and perspectives, 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 fold2 Figure 4.1.: NeSSi2 Project ers are named after the element types they contain. NeSSi project files include the following types: networks, appliExplorer cations, profiles, scenarios, simulations, recorder configurations 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 supported. The mode included in default NeSSi2 implementation is IP-mode and it allows 1 The

Eclipse Foundation’s page for RCP: http://www.eclipse.org/home/categories/rcp.php

15

4. Graphical User Interface

for the execution of IP-based simulations. NeSSi2 , however, is designed to support multiple modes at the same time.

4.1.2. Networks Networks consist of nodes and edges. A network is independent of any other components. 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. Applications are actually classes contained in JAR files created using Maven. Due to NeSSi2 architecture, which prescribes a separation between user interface and simulation backend, 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 corresponding 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 replications 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 configured 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 recording 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 simulation execution in NeSSi2 Backend onto the database. The default configurations can be found in Recordings/Examples folder of each NeSSi2 project. Recorder configurations are based on log4j 2 . Please refer to the log4j’s homepage for more details. 2 http://logging.apache.org/log4j/

17

4. Graphical User Interface

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 editors, so that the presented interface contains essential elements while hiding functionality 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 element’s 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 hierarchical 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 display 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. Figure 4.3.: The Routing Table View for a Network Node

As can be seen in figure 4.3, this views contains IP addresses of the gateway, sub 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 selected network element. Among other information, device name and device type are displayed for nodes. For network links the following 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.

4.2.5. Problems

Figure 4.4.: The Properties View for a Network Edge

When creating and modifying simulation components in a NeSSi2 project, the NeSSi2 Project Builder runs in the background and verifies these modifications. When inconsistencies 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

4. Graphical User Interface

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 periodically 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 network 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

4. Graphical User Interface

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 federated 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. Network Editing Perspective comprises a main network editor window grouped with a variety of different views which provide additional information corresponding to the element 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 visualization of simulation results. This perspective consists of Recorded Simulations, Statistics, 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 downloaded 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

4. Graphical User Interface

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 preferences (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, password, 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 specified 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

4. Graphical User Interface



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 dependencies. This means uploading/downloading a NeSSi2 component will require the

27

5. NeSSi2 Repository

transfer of other components which have references to it and as a result, the whole upload/download process is rarely restricted to a single download/upload operation. In order for NeSSi2 components to be compatible with a Maven repository, each component requires some additional Maven attributes such as ArtifactID, GroupID and Version. 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 repository 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 following 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

5.2. Configuration and Preferences

its content will be parsed and displayed. If such file doesn’t 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: nessi2intern-release, nessi2-intern-snapshot and nessi2-extern. By clicking on each repository 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 repository 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

5. NeSSi2 Repository

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 available 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

5.2. Configuration and Preferences

. 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 available, 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 repository will be complied. Options such as default repository ID and download configurations 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

5. NeSSi2 Repository

siteServer /path/to/private/key optional; leave empty if not used. example username password . . . NeSSi Profile example http://repositories.example.com

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. Uploading 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, select a component in project explorer view and select "Upload Artifact..." action from the component’s 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 computed 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, backslash and dot, are allowed. User will not be able to continue to the next page unless 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

5. NeSSi2 Repository

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 ArtifactID, 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 Wizard. 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 locations 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 repositories by using the download wizard, which can be accessed through "Download Artifact..." action in the context menu of any project’s 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

5. NeSSi2 Repository

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 repository’s 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 Figure 5.9). During the download process, a progress bar and a label will display the download’s 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 downloaded 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 application 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.

5.5. Artifact Database Along the growing number of artifacts, maintaining an overview of uploaded and downloaded 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 downloaded. 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

5. NeSSi2 Repository

Figure 5.11.: Viewing all database entries within the NeSSi2 User Interface

will open a dialog window containing information about the selected artifact (see Figure 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 ) located in NeSSi2 ’s main toolbar. The other option is by the database symbol ( 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_ ArtifactsDB.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 column’s title. Additionally, a simple search function is integrated on the top of this dialog window (see Figure 5.11). The search

38

5.5. Artifact Database

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 functionalities that are involved with federated simulations are the creation of multiple networks 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 following 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 project’s 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 fulfilled. 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 conditions. 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 conditions for a simulation can be set. If a termination condition field is selected, the configuration 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 condition’s 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 implemented 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. Termination Conditions

7.1. Simulation Termination Condition F igure 7.2 demonstrates an example implementation of a simulation termination condition. 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 4 5

import de.dailab.nessi.api.applications.annotations.Description; import de.dailab.nessi.api.applications.annotations.IntegerOption; import de.dailab.nessi.api.termination.AbstractSimulationTerminationCondition;

6 7 8 9

@Description("This termination condition simulates a fixed number of replications.") public class FixedRunsSimulation extends AbstractSimulationTerminationCondition {

10

@IntegerOption("Number of Replications") private int numberRep = 1;

11 12 13

private int currentReplication = 0;

14 15

private final static String NAME = "Fixed Number of Runs";

16 17

@Override public void addReplicationTerminationResults(Object newValue) { this.currentReplication++; }

18 19 20 21 22

@Override public boolean isSatisfied() { if (this.currentReplication >= this.numberRep) { return true; } return false; }

23 24 25 26 27 28 29 30

public static String getName() { return NAME; }

31 32 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 4

import java.util.LinkedList; import java.util.Map;

5 6 7 8

import de.dailab.nessi.api.applications.annotations.Description; import de.dailab.nessi.api.applications.annotations.IntegerOption; import de.dailab.nessi.api.termination.AbstractReplicationTerminationCondition;

9 10 11 12 13

@Description("This termination condition allows a fixed simulation length " + "with the defined number of ticks.") public class FixedTicksReplication extends AbstractReplicationTerminationCondition {

14

private static final String NAME = "Fixed Run Length"; @IntegerOption("Number of Ticks") private int numberTicks = 1000;

15 16 17 18

@Override public boolean isSatisfied(Map newValues, int tick) { if (tick >= this.numberTicks) { return true; } return false; }

19 20 21 22 23 24 25 26

@Override public Object getResult() { return null; }

27 28 29 30 31

@Override public void reset() { return; }

32 33 34 35 36

public static String getName() { return NAME; }

37 38 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