Network Modeling

CHAPTER 5 Network Modeling

This chapter expands upon the concepts introduced in earlier chapters and applies them to the area of network modeling and simulation. We discuss the different applications of modeling and simulation in the design and optimization of networked environments. We introduce the network modeling project life cycle, and expose the reader to some of the particular considerations when modeling network infrastructures. Finally, the chapter attempts to describe applications of network modeling within the linkage between network modeling and business requirements.

Although we will focus on network modeling and simulation in the context of computer communication networks, the content of this chapter applies to networks in general. In the case of computer communication networks, this influence is codified by the transmission of data packets, wireless signals, etc. Historically, the first network simulations were developed in the area of computer communication systems, and thus many of the available tools and frameworks are tailored to this application area. Nevertheless, most network simulation tools are amenable to being applied in a wide range of different problem domains.

In the area of computer network design and optimization, software simulators are a valuable tool given today's complex networks and their protocols, architectures and dynamic topologies. Designers can test their new ideas and carry out performance related studies, being freed from the burden of the "trial and error" hardware implementations. A typical Network Simulator can provide the Engineer/programmer with the abstraction of multiple threads of control and inter thread communication. Functions and protocols are described either by finite state machine, native programming code, or a combination of the both. A simulator typically comes with a set of predefined modules and user friendly GUI. Some network simulators even provide extensive support for visualization and animation. There are also emulators such as the Network Emulation Tool (NIST Net). By operating at the IP level, it can emulate critical end to end performance characteristics imposed by various wide area network situations or by various underlying subnetwork technologies in a laboratory test bed environment.

5.1 Simulation of Networks

Simulation of a network frequently requires a collection of interdependent nested concurrent sub simulations arising from:

The entities that are the nodes of the network, and the processes therein.
The links that are the edges of the network, and the processes therein.

In the specific case of computer communication networks, these elementary subcomponents span functionally distinct elements of the system such as networks, links, circuits, the propagation medium, etc. In practice, simulation of these elementary subcomponents can be conducted using different approaches—with certain approaches being better suited to certain components. A broad classification of approaches would include:

Discrete event driven simulations
Time driven simulations
Algorithm simulations
Circuit simulations
Physical media simulations

Different simulation tools specialize in one or more of these simulation approaches. For example, ns2 and OPNET deal primarily with event driven simulations, while SPW, COSSAP, Simulink/Matlab focus on time driven simulations. TI CodeComposer provides a platform for algorithm simulation, while NC VHDL/Verilog and Scirroco support circuit simulations. PSpice, ADS, XFDTD are often used for simulation of RF channels and other media. Within a given system, the constituent subcomponents to be simulated usually exhibit a natural hierarchical structure, e.g., simulating a network requires simulating event driven protocols operating at each node. But, simulating a protocol requires simulating a single packet transmission across a wireless link, and this in turn requires modeling how a radio frequency transmission fades in the medium of air. In short, a hierarchy of subcomponents of a system induces a hierarchy of simulations, each of which usually requires a different simulation tool.

5.2. The Network Modeling and Simulation Process

Successive refinements of a block diagram describing the typical phases in the modeling and simulation process. Within these, block 1 represents determination of the actual system to be modeled and simulated. Blocks 2 and 3 constitute modeling and will be discussed in Section 5.3. Blocks 4 and 5 constitute model implementation in computational terms and instantiation via input/parameter selection. Block 6 represents the actual simulation execution, and block 7 represents analysis of simulation data generated on performance measures through simulations. Blocks 4 7 are very much dependent on the choice of the simulation package, which as noted above, should be deliberately selected based on the nature of the subcomponent being simulated. These will be covered in details in Section 5.4.

Ideally, a mathematical model perfectly describes the evolution of the actual system, but in practice this is computationally not feasible. In addition, it may introduce many parameters that have to be measured in the real world in order to be initialized to be used in the simulation. A posteriori to the simulation studies, one can determine which parameters were irrelevant in the sense that they have introduced additional complexity into the model without qualitatively alter the conclusions of the investigation. The question is how to determine this a priori to the simulations. In practice, this depends on the individual's experience and is considered as an art. The general approach taken is to consider ever more complex models, execute simulations, and validate the simulation outcomes with observations of the actual system in an upward increasing design complexity. Blocks 2 7 in the previous block diagram (figure 5.2), actually form a closed loop, with validation against the physical system playing the role of the return arc. Following this recipe yields a model satisfying Occam's Razor—the simplest model which explains the observed phenomenon.

