1 Description of the document

This guide identifies installation prerequisites, describes how to install Net2Plan, and explains how to run it and extend its functionalities.

2 What is Net2Plan?

Net2Plan is a free and open-source Java tool devoted to the planning, optimization and evaluation of communication networks. It has been originally thought as a tool to assist the teaching of communication networks planning courses. Finally, it has converted into as a (in our opinion) powerfull tool for network planning for the academia and industry.

Net2Plan allows testing several built-in algorithms, or new algorithms that users (i.e. students) can easily implement. This process is facilitated by a set of included libraries. The integration of the user-made algorithms in the tool is straightforward. The algorithms are implemented as Java .class/.jar files with a mandatory format for input and output parameters. Hence, algorithms in this form can be readily integrated into Net2Plan (see Section 5.1.2).

Net2Plan is implemented as a Java library along with both command-line and graphical user interfaces (CLI and GUI, respectively). The GUI is specially useful for laboratory sessions as an educational resource, or for a visual inspection of the network. In its turn, the command-line interface is specifically devoted to in-depth research studies, making use of batch processing or large-scale simulation features. Therefore, Net2Plan is a tool intended for a broad spectrum of users: industry, research, and academia.

Regardless of the interface (CLI or GUI) selected by the user, Net2Plan currently provides five different tools: network design, traffic matrix generation, resilience simulation, connection-admission-control (CAC) simulation, and reporting.

3 Installation guide, system requirements and starting Net2Plan

Net2Plan requires Java Runtime Environment 7 or higher versions and a screen resolution of, at least, 800x600 pixels. Since it is developed in Java, it works in the most well-known operation systems (Microsoft Windows, Linux, Mac OS X).

To install Net2Plan, save the compressed file in any directory. Then, extract all the files and folders into a new directory, for example C:\Work\Net2Plan (in a Windows environment).

To run Net2Plan in GUI mode, just double click on Net2Plan.jar, or execute the following command in a terminal:

java -jar Net2Plan.jar

To run Net2Plan in CLI mode, execute the following command in a terminal:

java -jar Net2Plan-cli.jar

3.1 Directory structure

This section describes the directory structure in the toolbox. It has the following folders:

Table 2. Directory Structure
Directory Description

help

Includes this guide

javadoc

Includes the library API Javadoc

lib

Includes auxiliary Java libraries required by the kernel

src

Includes the kernel code and some example codes

workspace

Includes examples: topologies, traffic matrices, algorithms, reports…

4 Background

In this section, we provide the theoretical framework that is behind Net2Plan philosophy, and the (common) notation we use to characterize the network, topology, routing etc.

4.1 Topology

In Net2Plan a network topology is defined as a graph \(G(N,E)\), where \(N\) is the set of nodes and \(E\) is the set of links. The number of nodes and links are the cardinality of sets \(N\) and \(E\), which are \(|N|\) and \(|E|\), respectively. Network topologies are considered as multi-digraphs. This means that every link is unidirectional (directed graph or digraph), and that network topologies can have multiple links between the same node pair. No self-links are allowed.

Given a link \(e \in E\), \(a(e)\) denotes the initial node of the link, and \(b(e)\) denotes its destination node. We use \(l_{e}\) to denote the link length (measured in km). Given a node \(n\), \(d^{+}(n)\) is the set of outgoing links from \(n\) (\(d^{+}(n) = \{e \in E : a(e) = n\}\)) and \(d^{-}(n)\) is the set of incoming links to \(n\) (\(d^{-}(n) = \{e \in E : b(e) = n\}\)). In Fig. 4.1 an example of network topology is shown.

Fig. 4.1. Topology with |N| = 3 nodes, N = \{n_1,n_2,n_3\}, |E| = 3, E = \{e_1,e_2,e_3\}. End nodes of e_1 are a(e_1) = n_1 and b(e_1) = n_2. Outgoing links from node n_2 are d^{+}(n_2) = \{e_2,e_3\}, and the incoming one is d^{-}(n_2) = {e_1}

