activity report · o queue modules: provide a superset of the functionality of processor modules,...

Investeşte în oameni! Proiect cofinantat din Fondul Social European prin Programul Operaţional Sectorial pentru Dezvoltarea Resurselor Umane 2007 – 2013 Axa prioritară: 1 „Educatie si formare profesionala initiala de calitate in sprijinul dezvoltarii si cresterii

economice” Domeniul major de intervenţie: 1.5 „Programe doctorale si postdoctorale in sprijinul cercetarii” Titlul proiectului: Proiect de dezvoltare a studiilor de doctorat in tehnologii avansate- ”PRODOC”

Cod Contract: POSDRU 6/1.5/S/5 Beneficiar: Universitatea Tehnica din Cluj-Napoca

ACTIVITY REPORT

Host Advisor:

Prof. Dr. Ing. Jordi DOMINGO PASCUAL

Ph.D. Advisor: Ph.D. Student:

Prof. Dr. Ing. Virgil DOBROTĂ Ing. Georgeta Lucia BOANEA

-2010-

2

Contents

1. Overview of the OPNET network simulator ............................................................................. 3

1.1 OPNET modeler architecture ............................................................................................. 4

1.2 Modeling Domains ............................................................................................................. 6

Network Domain........................................................................................................................ 6

Node Domain ............................................................................................................................. 6

Process Domain ......................................................................................................................... 7

2. Analysis of the OSPF routing protocol in case of congestion ................................................. 11

2.1 OSPF in OPNET overview ............................................................................................... 11

2.2 Test network ..................................................................................................................... 12

2.3 Simulations and results ..................................................................................................... 13

3. The IP package of the OPNET network simulator .................................................................. 16

4. Implementation of SAMP, a new multipath routing algorithm in OPNET simulator ............. 21

4.1 Steps for modeling a new process .................................................................................... 21

4.2 Flow-Identification module .............................................................................................. 25

4.3 Management application module ..................................................................................... 27

4.4 Routing application module ............................................................................................. 29

5. Bibliography ............................................................................................................................ 33

3

1. Overview of the OPNET network simulator

The OPNET Modeler software package is among the most comprehensive tools available on the

market for modeling new communication technologies and protocols. OPNET Modeler includes a

vast model library of communications devices, communication mediums, and cutting-edge

protocols. It also allows users to extend models and create new ones using C/C++.

The OPNET simulator is very complex and because of this, in the present document I will focus

only the components that are important in the implementation of a new module.

Regarding the modeler architecture there are three major categories that correspond to the three

phases of modeling and simulation projects:

Model Specification and Modeling Communications with Packets

Data Collection and Simulation

Analysis

Figure 1-1: OPNET architecture

Some of the simulator features are:

Object orientation: configurable sets of attributes, characteristics in terms of behavior and

capability. Definitions of new classes are supported to address as wide a scope of systems

as possible.

Specialized in communication networks and information systems: high leverage for

modeling of networks and distributed systems.

Hierarchical models: OPNET models are hierarchical, naturally paralleling the structure

of actual communication networks.

Graphical specification

Flexibility to develop detailed custom models: flexible, high-level programming language

with extensive support for communications and distributed systems. This environment

allows realistic modeling of all communications protocols, algorithms, and transmission

technologies.

Automatic generation of simulations: model specifications are compiled automatically

into executable, efficient, discrete-event simulations implemented in the C programming

language.

Application-specific statistics: built-in performance statistics that can be collected

automatically during simulations. Modelers can also augment this set with new

application-specific statistics that are computed by user-defined processes.

4

Integrated post-simulation analysis tools: performance evaluation, and trade-off analysis

require large volumes of simulation results to be interpreted.

Interactive analysis: a sophisticated interactive debugger.

Animation: simulation runs can be configured to automatically generate animations of the

modeled system at various levels of detail and can include animation of statistics as they

change over time.

Cosimulation: connect OPNET Modeler with one or more other simulators.

Application program interface (API): models and data files may be specified via a

programmatic interface.

1.1 OPNET modeler architecture

OPNET Modeler supports the concept of model reuse so that most models are based on lower

level models developed beforehand and stored in model libraries. OPNET Modeler supports

model specification with a number of tools, called editors, which capture the characteristics of a

modeled system's behavior. Models built in the Project Editor rely on elements specified in the

Node Editor; in turn, when working in the Node Editor, you use models defined in the Process

Editor and External System Editor.

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

Network Domain in which the Project Editor works is the highest modeling level, in the

sense that it encompasses objects that are defined in the other modeling domains. The

Project Editor provides operations to support the creation, editing, and verification of

network models.

Node Editor: develop node models. Node models are objects in a network model. Node

models are made up of modules with process models. Modules may also include parameter

models. Nodes are composed of several different types of objects called modules. At the

node level, modules are black boxes with attributes that can be configured to control their

behavior. Each one represents particular functions of the node's operation and they can be

active concurrently. Several types of connections support flow of data between the

modules within a node. The objects used to build node models are:

o Processor: general purpose, programmable object whose behavior is specified by a

process model.

o Queue: like a processor, but also provides internal packet queuing facilities.