5.3. Developing Models

The modeling process (Blocks 2 and 3) frequently requires making simplifying assumptions and introducing approximations to reduce the model's complexity. These simplifications can be carried out at two distinct levels:

Modeling: Here, we simplify the functional description of network elements. For example, we might consider packet transmission to be error free, or we might consider that channel contention due to simultaneous radio frequency transmission is negligible. Such simplifications themselves generally fall into one of three categories:

System Modeling—simplifications at the highest level of description of the interactions between distinct elements of the simulation; complexity reduction. As an example, assume that we are simulating a "vehicular network" and we choose to assume that the nodes only move on a Cartesian lattice.
Element/Device Modeling—simplifications at the level of description of the behavior within a single element of the simulation. Assume, we are simulating a routing protocol, and we choose to assume that each constituent switch is either fully functional or else fail completely (i.e., there are no partial failures). Another example is the simulation of the propagation of a social network, and we assume that each individual adopts the same probability whenever it is expressed by any of its peers (regardless of the specific identity of the peer).
System models and element/device models are frequently expressed with reference to random processes. For example, a network of computers might be connected using links that are drawn uniformly at random from the set of all distinct pair of nodes. An individual element in a social network might have traits selected at random from the Normal distributions centered at the mean value observed in the actual population census. Frequently, simplifications of system and device/element models entail simplifications in the distributions referenced by their constituent random processes. This brings us to a third type of simplification called Random Process Modeling.

Performance Evaluation: Here, we simplify the measurements being made of the simulation to provide less precise but potentially more useful estimates of the system's behavior.

5.4. Network Simulation Packages

As noted earlier, blocks 4 7 are very much dependent on the choice of simulation tools. Some examples of academic simulators include:

REAL is a simulator for studying the dynamic behavior of flow and congestion control schemes in packet switch data networks. Network topology, protocols, data and control parameters are represented by Scenarios, which are described using NetLanguage, a simple ASCII representation of the network. About 30 modules are provided which can exactly emulate the actions of several well known flow control protocols.
INSANE is a network simulator designed to test various IP over ATM algorithms with realistic traffic loads derived from empirical traffic measurements. Its ATM protocol stack provides real time guarantees to ATM virtual circuits by using Rate Controlled Static Priority (RCSP) queuing. A protocol similar to the Real Time Channel Administration Protocol (RCAP) is implemented for ATM signaling. A Tk based graphical simulation monitor can provide an easy way to check the progress of multiple running simulation processes.
NetSim is intended to offer a very detailed simulation of Ethernet, including realistic modeling of signal propagation, the effect of the relative positions of stations on events in the network, the collision detection and handling process and the transmission deferral mechanism. But, it cannot be extended to address modern networks.
Maisie is a C based language for hierarchical simulation, or more specifically, a language for parallel discrete event simulation. A logical process is used to model one or more physical processes; the events in the physical system are modeled by message exchanges among the corresponding logical processes in the model. Users can also migrate into recent extension: Parsec and MOOSE (an object orient extension).
OPNET (Optimized Network Engineering Tool) is an object oriented simulation environment that meets all these requirements and is the most powerful general purpose network simulator available today. OPNET's comprehensive analysis tool is especially ideal for interpreting and synthesizing output data. A discrete event simulation of the call and routing signaling was developed using a number of OPNET's unique features such as the dynamic allocation of processes to model virtual circuits transiting through an ATM switch. Moreover, its built in Proto C language support gives it the ability to realize almost any function and protocol. OPNET provides a comprehensive development environment for the specification, simulation and performance analysis of communication networks. A large range of communication systems from a single LAN to global satellite networks can be supported. Discrete event simulations are used as the means of analyzing system performance and their behavior. Key features of OPNET include:
Modeling and Simulation Cycle: OPNET provides powerful tools to assist users to go through three out of the 5 phases in a design circle (i.e., the building of models, the execution of a simulation and the analysis of the output data).
Hierarchical Modeling: OPNET employs a hierarchical structure to modeling. Each level of the hierarchy describes different aspects of the complete model being simulated.
Specialized in communication networks: Detailed library models provide support for existing protocols and allow researchers and developers to either modify these existing models or develop new models of their own.
Automatic simulation generation: OPNET models can be compiled into executable code. An executable discrete event simulation can be debugged or simply executed, resulting in output data. This sophisticated package comes complete with a range of tools that allow developers specify models in detail, identify the elements of the model of interest, execute the simulation and analyze the generated output data.