Fig. 4.1. Topology with \(|N|\) = 3 nodes, \(N = \{n_1,n_2,n_3\}\), \(|E|\) = 3, \(E = \{e_1,e_2,e_3\}\). End nodes of \(e_1\) are \(a(e_1) = n_1\) and \(b(e_1) = n_2\). Outgoing links from node \(n_2\) are \(d^{+}(n_2) = \{e_2,e_3\}\), and the incoming one is \(d^{-}(n_2) = {e_1}\)

4.2 Installed capacities

Each node \(e\) in a network has associated a real number \(u_e\) = 0 which represents its capacity. The capacity is the amount of traffic the link is able to carry. Thus, capacities and traffics are measured in the same units. Unless stated otherwise, the traffic and capacities in Net2Plan are measured in Erlangs.

For the sake of simplicity, we denote the set of link capacities as a vector u = \(\{u_e, e \in E\}\). In addition, the carried traffic by link \(e\) is denoted by \(y_e\). The vector y = \(\{y_e, e \in E\}\) represents the traffic carried in all the links in the network.

Typically link capacities are limited to a discrete range of values due to technological reasons, such as STM-\(N\) carriers in SDH. In these cases, capacities are referred as modular capacities.

4.3 Traffic model

Traffic is modelled through a set of demands (or commodities) \(D\). Each demand \(d \in D\) represents an offered traffic flow to the network. In general, the traffic of a demand \(d\) can have one or more ingress nodes in the set \(a(d)\), and one or more egress nodes denoted by the set \(b(d)\); however, in current version of Net2Plan demands are considered unicast. This means that each demand \(d\) has one ingress node and one egress node, thus \(|a(d)|\) = \(|b(d)|\) = 1. In addition, self-demands are not allowed.

The offered traffic by a demand \(d\) is represented as \(h_d\). Such value is measured in the same units as link capacities u (i.e. Erlangs). In some situations, it is not possible to carry all the offered traffic by the demands. Then, \(r_d \leq h_d\) represents the amount of traffic belonging to demand \(d\) that is carried. In their vector form, h = \(\{h_d, d \in D\}\) and r = \(\{r_d, d \in D\}\) represent offered and carried traffic, respectively.

A simplified approach to model the offered traffic between nodes is the so-called traffic matrix. A traffic matrix is a \(|N|\)x\(|N|\) matrix (where \(|N|\) is the number of nodes in the network) in which each pair \((i,j)\) represents the traffic from node \(i\) to node \(j\). The traffic design tool is intented to help users to generate traffic matrices using several random traffic models.

The main drawback of representing the offered traffic by means of traffic matrices, is that the traffic matrix representation assumes that at most one demand exists between each pair of nodes. Then, if we compute the traffic matrix representation of a demand set \(D\) where some node pairs have more than one demand between them, an ambiguity can occur. This situation is posed in Fig. 4.2, where demands 1 and 2 from the demand set on the left are grouped in a single entry in the traffic matrix. The same result is obtained with the demand set on the right.

Fig. 4.2. Ambiguity in traffic matrices

Fig. 4.2. Ambiguity in traffic matrices

4.4 Routing

Routing is the process of, for each traffic demand, selecting paths in a network along which to send the traffic. Given a network topology \(G(N,E)\), a path \(p\) is an ordered sequence of links \(p = (e_1,\dots,e_k)\), such that the destination node of a link \(e_i\) is the origin node of the following link \(e_i+1\). The set of all possible paths in a network is denoted as \(P\). The first node of the path \(a(p)\) is the origin node of the first link \(a(e_1)\), and the last node in the path \(b(p)\) is the destination node of the last link \(b(e_k)\). Finally, given a link \(e \in E\), \(P_e\) is the set of paths which traverse the link \(e\). For example in Fig. 3.3, given \(p_1 = \{e_{12},e_{23},e_{34}\}\) and \(p_2 = \{e_{42},e_{23}\}\), \(P_{e_{23}} = \{p_1,p_2\}\). In addition, \(l(p)\) is the number of hops in path \(p\).