o Transmitter: allows packets to be sent outside of the node's boundary via attached

links.

o Receiver: allows packets to be received from other nodes via attached links.

o Packet Stream: connects an output stream of a source module to the input stream

of a destination module, allowing packets to be communicated and buffered

between them.

o Statistic Wire: connects an output statistic of a source module to the input statistic

of a destination module, allowing numerical data to be communicated.

5

o Logical Association: indicates a coupling between two modules. Currently

supported for appropriate transmitter-receiver pairs only to specify that they be

kept together when attaching the node to a link.

o Esys Module: contains both a process model and an external system definition

(ESD).

Process Editor: develop process models. Process models control module behavior and

may reference parameter models. Process models are instantiated as processes in the Node

Domain and exist within processor, queue, and esys modules. Processes can be

independently executing threads of control that do general communications and data

processing functions. Process models use a finite state machine (FSM) paradigm to express

behavior that depends on current state and new stimuli. FSMs are represented using a state

transition diagram (STD) notation. The states of the process and the transitions between

them are depicted as graphical objects. The objects used to build node models are:

o State: Represents a mode of the process which has been attained due to previous

stimuli and corresponding decisions.

code expressing processing that is performed immediately after they are

entered, or immediately before they are exited;

can be forced or unforced;

a process blocks immediately upon executing the enter code of an unforced

state, at which point it waits for a new interrupt before continuing;

o Transition: Indicates a possible path that a process can take from a source state to

a destination state.

condition statement which specifies the requirements for the process to

follow the transition;

executive statement specifies actions that are to be taken when the process

does follow the transition;

o Model-level information "blocks": blocks of text specify additional components

of the process.

declaration of state (persistent), and temporary (scratch) variables;

user-defined functions that can be called by the process' states and

transitions;

code to be executed upon process termination;

declaration of globally-scoped variables;

data structures;

External System Editor: develop external system definitions. External system definitions

are necessary for cosimulation.

Link Model Editor: create, edit, and view link models.

Packet Format Editor: develop packet formats models. Packet formats dictate the

structure and order of information stored in a packet.

ICI Editor: create, edit, and view interface control information (ICI) formats. ICIs are used

to communicate control information between processes.

PDF Editor: create, edit, and view probability density functions (PDFs). PDFs can be used

to control certain events, such as the frequency of packet generation in a source module.

6

1.2 Modeling Domains

Network Domain

A network model defines the overall scope of a system to be simulated; it specifies the objects in

the system, as well as their physical locations, interconnections and configurations. The size and

scope of the networks modeled can range from simple to complex. A network model may contain

one node, one subnetwork, or many interconnected nodes and subnetworks. It is a high-level

description of the objects contained in the system.

Node Domain

Network models in OPNET Modeler are constructed from two broad classes of components:

communication nodes and communication links. The internal structure of these objects, for the

most part, is not visible at the network level. The system provided by OPNET Modeler is

powerful enough to specify virtually any form of communication node; moreover, it supports

reusability of node substructures.

Node modeling system is based on a block-structured approach. It is a natural technique for

describing hardware systems, and can also be an effective tool when describing the relationships

between high-level software objects with well defined interfaces.

A node model is composed of a series of connected blocks called modules. Each module contains

a set of inputs and outputs, some state memory, and a method for computing the module's outputs

from its inputs and its state memory. The manner in which this computation takes place depends

upon the type of module.

Node models specify the manner in which the inputs and outputs of various modules are

connected using objects called connections. There are two types of connections:

o packet stream object: to carry data packets, send data packets over its output packet

streams, and receive them from its input packet streams;

o statistic wire object: to transmit individual values, send individual values over output

statistics, and receive them from input statistics.

o logical associations: special connections that to not actually carry data between modules,

the purpose is to indicate that a relationship exists between two modules in a node model

The main modules are:

o Process modules: the primary general-purpose building blocks of node models. Their

behavior can be completely specified by setting their "process model" attribute, which

specifies the process model to be executed by the module. Can be connected to other

modules to send and receive packets via any number of packet streams. The processor

often communicates directly with other modules through statistic wires or remote

interrupts. These modules have a number of built-in attributes that configure their

behavior. Process model attribute interfaces allow the process model developer to specify

values in advance for processor built-in attributes.

o Queue Modules: provide a superset of the functionality of processor modules, they can

execute an arbitrary process model that describes the behavior of a particular process or

protocol, and can be connected via packet streams to other modules, allowing them to send

and receive data packets. Each queue module contains a definable number of subqueues. A

7

subqueue is an object which is subordinate to the queue object and which has its own

attributes used to configure it. Subqueues may be selected directly by a physical index, or

via abstract indices, which allow the process model to choose a subqueue based on its

state relative to other subqueues.

o Esys Modules: provides a superset of the queue's functionality.

o Transmitter Modules: serve as the outbound interface between packet streams inside a

node and communication links outside the node. There are two types of transmitter

modules, corresponding to the different types of communication links: point-to-point and

bus. Transmitter modules can collect packets from one or more input packet streams and

relay them over corresponding channels within the communications link. Packets arriving

