Xavi Report

Design and Implementation of a Traffic Engineering Research Platform based on OPNET
Xavier Os Alicart
Lund University Department of Communications Systems Lund Institute of Technology
Supervisor: Dr. Ulf Ahlfors
ABSTRACT
Traffic engineering research is a branch of Internet research that often needs network simulators in order to facilitate development and analysis of new traffic management and control schemes. One of these simulators is the OPNET Modeler, which is a commercial and powerful simulation software that allows us to study and design communication networks and protocols under realistic assumptions. The aim of this thesis is to design and implement a traffic engineering platform based on the OPNET Modeler that allows us work efficiently with the traffic engineering and simulation software. More specifically, the platform should offer seamless integration with other software modules, including a traffic engineering and optimization engine and a network topology generator (for generating large and realistic Internet topologies). It also has to permit the definition of MPLS networks and the ability to define them automatically, based on external input. This thesis report gives an introduction to OPNET and MPLS technology, and it describes the simulation platform and the way to use it.
TABLE OF CONTENTS
1. INTRODUCTION ........................................................................................................ 4 1.1. SCOPE OF THIS THESIS ............................................................................ 4 1.2. OBJECTIVES................................................................................................ 5 1.3. OUTLINE OF THESIS ................................................................................. 5 2. INTRODUCTION TO OPNET MODELER ............................................................... 6 2.1. INSTALLING OPNET MODELER ............................................................. 6 2.2 OPNET MODELER TOOLS ......................................................................... 8 2.3. THE MODELER WORKFLOW................................................................. 10 3. MPLS.......................................................................................................................... 13 3.1. FORWARDING PACKETS IN AN MPLS NETWORK ........................... 13 3.2. MPLS LABEL DISTRIBUTION AND SIGNALING................................ 15 3.3. MPLS APPLICATIONS ............................................................................. 16 3.4. MPLS IN OPNET MODELER ................................................................... 18 4. GENERATION OF NETWORK TOPOLOGIES...................................................... 21 4.1. PLACING INDIVIDUAL NODES ............................................................. 21 4.2. RAPID CONFIGURATION TOOL............................................................ 21 4.3. IMPORTING A NETWORK MODEL ....................................................... 22 4.3.1. Different Options to Import .......................................................... 22 4.3.2. Importing from an XML file......................................................... 23 4.4 THE BRITE NETWORK GENERATOR.................................................... 24 4.4.1. Running BRITE ............................................................................ 25 4.4.2. The BRITE Output Format ........................................................... 27 4.4.3. Adapting the BRITE output format to OPNET XML format....... 29 4.4.4. Generating a backbone of the network ......................................... 31 5. ADDING TRAFFIC TO THE NETWORK............................................................... 33 5.1. TYPES OF TRAFFIC.................................................................................. 33 5.2. DETAILED TRAFFIC CONFIGURATION OPTIONS ............................ 34 5.3. TRAFFIC GENERATOR............................................................................ 36 6. CONFIGURING THE MPLS PATHS....................................................................... 38 7. SYNTHESIZING THE WORKFLOW OF THE PLATFORM................................. 41 7.1. WORKFLOW.............................................................................................. 41 7.2. RUN A SIMULATION WITHOUT THE GUI........................................... 46 8. CONCLUSIONS ........................................................................................................ 48 APPENDIX A: GLOSSARY ......................................................................................... 49 APPENDIX B: LIST OF CLASSES DEVELOPED ..................................................... 50 REFERENCES ............................................................................................................... 52
1. INTRODUCTION
This thesis concerns the design and implementation of a network simulation platform for traffic engineering research. Internet Traffic Engineering is defined as that aspect of Internet network engineering which is concerned with the performance optimization of operational networks [11]. It encompasses the application of technology and scientific principles to the measurement, modeling, characterization, and control of Internet traffic, and the application of such knowledge and techniques to achieve specific performance objectives, including the efficient utilization of network resources, and the planning of network capacity. Traffic engineering research often needs network simulators in order to facilitate development and analysis of new traffic management and control schemes. Network simulators can be either open source or commercial. The open source simulators are free and usually developed and maintained by academic institutions, and they are easy to modify and add new features to. However, as they have been developed by different people and there is not one company behind the software, no one will guarantee the rightness and the quality of the results. The most well-know simulator in the research field is NS-2 [14]. On the other hand, the commercial simulators are supposed to deliver valid network models. One of the most popular software is the OPNET Modeler developed by OPNET, which is the simulator used in this thesis.
1.1. SCOPE OF THIS THESIS

The scope of this thesis is to provide a software that facilitates the communication between the network simulator (OPNET) and the routing/traffic engineering software as shown in the following figure:
OPNET
interface
PARSER TOOLS
interface
ROUTING ENG. SOFTWARE
Figure 1.1 Relationship between the different softwares
The work focuses on understanding OPNET and to develop the parsing software. The Routing engineering software is out of the scope of this work.
1.2. OBJECTIVES
The main goal of this thesis is to design a traffic research platform based on OPNET Modeler. The platform should make it possible to simulate large scale networks. In order to reach this goal, we followed the steps below: First, get the simulator working and discover how to use it. Analyze the different options to generate networks automatically and the way to import them into the Modeler. Develop a parser to adapt the network configuration files. Find out and study the different ways to introduce traffic into the network in OPNET Modeler. Study the characteristics of a MPLS network, how to configure it in Modeler and the attributes to set. Develop a software to set all the attributes and nodes automatically, based on external input. Analyze the way to run simulations without the Graphical User Interface in a remote machine, in order to generate batches of simulations of the same or different network configurations. Finally, outline a workflow on how to use the research platform.
1.3. OUTLINE OF THESIS

In Chapter 2 we provide a description of the main characteristics of OPNET Modeler. An MPLS introduction is found in Chapter 3. Chapter 4 deals with the different ways of importing a network topology into OPNET Modeler. Chapter 5 is focused on the different kinds of traffic which we can generate in the simulation tool. The way to configuring MPLS is explained in chapter 6. The description of the final software platform and the workflow for using it is described in the chapter 7. At the end, we state some the conclusions. There are two appendices: one is a glossary of the acronyms used in this report and the other gives an explanation of the different classes that implements the platform.
2. INTRODUCTION TO OPNET MODELER

OPNET Modeler allows you to design and study communication networks, devices, protocols, and applications [2]. It provides a graphical editor interface to build models for various network entities from physical layer modulator to application processes.
2.1. INSTALLING OPNET MODELER

OPNET Modeler has three components: software, models, and documentation. This software can work either in Windows OS or a Solaris OS. You must install all three components to run Modeler successfully [1]. Furthermore, an ANSI C or C++ compiler is necessary for simulation and model building. You may need to update system-wide environment variables to include the directories that contain the compiler. In order to install the OPNET Modeler correctly, one may use following steps: 1) Install an ANSI C or C++ compiler. If you are working in: Windows: its necessary Microsoft Visual C/C++ 6.x or Visual Studio .NET (up to Visual Studio .NET 2003) Solaris: gcc or g++ 2) Set the environment variables in order to let the Modeler to compile the models and run the simulations. The variables needed to set are:
Name
include Lib MSDevdir Path
Value
C:\Program Files\Microsoft Visual Studio\VC98\atl\include;C:\Program Files\Microsoft Visual Studio\VC98\mfc\include;C:\Program Files\Microsoft Visual Studio\VC98\include C:\Program Files\Microsoft Visual Studio\VC98\mfc\lib;C:\Program Files\Microsoft Visual Studio\VC98\lib C:\Program Files\Microsoft Visual Studio\Common\MSDev98 C:\Program Files\Microsoft Visual Studio\VC98\bin;C:\Program Files\Microsoft Visual Studio\Common\MSDev98\bin;C:\Program Files\Microsoft Visual Studio\Common\Tools\WinNT;C:\Program Files\Microsoft Visual Studio\Common\MSDev98\Bin;C:\Program Files\Microsoft Visual Studio\Common\Tools;
In order to set an environment variable in Windows XP, it is necessary to do the following:

Start -> Settings -> Control Panel -> System Go to Advance Label -> Click Environment Variables Button -> 1) Create a new one if it doesnt exist else 2) Add at the end of the definition the value
3) Install the Modeler 4) Install the model library 5) Install the documentation 6) Run the License Manager and add the license information.
After all these operations, Opnet Modeler should be running successfully. The main window of the Opnet Modeler is shown in the next figure:
Figure 2.1 Main window OPNET Modeler 11.0
2.2 OPNET MODELER TOOLS