SimJava is a discrete event, process oriented simulation package. It is an API that augments Java with building blocks for defining and running simulations. The original SimJava was based on HASE++, a C++ simulation library, which was in turn based on SIM++. A SimJava simulation is a collection of entities each running in its own thread. These entities are connected together by ports and can communicate with each other by sending and receiving event objects. A central system class controls all the threads, advances the simulation time, and delivers the events. The progress of the simulation is recorded through trace messages produced by the entities and saved in a file. Using a programming language to build models (rather than building them graphically) has the advantage that complex regular interconnections are straightforward to specify, which is crucial for some of the networks we are interested in simulating. It also allows the inclusion of existing libraries of code to build simulations. The SimJava package has been designed for simulating fairly static networks of active entities which communicate by sending passive event objects via ports. This model is appropriate for hardware and distributed software systems modeling. As of version 2.0, SimJava has been augmented with considerable statistical and reporting support. The modeler has the ability to add detailed statistical measurements to the simulation's entities and perform output analysis to test the quality of the collected data. Furthermore, much effort has gone into the automation of all possible tasks allowing the modeler to focus on the pure modeling aspects of the simulation. Automated tasks range from seeding the random number generators used in the simulation, to producing detailed and interactive graphs. A SimJava simulation contains a number of entities each of which runs in parallel in its own thread. An entity's behavior is encoded in Java using its body() method. Entities have access to a small number of simulation primitives:

sim_schedule() sends event objects to other entities via ports.
sim_hold() holds for some simulation time.
sim_wait() waits for an event object to arrive.
sim_select() selects events from the deferred queue.
sim_trace() writes a timestamped message to the trace file.

Network Simulator (ns 2) is an object oriented, discrete event simulator targeted to be used in research in networking. Developed at UC Berkeley and written in C++ and OTcl, ns is primarily useful for simulating local and wide area networks. ns provides substantial support for simulation of TCP, routing, and multicast protocols over wired and wireless (local and satellite) networks. The original ns project began as a variant of the REAL network simulator in 1989 and evolved substantially over the past few years. The ns 2 simulator covers a large number of protocols, network types, network elements and of traffic models, which are called "simulated objects." One of the main advantages of ns 2 is its Open Source availability.
Fast ns 2 simulator: The fast ns 2 simulator is the modification of the network simulator (ns 2). Fast ns 2 is developed at the Laboratory for Software Technologies at ETH Zurich to enable simulation of large scale ad hoc wireless networks . Research in ad hoc networks often involves simulators since management and operation of a large number of nodes is expensive. However, the widely used original ns 2 did not scale and it was very difficult to simulate even medium scale networks with 100+ nodes. Hence, ns 2 was modified by ETH Zurich to meet the needs of large ad hoc network simulations. The modified fast ns 2 simulator exploits assumptions in the structure (or absence) of interference of concurrent wireless communication. The modified simulator has simulated populations of up to 3000 nodes so far and works up to 30 times faster than the original version.
Simulink: Simulink is a platform for multi domain simulation and Model Based Design for dynamic systems. It provides an interactive graphical environment and a customizable set of block libraries, that let one accurately design, simulate, implement, and test control, signal processing, communications, and other time varying systems. It can also be extended for specialized applications. Simulink is an extension to MATLAB which uses an icon driven interface for the construction of a block diagram representation of a process. It uses a graphical user interface (GUI) for solving process simulations. Instead of writing MATLAB code, it simply connects the necessary "icons" together to construct the block diagram. The "icons" represent possible inputs to the system, parts of the systems, or outputs of the system. It allows the user to easily simulate systems of linear and nonlinear ordinary differential equations. Add on products extend the Simulink environment with tools for specific modeling and design tasks and for code generation, algorithm implementation, test, and verification. Simulink is integrated with MATLAB, providing immediate access to an extensive range of tools for algorithm development, data visualization, data analysis access, and numerical computation.

In the next sections of this chapter, we will discuss in more details the OPNET network simulation tool since it is the most used package by academia and industry, as far as the authors know (during the time of writing this book).

5.5. OPNET A Network Simulation Package

In the next Chapter, we will be designing our own event based network simulation framework, from the ground up, on top of the discrete event framework we developed in Chapter 2. The purpose of this exercise is to understand how such a framework operates "under the hood". Before we embark on this task, it will be illuminating to consider the features offered by a "professional grade" event based network simulation tool, as a "gold standard" of comparison. The simulation tool we have in mind is OPNET.