Fig. 4.3. Topology with |N| = 4 nodes, N = {n_1,\dots,n_4}, |E| = 4, E = \{e_{12},e_{23},e_{34},e_{42}\}

Fig. 4.3. Topology with \(|N|\) = 4 nodes, \(N = {n_1,\dots,n_4}\), \(|E|\) = 4, \(E = \{e_{12},e_{23},e_{34},e_{42}\}\)

In Net2Plan, the routing is internally represented in the form of demand-path variables. Formally, for each demand \(d\) in the network, a set of paths \(P_d \subset P\) is defined between the end nodes of the demand (\(a(d) = a(p), b(d) = b(p)\)). Also, given a path \( p \), the demand that the path is linked to is denoted as \( d(p) \). Then, traffic routing is represented by a vector x = \(\{x_{p}, p \in P\}\) where \(x_{p}\) is the traffic volume carried through the path \(p\) for demand \(d(p)\). Note that we define a path \(p \) as a sequence of links that carry traffic of a specific demand \( d (p) \). If two demands exist \( d_1, d_2 \) between the same end nodes, and the traffic of both demands is carried through the same sequence of links, we consider in Net2Plan that the routing is composed of two paths \( p_1, p_2 \) with the same end nodes, one for each demand, so that \(d (p_1 ) = d_1, d(p_2) = d_2 \).

According to the notation used to define the network routing in Net2Plan, the following relations hold:

\[\sum_{p \in P_{d}} x_{p} = r_d \leq h_{d}\ \ \ \ \ \ \forall d \in D\ \ \ \ \ \ \text{the traffic carried by a demand $d$ is the sum of traffics in the paths assigned to that demand}\]

\[\sum_{p \in P_{e}} x_{p} \leq u_{e}\ \ \ \ \ \ \forall e \in E\ \ \ \ \ \ \text{the traffic in a link is the sum of the traffic in the paths traversing that link, and is constrained (in general) to be limited by the link capacity}\]

Next, two typical routing constraints are described:

4.5 Quick reference card

Table 1 summarizes information about background underlying Net2Plan.

Table 1. Summary of network elements involved in Net2Plan
Element Parameter Description

Nodes

\(N\)

\(\delta^{+}(n)\), \(\delta^{-}(n)\)

Set of nodes \(n \in N\)

Set of outgoing and incoming links from/to node \(n\)

Links

\(E\)

\(a(e)\), \(b(e)\)

\(l_{e}\)

\(u_{e}\)

u

\(y_{e}\)

y

Set of links \(e \in E\)

Origin and destination nodes of link \(e\)

Length of link \(e\) (Km)

Capacity of link \(e\) (Erlangs)

Vector form of \(u_{e}\)

Traffic carried by link \(e\) (Erlangs)

Vector form of \(y_{e}\)

Demands

\(D\)

\(a(d)\), \(b(d)\)

\(h_{d}\)

h

\(r_{d}\)

r

Set of demands \(d\in D\)

Ingress and egress nodes of demand \(d\)

Offered traffic for demand \(d\) (Erlangs)

Vector form of \(h_{d}\)

Carried traffic for demand \(d\) (Erlangs)

Vector form of \(r_{d}\)

Routing

\(x_{p}\)

\(x\)

\(a(p)\), \(b(p)\), \(l(p)\)

\(p=\{\dots\}\)

\(d(p)\)

\(P\)

\(P_{d} \subset P\)

\(P_{e}\)

Traffic volume carried by \(p\in P_{d}\) for demand \(d(p)\)

Vector form of \(x_{p}\)

Origin and destination nodes of path, number of hops in the path \(p\)

Sequence of links traversed in path \(p\)

Demand corresponding to path \(p\)

Set of all paths defined in the network \(p\in P\)

Subset of the paths in \(P\) that are associated to demand \(d\)

Subset of the paths in \(P\) that traverse link \(e\)

4.6 Metrics

In this section several performance and cost metrics are described. These metrics are useful to define objective functions or problem constraints.

4.6.1 Topology

4.6.3 Offered traffic

4.6.4 Routing (carried traffic)