OPNET supports model specification with a number of tools, called editors. These editors handle the required modeling information in a manner that is parallel to the structure of real network systems. Therefore, the model-specification editors are organized hierarchically. Model specifications performed in the Project Editor rely on elements specified in the Node Editor. The rest of the editors are used to define various data models, new links and nodes, etc. This organization is described in the following list: Project Editor - Develop network models. Network models are made up of subnets and node models. This editor also includes basic simulation and analysis capabilities. The Project Editor is the main staging area for creating a network simulation. From this editor, you can build a network model using models from the standard library, choose statistics about the network, run a simulation and view the results. It is also possible to create node and process models, build packet formats, and create filters and parameters, using specialized editors that you can access from the Project Editor. In fig. 2.2 an example of the project editor view of an MPLS network is shown.
Figure 2.2 Example of an MPLS network
Node Editor - Develop node models. Node models are objects in a network model. They are made up of modules with process models. The Node Editor lets you define the behavior of each network object. Behavior is defined using
different modules, each of which models some internal aspect of node behavior such as data creation, data storage, etc. A network object is typically made up of multiple modules that define its behavior. In the next figure, there are some parts of a routers internal structure, such as a TCP module, an UDP module and an IP module.
Figure 2.3 Internal structure of a router in the node editor
Process Editor - Develop process models. Process models control module behavior and may reference parameter models. This editor lets you create process models, which control the underlying functionality of the node models created in the Node Editor. Process models are represented by finite state machines (FSMs), and are created with icons that represent states and lines that represent transitions between states. Operations performed in each state or for a transition are described in embedded C or C++ code blocks.
Figure 2.4 Process editor models
External System Editor - Develop external system definitions. External system definitions are necessary for cosimulation. Link Model Editor - Lets you create new types of link objects. Each new type of link can have different attribute interfaces and representation. It is also possible to edit and view link models already created. Packet Format Editor - Develop packet formats models. This editor lets you define the internal structure of a packet as a set of fields. A packet format contains one or more fields, represented in the editor as colored rectangular boxes. The size of the box is proportional to the number of bits specified as the fields size. ICI Editor - Create, edit, and view interface control information (ICI) formats. ICIs are used to communicate control information between processes. PDF Editor - The PDF (Probability Density Function) Editor lets describe the spread of probability over a range of possible outcomes. A PDF can model the likelihoods associated with packet interarrival times, or it can model the probability of transmission errors. This editor allows you to create, edit, and view probability density functions (PDFs). Once all the different interfaces are shown, it is necessary to describe the different steps to build a network model and to simulate it. For the purposes of this thesis work, its only necessary to work with the project.
2.3. THE MODELER WORKFLOW

This section outlines the suggested workflow when using OPNET.
1. Create Network Models
3. RUN SIMULATIONS
2 .Choose Statistics
4 .View and analyze results
Figure 2.5 Diagram of Modeler Workflow
1) The first step is to create the networks models. Its necessary to generate the network to simulate in any of the following 3 ways (will be detailed in chapter 4): 10
Placing individual nodes from the object palette into the workspace Using the rapid configuration tool And/or importing the network from an external data.
Furthermore, you have to introduce the traffic you want to run through the network. There is two main ways of putting traffic in the model: a) Importing b) Manually specifying 2) Afterwards and before running a simulation, it is necessary to choose the statistics we want to collect. OPNET does not automatically collect all statistics in the system because there are so many available that you may not have enough disk space to store them. Specifying statistics is a straightforward task which is performed through the GUI. This is described in detail later. 3) The third thing to set is configuring the parameters of the simulation and running them. Running simulations is typically thought of as the next-to-last step in the simulation and modeling process, the last step being results analysis. However, simulation is typically done many times in the modeling process to check the rightness of the generated network. There are different kinds of analysis that can be done in OPNET Modeler. 1. 2. 3. 4. Discrete Event Simulation Flow Analysis Failure Impact Analysis NetDoctor Validation
Discrete event simulation provides the most detailed results but has the longest running times [2]. This is because it does a more thorough analysis than the others, handling explicit traffic, conversation pair traffic, and link loads. The other types answer specific types of questions and generate results much faster than a discrete event simulation. A flow analysis, for example, handles only conversation pair traffic (flows) and a NetDoctor validation does not consider traffic at all. Our licenses only allow generating Discrete Event Simulations (DES), so we have focused in this type of analysis. 4) View and analyze the results of the simulation is the last step. The results can be watch from the Project Editor or from the Analysis Tool. The Analysis Tool provides the capability to extract data from simulation output files, and to manipulate and display it according to various plotting methods. Data can be manipulated through built-in operations in a different ways to get wanted information. Hence, the final workflow of a project could be as follows: Create project Create baseline scenario - Import or create topology - Import or create traffic - Choose results and reports to be collected 11
- Run simulation - View results and analyze them Iterate by duplicating the scenario and changing parameters Opnet uses a project and scenario approach to model networks. Project is a collection of related network scenarios in which each explores a different aspect of network design. A project contains at least one scenario and a scenario is a single instance of a network containing all the information. It is possible to run all the scenarios of the network at the same time and compare the results of each one. This approach for modeling networks allows you to try what-if scenarios to check if a server will support and increment of the traffic, the effect of the increment of the traffic in a link in the response of a service, etc.
12
3. MPLS
The Multi-Protocol Label Switching is a standard of the IETF [3]. Multiprotocol because it might be applied with any Layer 3 network protocol, although almost all of the interest is in using MPLS with IP traffic. MPLS allows for the marriage of IP to layer 2 technologies by overlaying a protocol on top of IP networks. This new protocol lets you combine the intelligence of the routing with the efficiency of the switching. MPLS is based in the following ideas: The separation between the routing and the packet forwarding functions. The exchange of the labels for sending the data packets.
3.1. FORWARDING PACKETS IN AN MPLS NETWORK:

The first idea to separate the routing and the forwarding functionality may be described as follows. As a packet of an IP network layer protocol travels from one router to the next, each router makes an independent forwarding decision for that packet. Each router analyzes the packet's header, and each router runs a network layer routing algorithm. Each router independently chooses a next hop for the packet, based on its analysis of the packet's header and the results of running the routing algorithm. Thus, there is a lot of work that is done in every router of the packet path from the source to the destination. Instead of all this repeating work, in a MPLS network this work is only done once in the ingress router. The rest of the routers along the path will only decide which is the next hop node, based on the incoming link and the value on the label of the packet. The label that identifies each packet is a field of few bits added in the MPLS header and it identifies the FEC (Forwarding Equivalence Class). A FEC is a set of packets that are sent on the same way through a network, even though their final destinations are different. For example, in conventional IP routing by network address a FEC could be all the packets whose directions of destiny have the same network address. Really, a label is similar to a connection identifier (like the VPI/VCI of ATM or the DLCI of Frame Relay). The assignment of a particular packet to a particular FEC is done just once when the packet enters the network. The FEC to which the packet is assigned is known as a label. When a packet is forwarded to its next hop, the label is sent along with it. In the following routers, the label is used as an index into a table which specifies the next hop, and a new label to replace the old one. The labels on a router have only a local meaning and an exchange label algorithm is needed in order to create the Label-Switched Paths (or LSPs). The base of the MPLS is in the allocation and swapping of labels already described, which in turn allows for the establishment of the LSPs in the network. Each LSP is created by concatenating one or more links. The labels are swapped in the Label Switching Routers (LSR) along a path. The first and the last routers of a LSP in a MPLS network are called LERs (Label Edge Routers): The first is called the MPLS ingress node, which is where labels are pushed into the raw IP traffic arriving at the LER [4]. These packets are forwarded along the assigned LSP to each LSR in the path where the labels are swapped.
13
The last node, called the MPLS egress node, removes the MPLS labels and delivers IP packets to the next hop outside the MPLS network.
An example MPLS network is shown below, in figure 3.1.
Figure 3.1 Topology of an MPLS network
The more detailed operation can be described as follows. On the ingress side, the LER examines the incoming packet to determine whether the packet should be labelled. A special database in the LER matches the destination address to the label. An MPLS shim header, which is shown in the next figure, is attached and the packet is sent. The egress LER has to remove the MPLS header and decide the next hop in conventional way.
Figure 3.2 MPLS shim header and format
The Shim Header consists of 32 bits in four parts twenty bits are used for the label, three bits for writing the different Type of Services (ToS), one bit for stack function, and eight bits for time to live (TTL) which has the same function as in IP. When the MPLS packets leave the LER, they are destined for LSR where they are examined for the presence of labels. The LSR looks to its forwarding table (called a
14
Label Information Base, LIB, or a connectivity table) for instructions. The LSR will swap labels according to the LIB instructions. This process happens in every LSR as it is shown in the figure 3.3. The following table shows an example of a LIB.
Label/In 80 17 Port In B Label/Out 40 Port/Out B FEC B Instruction Next Hop Swap Swap
A 18 C A Table 3.1 A Label Switch Routers Label Information Base (LIB)
Figure 3.3 LSR performing its label-swapping functions
3.2. MPLS LABEL DISTRIBUTION AND SIGNALING:

In the previous chapter, we described how the MPLS labels are used for forwarding packets. Here we describe the other central idea in MPLS, namely how the labels actually are distributed and communicated across an MPLS network. There are several methods used in label creation and distribution [5]: topology-based method: uses normal processing of routing protocols (such as OSPF and BGP). MPLS needs the information of the routing protocols to generate the LSPs. Per each IP path, a LSP is created. request-based method: uses processing of request-based control traffic. It uses the protocols RSVP (Resource reSerVation Protocol) or LDP (Label Distribution Protocol). MPLS architecture does not mandate a single method of signaling for label distribution. Existing routing protocols, such as the border gateway protocol (BGP), have been enhanced to send the label information within the contents of the protocol. The RSVP has also been extended to support exchange of labels. The Internet Engineering Task Force (IETF) has also defined a new protocol known as the label distribution protocol (LDP) for explicit signaling and management of the label space. Extensions to the base 15
LDP protocol have also been defined to support explicit routing based on QoS and CoS requirements.
3.3. MPLS APPLICATIONS:

The main applications of the MPLS are: 1) Traffic engineering 2) Different CoS/QoS Traffic engineering is a process that enhances overall network utilization by attempting to create a uniform or differentiated distribution of traffic throughout the network. An important result of this process is the avoidance of congestion on any one path. It is important to note that traffic engineering does not necessarily select the shortest path between two devices. It is possible that, for two packet data flows, the packets may traverse completely different paths even though their originating node and the final destination node are the same. This way, the less-exposed or less-used network segments can be used and differentiated services can be provided. The main idea is to send traffic from the most utilized links to the under-utilized links.
Figure 3.4 Comparison between the shortest path and TE path
In MPLS, traffic engineering is inherently provided using explicitly routed paths. The LSPs are created independently, specifying different paths that are based on userdefined policies. However, this may require extensive operator intervention. RSVP and CRLDP are two possible approaches to supply dynamic traffic engineering and QoS in MPLS. MPLS is also designed to attend differentiated services for QoS assurance, typically according to the DiffServ Model of the IETF. Differentiated Services is an architecture defined by IETF based on classify the traffic entering to a network into different classes 16
and give a different level of resources to each class [7]. This model defines a variety of mechanisms to classify the traffic in a reduced number of classes with different priorities. According to the requirements of the users, DiffServ allows to differentiate traditional services such as the WWW, the electronic mail or the transference of files, of other applications more affected by the delay and its variation (streaming multimedia and voice over IP). For this purpose, it is used the field called ToS (Type of Service) in the IP packet. Class of Service (CoS) classifies packets by examining packet parameters and places packets in queues of different priorities based on predefined criteria. Diffserv provides new uses for the ToS octet field of the IP header. The protocol field structure is presented in the next figure. The DSCP (Differential Services Code Point) has six bits. All the traffic with the same DSCP receives the same deal in the network. The DS implementation in a network defines the Per-Hop Behaviors (PHB). The PHB is the externally observable forwarding behavior applied at a DS-compliant node to a DS behavior aggregate.
0 1 2 3 4 5 6 7
DSCP
Not used
Not used
Defined in RFC 2474

Figure 3.5 DS field
The standardized PHBs are [8][9]: EF: Expedited Forwarding. The EF gives the highest level of QoS. It guarantees the bandwidth (BW) as a virtual dedicated circuit. Any traffic that exceeds the traffic profile is discard [8]. AF: Assured Forwarding. It offers different levels of forwarding assurances for IP packets. Four AF classes has been defined, where each class is in each DS node allocated a certain amount of buffer space and bandwidth [9]. Within each AF class, there are 3 different drop precedence values. The drop precedence determines the importance of the packet and, in case of congestion, the DS node tries to protect the packets with a lower drop precedence discarding packets with a higher drop level. Packets in one class must be forwarded independently from packets of another AF class. MPLS adapts perfectly to the Diffserv model because in its header has the field called EXP to propagate the CoS in the corresponding LSP. This way, a network MPLS can transport different classes from traffic, since: The traffic that flows through a certain LSP can be assigned to different queues in the LSRs, in agreement with the information contained in the bits of field EXP. Between each pair LERs it is possible to set multiple LSPs, each one of them with different characteristics and different bandwidth guarantee. For example, a LSP can be for traffic of maximum priority, another one for an average priority and third for traffic best-effort.
17
3.4. MPLS IN OPNET MODELER

Now when MPLS has been described, we need to explain what is necessary to configure in the OPNET Modeler to get a MPLS network working [2]. There are two different types of LSPs: 1) Dynamic LSPs The dynamic LSPs are signaled using RSVP o CR-LDP at the beginning of the simulation. It is possible to specify some part of the LSP with an explicit route or only specify the beginning (the ingress LER) and the end of the LSP and the protocols will find a path. In case of working with dynamic LSP with explicit routes it is necessary to specify each individual router along the path. It is needed to specify the objects in the same order that they occur in the LSP. In case of dynamic LSP with CSPF routes it is only necessary to specify the beginning and the end. Also it is possible to specify some routers or links that must be used. 2) Static LSPs Using static LSPs it is possible to specify the static route used by a LSP. In this way, you have more control about LSP routes, but in case of a router or link failure the path would fall down. For this reason, it is possible to specify a backup route when you are setting static LSPs. Before LSP are configured, the different devices of the network should have MPLS enabled and the routing protocol must be OSPF or ISIS. ISIS can not be used with the modules we have in our license, so that we have to configure the routers with OSPF. OSPF and ISIS are routing protocols that supports extensions for traffic engineering. To configure MPLS on the routers selected, it is possible to do it in this way: Select Protocol -> MPLS -> Configure Interface Status After the definition of the LSPs or any changed in one of them, it is necessary to do the next step: Select Procols -> MPLS -> Update LSP Details In order to send traffic through LSPs, it is necessary to configure more devices. You have to specify the traffic associated to a LSP. There are two more options: work with static mappings or IGP shortcuts. a) IGP Shortcuts When you are using IGP shortcuts, the network consider the LSP as a single link. In this way, you have no control about the traffic that is sent through the LSP and there are no chances of traffic engineering as it is impossible to differentiated 2 traffics going into a router. Although it can be useful in some experiments, we have tried several times to set it but it has been impossible to send the traffic through the LSP. 18
b) Static Mappings With the static mappings we are creating forwarding equivalence classes (FECs) and traffic trunks, which are used to define the different types of traffic. So, it is necessary to set in the workspace a node called MPLS Configuration and define a FEC and a traffic trunk. A traffic trunk is an abstract representation of traffic to which specific characteristics can be associated [6]. Another definition is: A traffic trunk is a set of flows aggregated by their service class and then placed on a LSP or set of LSPs called a traffic engineering tunnel [2]. It is characterized by the ingress and egress LSR, the forwarding equivalence class (FEC) and a set of attributes which determine its behavioral characteristics.
Figure 3.6 MPLS Configuration Node and their attributes
In order to define a FEC, the only needed fields we have to fill are: Give a name to differentiate one FEC of the others. Assign the destination address of the FEC: give the address of the host or network destination. The attributes that must be set to define a traffic trunk are: The name to identify the traffic trunk The characteristics of the traffic profile: maximum bit rate, average bit rate and the maximum burst size The traffic class must be configured to EF, AF11, AF12, , AF42, AF43. This is useful to define differentiated services for different traffic flows going through the same LSP. In OPNET Modeler, the priorities between the different classes are defined in the attribute called EXP <-> PHB. This attribute is a table where each value of one of these classes is mapped to a different value of PHB. The default values, called Standard Mappings give the next priorities:
EF > AF41 > AF32 > AF31 > AF22 > AF21 > AF11
19
The other classes are not defined but it is possible to define them in the MPLS Configuration node. The expedited forwarding (EF) PHB is proposed in RFC2598, whereas the assured forwarding (AF) PHB group is presented in RFC2597. After all the LSPs, FECs ans traffic trunks are created, we have to define the static mappings or the traffic engineering bindings that govern which packets are sent to one LSP or another. To set these parameters, there are two ways: 1) Manually, do it in the LERs MPLS > MPLS Parameters > Traffic Mapping Configuration attribute and specify the interface where the traffic in getting inside the LER, the FEC, the traffic trunk and the primary and backup LSPs used. 2) Set it automatically using a software developed in order to configure them. This software is called the mpls configurator and also set all the information about the FECs and the traffic trunks. The format of the files that this software uses and the way to run it will be described later in the chapter Workflow in the platform.
20
4. GENERATION OF NETWORK TOPOLOGIES

Opnet Modeler lets us generate and load a network topology in different 3 ways (or a combination of them) [2]. 1) Manually, placing individual nodes from the object palette into the workspace 2) Manually, using the rapid configuration tool 3) Automatically, by importing the network model from an external data source. It can be a system that monitors a network or one or more data files that describe the network
4.1. PLACING INDIVIDUAL NODES