OPNET (Optimized Network Engineering Tools) has achieved widespread use in academia, industry and government. The U.S. Army has adopted OPNET as a standard under the auspices of the Army Enterprise Strategy under the leadership of the U.S. Army Office of the Director of Information Systems for Command, Control, Communications and Computers. OPNET is widely used in universities as well as many parts of the DOD. OPNET supports the visualization through modeling objectives. It may be described as a communications oriented simulation language. The single most significant aspect of OPNET is that it provides direct access to the source code coupled with an easy to use front end.

A generic approach to network modeling can be constructed using the OSI Reference Model as its basis, as shown in Figure 5.6. This approach allows the implementation of different network protocols which are compatible with the OSI layer boundaries. Pedagogically, this approach has limitations. As illustrated in Figure 5.6, any detailed implementation of an Ethernet model will not directly align with the OSI Reference Model. Other protocols such as Fiber Distributed Data Interface (FDDI) also do not perfectly align with the OSI Reference Model.

OPNET models are composed of three primary model layers: the process layer, the node layer and the network layer. The lowest modeling layer is the process layer. This Modeling Hierarchy is illustrated in Figure 5.7. The process model in Figure 5.8 shows a state transition diagram (STD) for the generation of packets. Process models are built using finite state machines (FSM) described by STD's.

Finite state machines are an effective means of defining discrete event systems that maintain state information. FSM based design provides a means to manage complexity. Complex networks can be broken down into individual states and then each state is defined and implemented.

The source code for each state is readily accessible and modifiable by the user. Each state has entry execs and exit execs. Execs is the term used to describe the code executed when a state is entered and when a state is exited. The code defining the state transition between states is also accessible. The next level of abstraction up from the process model is the node model. Each element in the node model is either a predefined OPNET artifact or defined by its own STD. Double clicking on a node model element brings up its underlying process model. Figure 5.9 is an example of a node model that defines a station on an FDDI network. Packets are generated from the source llc_src, processed in the mac module and are put on the ring by the phy_tx module. Traffic from the ring is received via the phy_rx module processed in the mac module and finally received and discarded by the llc_sink module.

The heart of a node model is either a processor module or a queue module. Processor modules are used to perform general processing of data packets as specified in the applicable protocol. Queue modules are supersets of processor modules with additional data collection capabilities built in. The MAC module in Figure 5.10 is an instantiation of a queue module.

The network model is the highest modeling layer in the OPNET model hierarchy. The network model may represent a hierarchy of sub networks. A network model is shown in Figure 5.10. Each of the stations (nodes) in Figure 5.11 is defined by a node model such as the one in Figure 5.10. Again, each module in a node model is defined by state transition diagram as shown in Figure 5.8 thus conforming to the modeling hierarchy shown in Figure 5.7.

The network model may be used to model a single network, subnet or segment or a hierarchy of networks, sub networks or segments. The segment in Figure 5.10 may be joined with other segments and aggregated into a single subnet icon as shown in Figure 5.9. The operation of a single network segment may now be studied. The implemented functionality of the physical and link layers of the OSI Reference Model are sufficient to model the operation of a single segment. At this point, the individual stations on the segment may be customized if a more detailed representation is desired. Individual workstations or types of workstations may be specially modeled. Special characteristics could be implemented by modifying the individual modules of the station of interest or the physical network line connecting the stations. Many modifications can be made via the built in menus. However, modifications may be made at the source code level should the menu choices not be fully satisfactory. Adding network services in a TCP/IP network requires the implementation of the Internet Protocol (IP). To simulate the operation of more than one segment, the functionality of network layer services must be added to the model. The node model of Figure 5.9 may be extended by adding modules to implement the Internet Protocol (IP) and Address Resolution Protocol (ARP). ARP tables are implemented statically with entries matching IP addresses to MAC addresses.

5.6. Summary:

In this chapter, different applications of modeling and simulation in the design and optimization of networked environments have been discussed. Network modeling project life cycle has been introduced with network modeling and simulation processes. Then, different network simulation tools/packages used in academia and industry were introduced, such as REAL, INSANE, NetSim, Maisie, OPNET, SimJava, Network Simulator (ns 2), Fast ns 2 simulator and Simulink.

Essay Writing

Resources

Network Modeling

CHAPTER 5