5 Addressing network design and evaluation problems

In practical network design different variables can be involved: link capacities, the traffic routing, the topological design of the network, the storage capacity at each node, and so on. Usually, network design problems receive some of this information as input parameters (e.g. traffic demand, and network topology) and try optimize the rest (e.g. capacities in the links and traffic routing) according to a performance merit of interest. Clearly, the number of possible variants and subtypes of network design problems is infinite. Moreover, different technologies add their own particular aspects to network design. For this reason, network design has become a mixture of art and engineering.

In an attempt to provide a (somehow) systematic criteria to cathegorize network design problems, in Net2Plan we adopted the following scheme, which is just an extension of the network design problems’ taxonomy in Kleinrock’s book [Kleinrock1976]:

According to this naming scheme, combinations of these problems are named combining the acronyms. For example, a capacity and flow assignment (CFA) problem involves the joint computation of routing and link capacities. We remark that this taxonomy should be considered as an attempt to give a didactic organization to the utmost diversity of planning problems that arise in communication networks.

5.1 Algorithms

Typically network design problems are presented as optimization problems, this means that there are a set of performance criteria to maximize or minimize, subject to some constraints (qualitative statements about network design and performance), given a set of input parameters (i.e. partial network designs, technology constraints...). Optimization algorithms (or just "algorithms") are the methods that compute a numerical solution to a given problem instance. In Net2Plan, an algorithm is a Java file with a given signature (see Section 5.1.2 for more information) that establishes the format of the input and output parameters.

Net2Plan is divided into two main parts: user interface (GUI or CLI) and kernel. The main idea is that all the design algorithms, independently of their specific target, receive as input parameter the current network structure (see Section 4 for more information), and return an updated version of this network structure. Then, the Net2Plan kernel and GUI, are devoted to just process the designs returned by the algorithms: check its validity (e.g. the topology has a correct format, the links are not oversubscribed etc), graphically display the network design, and compute some reports and performance merits.

The idea behind Net2Plan is that you can progressively design your network. This is, you can chain successive algorithms, each one completing a part of the network design. For instance, you can start with a network where only the nodes are defined. Then, an algorithm is used to define the links in the network according to some figure of performance. Afterwards, an algorithm can be run to jointly decide on the capacity in the links and routing of the flows, for a given traffic matrix. As a result, Net2Plan can be a powerful tool for communications network planning courses, since students can see step by step how their designs grow.

Fig. 5.1. Design flow in Net2Plan

Fig. 5.1. Design flow in Net2Plan

Net2Plan assists the task of creating and evaluating network design algorithms by providing built-in example algorithms. Please, visit the Net2Plan website to see an updated list of built-in algorithms and use cases. In Section 5.1.2 we explain in more detail how to integrate new algorithms in Net2Plan.

5.1.1 Built-in algorithms

Please, visit the Net2Plan website to see an updated list of built-in algorithms and use cases.

5.1.2 Integrating new algorithms

New algorithms can be implemented as Java classes (.class/.jar files) with a given signature. Integration of algorithms simply requires saving them in any directory of the computer, although it is a good practice to store them in the \workspace directory.

Important: When algorithms are implemented as Java classes, the full path to the class must follow the package name of the class, in order to successfully load the algorithm. For example, if we create an algorithm named testAlgorithm in the package test.myAlgorithms, the full path to the class must be like ...{any}.../test/myAlgorithms/testAlgorithm.class. For .jar files there is not any restriction on the full path, they can be stored at any folder.

Algorithms must implement the IAlgorithm interface in package com.net2plan.networkDesign (check the Library API Javadoc for more information) which can be found in lib\net2plan-lib.jar. Users are responsible to implement three methods: getDescription() returns a description of the algorithm; getParameters() returns the set of parameters of the algorithm, including name, default value and description; and finally executeAlgorithm() which implements the algorithm.

The signature of executeAlgorithm() must be like this:

String executeAlgorithm(NetPlan netPlan, Map<String, String> algorithmParameters, Map<String, String> net2planParameters)

The input parameters are defined as follows:

The output parameter is a String including any kind of information.

In order to improve the user experience, kernel is able to catch any exception thrown by algorithms. Those exceptions are introduced in a Java error console (see Section 6.1.3 for more information). For example, exceptions allow users to check if their algorithms are well-programmed (i.e. no null-pointers), thus in the error console they got a full trace of the error (files, line numbers...). However, when input parameters are wrong or an error within the algorithm is returned (i.e. an optimization problem is unable to find feasible solutions), we we recommend to throw extensions using the Net2PlanExtension class (see Library API Javadoc for more information), since it allows users to see the error in a small dialog in which the only information is the error message (i.e. "A feasible solution was not found") instead of the full error trace in the error console (i.e. "RuntimeException: A feasible solution was not found (MyAlgorithm.java:35), ...)".

5.2 Reporting

When the network design phase is finished, users can evaluate their networks by means of reports. Reports return every kind of information that user requires from a network plan e.g. blocking or delay analysis... Users can also create report-generating routines, that show the network performances they want in the form they want.

5.2.1 Built-in reports

Please, visit the Net2Plan website to see an updated list of built-in reports and use cases.

5.2.2 Integrating new reports

Integration of new reports follows a similar scheme as for algorithms. Reports must implement the IReport interface in package com.net2plan.networkDesign (check the Library API Javadoc for more information) which can be also found in lib\net2plan-lib.jar. Users are responsible to implement four methods: getTitle() returns a brief title of the report, getDescription() returns a description; getParameters() returns the set of parameters of the report; and finally executeReport() which implements the report.

The signature of executeReport() must be as follows:

String executeReport(NetPlan netPlan, Map<String,String> reportParameters, Map<String,String> net2planParameters, IWrapperManager wrapperManager)

The input parameters are defined as follows:

The output parameter is a String including any kind of information. However, it is recommended that returns an HTML file, since the GUI is able to parse and show it to the user, with the option of showing in an Internet browser. This feature allows to include e.g. images within reports.

5.3 Resilience simulation

TBD

5.4 Connection-admission-control simulation

TBD

6 Using the graphical user interface

In order to start Net2Plan follow the instructions presented in the previous section. Then, if you choose the GUI, the welcome screen will appear.

Fig. 6.1. Welcome screen

Fig. 6.1. Welcome screen

In the top menu you can choose between the different options which Net2Plan provides. Below are listed and explained:

Fig. 6.2. Main menu

Fig. 6.2. Main menu

6.1 File menu

This menu has four options: Options, Classpath Editor, Show Java console, and Exit.

6.1.1 Options

Use Options to set Net2Plan-wide parameters. These options have a global scope to all Net2Plan modules: are used within the kernel, and, for instance, to compute delay metrics in built-in reports. In this version there are just four options:

Fig. 6.3. Options

Fig. 6.3. Options

6.1.2 Classpath editor

Although a moderate library set is provided within Net2Plan, users may require extra Java libraries (.jar files) to develop their own algorithms or reports (i.e. mathematical or graph theory libraries). So, the classpath editor avoids the tedious task of include Java libraries in environment variables (i.e. CLASSPATH in Windows).

Fig. 6.4. Classpath editor

Fig. 6.4. Classpath editor

In the current version of Net2Plan Java libraries can be included in run-time, but unfortunately it is not possible to do the same to remove libraries. In this case, user is forced to restart Net2Plan.

6.1.3 Java error console

This feature centralizes the error handling within Net2Plan. When an error is thrown, for example, due to invalid input parameters in an algorithm, the error and the stack trace is shown there. Moreover, System.out/System.err is redirected there also, allowing users to debug their Java code.

Important: When JNI/JNA for native library access is used, the native output (i.e. stdout in C/C++) is not equivalent to the Java output, thus such an information will not appeared in the Java error console. A workaround is to start Net2Plan from the command-line according to Section 3.

Fig. 6.5. Error console

Fig. 6.5. Java error console

6.1.4 Exit

Quits Net2Plan.

6.2 Tools menu

This menu has three items: Network design, Traffic design, Resilience simulation and Connection-admission-control simulation.

6.2.1 Network design

Selecting Network design opens the Network design window, which you can use to execute your algorithms.

The workspace of the window is divided into three areas: input data, execution and reporting (right area), plot area (top-left area), and information area (bottom-left area).

Fig. 6.6. Network design window

Fig. 6.6. Network design window

6.2.1.1 Network topology

This panel is used for graphically design and see networks. Users are able to add or remove nodes and links, make zoom or take a picture.

Nodes are inserted by right clicking into the canvas and using the option “Add node here”. Nodes can be removed by right clicking on them and using the option “Remove node”.

Fig. 6.7. Inserting a node

Fig. 6.7. Inserting a node

Links are inserted by clicking first in the origin node and then in the destination node. It is possible to insert unidirectional links or bidirectional ones (in this case, you must press SHIFT key during that process). Also links can be inserted by right clicking over the origin node and selecting the destination node in the popup menu.

Fig. 6.8. Inserting a link graphically

Fig. 6.8. Inserting a link graphically

Fig. 6.9. Inserting a link using a popup menu

Fig. 6.9. Inserting a link using a popup menu

In addition, in this panel you can see the current state of the network design through the "Edit network plan" tab. If the design includes routing information, it is possible to visualize the paths which carry traffic of a demand, the paths traversing a link…

Fig. 6.10. Showing the route followed by a traffic demand

Fig. 6.10. Showing the route followed by a traffic demand

Finally, users can add/remove network elements (nodes, links, demands...), assign values to certain properties (e.g. link capacities to all links), or even add/remove user-specific attributes to every network element (nodes, links... or the whole network) using popup menus in the "Edit network plan" tab.

Fig. 6.11. Editing attributes

Fig. 6.11. Editing attributes

6.2.1.2 Information

In this panel you can see the general state of the network design e.g. if node, link or demand sets are defined, if routing is defined… that is, to check the current state in which the network is.

6.2.1.3 Execution controller and Edit network plan

With these two panels, users are able to execute and edit their designs and execute algorithms.

In the Execution controller, users can load network designs and traffic demands and execute algorithms. In general, to calculate a new design the user has to specify the following things:

Fig. 6.12. Executing an algorithm

Fig. 6.12. Executing an algorithm

Once those inputs are filled, the algorithm can be executed by clicking on “Execute”. A popup will be shown during the execution of the algorithms, allowing to stop algorithms taking long execution times. When the execution finishes, a message will be shown, informing whether the algorithm runs well or some error was thrown. Users are able to save current designs using the option “Save”.

In the Edit network plan, users can see and edit information of each element within the network plan e.g. change node name or position, change link capacity, or add a demand attribute. Moreover, as network plan is being completed, more information appears, e.g. if all traffic is being carried, if there are traffic losses…

Fig. 6.13. Edit network plan

Fig. 6.13. Edit network plan

6.2.1.4 View reports

In this panel user can select a report to apply to the network plan. The structure is similar to those to execute algorithms. Upon selection and clicking “Show” the report is shown in the bottom part. The user can see it in a browser using the option “View in navigator”.

Fig. 6.14. Showing a report

Fig. 6.14. Showing a report

Reports can be closed individually using the CTRL + W combination.

6.2.2 Traffic matrix design

Selecting Traffic matrix design under Tools menu activates the Traffic generation window. This interface allows the user to generate a .xml file representing a traffic matrix. This figure displays the workspace window for this option.

Fig. 6.15. Traffic matrix design window

Fig. 6.15. Traffic matrix design window

The Traffic design window is divided into four different parts:

6.2.2.1 Traffic matrix

The user initiates the process by selecting the number of nodes \(N\) in the network using Resize option. The traffic matrix will be like this:

where \(i\) and \(j\) are the node identifiers. Self-demands are not allowed (\(\gamma_{ii} = 0\)).

Next, the user has two options: to introduce values manually, or to use traffic generation patterns. Also you can open an existing .xml file to edit it, or reset to all-zero matrix.

Finally, the user can save it into the file system with the Save button.

6.2.2.2 Traffic normalization

Now, the user can apply an automatic normalization of the matrix. Three types of normalization methods are implemented: total, row and column normalization [Cahn1998]. The first adjusts the traffic matrix so that the total traffic offered to the network matches a user defined value. The second (third) modifies the matrix so that the \(i\)-th row (column) of the matrix sums \(x_{i}\), being \(x_{i}, \)i$ = \(1...N\) a vector defined by the user. Note that this means that the total traffic transmitted (received) by node \(i\) is fixed to exactly \(x_i\).

Fig. 6.16. Traffic normalization

Fig. 6.16. Traffic normalization

\[M'_{T}(i,j) = M_{T}(i,j)\cdot\frac{\text{Total offered traffic}}{\sum_{ij}M_{T}(i,j)}\]

where \(M'_{T}(i,j)\) is the normalized traffic and \(M_{T}\) is the original traffic matrix.

The user introduces the total offered traffic volume in a popup.

6.2.2.3 Traffic generation: uniform traffic models

After this, the user can select one of the traffic generation patterns among the five modes available: four of them are simpler, and based on the uniform distribution.

Please note at the end of this process diagonal values of traffic matrix are zero, since self-demands are not allowed.

Fig. 6.17. Uniform traffic models

Fig. 6.17. Uniform traffic models

Traffic generation: population-distance traffic model The fifth mode allows creating a traffic matrix according to the model described in [2]. This latter model applies the information of node position, population and node level, present in a topology information table (user can load a topology from a .xml file). The distribution based on populations and distances follows the next expression:

where Level is a \(L\)x\(L\) two-dimensional matrix (\(L\): number of levels or node types defined by the user). This matrix allows us to introduce asymmetric traffic in the traffic generator; \(Pop_i\) is the population of the node \(i\); \(Pop_{max}\) is the maximum population; \(dist\) is a matrix \(N\)x\(N\) (\(N\): number of nodes) with the distances between nodes; \(dist_{max}\) is the maximum distance.

Fig. 6.18. Population-distance traffic models

Fig. 6.18. Population-distance traffic models

6.2.3 Resilience simulation

TBD

6.2.4 Connection simulation

TBD

7 Using the command-line interface

TBD

8 Net2Plan library

In order to help users to develop their own classes, Net2Plan is shipped along a Java library (lib/net2plan-lib.jar) which includes, not only interfaces to implement algorithms and reports, but also classes e.g. to compute shortest paths, network performance metrics, or random traffic matrix models, along with general helper Java classes such as IntUtils or DoubleUtils. Check the library API Javadoc for more information.

9 Release notes

Net2Plan 0.2.0 (March 18, 2013)

In its very early stage Net2Plan was designed as a MATLAB toolbox. From version 0.2.0, previous MATLAB versions were discontinued, thus backward-compatibility is not ensured at all. However, interested users can found them in the website.

10 Authors

Net2Plan tool has its origins in 2011, during the preparation of the teaching materials for two new Communication Networks Planning courses at Universidad Politécnica de Cartagena (Spain) taught by Prof. Pablo Pavón Mariño:

Net2Plan is also a part of the Ph.D. work of José Luis Izquierdo Zaragoza, supervised by Prof. Pablo Pavón Mariño.

Aside from Net2Plan, authors also collaborate in the development of MatPlanWDM, an open-source tool for multilayer optical networks. Moreover, Prof. Pablo Pavón Mariño develops the JOM, an open-source Java library for modeling and solving optimization problems in a simple MATLAB-like syntax.

Pablo Pavón Mariño

José Luis Izquierdo Zaragoza

11 References

[Cahn1998] R.S. Cahn, Wide Area Network Design: Concepts and Tools for Optimization. The Morgan Kaufmann Series in Networking, Morgan Kaufmann, 1998

[Kleinrock1976] L. Kleinrock, Queueing Systems, Volume 2: Computer Applications. John Wiley & Sons, 1976

[Pavon2012] P. Pavon-Marino, “Lectures of the Telecommunication Networks Theory course,” 2012