on an input stream while the corresponding channel is busy with a previous packet are

automatically queued in a buffer. This buffer has a default capacity of 1000 packets of any

size.

o Receiver Modules: serve as the inbound interface between communication links outside a

node and packet streams inside the node. There are two types of receiver modules,

corresponding to the different models of communication links: point-to-point and bus.

From the point of view of the network model, a receiver module acts as an input port, to

which a communication link of the corresponding type may be connected: simplex and

duplex links to point-to-point receivers and bus links to bus receivers.

Process Domain

A process is an instance of a process model defined with the Process Editor. In other words, each

process model may be assigned too many QPs (modules, queues, and processors) within one

system. Individual processes or groups of processes are defined to implement a particular task

when placed within a QP.

Interrupt-Driven Execution

o One of the first actions that is generally taken by a process upon being interrupted is to

determine what type of interrupt has occurred.

o A process always begins the simulation in a resting mode, waiting to be invoked; a process

that is waiting in this conditions is said to be blocked.

o After these actions are completed, the process must again block, returning control to the

Simulation Kernel.

o Simulation time observed at the start and at the end of an event, must always be identical.

8

Figure 1-2: Interrupt-Driven Execution

Dynamic Processes

At the moment when a simulation begins, each QP hosts only one process that is automatically

created by the Simulation Kernel: root process: "process model" attribute. One QP might be

the host to many processes that cooperate to implement its function within the surrounding

node model.

Processes that are created by other processes (as opposed to the root processes created by the

Kernel) are referred to as dynamic processes.

Process hierarchy: the root is involved in the first generation of dynamic processes, these may

then in turn create new processes, which would be referred to as second generation. A process

is capable of creating child processes of any type (i.e., based on any process model), including

its own or the type of its parents. Processes can be destroyed as well as created, the process

hierarchy may shrink as well as grow, and „holes" may appear at certain levels within in the

process hierarchy, corresponding to the fact that certain processes have no active parent

processes.

Figure 1-3: Dynamic Processes

Shared Memory Architecture: the Simulation Kernel provides three communication

mechanisms that allow multiple processes to share information:

9

o QP-level shared memory: placing information in a common area;

o Parent-to-child shared memory: private shared memory area to be set up at the

time that a child process is created;

o Argument memory: the memory address points to a block of memory whose format

is user-defined and the two processes must be designed to agree on how its

contents are organized (invoke process).

Process model components

A process model must describe the actions that a process will implement under all possible

circumstances. OPNET Modeler supports one language for developing models of processes, called

Proto-C; it is supported by the Process Editor which is integrated into the OPNET Modeler

application. Proto-C provides a powerful and efficient method for describing the behavior of

discrete event systems; it offers the following major features:

based on state transition diagrams (STDs)

combined graphical/textual representation

ability to represent general state information

dynamic process creation

efficient execution: Proto-C diagrams and the logic contained within are translated to the C

and C++ languages with minimal overhead.

1. State Transition Diagrams

Proto-C models consist of two basic component types: states and transitions. States are generally

used to represent the top-level modes that a process can enter. Transitions specify the changes in

state that are possible for the process. STDs are graphically depicted in the Process Editor.

States. The word state refers to an object that corresponds to one of the primary modes or

situations that a process may find itself in. States are mutually exclusive and

complementary, meaning that a process is always in exactly one state: more than one state

may never be occupied at a time. The process can move between states in response to the

interrupts that it receives. The transitions that depart from a state indicate which states may

be occupied next, and the condition that each change requires. Two types of states that

differ in execution-timing:

o Unforced: allow a pause between the enter executives and exit executives, and thus

can model true states of a system. After a process has completed the enter

executives of an unforced state, it blocks and returns control to the previous context

that invoked it. At this point, the process remains suspended until a new invocation

causes it to progress into the exit executives of its current state.

10

Figure 1-4: State Transition Diagrams

o Forced: do not allow the process to wait, exit executives of a forced state are

executed by a process immediately upon completion of the enter executives.

One special state, called the initial state, must be designated in each process model. The

initial state is the point at which execution begins on the first invocation of the process.

Upon receipt of the first interrupt, entry into the initial state takes place at the beginning of

the enter executives.

11

Transitions. Transitions describe the possible movement of a process from state to state

and the conditions under which such changes may take place. There are four components

to a transition's specification: a source state, a destination state, a condition expression,

and an executive expression. Each state may have any number of outgoing and incoming

transitions depicted as directed arcs with the arrow pointing toward the destination state.

The condition and executive expressions appear in a combined label next to the arc. The

tool always places the condition expression within parentheses and precedes the executive