The first option is useful to complete the design of an existing network model, but it is not if we are trying to simulate large networks (as is required in this work). The way to do it in OPNET is straightforward: drag and drop an object from the object palette and paste it into the workspace.
4.2. RAPID CONFIGURATION TOOL

The software also provides a technique called Rapid Configuration that lets you to quickly create standard topologies (star, tree, bus, mesh, etc.) containing many devices with a few clicks. Once a topology has been created by hand, the software provides features that allow the user to select a large number of objects and apply attribute values in one operation. This allows building regularly structured network topologies quickly and easily. You can select the type of network configuration to be builtsuch as a ring or busand specify its node models, link models, and arrangement all at once, without having to create and specify each network component individually. There are seven types of topological configurations available through this operation. They are: ring star bus tree full mesh randomized mesh unconnected network The window below shows the first window to select the type of topology:
21
Figure 4.1 Rapid configuration interface
Once it has been specified the type of network, it is possible to set the other parameters in a window:
Figure 4.2 Rapid Configuration attributes
This tool appears to be suitable for generating large networks without a fix topology (bus, star, ring, etc). For example, in the Randomized Mesh option, you can specify: the number of devices the type of device and link the number minimum and maximum of links per device At first sight, this tool seems to be what we needed. But a further analysis revealed that the network created can be not connected. This means that the network can be split in 2 parts and there is no link to reach the other. In graph theory terms, it may generate an unconnected graph. A graph is considered to be connected if a path exists between all pairs of vertices thus making each of the vertices in a pair reachable from the other. As there is no way in Opnet to find out if the generated graph is connected, we choose to discard this tool.
4.3. IMPORTING A NETWORK MODEL

4.3.1. Different Options to Import: Opnet provides different options to import a network from an external data source. The following list shows the data sources from which it is possible to import:
22
a) b) c) d) e) f)
ATM text files VNE Server HP Network Node Manager XML file Device Configuration Data ACE
The option a) is useful for importing ATM networks, but since this project is focused in analyzing MPLS networks, this is not useful. The VNE Server (option b)) is software developed by Opnet that provides an integrated view of your network where you are working. As we want to simulate networks that do not physical exist, this option is not useful for our objectives. The HP Network Node Manager is also used to get a model of your own network. When you get, it is possible to import to Opnet Modeler and then simulate what-if scenarios to get some information about your company network with more load in some servers, links or more users. However, this is not one of the goals of the project, so we must discard this option also. The option d), importing from an XML file, is a general way to import network models. The options e) and f) require others software licenses that are not available for the development of this project. Hence, we must reject them as valid options to import a network topology. 4.3.2. Importing from an XML file The minimum information we need to give to Opnet Modeler in order to import a device (ie, a router) is: The position of the device: < x , y > Give an unique name The device model (e.g. CS_4000_3s_e6_fr2_s12_tr2, ethernet2_slip8_ler, etc) The identifier of the AS (Autonomous System) Another information about the icon shown in the network to represent the device, etc.
An example of a router description in XML is:

<node name="node_1" model="CS_4000_3s_e6_fr2_sl2_tr2" ignore_questions="true" min_match_score="strict matching"> <attr name="x position" value="771"/> <attr name="y position" value="436"/> <attr name="icon name" value="cisco_4000"/> <attr name="doc file" value="nt_fixed_node"/> <attr name="tooltip" value="Cisco C4000 Router"/> <attr name="creation source" value="Object Palette"/> <attr name="creation data" value=""/> <attr name="IP Routing Parameters.count" value="1"/>
23

<attr name="IP Routing Parameters [0].Autonomous System Number" value="2"/> </node>
To introduce a link it is necessary to state the following data: A unique name The model name of the link The source and destination node name The position of the beginning and the end of the line between the nodes. That is, it is necessary to provide the position of the source and destination node The rest of the information is about the color of the line and their format and it is not so useful. Any color given is valid if it is done in the right format The minimum information necessary to generate is the next XML text:
<link name="edge_0" model="1000BaseX" class="duplex" srcNode="node_3" destNode="node_4" ignore_questions="true" min_match_score="strict matching"> <attr name="doc file" value="nt_link"/> <attr name="tooltip" value="Ethernet 10Gbps Link"/> <attr name="creation source" value="Object Palette"/> <attr name="creation data" value=""/> <attr name="arrowheads" value="head and tail"/> <attr name="color" value="#850000"/> <attr name="line style" value="solid"/> <attr name="symbol" value="none"/> <attr name="thickness" value="1"/> <attr name="polyline.count" value="2"/> <attr name="polyline [0].x" value="623"/> <attr name="polyline [0].y" value="111"/> <attr name="polyline [1].x" value="842"/> <attr name="polyline [1].y" value="86"/> </link>
General information needed to import a network in the Opnet Modeler is the view properties of the network and its sub networks: The minimum and maximum x,y parameters of the view Grid style and division x, y span Other attributes of the network: name, position, etc.
4.4 THE BRITE NETWORK GENERATOR

As described before, it is needed to use a topology generator to generate the models we want to simulate in the Opnet Modeler. The one chosen is the BRITE (Boston university Representative Internet Topology gEnerator) [10]. The main reasons of choosing BRITE are:
24
1) It is flexible, since it is possible to generate flat as well as multiple levels of networks (AS and nodes), 2) It is commonly accepted in the research community as a valid topology generator 3) It is implemented in Java (it runs in Windows and Linux OS). Other network generators are Inet [12] and Tiers [13]. 4.4.1. Running BRITE: After installing BRITE, it is necessary to decide what kind of network we want to generate. In our study we want to simulate large networks containing a large number of AS in it. BRITE offers 4 different models as it shows the next figure:
Figure 4.3 Topology types available in BRITE
1. Flat Router-level: It generates a flat network of routers, without considering the existence of different Autonomous Systems (AS). There are two different algorithms to use it: Waxmans algorithm and Barabasis algorithm. As we are interested in generating a network of more than one AS, we have to discard this option. 2. Flat AS-level: This approach appears very similar to the previous one. The main difference between the two is that AS models place AS nodes in the plane and these have the capability of containing associated topologies. The main problem with this approach is that it only generates a flat topology of ASs and doesnt show how connect them to build a final topology. 3. Top-Down Hierarchical: Top-down means that BRITE generates first an AS-level topology according to one of the available flat AS-level models (e.g. Waxman, etc.). Next, for each node in the AS-level topology, BRITE will generate a router-level topology using a different generation model from the available flat models that can be used at the router-level. BRITE uses an edge connection mechanism to interconnect router-level topologies as dictated by the connectivity of the AS-level topology. BRITE provides four different edge connection mechanisms. If (i; j) is a link in the AS-level topology, then pick a node u from the router-
25
level topology associated with AS node i, RT(i), and a node v from the router-level topology associated with the AS node j, RT(j), such that: 1) Random: u is picked randomly from RT(i) and v randomly from RT(j) 2) Smallest degree: u and v are nodes with the smallest degrees in RT(i) and RT(j), respectively. 3) Smallest degree non-leaf: u and v are nodes of smallest degree in RT(i) and RT(j) respectively but are not leaves. 4) Smallest k-degree: u and v are nodes of degree greater that or equal to k in RT(i) and RT(j) respectively. The final topology is obtained by flattening the hierarchical topology out into a router-level topology composed of the individual topologies associated with each node at the AS-level. 4. Bottom-Up Hierarchical: In this model, BRITE first generates a router-level topology using any of the available models (router Waxman, imported file, etc.). Once this topology has been constructed, BRITE assigns to each AS node (level-2 node) a number of routers according to an assignment type specified by the user. With this number of assigned routers to an AS node, BRITE groups that many nodes from the router topology following a grouping method specified also by the user as a parameter to BRITE. Unfortunately, the BRITE users guide explains that the accuracy of this approach in order to generate representative Internet topologies still has to be validated. After analyzing the 4 different options provided by this topology generator, the TopDown Hierarchical appears to be the best one to generate large networks with multiple ASs.
26
Figure 4.4 View of BRITEs GUI 4.4.2. The BRITE Output Format A BRITE-formatted output file contains three sections: 1) Model information: information about the topology contained in the file. Includes number of nodes and edges, and information specific to the model used to generate the topology. 2) Nodes: for each node in the graph, a line is written into the output file with the following format: NodeId xpos ypos indegree outgdegree ASid type The meaning of each field is described in the next table:
Field NodeId Xpos Ypos indegree Meaning Unique id for each node x-axis coordinate in the plane y-axis coordinate in the plane Indegree of the node
27

outdegree Asid Type Outdegree of the node id of the AS this node belongs to (if hierarchical) Type assigned to the node (e.g. router, AS)
Table 4.1 Description of each field of a node
3) Edges: for each edge in the graph, a line with the following format is written in the output file: EdgeId from to length delay bandwidth ASfrom ASto type The meaning of each field is described in the following table:
Field EdgeId From To length delay bandwidth ASfrom ASto Type Meaning Unique id for each edge node id of source node id of destination Euclidean length propagation delay bandwidth (assigned by AssignBW method) if hierarchical topology, AS id of source node if hierarchical topology, AS id of destination node Type assigned to the edge by classification routine
Table 4.2 Description of each field of a node
As an example, the output file listed at the end of this paragraph. It corresponds a network topology of 4 Autonomous Systems (AS) and 5 nodes in each AS. Therefore, it is a model of 20 nodes and 34 edges with the description of each element of the network. We choose not to plot this network here. This output file will now have to be adapted to the OPNET Modeler input format, done next.
Topology: ( 20 Nodes, 34 Edges ) Model (5 - TopDown) Model (3 - ASWaxman): 4 1000 100 1 0.20000000298023224 1 1 10.0 1024.0 Model (1 - RTWaxman): 5 1000 100 1 0.20000000298023224 1 1 10.0 1024.0 Nodes: ( 20 4 400 5 456 6 448 7 31 8 264

2 2
0.15000000596046448 0.15000000596046448
) 920 648 935 552 342
3 4 4 4 3
3 4 4 4 3
1 1 1 1 1
RT_NODE RT_BORDER RT_NODE RT_BORDER RT_NODE
Edges: ( 34 ) 4 7 8 5 7 4 6 5 8 7 5 4 8 6 7 9 6 5 10 4 6

313.67 521.13 361.24 277.70 566.19 287.11 50.28
1.04 1.73 1.20 0.92 1.88 0.95 0.16
10.0 10.0 10.0 10.0 10.0 10.0 10.0
1 1 1 1 1 1 1
1 1 1 1 1 1 1
E_RT E_RT E_RT E_RT E_RT E_RT E_RT
U U U U U U U
Table 4.3 BRITE output format file example
28
4.4.3. Adapting the BRITE output format to OPNET XML format In the previous chapters we describe the BRITE output format and the OPNET XML format. In order to adapt the two, a parser was developed. This parser is implemented in Java. The main parts of the parser include: A user interface where the user can set the names of the input file in BRITE format and the name of the output file in OPNET Modeler XML format. The reader of the input file that fills in the data structures to keep the information of the nodes, the edges, number of AS, number of nodes and number of edges. The writer of the output file that creates the output file in XML format. In the way it has been implemented, any of these parts can be implemented in another way or to another kind of input or output file with no modifications in the other two parts. In order to implement the parser, 3 Java classes have been designed. The node.java class and edge.java class are created to keep the information from the input file. The class pars.java is the main class which reads the input file and writes the output. In order to improve the visualization of the network it is necessary to rearrange the nodes giving them a new position in the plane. The problem is shown in the figure 4.5. This task can be split into two subtasks: 1. Split the plane in a sufficient number of parts to assign each AS to a part. For doing this, first is necessary to decide how many vertical and horizontal divisions are needed. Then, calculate the position of each division in order to place the nodes there. 2. Once every AS is assigned to a region of the plane, it is necessary to place the nodes of this AS in the determined region. The final result of the parser is shown in the figure 4.6 , apparently resulting in a more understandable network topology view.
29
Figure 4.5 - Output of the parser without rearranging of nodes, OPNET view
Figure 4.6 Parser with rearranged nodes positions, OPNET view
30
4.4.4. Generating a backbone of the network Since we are interested in studying the effects of really large networks which also reproduces the behaviour of the real networks, we need to generate networks which are divided into subnets, with one or several core networks interconnecting them. Our approach in this thesis was to take the BRITE network output file and to place the different AS as it is shown in the next diagram: X axis divisions
AS1 AS2 AS3 AS4 AS5 AS6 AS7 AS8 AS9
Yaxis divisions
Figure 4.7 Dividing the network into AS areas
In each position of the matrix, there is one AS. It is reasonable to think that the core areas have to be in the centre (the cells marked in grey in the figure above this text). In the following, we outline the algorithm that selects automatically the areas which are going to be a part of the core network. The input parameters of this algorithm are: The number of areas along the X-axis The number of areas along the Y-axis The output information is a boolean matrix that shows in every position whether it is part of the core or not. The resulting network for different inputs is shown in the following figures (the core ASs are marked in grey):
AS_x = 3 AS_y = 2
AS_x = 3 AS_y = 3
AS_x = 6 AS_y = 5
31
AS_x = 8 AS_y = 7
AS_x = 13 AS_y = 12
The algorithm takes as a parameter the relative size of the core (in number of ASs) in the examples shown above. In conclusion, after analyzing the behaviour of this algorithm, it is possible to affirm that it works in the correct way and it is useful to solve the problem whether or not an AS must be configured as an MPLS network. An example network with a core consisting of 6 ASs, is shown in the figure 4.8.
Figure 4.8 A network with an MPLS core
32
5. ADDING TRAFFIC TO THE NETWORK

After creating the network topology, the next step is to add traffic to the network. There are two options to create traffic: Manually, by setting attributes on various network objects Automatically, by importing traffic from external files or programs.
5.1. TYPES OF TRAFFIC

There are two types of traffic that can be modelled by OPNET Modeler: the explicit traffic and the background traffic [2]. Explicit traffic: This kind of traffic is packet-by-packet traffic, in which the simulation models each packet-related event (packet created, packet queued, etc.) that occurs during the simulation. Explicit traffic modelling provides the most accurate results because it models all protocol effects. However, this also results in longer simulations (more CPU instructions are needed) and higher memory usage (because the simulation allocates memory for each individual packet). There are three general methods for explicitly modelling traffic in OPNET: Packet generation: configuring certain node objects to generate streams of generic packets. This is a basic method of adding traffic to a network topology. Application demands: creating application demands to represent the traffic flowing between two nodes. The traffic generated by application demands can be purely discrete (explicit), purely analytic (background), or a combination of these two (hybrid). Application traffic models: OPNET Modeler includes a set of models for generating traffic based on standard applications such as FTP, HTTP, voice and e-mail. It is also possible to design the characteristics of a traffic application. Background traffic: Background traffic is affects the performance of explicit traffic by introducing additional delays. The simulator model includes the effects of background traffic to calculate queues on intermediate devices and delays based on the queue length, at any time during in the simulation. However, each packet of this kind of traffic is not explicitly modelled, so it will not generate an event in each state of the packet and it has not a piece of memory to keep all the characteristics of it. Hence, the simulation will be faster and use less memory. There are 3 ways of generating background traffic: Traffic Flows: A traffic flow describes an end-to-end flow of traffic from a source to one or more destination nodes. It is possible to create traffic flows
33
manually or import them from external files. You can set this traffic also as an explicit traffic modifying the value of the attribute called Traffic Mix, where is it possible to set the percentage of explicit traffic. Device/Link Loads: This type of traffic represents traffic as a background load on a link or node object. Unlike a traffic flow, which can span multiple links and nodes, a traffic load only affects to one object. It is also able convert existing link loads to traffic flows, which allows flow analyses to account for these loads. It is also possible to import device/link loads from external ASCII files. Application demands: Represent background traffic flowing between two nodes. As it has been explain before, this kind of traffic can be purely explicit, background or any combination of both types.
5.2. DETAILED TRAFFIC CONFIGURATION OPTIONS

In the following paragraphs, we give a description of each kind of traffic. Packet generation: The OPNET model library includes traffic source/sink node models. These models let you generate streams of packets that contain no protocol data above layer 2. This way of generating traffic can be useful for studying layer-2 technologies but not for studying routing protocols and MPLS. Thus, we must discard this way of generating traffic. Application traffic models: This software includes a large set of models that allow you to create explicit traffic based on applications such as FTP, HTTP, etc. In order to set this kind of traffic it is necessary to set an Application Configuration and a Profile Configuration in the workspace of the network. A profile is applied to a workstation, server, or LAN. It specifies the applications used by a particular group of users. An application may be any of the common applications (email, file transfer) or a custom application you define. Eight common applications are already defined: Database Access, Email, File Transfer, File Print, Telnet Session, Video conferencing, Voice over IP Call, and Web Browsing. Furthermore, it is necessary to place a server to answer the requests made by the different workstations and also set the parameters in the workstations and in the server. Application demands: This is an easier way to introduce traffic in the network than with application traffic models. It is not needed to configure some parameters in the sources and the destinations of the traffic, it is only necessary to configure the application demand itself. These demands characterize traffic in terms of the size and rate of the requests and responses going back and forth between two nodes. As with the application traffic models, the traffic from application demands flows as a series 34
of requests and responses between the application layers of the end nodes. The source node of the application demand sends requests to the destination node, which returns responses to the source. Traffic flows: Another type of background traffic is called a traffic flow, or background routed traffic. Unlike a device/link load, which models traffic on one link or node, a traffic flow traverses the network from one source to one or more destinations. You create traffic flows in your network using traffic flow objects. A traffic flow is a network object that connects two nodes (like a link object) and specifies: A traffic source and a traffic destination A period of simulation time, which may be divided into time slots The rate of traffic (in bits-per-second, packets-per-second, or some other measure) from source to destination during each time slot.
Figure 5.1 Traffic attribute profile for a flow object After the description of each kind of traffic and describing of setting it, the most straightforward traffic to generate and the most suitable available traffic is the application demands. An application demand has to be defined between 2 workstations and it is not possible to define it between two routers. Thus, it is necessary to introduce a workstation linked to a router to generated traffic between two nodes of the network (one workstation for the source and another for the destination of the application demand). Hence, it is necessary to modify the parser again to introduce the auxiliary workstations next to the routers chosen to have traffic between them. In the next figure, such an example is shown:
35
Figure 5.2 Workstation linked to the node
5.3. TRAFFIC GENERATOR