expression by a forward slash (`/') to separate the two components. Transitions that have

non-empty condition expressions are depicted as dashed arcs; those without conditions are

depicted as solid arcs.

A transition's condition is evaluated as a boolean expression to decide whether or not the

process should enter the transition's destination state. A process evaluates outgoing

transitions after the exit executive statements of the source state have completed.

All transitions that depart from a state are evaluated before a process may progress to any

transition destination. A special condition called default is provided to represent the

complement of the conditions associated with the defined transitions leaving a state.

2. Analysis of the OSPF routing protocol in case of congestion

2.1 OSPF in OPNET overview

Model parameters:

1) Process parameters:

Start Time: specifies a distribution for the OSPF protocol’s start time on all interfaces

of the router.

External Route Information: specifies static routing information for areas of the

network that does not use a dynamic routing protocol.

Area Summarization: specifies route aggregation on border routers of an area.

Virtual Links: specifies a list of virtual links connecting this router to other area border

routers (ABRs). This attribute must be configured on both routers (one at each end) of

the virtual link.

SPF Calculation Parameters: specifies parameters that determine how and when

routing table calculations are done.

Reference Bandwidth: specifies the reference bandwidth used to calculate interface

cost.

2) Interface Information

Type: specifies the type of technology (Broadcast, Point To Point, Non-Broadcast,

Point-to-Multipoint, or MANET)

Router Priority: specifies the router priority used to perform designated router (DR)

election.

Area ID: specifies the area the interface belongs to.

Process Tag: specifies the OSPF process (es) that this interface belongs to.

Cost: specifies the cost of sending a packet on the interface.

12

Timers: Hello Interval, Router Dead Interval, Interface Transmission Delay,

Retransmission Interval.

Neighbor List: specifies the IP interface addresses of the neighboring routers.

Model architecture:

Figure 2-1: OSPF model architecture

The OSPF module is directly connected to the IP Encapsulation/Decapsulation module that

communicates with the IP component. This connection is necessary for the transmission of the

Hello messages.

2.2 Test network

The architecture of the test network is presented in the figure below. This is the same architecture

as the real testbed, the scope is to observe the simulator behavior in this case.

Figure 2-2: OSPF test network

Network components:

1. Router: Cisco 7609

o OPNET name: CS_7609_9s_a2_ae8_fr4_sl8_adv

o Technologies:

13

ATM: 2 interface

Ethernet: 8 interface

Frame Relay: 4 interface

SLIP: 8 interface

2. Workstation: HP j6750

o OPNET name: HP_wkstn_j6750_2CPU

o Characteristics: server with client-server application support running over TCP/IP

and UDP/IP

o Technologies:

Ethernet: 4 interface (selectable data rate)

SLIP: 4 interface (selectable data rate)

3. Application definition: Video Conferencing-High Resolution Video

4. Profile Definition:

o Start Time (s): uniform(100, 110)

o Duration (s): End of simulation

5. Connections: Ethernet connection operating at 100Mbps

o OPNET name: 100BaseT duplex link

2.3 Simulations and results

The observations are focus on the traffic sent from node6 to node7.

Simulation setup

Figure 2-3: OSPF simulation setup

Two testing scenarios:

1. No congestion

Traffic node5-> node7 and node6 -> node0

14

Figure 2-4: Video conference data rate

The transmitted traffic corresponds to a video conferencing at high resolution. This is a standard

application defined in the simulator. From the graphic we can observe that the traffic has a CBR

characteristic with a data rate about 8.5Mbps. In a real environment the graphic of the traffic

would be different because the data rate would vary around a mean value. In the future to obtain a

variable data rate (condition closer to the real situation) we will use a input file with real traffic.

OSPF traffic

Figure 2-5: OSPF traffic

15

The traffic generated by the OSPF routing protocol is send in the first 5 minutes of the

simulation time. The main traffic is sent in the first 2 minutes, after this period the network

is stable and the routing tables in each node are complete.

2. Congestion on link node3 -> node5

After 5 minutes of simulation we generate background traffic between node3 and node5 of

100Mbps

Figure 2-6: Background traffic

Traffic node5-> node7 and node6 -> node0

Figure 2-7: Video conference data rate

From the figure above we can observe that because of the introduced background traffic the data

rate of the transmitted video traffic between node5 and node7 drops below 1Mbsp from

approximately 8.5Mbps. This fact has as consequence the degradation of the received quality.

16

Regarding the OSPF behavior we can observe that the routing protocol does not change the path

of the flow even if more than one alternative route is available.

The OSPF traffic is the same as in the previous scenario because there is no change in the OSPF

routing tables.

3. The IP package of the OPNET network simulator

The IP module is one of the main components in an ip communication system of the OPNET

simulator. The main responsibility of this module is to handle the routing processes that can occur

in a routing node.

The main features of the IP model are:

IP addressing: the addresses are specified using dotted decimal notation.

Routing and forwarding: ip routers are modeled using a finite buffer with two available

processing modes (slot-based and central). Regarding the routing tables these can be

created by a dynamic routing protocol or user configured (static).

Fragmentation and reassembly.

Processing delay and queuing capacity: specific queuing capacities and packet processing

speeds.

Queuing algorithms.

IP cloud models: abstract parts of a network infrastructure.

IP routing parameters:

Router ID: specifies the router ID used by the OSPF routing protocol

Autonomous System Number: specifies the router’s autonomous system (AS) number.

Specifying a value of “Auto Assigned” chooses a number from 1 to 65535, inclusive,

during a simulation.

Interface Information: specifies IP routing attributes that apply on a per-interface basis.

o Status: specifies if the interface can receive and forward packets. If the status of

an interface is set to Shutdown, no packets are received or forwarded on that

interface.

o Address: specifies this interface’s IP address.

o Subnet Mask: specifies this interface’s subnet mask.

o Subinterface Information: specify one or more subinterfaces for each physical

interface.

o Routing Protocol(s): specifies the routing protocols used on the interface.

o MTU: specifies the MTU (maximum transfer unit) of the interface. The MTU

depends on the data link technology used for packet transfer on this interface and

should be greater than the size of the IP header.

o Metric Information: specifies values for bandwidth, delay, reliability, and load,

which are used to compute the interface cost.

o QoS Information: specifies Quality of Service (QoS) related parameters for this

interface.

o Multicast Mode: specifies if IP multicasting is enabled or disabled on this

interface.

17

o Layer 2 Mapping: specifies an ATM or Frame Relay PVC connected to this

physical interface.

o Packet Filter: configure extended ACLs to filter IP packets being received and

sent from this interface.

o Policy Routing: configure a route map to be used to policy route all data arriving

on this interface.

o VRF Name: specifies a VRF name to be associated with the interface when

configured for BGP/MPLS VPNs.

o Compression Information: specifies the compression scheme used on this

interface.

o Description: optional description of the interface.

Loopback Interfaces: specifies the address and routing protocol information of this

router’s loopback interfaces.

Static Routing Table: specifies static routing information.

Load Balancing Options: specifies if load balancing for multi-path routes is done on a per-

packet or per-destination basis.

Routing Table Export: specifies if the routing table used during a simulation should be

exported.

Multipath Routes Threshold: specifies the maximum number of routes that are considered

by the routing table if there are multiple routes to the same destination.

Administrative Weights: specifies a routing protocol priority system for traffic forwarded

by the router.

Extended ACL Configuration: configures extended access control lists, which are used to

filter packets and as match conditions in route maps.

Prefix Filter Configuration: configures prefix filters, which are used to filter routes and as

match conditions in route maps.

Route Map Configuration: configures the route maps used in this router.

Model architecture:

Figure 3-1: IP model architecture

The network layer is simulated via two modules:

ip_encap. This module uses the ip_encap_v4 process model to implement encapsulation,

e.g. adding the IP header to the packets that travel from the upper layers down into the

network, and decapsulation, i.e. stripping the IP header off the packets that arrive from the

network and travel to the upper layers

ip. This module relies on the ip_dispatch process model to implement such basic IP

activities as forwarding, fragmentation, and reassembly. In addition, ip_dispatch invokes

the ip_output_iface process model to implement packet processing at individual outgoing

interfaces of the node. The majority of new IP technologies for QoS support are

18

based on effective management of outgoing interfaces and network resources associated

with them, such as bandwidth and queue occupancy.

IP routers are modeled on a finite buffer architecture that operates in a slot-based processing mode

or a central processing mode. Each node intended to use IP has an IP routing module, which

contains a dispatcher process that spawns the various routing processes. The centralized

processing module is presented in the figure below:

Figure 3-2: IP operation mode

1. Ip dispatch

This process model implements IP routing functions, and fragmentation and reassembly. IP

packets arriving on any interface are routed to the appropriate output interface based on their

destination address. The ip_dispatch process requires a fixed amount of time to route each packet.

Packets are forwarded on a first-come, first-served basis.

State transition diagram of the ip dispatch process

19

Init:

o initialization procedures like:

Initialize child process handles

Initialize the IP address package

Initialize the IP datagram package

Initialize important state variables for this process

Initialize the global address table

Register some attributes in the process registry

o Schedule a self interrupt at the current time to let all the ip modules resolve

their IP addresses. This involves assigning unique addresses.

o Determine the interrupt type.

3 wait states: schedule self interrupts to assure that all the rest of the network components

are ready and the initialization phase is finished.

Cmn_rte_tbl: state used to initiate the initial redistribution of routing information

between the routing protocols configured on this router. This is done via an invocation

of the ip_cmn_rte_table_redistribute function in the executive of the transition out of this

state.

Init_too: state used to finish the initialization. It involves creating the appropriate set of

child processes.

Inactive: IP will go into this INACTIVE if the node has all IP interfaces set to Shutdown.

No processing will be done.

20

Idle: from this state, depending on the interrupts type that can occur, different actions will

take place like: forward a packet to the appropriate recipient, which can be another child

process, or the stream connecting IP to the upper module.

2. Ip_rte_central_cpu

This is a child process of ip_dispatch and it implements the centralized processing mode.

State transition diagram of the ip_rte_central_cpu process

Figure 3-3: Ip_rte_central_cpu STD

Steps:

1. Perform appropriate initializations before reaching the wait state (ip_central_cpu).

2. Determine if the process is being invoked by one of the child processes maintained by IP.

3. Determine the interrupt type.

4. Depending on the interrupt type and some conditions transition to next state and execute the

corresponding transition executive expression:

If the processing rate is infinite (idealized) and (interrupt mode = direct and interrupt

type = stream interrupt) or (interrupt mode = indirect): handle an incoming packet from

an “upper layer”, a “lower layer” or generated within ip. Remain in the same state,

ip_central_cpu.

If the processing rate is not infinite (same conditions as above): handle incoming

packet accordingly. The succession of the next states simulates the processing time of

the CPU.

If the interrupt mode is direct and it has a process type: the process packet is sent to the

appropriate level. If the processing speed is not set to infinity the packet must be

extract from the buffer.

21

After every action the process turns in the wait state, ip_central_cpu, and from here depending on

the conditions (interrupt mode and type) a certain action is performed.

4. Implementation of SAMP, a new multipath routing algorithm in OPNET

simulator

The integration of a new process model within OPNET is a challenging task because it requires a

good knowledge of the standard build-in OPNET process models which are quite complex. As a

consequence, the implementation or modification of a routing protocol requires the understanding

of the corresponding routing process model, to determine how to invoke the new process model

from within the OPNET’s code.

For the implementation of a new routing algorithm there are two main approaches:

Create a router structure from scratch.

Modify an existing router structure by integrating the new features in the behavior of the

router.

Both methods have advantages and disadvantages. In the first case the implementation is simpler

because we do not have to focus on all the aspects of a router, only on the features that are

important for us, and also no integration is needed. The downside is that this model is quite

different from the real model and the obtained results can be different from the one obtained in a

real environment. The second variant implies the knowledge of the existing structure of the

router, higher complexity, but it is a more realistic approach.

For the implementation of the new multipath routing algorithm SAMP we have chosen the second

approach. We consider the basic structure of an ip router, available in OPNET, and in that

structure we integrate the new module.

The main challenges of this variant are:

Understanding the function mode of the basic model.

Identification of the components with that the new module will interact.

Study de behavior of the indentified components.

Detect the functions that will be able to interact with the new module.

Identify a mode to enable the communication between the basic structure and the new

module.

4.1 Steps for modeling a new process

1. Defining the system context

Process models describe the behavior of one component within a larger system model, consisting

of many components. Our system is the router.

22

Figure 4-1: Router structure

From the figure we can identify the main groups of the router: application layer, transport layer,

routing protocols, ip layer, data link and physical layer.

In the first phase we have to indentify the interdependent modules of the system. We are interested

only in the modules that will interact with the new designed components. The diagram below

presents the interdependent modules of the system that are of interest.

Figure 4-2: Interdependent modules diagram

In the next phase we have to establish the communication mechanisms between the modules. The

main mechanisms are:

23

Packet communication: message-based communication, the packets are messages whose

content are formatted into individual fields that carry information. Packets can be sent

between modules in the same node via connecting packet streams objects.

Remote interrupt: used to indicate simple information such as status of a semaphore, or a

value of a variable. These are suitable for modeling transactions as request and indications,

parameterized commands.

Access interrupts: used in conjunction with packet communication because it requires the

presence of a packet stream object. Access interrupts travel backwards on a stream; request

that a stream’s source request a packet.

Statistic communication: statistic wires. Used to live monitoring of an output statistic

value. It also provides triggers which allow asynchronous interrupts to be generated for the

destination module when certain patterns of change occur in the monitored statistic.

2. Process level decomposition

A router is composed of many processes; these are already connected and function as a whole.

The new process that we are gonna add are: a flow identification module, a multipath routing

module, a management module. All these modules are composed from one process and are created

statically.

The next steps are performed for each process. At this point these steps are presented theoretically,

following that the concrete implementation to be presented later.

3. Enumeration of events (per process)

A process assumes some or all of the functions of the system in which it is located by performing

actions and modifying state information in response to logical events. A logical event (as opposed

to an ordinary simulation event) is an occurrence that requires the intervention of the process. At

this step we construct a complete list of the logical events that can affect the process of interest.

Identifying logical events: logical events may be generated from three types of sources: (1)

modules outside the local system; (2) other processes within the same module; (3) the

process itself.

Determining event implementation methods: how logical events are implemented in the

simulation model. OPNET Modeler supports only a small, finite set of interrupt types with

which to implement these events. We have to select a correct type of interrupt to represent

each logical event expected by a process. For example if the logical event is the creation of

a process then the interrupt type for the root process will be “begin simulation”.

4. State-level decomposition (per process)

At this stage the goal is to define a set of discrete states that will later be connected with

transitions to form an STD (state transition diagram).

Some criteria to define a state are:

A state should correspond to a mode of the process in the sense that only specific

sequences of events can bring the process into that state.

24

A state is characterized by the fact that events are handled a particular way as a result of

the process being located in that state.

The combination of states should form a mutually exclusive, complementary set, such that

the process always occupies exactly one of the states.

A state should represent a “resting place” for a process, meaning that the process should

be able to wait in the state for new interrupts to occur. This implies that the states that are

defined in this step of the methodology should not be used simply to specify actions.

5. STD development (per process)

The purpose of this stage is to combine the defined states with the logical events to form the basic

transition diagram (STD).

If the process is located in a given state there is only a subset of states that can occur. There are

three categories of events:

Infeasible: have no possibility of occurring due to the particular circumstance that the

process finds itself.

Suppressed: have the physical possibility of occurring but provide no useful information to

the process.

Feasible: are not only possible to receive, but the process may have a use for while

occupying a particular state. These events will appear in the STD.

After a logical event is received, the process has the opportunity to carry out a sequence of five

steps as follows:

1) Actions may be performed by the exit executive statements of the unforced state that is

currently occupied.

2) The condition statements are evaluated for all of the outgoing transitions of the

currently occupied state.

3) Actions may be performed by the executive statement of the transition that is selected

(i.e. the one that evaluates to a TRUE boolean value).

4) The process follows the transition and occupies a (possibly) new state.

5) Actions may be performed by the enter executives of the new state.

A process must have the ability to transit differently or to do substantially different actions, based

on the fulfillment of certain conditions at the time the event occurs.

All this data can be represented in a table that has five columns: current state, logical event,

condition, action, next state.

In the next phase we will define the transition between the states. Each logical event that is

feasible in a given state must be handled by at least one outgoing transition of that state. A

transition could be defined between two states to express the following: if the current state is S0,

and the logical event E occurs, and the condition C holds, then the process should move to occupy

state S1. One transition may handle a union of multiple logical events. If in a given state of a

process there are multiple feasible logical events, then it is possible for several of these events to

cause a transfer to the same destination state. It is recommended to use one transition with a

condition statement that represents a union of the individual logical events and conditions. It is

also possible the handle of one logical event can be split among multiple transitions.

25

The final phase is to assembly the state transition diagram.

6. Specification of a process actions (per process)

Process models do actions to modify their state memory, communicate with other modules,

control their own timing, and gather statistics. Actions are performed by statements called

executives, which respect a C syntax. Executives can make use of any C language operators and

constructs, the process’ state, temporary, and global variables, and may include function calls to

Simulation Kernel procedures.

Executive statements may be associated with states and with transitions. There are three types of

locations in which executive state can be place:

Exit executives: actions that take place immediately after receiving a new event, and before

evaluating transitions.

Transition executive: associated with each transition to associate an action with a particular

transfer of control from one state to another (only one Proto-C line).

Enter executives: actions that take place after a transition, upon entering a new state.

7. Initial state designation (per process)

When we select the initial state there are two concerns:

The time when the process is activated. We can chose to activate the process with a begin

simulation interrupt (this interrupt happen before all other interrupts). In this case all the

initialization activities can be completed before the mainstream events occur.

The type of the state. The initial state can be a forced or an unforced state. The initial state

should be unforced only if the process is not required to do any initialization actions.

4.2 Flow-Identification module

The flow-identification module identifies the flows that traverse each node. The streams are

identified based on the triplet (IP source address, IP destination address, destination port). The

packets are extracted at the mac module level. The results obtained with the help of this

component will be used by the new multipath routing module SAMP.

26

Figure 4-3: Flow identification STD

This module is connected through a stream packet object with all the mac modules available in the

router. For each received packet a copy is made and this copy is sent to the flow_id module.

1. Enumeration of events

Event Name Event description Interrupt type

Creation of process The module is initiated at the beginning of

the simulation

Begin simulation interrupt

Receive of a packet A packet is received at one of the interface

of the router

Stream interrupt

2. State-level decomposition

State name State description

Init At the beginning of the simulation initialization are made, like: state variable

initialization, flow file creation.

Idle Waiting for a packet to arrive from one of the mac modules of the router.

This is the wait state of the process.

Wrt_Flow A packet was received. The packet is processed and the information of

interest is extracted.

3. STD development

Current state Logical event Condition Action Next State

Init Begin_simulation None Initialization Idle

Idle Packet_rcv New_Packet None Wrt_Flow

No_packet Default None Idle

Wrt_Flow None None Packet processing Idle

27

Transition condition macros

Macro Meaning

NEW_PACKET A new packet has arrived. Interrupt type = stream interrupt

4. Specification of a process actions

The actions performed in every state are:

INIT: forced state

o State variables initialization.

o Create a binary file. This file will contain the flows that traverse the router, also

trough this file the module will communicate with the routing entity. The structure

of the file is: destination IP address, source IP address, destination port. Each flow

is represented trough a line in the file.

IDLE: unforced state

o No actions are made, the process waits for a stream interrupt, a packet arrival.

WRT_FLOW: forced state

o Determine the fields of the packet that are of interest: IP address, source IP address,

destination port.

o Update the list of existing flows.

o Update the time of the last received packet for each flow.

o Delete a flow from the list if the time interval between the packets is more than a

predefined value.

5. Initial state designation

The process is activated at the beginning of the simulation trough a begin_simulation interrupt

from the simulation kernel. Because the process requires initialization, the first state is a forced

one.

4.3 Management application module

The management application module was designed to take the place of the management

application. This is a simplified version of the management application that offers to the routing

module the necessary information regarding the structure of the network and the link information

(data-rate, delay, BER).

This module will gather all the information regarding the network structure. This data will be used

by the routing module to determine de paths in the network. During the simulation time the

management application will watch the state of the links and will signalize to the routing module

any significant changes. Based on this information the routing process will change accordingly.

Only one instance of the management application will be present in the network, this entity will

have a global view.

28




the simulation


Finalization of the

network elements

initialization

All the network elements are registered in

the global registry.

Invoke interrupt

Link state change The metric of one or more links had a

significant change.




initialization.

Topo_discovery The topology of the network is written in a file. This file will be used by the

routing module to calculate the paths in the network.

Idle Waiting for a change to occur in the network. This change can be a

modification in the node list or a change of the link state. This is the wait

state of the process.

Links_update The state of one or more links has change; the link state file will change.

Node_update The topology of the network has change; the node file will change.

3. STD development


Init Begin_simulation None Initialization Topo_dicovery

Topo_dicovery Network_ready None Write node file;

Write links state file

Idle

Idle None None Wait for changes in

the network.

Idle

Links state update None None Links_update

Topology update None None Node_update

Links_update None None Rewrite the links state

file

Idle

Node_update None None Rewrite the node file Idle


Macro Meaning

LINKS_UPDATE The state of the network links has changed.

NODE_UPDATE The topology of the network has changed.

29

Figure 4-4: Management application STD



INIT: unforced state


TOPO_DISCOVERY: forced state

o Create the file that contains the topology of the network (nodes and links).

o Create the links state file.


o No actions are made; the process waits for modification in the network.

LINKS_UPDATE: forced state

o Rewrite the links state file accordantly to the state of the network.

NODE_UPDATE: forced state

o Rewrite the network topology file.



from the simulation kernel. The first state is unforced because the process can translate to the next

state only if the network is already initialized. The initial initialization is made in the enter

executive of the INIT state.

4.4 Routing application module

The routing application module will have the function similar to a standard routing protocol

module, like OSPF. This entity will communicate with the ip module, management module, and

flow identification module. The goal is to change the routing table/s accordantly to the state of the

network and also obtain a load balancing trough the transmission of different flows using multiple

paths.

30

Figure 4-5: SAMP STD




the simulation


Network nodes file is

ready

The network nodes file from the

management application is ready.

Invoke interrupt

Link state file change The link state file from the management

application has changed.

Invoke interrupt




initialization.

Init_rte_table Initialization of the routing table (s).

Idle Waiting for a change to occur in the network. This change can be a

modification in the node list or a change of the link state. This is the wait

state of the process.

Topo_info The information about the network topology is ready. Extracting de

topology data.

Path_calc Based on the topology data the paths in the network are calculated.

Metric_calc Based on the link state information for each calculated route the

correspondent metric is calculated.

31

Write_rte Deciding for each destination which gateway will be used. Based on the flow

file for each stream a next hop will be decided. After the decisions are made

the routes are written in the routing table (s).

3. STD development


Init Begin_simulation Ip module is

ready.

Initialization Init_rte_table

Init_rte_table Ip module ready None Initialize the routing

table (s).

Idle

Idle None None Wait for changes in

the network.

Idle

Topology file

ready or the

topology file has

change.

None Load the network

topology information

Path_calc

Link state file has

change

None Recalculate the metric

of the paths

Metric_calc

Topo_info None None Load the network

topology information

Path_calc

Path_calc None None Calculate the routes in

the network

Metric_calc

Metric_calc None None Calculate the metric

of the determined

routes

Write_rte

Write_rte None None Write the routes in the

routing table (s)

Idle


Macro Meaning

TOPO_READY The topology file is ready

TOPO_UPDATE The topology of the network has changed.

LINKS_UPDATE The state of the links network has change



INIT: unforced state


INIT_RTE_TABLE: forced state

o Initialize the routing table (s).


o No actions are made; the process waits for modification in the network.

TOPO_INFO: forced state

o Extract the information about the topology of the network from the topology file.

PATH_CALC: forced state

o Calculate the paths in the network.

METRIC_CALC: forced state

32

o Calculate the metric for each determined route.

WRITE_RTE: forced state

o Determine for each flow, present in the flow file, the gateway that will be used.

The decision is made based on the metric of the routes and the length of the paths.



from the simulation kernel. The first state is unforced because the process can translate to the next

state only if the network is already initialized and the ip module is ready. The initial initialization

is made in the enter executive of the INIT state.

Because the new modules are not quite ready implemented, for the moment no simulation results

are ready.

33

5. Bibliography

[1] OPNET Modeler Documentation Set, Version 15.0, OPNET Technologies, Inc. Bethesda MD,

2008.

[2] V. Hnatyshin, G. Gramatages, M. Stiefel, “Practical Considerations for Extending Network

Layer Models with OPNET Modeler,” MOAS'07 Proceedings of the 18th conference on

Proceedings of the 18th IASTED International Conference: modelling and simulation, ACTA

Press Anaheim, CA, USA ©2007.

[3] T. Brito Pereira, Lee Luan Ling, “An OPNET Modeler Based Simulation Platform for

Adaptive Routing Evaluation,” FEEC, UNICAMP, Campinas, S.P., Brazil.

[4] Peter Pieda, John Spicer, “Using OPNET to Evaluate Diverse Routing Algorithms,” Tropic

Networks 135 Michael Cowpland Drv., Kanata, On. K2M 2E9.

activity report · o queue modules: provide a superset of the functionality of processor modules,...

Documents