We developed a simple traffic generator to introduce traffic to the network topology generated by the BRITE. The source and the destination of the traffic are workstations linked to routers that are not in the core of the network. A file format has been defined in order to work together with the parser and generate an XML file for the OPNET Modeler. In case of a change of the file format, the software called pars.java has to be modified in order to be able to read the new format file. The file format is as follows: 1. Name of the BRITE file that describes the network topology 2. Number of nodes (routers) in the network 3. For each router that generates traffic it is written a row with the following format:
SourceNode <TAB> DestNode ReqSize Rate(Request/hour) RespSize Duration <TAB> DestNode ReqSize Rate(Request/hour) RespSize Duration<TAB> SourceNode and DestNode: number of the node between 0 and (numberNodes -1) ReqSize: the size of the request packet in Bytes RespSize: the size of the response packet in Bytes Rate: an integer that set the number of the requests per hour. Duration: the duration of the traffic generation in SECONDS
The separations between the source node and the destinations can also be a space instead of the TAB. This is an example of a file generated by the traffic generator:
big.brite 108 0 54 1024 15000 4096 3600 3600 94 1024 15000 4096 3600 1 48 1024 15000 4096 3600 3600 93 1024 15000 4096 3600 2 27 1024 15000 4096 3600
86 1024 15000 4096 3600 105 1024 15000 4096 3600 66 1024 15000 4096 3600
91 1024 15000 4096 92 1024 15000 4096
The traffic generated is Poisson traffic with an exponential time between request packets. The size of the request and response packets also follows the exponential distribution. The result network generated is shown in the following figure where it is possible to observe the workstations needed to set traffic between two nodes. 36
Figure 5.3 Network with added traffic
37
6. CONFIGURING THE MPLS PATHS

Once we have introduced traffic to the network, the next step is to configure a complete MPLS network. As it is explained before in chapter called MPLS in OPNET Modeler, we use the dynamic LSPs with explicit routes. In order to configure a Dynamic LSP with explicit routes it is necessary to mark each node of the LSP in the same order that they will be used. This means if the path we want to define is starts in node 5 and then continues with the nodes: 3, 4, 9 and 12, it is necessary to define the nodes in that same order. We developed a small program that takes an XML file (one generated with the pars.java) and introduces some new lines in the right place to define all the paths. The place to introduce them is after the subnet is completely defined, that means after the line </subnet>. In the next figure shows where to introduce it:
<attr name="current view" value="Default View"/> <attr name="view mode" value="geographic"/> </view-props> </subnet> INTRODUCE HERE <path name="node_28 - node_5" model="MPLS_E-LSP_STATIC" ignore_questions="true" min_match_score="strict matching"> <path-element name="Campus Network.node_28" type="node"/> <path-element name="Campus Network.node_16" type="node"/>
Figure 6.1 Place to introduce the paths definitions and the first lines of a path definition
The program paths.java generates the XML lines to define the paths in the correct place. To give the information to the program in order to generate the LSPs, it is necessary to define a file with the extension .pth with the following format: Define a row for each LSP, no additional lines are needed in the beginning of the file. A node is described by its number. The path identifier is a number to difference two paths between the same nodes. The only condition is that it has to be different for each path with the same souce and destination. It can be different for all the paths Each row has to have the next format: SourceNode <SEP> 2nd Node <SEP> Last Node <SEP> Path_ID <SEP> = TAB or SPACE The following example shows the definition of two LSP in a path definition file:
0 12 3 14 2 13 1 10 0 9
The first path is defined between the nodes 0 and 1, and uses the nodes {0,3,2,1} and its identifier is the number 0. The second starts at node 12 and then continues to 14, 13, 10, 9 and 7. The identifier of the second path is the 1. The design of the algorithm that calculates the LSPs is out of the scope of this project and it has not been implemented. This is a part of the routing engineering software.
38
Figure 6.2 Network with imported LSPs
The routing engineering software also has to create a second file where we will keep the information about which LSPs are used by a traffic flow. For each traffic between two workstations that use one or more LSPs, it has to be kept the information about its traffic trunk (AF11, AF12 EF) and the paths it takes as primary paths and the backup paths for the primary ones. The primary paths are the paths used to send traffic of a FEC between two nodes of the MPLS network. When these paths fall down, the traffic is sent through the backup paths. It is possible to select the percentage of the total traffic that is splitted to each primary path specifying values to the field weight. This file has defined with the extension .te (traffic engineering) and has the following format: For each traffic that uses it is necessary to define row, no additional lines in the beginning of the file. The traffic is identified by the source node and the destination node number A node is described by its number The traffic trunk is described by the Assured Forwarding (AF) or Expedited Forwarding (EF) class The primary paths have to have defined a weight. The backup paths must not have defined a weight. The letter P indicates the beginning of the definition of a set of primary paths The letter B indicates the beginning of the definition of a set of backup paths Each row of the file has this format:
Traffic_Source <SEP> Traf_Destination <SEP> Trunk <SEP> P <SEP> LSP_start <SEP> LSP_end <SEP> LSP_id <SEP> LSP_Weight <SEP>LSP_start <SEP> B <SEP> LSP_start <SEP> LSP_end <SEP> LSP_id <SEP> P <SEP>
39
Design and Implementation of a Traffic Engineering Research Platform based on OPNET <SEP> = TAB or SPACE
The next examples clarifies the file format: 1) 0 8 AF11 P 40 37 0 10 B 40 37 1 P 17 13 0 10 The traffic from the node 0 to the node 8 has the traffic trunk AF11 and takes 2 LSPs to reach the destination. It takes the LSP from the node 40 to the node 37 with the identifier 0 and the LSP from the node 17 to the node 13 with the identifier 0. They have defined a weight but as they are the only primary paths between the nodes the value is not important. The first path has a backup LSP from the node 40 to the 37 with the identifier 1.The order to specify the LSPs is not important. 2) 11 52 AF21 P 23 21 0 10 23 21 3 20 B 23 21 1 The traffic from the node 11 to the node 52 has the traffic trunk class AF21. Between the nodes 23 and 21, the traffic takes two different LSPs. The first path (source: 23, destination: 21, id: 0, weight: 10) absorbs the 1/3 (10/30 = path_weight/ total_amount_of weight )of the total amount of traffic and the second (source: 23, destination: 21, id: 3, weight: 20) deals with the 2/3 (20/30).
40
7. SYNTHESIZING THE WORKFLOW OF THE PLATFORM

In this chapter we synthesize the approach outlined in the previous chapters of the thesis. We begin with presenting a summary of all the steps needed to generate, import and run a simulation of an MPLS network. Then we describe how to run the simulations in an off-line manner.
7.1. WORKFLOW
In the next figure, there is a scheme describing all the steps needed to generate, import and run a simulation of an MPLS network. The numbers in the picture (shown within brackets) corresponds to the order of the tasks to perform.
(7) XML file
MPLS Configurator
XML file te file
OPNET (6)
(8)
XML file (5) Importing paths pth file
XML file Parser (3)
(4)
Routing engineering
brite file (1) BRITE
trf file Traffic generator
trf file (2)
brite file
brite file
Figure 7.1 Workflow scheme for the platform
The main steps are: 1) BRITE generation of the network topology
41
The first step is the generation of the network topology. BRITE, which is the topology generator chosen, generates an output file with the extension .brite. In the following steps, in order to clarify the examples we have assumed that the name of the file generated is NET.brite. 2) Traffic Generator The traffic generator developed is the program called trf_gen.java. It takes two parameters: the name of the brite file, which describes the network topology, and the name of the output file where the information of the traffic will be saved. There is a third optional parameter to set the duration of the traffic generation. The duration is specified in seconds. The call to run the program assuming the output file is called traffic.trf is: java trf_gen NET.brite traffic.trf or java trf_gen NET.brite traffic.trf duration 3) Parser The parser is the software which has to translate the information generated by the BRITE and the traffic generator to the XML importing format of the OPNET Modeler. It is called pars.java. This program can be run with 3 or 4 parameters. In case of 3 parameters, it is necessary to specify the topology (BRITE) file, the name of the output XML file and if we want to set the whole network as a MPLS or only a core MPLS network. In case of 4 parameters, the third file contains the traffic information that will be also translated to the XML format to import the topology and the traffic information at the same time. If the traffic it is not introduce here, the only option to introduce it is do it in the step 6) manually. The call with 3 parameters is: java pars NET.brite netXML.xml all all = true or false The call with 4 parameters is: java pars NET.brite netXML.xml all traffic.trf all = true or false 4) Routing engineering The routing engineering program is the software in charge of calculating the optimal traffic distribution and routing scheme that gives the best performance of the whole network. We defined the output format file to import these paths to the network but the development of this program is out of the goals of this project. The format of this file is described before in this thesis and with the extension .pth. This software has to generate a second file that indicates which LSPs are used by each traffic. 5) Import of the LSP The program, that has to generate the XML code in order to import the LSP, also has to add this code to the file generated from the parser. This program
42
needs 3 parameters: the name of the file generated by the parser (.xml), the file generated by the routing engineering (.pth) and the name of the new output file (.xml). The call to run this program is: java paths netXML.xml opnet.xml paths.pth 6) OPNET In the OPNET Modeler it is necessary to do more than one step. 6.1. Run the OPNET modeler 6.2. Generate a new file File New Project Introduce the name of the project and scenario 6.3. Import the XML file Topology Import Topology From XML File select the XML file to import 6.4. Check the links and repair some of them if it is necessary 1. Double click on the subnet icon to get into the subnet
Figure 7.2 Subnet icon
2. If the number of traffic demands is so high that it is difficult to visualize the network, it is possible to hide them: View Demands Hide All or Ctrl+Shift+M 3. Verify links in order to detect if there is a problem with the import file Topology Verify Links or Ctlr+L or click on the icon
Figure 7.3 Verify links icon
4. After that, a new window appears and you have to select the option: Verify Links 5. The failed links has been selected and shown in the screen with a red cross on them. 6. If there is a one or more failed links, repeat the step 3 and then select the option: Choose transceivers for selected links
Figure 7.4 Verify links window
7. At the end of the process, it must be useful to repeat the step 3 in order to check there is no other problem with any link 6.5 Set OSPF
43
If we want to simulate an MPLS network or we want to run the simulation with this protocol, we have to do the next command to set it. Otherwise, the simulation will be done with RIP. Protocol IP Routing Configure Routing Protocols and set the window as it is shown in the next figure:
Figure 7.5 Routing Protocol Configuration Window
6.6 Auto assign IP In order to set the MPLS network, it is necessary to define the different FECs in it. In order to define a FEC, we have to know the IP address of the destination of the traffic. There is the option to set all the IP address automatically with the next call: Protocols IP Addressing Auto-assign IP Addresses NB: If the network you want to simulate is not an MPLS network, go to the step 8 to set the simulation parameters 6.7 Update LSP details Select Procols MPLS Update LSP Details
6.8 NB: If the network you want to simulate is not an MPLS network, go to the step 8 to set the simulation parameters Export the net to a new or the same XML file in order to get the file to generate the info for the MPLS configurator. Topology Export Topology To XML Entire Network And choose the file to keep the information. 7) MPLS Configurator This program has to set all the parameters in the LERs and the MPLS Configuration. This software generates a new XML file with all the parameters configured in order to import it again to OPNET. To import the file, follow the instructions described before in this chapter. This software takes 3 parameters: the name of the file exported by OPNET Modeler (.xml), the name of the traffic engineering file (.te) and the name of the output file where to save the information generated (.xml). The call to run this program is:
44
java mpls_conf opnet.xml trf_eng.te mpls.xml 8) OPNET This is the last step of the workflow where it is necessary to do the following steps: 8.1 Run the OPNET Modeler (if it is not running) 8.2 Choose the name of the file where we want to save the network. There are two different options: use the same file we have worked with before or create another file. In order to create another file, select: File New Project Introduce the name of the project and scenario In order to use the same file, open the file you have been working with before. 8.3 Import the new file generated by the mpls configuration software. Topology Import Topology From XML File select the XML file to import (in the example called mpls.xml) 8.4 Specify the statistics we want to collect. There are two different ways to do it: o Using the project editor by a right-click on the mouse and choosing the option: Choose DES Statistics o Using the probe editor to specify the statistics you want to collect. If we used this option, later we have to set in the network model the file where we have saved the information about the data collection. In order to do this last step, we have to expand the output tree element in the Run Simulation menu and set the probe file to the one we have just created. 8.5 Set the parameters to run the simulator. Select: DES Configure/Run Discrete Event Simulation In the new window it is possible to set the duration of the simulation, the seed of the random-generator and other parameters as the one described in the last step. None of them are needed. Once every parameter is set, we can save the parameters clicking on the button Apply and run later the simulation, or click the button Run to start the simulation (the parameters will be also saved). In the following picture, there is an screenshot of the Configure/Run DES window:
45
Figure 7.6 Configure/Run DES window
8.6 After the simulator is done, open the DES Log and check there were no errors during the simulation. Afterwards, check the results in the project editor or the analysis tool.
7.2. RUN A SIMULATION WITHOUT THE GUI

Another goal of this project was the capability to run a simulation via the command line (without the Graphical User Interface). Using the command line allows you to generate batches of simulations and to run simulations on remote workstations. In OPNET, the simulations are executed using the program op_runsim, either from the GUI or from the command line interpreter [2]. There are 3 methods of executing a simulation: 1) Run it from the graphical user interface 2) Run it from the command line using op_runsim 3) Create an executable file using op_mksim. Afterwards, run the executable created. Executing the simulation program from the shell is the same as executing any other program; it is only necessary to introduce the name of the program and the options to set what network we want to simulate, the duration of the simulation, etc. Under UNIX, the program must have the file execution permission set for user, group or other, depending on the relationship between the owner of the program and the login account. Under Windows, it is only necessary to have privileges to run the program. Only one argument is really needed to run a simulation: the names of the network model, but most of the simulations have more than one to set the seed, the duration, etc. It is possible to get the full list of arguments in the OPNET Modeler documentation or executing:
% op_runsim help
46
There are two kinds of preference assignments: static and dynamic. Static preferences are fixed options supported by all simulations (duration, seed, etc) and the dynamic ones are values that are not assigned during the generation of the network and the value is asked before the simulation. These values can be set to the default value and when you run a simulation with the GUI, these attributes are set to the default value. In order to set them in the default value, it is necessary to set the argument noprompt to TRUE. The table 7.1 shows the most common arguments:
-probe -ov_file -os_file -duration -seed -noprompt Specifies the probe list file that the simulation references for statistics gathering. Specifies the name of the output vector file that will capture all vector statistics selected by probes; if this preference is not specified, but vector statistics are probed, then the output vector file will have the same name as the simulation Specifies the name of the output scalar file that will capture all scalar statistics selected by probes or written by KPs; if this preference is not specified, no scalar values will be saved in a scalar output file by the simulation Specifies the length of the simulation (in seconds). Specifies the random number generator seed value. Causes the OPNET program to suppress prompts for the values of any unassigned dynamic preferences.
Table 7.1 Most common line arguments
An example of the called to run the simulation is:

% op_runsim net_name mpls-scenario1 seed 80 duration 3600 noprompt TRUE
As any other executable file, simulation sequences can be defined via shell scripts (UNIX) or batch files (Windows). They are also possible to execute via the opnet Simulation Tool. These programs allow us to run different simulations with different input parameters. The main advantages of scripts over the Simulation Tool are: They are little programs, so they need less memory resources than OPNET Modeler Scripts can execute simulations on remote hosts and can do it concurrently(more simulations executing at the same time) Configure a remote simulation environment In order to run a simulation in a remote machine it is necessary to install and configure OPNET Modeler correctly in the remote machine (most of the steps are described in the first chapter in this report but it is possible to find more information in the installation information). You also have to transfer any non-standard models needed for the simulator and all the files created when you are designing the network. Finally, run the simulation either from the simulation tool in OPNET or from the command line.
47
8. CONCLUSIONS
In this thesis we have designed and implemented a traffic engineering research platform based on OPNET. The design of the platform is such that it should give the most general software possible, still it should allow us to work efficiently with the traffic engineering software and the OPNET simulator simultaneously. The OPNET Modeler is a powerful software network simulator often used in traffic engineering research. One problem we have experienced with this simulation software is that it is necessary to specify a large set of parameters in order to run a simulation. Probably, this is due to the fact that this software was developed to be mainly used as a simulator of real networks and to implement realistic what-if scenarios to find out what happens to network performance in case of an increased number of users, changed network design and/or changing traffic patterns. The resulting workflow becomes quite complex and it is not totally automatic, mainly restricted by operational limitations in OPNET itself. On the other hand, OPNET seems to be a complete set of software that ensures us the results we get are valid for a large set of problems.
48
APPENDIX A: GLOSSARY
AF: Assured Forwarding AS: Autonomous System BGP: Border Gateway Protocol BRITE: Boston university Representative Internet Topology gEnerator CoS: Class of Service CR-LDP: Constraint Routed Label Distribution Protocol DES: Discrete Event Simulation DiffServ: Differentiated Services DS: Differentiated Services DSCP: Differentiated Services Code Point EF: Expedited Forwarding FEC: Forwarding Equivalence Class FSM: Finite State Machine FTP: File Transfer Protocol GUI: Graphical User Interface HTTP: HyperText Transfer Protocol IETF: Internet Engineering Task Force IP: Internet Protocol ISIS: Intermediate System to Intermediate System LAN: Local Area Network LDP: Label Distribution Protocol LER: Label Edge Router LIB: Label Information Base LSP: Label-Switched Path LSR: Label Switching Router MPLS: Multi-Protocol Label Switching OS: Operating System OSPF: Open Shortest Path First PDF: Probability Density Function PHB: Per-Hob Behaviour QoS: Quality of Service RFC: Request For Comment RSVP: Resource reSerVation Protocol RT: Router-level Topology TE: Traffic Engineering ToS: Type of Service TTL: Time To Live WWW: World Wide Web
49
APPENDIX B: LIST OF CLASSES DEVELOPED

In this appendix, there a little description of each class developed to help the users of this platform to change something if it is necessary to develop new features.
Pars.java
This class generates (translates) an XML code from the files generated by the BRITE and the traffic generator. The output file always consider the first node as node_0, it doesnt matter the identifier of the first node in the input BRITE file. This class uses core.java to calculate whether a node is in the core MPLS network or not. The classes node.java and edge.java are used to keep the information of the nodes (routers) and edges (links) read from the BRITE file.
Core.java
The core class generates a matrix of number divisions in x-axis per the number of divisions in the y-axis. In every position of the matrix, a boolean value indicates if the position is a member or not of the mpls core.
Node.java
It is used to keep the information about one node in the BRITE file. There is a get and a set method for each attribute of the class. The method print could be used as a debugger method.
Edge.java
It is used to keep the information about one edge in the BRITE file. There is a get and a set method for each attribute of the class. The method print could be used as a debugger method.
Test_core.java, test_edge.java & test_core.java

They are used to test the well-work of the classes core, edge and core.
Traffic_gen.java
It generates the file that has the information about the traffic. It uses also the classes core, edge and node. The first identifier it considers in the number 0 as the parser does.
Paths.java
This software merges the file generate from the parser and the file generated by the traffic engineering software that describes the paths. The file generated by this class is imported by the Opnet.
Mpls_conf.java
This program takes the file exported by the Opnet and the file generated by the traffic engineering software and generates the xml file with all the devices configured. This program uses the classes: trunk_list.java, back_list.java, path_list.java and traffic_list.java. The traffic_list keeps the information of the source and destination of all the traffic flows that use any LSP. The path_list class has for each LER of the network the information about the traffics getting into the MPLS network (source,
50
destination and identifier). The trunk_list has the information of the name of all the traffic trunks in the network. The back_list has for each traffic flow and LER the information of the primary LSPs and the backup LSPs. First this program gets the IP address information from the XML file and then loads the information of the input files to the data structures. At the end, makes a copy of the input XML file to the output XML file adding the information in the right places.
Trunk_list.java
It keeps a list of all the different traffic trunks defined in the traffic engineering file (.te). It has the methods to add an element to the list, get the component in a specific position of the list and get the length of the list.
Traffic_list.java
It is a class to keep the information about the source and the destination of several traffics. It is used in the mpls_conf class to keep the information about the traffic flows that are using at least one path. It has the methods to add one traffic into the list, get the number of elements of the list and get the source and the destination of a position of the list.
Path_list.java
It is a list of paths_te objects (from paths_te.java). It has the typical methods of a list, such as add an element, get the object in a specific position and get the number of elements of the list. It is used in the mpls_conf to keep for each path the information about the sources and destinations of the traffic flows that use it.
Paths_te.java
This class keeps the information of the traffic flows that uses a LSP.
Back_list.java
It is a list of back objects (from back.java). It has the typical methods of a list, such as add an element, get the object in an specific position and get the number of elements of the list. It is used in the mpls_conf to keep the information about the primary paths and the backup paths for a given traffic and a given LER.
Back.java
This class keeps the information of the primary paths and the backup paths for every path and source.
51
REFERENCES
[1] Modeler Installation Instructions for Windows NT/2000/XP, https://secure.opnet.com/Lic_Priv/support/install_instructions/110/mdlr_11_inst all.pdf (password required) OPNET Modeler 11.0 Documentation E. Rosen, A. Viswanathan, R. Callon, Multiprotocol Label Switching Architecture, RFC 3031, January 2001 R. Gallaher, An Introduction to MPLS, http://www.convergedigest.com/Bandwidth/archive/010910TUTORIALrgallaher1.htm Trillium, Multiprotocol Label lights.org/networking/mpls.pdf Switching (MPLS), http://blinky-
[2] [3] [4]
[5] [6] [7] [8] [9] [10]
D. Awduche, J. Malcolm, J. Agogbua, M. O'Dell, J. McManus, Requirements for Traffic Engineering Over MPLS, RFC 2702, September 1999 S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, An Architecture for Differentiated Services, RFC 2475, December 1998 V. Jacobson, K. Nichols, K. Poduri, An Expedited Forwarding PHB, RFC 2598, June 1999 J. Heinanen, F. Baker, W. Weiss, J. Wroclawski, Assured Forwarding PHB Group, RFC 2597, June 1999 Alberto Medina, Anukool Lakhina, Ibrahim Matta, John Byers, BRITE: Universal Topology Generation from a Users Perspective, April 2001, http://www.cs.bu.edu/brite/ 47th IETF Meetind in Adelaide, http://www.ietf.org/proceedings/00mar/47thietf-00mar-74.html University of Michigan, Inet Topology Generator, http://topology.eecs.umich.edu/inet/ J. M. S. Doar, http://www.isi.edu/nsnam/ns/ns-topogen.html#tiers The Network Simulator- NS-2, http://www.isi.edu/nsnam/ns/
[11] [12] [13] [14]
52

Xavi Report

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Xavi Report

Uploaded by

Copyright:

Available Formats

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

Supervisor: Dr. Ulf Ahlfors

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

1.1. SCOPE OF THIS THESIS

ROUTING ENG. SOFTWARE

Figure 1.1 Relationship between the different softwares

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

1.3. OUTLINE OF THESIS

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

2. INTRODUCTION TO OPNET MODELER

2.1. INSTALLING OPNET MODELER

In order to set an environment variable in Windows XP, it is necessary to do the following:

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

Figure 2.1 Main window OPNET Modeler 11.0

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

2.2 OPNET MODELER TOOLS

Figure 2.2 Example of an MPLS network

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

Figure 2.3 Internal structure of a router in the node editor

Figure 2.4 Process editor models

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

2.3. THE MODELER WORKFLOW

1. Create Network Models

4 .View and analyze results

Figure 2.5 Diagram of Modeler Workflow

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

3.1. FORWARDING PACKETS IN AN MPLS NETWORK:

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

An example MPLS network is shown below, in figure 3.1.

Figure 3.1 Topology of an MPLS network

Figure 3.2 MPLS shim header and format

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

A 18 C A Table 3.1 A Label Switch Routers Label Information Base (LIB)

Figure 3.3 LSR performing its label-swapping functions

3.2. MPLS LABEL DISTRIBUTION AND SIGNALING:

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

3.3. MPLS APPLICATIONS:

Figure 3.4 Comparison between the shortest path and TE path

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

Defined in RFC 2474

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

3.4. MPLS IN OPNET MODELER

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

Figure 3.6 MPLS Configuration Node and their attributes

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

4. GENERATION OF NETWORK TOPOLOGIES

4.1. PLACING INDIVIDUAL NODES

4.2. RAPID CONFIGURATION TOOL

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

Figure 4.1 Rapid configuration interface

Figure 4.2 Rapid Configuration attributes

4.3. IMPORTING A NETWORK MODEL

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

An example of a router description in XML is:

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

4.4 THE BRITE NETWORK GENERATOR

Design and Implementation of a Traffic Engineering Research Platform based on OPNET

Figure 4.3 Topology types available in BRITE