Chapter II

CHAPTER II

AMS : A TELIER FOR

M ODELING AND S IMULATION

I I . 1 . I

Software reuse is the process of creating software systems from existing software rather than building software systems from scratch. This definition of software reuse is used extensively for building our environment for modeling and simulation. As we will see later on, a prototype of our atelier is based on four existing software which proved their usefulness in their respective field. This type of software reuse can be seen as a coarse grain of reusability and we call it first level of reusability.

The simulation is now considered to be an integrated part of the design process

of communication systems. The design process also includes evaluation and

optimization of these systems. Simulation constitutes the only possible way to

obtain detailed information in this field. The objective of the atelier, named

AMS: Atelier for Modeling and Simulation [4, 5, 6, 7], is to make simulation a

creative task. In other words, instead of having to spend most of his time on

writing simulation code, which is a tedious task, the end-user will be able to

devote more time to think about how to improve his system.

The end-user of the atelier is a person who has no or little knowledge about performance techniques. He is not expected to have in-depth knowledge of the simulation techniques. He is just interested in the program results but not in the way they are obtained. However, he should be a communication system designer, a network architect, or a network manager. He will use the atelier to build and validate an architectural choice, and/or to compare several possible ways of solving a problem.

On the other hand, a modeler is a specialist of both the network area and the performance evaluation techniques. He is able to understand the exact behavior of a network component and to isolate its main characteristics for the purpose of performance evaluation. This empirical process is based on the experience and the practice of the modeler. Finally, an AMS-manager is a person who is responsible for managing the library of models (its update and extension) and for developing tools for the AMS.

AMS integrates facilities and powerful tools to build a communication system, and to study its performance. It provides several features that make it particularly suitable for the simulation and analysis of these types of systems. Using the atelier, the end-user can quickly and easily construct a concise system from models of several standard networks available in the library, which is the kernel of the atelier, and execute this system in an efficient way.

In the literature, we find the description of different toolkits dedicated to this field, such as TOPNET

[9] which is based on PROT net, a class of Petri nets;

NetMod

[12] which is based on simple analytical models; BONeS

[10] which is based on a block-oriented modeling paradigm written in C++; and OPNET

[8], which is based on extended finite state machines and C language. Unlike these approaches, ours is based on queueing networks. These toolkits are briefly described in appendix A.

1 Tool for the Object oriented, Petri net based Network Evaluation and Test

2 Network Modeling

3 Block Oriented Network Simulator

4 Optimized Network Engineering Tool

As already mentioned, our modeling paradigm behind AMS is the queueing networks theory. Actually, queueing network models have been used extensively as a modeling paradigm for deriving analytical as well as simulation based performance measures. Queueing networks are especially effective in modeling computer communication systems, including point-to-point communication, broadcast systems, distributed multiple access systems, etc. Indeed, it applies to networks because the payload to be transmitted across the network (e.g., packets, calls) must generally compete for resources (e.g., switches, routers, token frames, shared media access), and is often buffered (“queued”) until the service is provided.

QNAP2 (Queueing Network Analysis Package 2) [15, 14] which is our modeling and simulation language, is based on this paradigm, e.g., queueing network.

QNAP2 is a package for describing, handling and solving large and complex discrete event flow systems such as data communication networks and computer systems. It comprises an object oriented specification language, based on PASCAL and SIMULA, which is used for the description of the models under study and the control of their resolution. It comprises a collection of efficient resolution algorithms, including discrete event simulation, exact and approximate mathematical methods. It is a very powerful and easy to use tool, and has been coded in FORTRAN77 for portability. In appendix B, a more detailed description of QNAP2 is given.

The atelier is built around a library of basic models which includes standard networks such as popular LAN technologies (Ethernet, Token Ring, FDDI, etc.), WANs (X25, TCP/IP), satellite (TDMA, FDMA, etc.), radio networks, and special network components like routers, bridges and gateways.

The basic models should to be constructed in a very modular fashion in order to allow more flexibility. So, we have to build basic models, which will make up other models of more complex systems. Each basic model implements uniform and well-defined set of functions, while having clearly specified interfaces. The models are written in a high-level programming language, which is in our case QNAP2.

In addition to the library, and in order to provide a maximum flexibility, AMS

has a modular structure. It is made up of several components such as models

library, system editor, simulator and post-processor.

The AMS components are categorized in four essential phases, namely the editing phase, the ADL phase, the simulation phase, and finally the presentation phase.

The description of the system to be studied can be made graphically or textually by using the specific language ADL [39] (Architectural Description Language) designed for this purpose. ADL is an object-oriented language which provides a means for modular and hierarchical description of heterogeneous network architectures. So, the role of the ADL phase is to define a clear border between the editing and the simulation phases. Hence, the portability of the atelier becomes possible from one platform to another.

During the editing phase, a network topology is proposed by the end-user and the objects constituting the network (devices, links, protocols, applications) are selected and configured. During the simulation phase, the model of the proposed configuration is dynamically exercised using various experimental scenarios.

Based on the results of simulation, the proposed configuration is refined until some objective or combination of objectives (e.g. load handling, operating cost, etc.) are optimized. Clearly, this process is an iterative one, in which multiple candidate configurations must be tested against various scenarios, refined, and re-tested until requirements are satisfied.

AMS is based on the latest techniques in software engineering such as : graphics, windowing, pop-up menus and the object-oriented programming paradigm. On the other hand, in order to be operational in a reasonable time, AMS has been designed on the basis of existing and proven packages rather than starting from scratch. QNAP2, GSS [16] (Graphical Support System 4) MODLINE

, [18], and S-PLUS

[17] are the main software packages that will be used to operate AMS.

Based on those tools, a prototype of the atelier has been implemented.

This chapter is organized as follows. Section II.2 focuses on the modular structure of AMS and the components of each phase. Section II.3 presents the AMS prototype with an example on using AMS. Section II.4 gives a detailed overview on the ADL language given that more technical details on the language are presented in [39] and in appendix C. Finally, a conclusion is drawn.

5 These packages are trademarks of SIMULOG, a French company specialized in the field of simulation.

6 It is trademark of MathSoft, an American company specialized in statistics.

I I . 2 . F

S

A M S

AMS is designed in a modular manner. The main modules constituting AMS are structured in four phases, each of them is handled by one or several processes.

These phases are the editing phase, ADL phase, simulation phase and presentation phase.

Figure II.1 illustrates this structure. Processes are accessible by the end-user in a graphical and/or a textual manner. Furthermore, the atelier is based on the library of basic models constructed in a very modular fashion to allow more flexibility.

This library is the core of the AMS. A description of those phases, as well as of the library, is given hereafter.

Figure II.1 : AMS structure Editor

ADL Compiler

Experimenter Simulator

Post-Processor

Plotter Reporter Animator Basic

Models Library

ADL Phase Editing Phase

Presentation Phase Simulation Phase

I I . 2 . 1 . L i b r a r y o f B a s i c M o d e l s

The core of the AMS is the library of basic models. Each basic model

corresponds to a communication entity. It is represented by an icon, an ADL

object, as well as a QNAP2 object. Hence, the library has different

representations depending on the phase where it is used. For the editing phase, and in the case of a graphical environment, the library is seen as a set of icons. At the ADL phase, the components of the library are described in ADL language;

the description is limited to the main attributes of the models. Finally, at the simulation phase, the library is seen as a set of models written in QNAP2 language.

The whole chapter III is devoted to the description of basic models called DBMs for Detailed Basic Models. A DBM can be seen as a black-box which has as inputs a set of parameters and as outputs a set of measurements (figure II.2). It is atomic, namely its modeling code cannot be changed by the end-user. However, a DBM can be composed of other DBMs. The composition is realized by the modeler; and will be explained in detail in chapter III.

A DBM can be instantiated several times for the same communication architecture. An instance of a DBM can be connected to one or several other instances of other DBMs. The end-user can configure each instance differently from the other instances of the same DBM.

Figure II.2 : DBM as a black-box

DBM measurements

parameters

A link, which connects two instances of DBMs, can be considered also as an object. It can transport messages in the two directions between the connected instances. Furthermore, a link is associated with a set of measurements which can be used mainly for describing the data traffic transiting through the link.

I I . 2 . 2 . E d i t i n g P h a s e

In this phase, the end-user constructs a communication system graphically and

hierarchically using the detailed basic models from the AMS library. The editing

phase is managed by a dedicated process called the graphical editor. A text-based

version of this editor is also provided for an end-user without graphical

capabilities; in this case, the end-user has to describe his architecture directly

using the ADL language. On the contrary, when the end-user works in a graphical environment, he does not need to know the ADL syntax. Indeed, the editor process is to generate the ADL code corresponding to the edited architecture. It is more practicable to use the graphical environment in order to help the end-users gain time and effort.

AMS provides a Graphical Editor that corresponds to the world view of the network designer, with icons that represents rings, buses, bridges, protocols, etc.

To edit the architecture, an end-user can create several instances of basic models, and connect them by links. The editor has the ability to provide substantial user interaction for either simple parameter changes or major reconfigurations of systems, and to permit the provision of hierarchical modeling capability for extremely large models. As a matter of fact, the editing of a network architecture can be done hierarchically (figure II.3). That is, an entire edited graph may be represented as a node within another graph. This hierarchical composition brings the powerful notions of data abstraction and modular construction into model construction.

Figure II.3 : Hierarchical edition Level 1

Level 2

Level 3

Each basic model is represented by a simple icon, i.e. with one display. In addition, the end-user has two facilities to edit the architecture : generic icon display facility and sub-model icon edition facility.

A generic icon also represents a basic model such as a bridge, but has several

displays. The display that appears in the edition window depends on some

attributes and/or on the basic model to which it is connected. For instance, the

display of a bridge is different if it connects two Ethernets, or two Token-Rings.

The second facility is a powerful mechanism provided by the atelier for the implementation of the hierarchical composition. A sub-model icon represent a whole sub-model which is a part of the system under study. For instance, when several local area networks are to be interconnected by a satellite backbone, each local area network can be represented by a sub-model icon, which in its turn contains other sub-model icons such as stack icons. A stack icon is a sub-model icon inside which the end-user can edit a stack of protocols. In general, a sub-model icon is constructed by combining several simple or generic icons or other sub-models.

The editor process internally uses a graphical database, which contains all the information about icons, pop-up menu and edition rules, allowing the end-user to edit graphically his communication system. This database is necessary in the editing phase, and is not used directly by the end-user.

In order to reduce the number of errors made in the editing phase, the end-user is assisted by a help menu, some predefined restrictions on the available choices depending on the models used and the way they are linked, and an on-line checker (errors verifier). The Editor generates, in a manageable manner, the description of the edited system following the ADL syntax. This description is necessary for the ADL phase.

The current version of the atelier is based on the graphical kernel GSS (Graphical System Support) which provides generic graph edition facilities to make the development of graphical performance modeling tools easier. More detail will be given in section 3.

I I . 2 . 3 . A D L P h a s e

This phase mainly consists of translating the description written in ADL language into a QNAP2 simulation model. In addition, the aim of this phase is to fulfill several objectives :

1. The definition of a clear border between the editing phase and the simulation

phase (figure II.4). This separation will enforce the independence between the

interactive part of the atelier represented by the editor and the computational

part represented mainly by the simulator. This phase permits the design of the

editor separately from the design of the computational part of the atelier, so that modifications in either tend not to cause changes in the other.

2. The improvement of the portability of the atelier. Clearly, several graphical editors can be developed for the atelier, depending on the platform where the atelier can be implemented. These platforms will run different operating systems and graphical kernels.

3. This phase allows an end-user to simulate a communication architecture even if he has no graphical editor at his disposal. In this case, he will describe textually his communication architecture directly in the ADL language.

4. Finally, the AMS-manager who implements a graphical editor is not obliged to know the simulation language QNAP2.

End-user

OGK

Figure II.4 : ADL phase as a border between editing phase and simulation phase QNAP2 Simulator

Editing Phase

A DL Process GSS

End-user

End-user

Simulatio n

The ADL phase is handled by a process called the ADL process. The ADL code produced in the previous phase constitutes one of the inputs of this process.

This process includes three main tasks which consist on compiling the ADL description, validating the corresponding architecture, also called checking task, and generating the QNAP2 code.

7 OGK for Other Graphical Kernel

The role of the checking task is to verify the correctness of the description, i.e. :

• Completeness of the architecture; namely if the communication system architecture contains what is required for the system to function properly,

• Local connectivity; namely if a relationship has been defined between two DBMs, then we are permitted to establish a relationship between their instances in the network architecture. Otherwise, we cannot couple their instances together.

• Full connectivity; namely if all the elements created by the end-user are linked in such a manner as to avoid having two or several portions not connected to each other.

• Attribute domain specifications; namely if all the parameters of DBMs have values included in defined ranges or defined sets of values.

The checking task is done before the QNAP2 code generation. The concepts used to carry out the checking task will be presented in chapter III. Actually, DBMs to be connected to each other have to comply with a number of constraints, in order to build coherent communication systems. These constraints can be summarized as follows :

1. Each instance of a given DBM has to be connected to other instances of other DBMs. As we know, a given DBM can be connected to other DBMs but, of course, not to all available DBMs in the library.

2. A relationship between two DBMs may require a maximum or minimum number of participating instances. Thus, only a restricted number of instances can be connected to each other. For example, a TCP DBM can be connected to an FTP DBM but only one instance of FTP can be connected to one instance of TCP.

3. It may happen that, even if a given DBM can be connected to a number of

other DBMs, one instance cannot be connected at the same time to instances

of all these permitted DBMs. Clearly, a mutual exclusion may arise between

the permitted DBMs. For example, an FTP DBM can be connected to either a

TCP DBM or a TP4 DBM, but not both at the same time.

4. Finally, if a DBM is neither a source of messages nor a sink, an instance of this DBM has to be connected to at least two instances of two other DBMs.

Remark

It should be noted that so far we have only checked the local connectivity between DBM instances in a network model and even if the network is fully connected, this is not sufficient, because the mere fact that a sequence of wire line or wireless links exists between some pair of network devices does not mean that they can interoperate. We must also be able to ensure meaningful communication between network devices by examining their ability to exchange data.

For example, if a desktop computer runs only an OSI protocol stack, it cannot interoperate with an FTP server, running only an Internet protocol stack, at any layer higher than data link. Nevertheless, it might still be possible to exchange files between them, if a third device, say a protocol gateway, is connected to both devices, functioning as a translator. Such a device may implement both an Internet and an OSI protocol stack, with an FTP-FTAM application gateway between them.

I I . 2 . 4 . S i m u l a t i o n P h a s e

The main objective of this phase is to assess the performance of the previously edited system. This phase includes making scenarios, executing simulations, and post-processing the rough results. This phase is handled by three processes which are the experimenter, the simulator and the post-processor.

I I . 2 . 4 . 1 . E x p e r i m e n t e r P r o c e s s

The experimenter goal is to help formalizing a proper experimental design to obtain the maximum information with the minimum number of experiments, also called scenarios. The experimenter allows the end-user to concentrate on the desired conditions for model execution and treatment of results.

A scenario on a model may be thought of as one or more executions of that

model under controlled conditions in order to observe the outputs. A scenario can

be edited graphically or textually with the ADL language. A scenario is defined

mainly by varying the values of some parameters, called free-variables. To each

free-variable is assigned either a set of values or a range defined by the lower bound, the upper bound and a step.

The end-user can also define a scenario using the concept of parallel step variation, which means that two or several free-variables change their values simultaneously.

I I . 2 . 4 . 2 . S i m u l a t o r P r o c e s s

This process compiles and executes the QNAP2 code generated by the ADL process. It calls the QNAP2 simulation solver. The execution depends on the scenarios defined by the end-user. At the end of the execution, all the desired rough results are produced. Figure II.5 shows the inputs/outputs of the simulator.

This process provides a feature which permits the simulation to execute against an actual traffic stream captured from a live network (e.g., recorded via a protocol analyzer), instead of traffic generated by a statistical traffic generator.

This is typically used when actual data is available from an existing network, which needs to be simulated to test for reconfiguration or future growth.

Figure II.5 : Inputs and outputs of the simulator Simulator

Results

QNAP2 Model DBM Scenario

Specifications

I I . 2 . 4 . 3 . P o s t - P r o c e s s o r

The recorded results of the simulation can be statistically analyzed with the

post-processor, so that aggregate parameters of interest can be reported. A

post-processor will compute the statistical information which the network

architect requests. It allows to draw direct cause-and-effect inferences about

system operation. The post-processor provides several routines that perform statistical analysis.

I I . 2 . 5 . P r e s e n t a t i o n P h a s e

This phase is meant to allow different presentations of the simulation results. It offers the end-user the possibility of supervising the simulation by visualizing its executions. In other words, it offers a high level animation showing, for instance, messages passing through the simulated architecture. This phase is handled by three processes which are the plotter, the animator and the reporter.

I I . 2 . 5 . 1 . P l o t t e r P r o c e s s

This process is to represent the results provided by the simulator in different ways depending on the choices of the end-user. He can choose the representation form (e.g., textual output, table, representational graph, bar diagram, pie chart, histogram, time series), colors, labels, etc.

I I . 2 . 5 . 2 . A n i m a t o r P r o c e s s

Animation serves many purposes. A well constructed animation can serve as a powerful validation device, particular with experts who know the “look and feel”

of a system and can assess it more easily visually than statistically.

The animation consists in visualizing the execution of the simulation by showing messages passing through the simulated architecture and the behavior of some given measurements. The animator process can be executed in parallel with the simulator process to show the progress of simulations on-line. In this case, we can speak of a synchronized animation. On the other hand, the animator can work asynchronously, namely this process will be activated, after the simulation is finished. In this case, the process needs a specific file containing the trace of the simulation.

I I . 2 . 5 . 3 . R e p o r t e r P r o c e s s

The reporter makes the management of documentation easier and allows the

development of tailored reports. Actually, intermediate reports can be produced

on a model, on a run, on a scenario, or on an analysis. Thus, the end-user has the capability to choose the kind of information he wants to include in his final reports.

I I . 3 . A M S P

A prototype of AMS is developed based on existing packages except the ADL language which is developed specially for the atelier. These packages are : QNAP2, GSS, MODLINE and S-PLUS. Figure II.6 shows the available tools in the prototype and on which packages they are based. Furthermore, the graphical user’s interface (GUI) of the prototype is the same as the GUI of MODLINE.

The simulator is based on QNAP2, the post-processor is based on S-PLUS, the

graphical editor is based on GSS, the textual editing of an architecture can be

done using ADL. The Reporter, Plotter, Animator, and Experimenter processes

are based on MODLINE.

Graphical Editor Textual Editor

Post-Processor Simulator

Reporter Experimenter

Plotter Animator

MODLINE

ADL GSS

QNAP2

SPLUS

Figure II.6 : AMS prototype

All the available tools can be used in any order. However the normal order of a performance evaluation study cycle (figure II.7) can be followed by the end-user.

It begins by editing a communication system and finishes by producing reports.

Figure II.7 : Performance evaluation study cycle

Animator Plotter

ADL Compiler Editor

Reporter

Simulator Post-processor

Experimenter

This section is structured as follows : first the packages are briefly described, then some important implementation aspects of the prototype are explained;

finally a concrete example of a communication network including a satellite backbone is given to illustrate how AMS is used to simulate such a system.

I I . 3 . 1 . S o f t w a r e K e r n e l s o f A M S

I I . 3 . 1 . 1 . G r a p h i c a l S u p p o r t S y s t e m ( G S S )

GSS

is a general graphical front-end which provides a generic graph editing facility, and facilitates the construction of graph manipulation tools. A GSS graph consists of a collection of nodes, links and comments. Both nodes and links can have attributes which consist of a variable quantity of data associated with each object. The nodes are displayed as small icons, the links are displayed as lines joining the icons, and the comments are displayed as text added to the graph.

GSS provides the end-user with facilities for editing the graph in a direct manipulation style. GSS displays the graph in a window, and then the end-user can create, move, modify or delete objects under control of the mouse or use a form-like interface for changing the values of objects attributes.

Any tool based on GSS consists of three parts :

1. GSS itself, which is a library of domain independent routines (more than 200) that provide facilities for interactive graph manipulation, storage, graph traversal, and so on.

2. A special format file which provides a description of the types of nodes and links out of which graphs may be built. This is known as the class description file. This file is written using a specific language called GDL for Graph Description Language.

3. Additional routines, which are specific to the application domain of the tool.

8 GSS is the result of an ESPRIT project called IMSE (Integrated Modeling Support Environment).

In GSS, graphs can be organized into hierarchy through the notion of subgraph.

A subgraph of a parent graph is a graph associated with one of the nodes in the parent graph.

I I . 3 . 1 . 2 . M O D L I N E

MODLINE is a Unix-based modeling environment. It consists in a set of (mostly) graphical tools connected to each other by a typed object system.

The tools supported within MODLINE are designed to assist in all stages of the performance analysis, including model construction, through experimentation, to the generation of final reports on findings. The environment has been designed to support users without in-depth knowledge of the tools and techniques employed.

The environment is made available to the user through a graphical interface, known as the Workbench, and by mouse and menu-driven operations on iconic objects.

A key feature of MODLINE is an object-oriented approach which is implemented by the Object Management System (OMS) at the core of MODLINE [40]. Objects are derived from a common entity relationship model of the whole system and may be, for example, models, results, reports or collections of input values. The OMS provides functions that allow the tools, and therefore allow the end-user, to create and delete certain objects, to group objects into directories, and to establish relational links between them.

I I . 3 . 1 . 3 . S - P L U S

S-PLUS is a statistical data analysis package, providing the end-user with convenient features for exploratory data analysis, modern statistical techniques, and offering an interactive graphical environment for visually exploring and thoroughly analyzing data.

Using graphical displays and various other data analysis tools, the end-user can obtain an understanding of the structure of his data, their distribution, and more.

Among its data analysis tools, there are a wide variety of built-in functions for

statistical and mathematical analysis, and a rich language for defining and

analyzing statistical models. These models range from simple, classical linear

regression models to complex, modern models involving locally weighted regression smoothers and classification.

S-PLUS includes an object oriented programming language and a unified paradigm for developing statistical models which will be used to create AMS post-processor routines. S-PLUS has features reminiscent of many other languages. It is strongly oriented towards vector and array operations, like APL.

It is interpreted, like BASIC and LISP. It is object-oriented, like C++ and CLOS (the Common LISP Object System). Its syntax is reminiscent of C.

I I . 3 . 2 . I m p l e m e n t a t i o n A s p e c t s o f A M S

In this sub-section, we focus on two important implementation aspects of AMS.

First, we will show for a normal use of the atelier, which data entries (i.e. inputs) the different AMS tools will use and which information they will produce (i.e.

outputs). The inputs/outputs are, essentially, text files. Several types exist, each file type has its proper format and its proper extension. These kinds of technical details are out of scope of this chapter. For more details, see [41] and [42].

Secondly, all the used and produced files are stored in a hierarchical structure which will be briefly presented.

I I . 3 . 2 . 1 . F i l e T y p e s

Eight types of files are used by the available AMS tools. Figure II.8 shows all the tools available inside AMS, except the reporter, in addition to the most important files handled by the tools as inputs and/or outputs.

The editor generates an “___.adl”

file containing the description of the edited communication network. This file is the input of the ADL compiler. If the file does not contain errors, neither syntactic nor semantic, the ADL compiler generates two files: a “___.qnp” file which contains the QNAP2 model associated with the edited communication network and a “___.var” file which contains the set of free-variables defined by the end-user. If this set is not empty, the end-user defines, through the experimenter, the scenarios he wants to make.

9 Each file type has an extension and its name is either chosen by the end-user or by AMS. In the text, the file names are not written and just represented by three under scores (“___”).

The experimenter generates a “___.sce” file. This file with the “___.qnp” file are used by the simulator for launching the execution of the simulations. The simulator generates several runs contained in “___.run” files, each one corresponds to a combination of the free-variables. A run file contains mainly the measurements asked by the end-user during the editing phase. Moreover, if the end-user wants to animate his simulation, the animation traces stored into

“___.tl” files are also generated by the simulator. These files will be used later by the animator for visualizing the execution of simulations.

The end-user can ask for the generation of appropriate measurements for his study using the post-processor tool. Herein, “___.run” files will be used as inputs. Clearly, the rough measurements produced by the simulation will be used to compute more pertinent measurements. The plotter can visualize either the rough results represented by “___.run” files or the measurements generated by the post-processor represented by “___.ana” files. It can generates also “___.plo”

files for later visualizations.

The last tool available inside AMS is the reporter. It can generate tailored reports.

Reports can contain interesting information chosen by the end-user. Reports are

generated at several levels. Communication network description, QNAP2 model,

scenarios, simulation runs, simulation results, or charts can be parts of reports.

Figure II.8 : Different file types used by the AMS tools

___.adl

ADL Compiler

___.var

___.qnp

Experimenter

___.sce

___.ru ___.tl

Post-processor Animator

___.ana Plotter

___.plo

I I . 3 . 2 . 2 . F i l e s S t r u c t u r e

Figure II.9 shows the structure of a database which contains a communication network model (“___.ams”), edited, executed, documented and analyzed. The file “___.gss” contains the graphical representation of the edited communication network; this file is generated by the graphical kernel GSS. For each model, several experiment plans can be created, each one will be stored in a directory (“___.plan”). Each plan directory might contain a scenario, simulation runs, animation files, plot files, and a report (“___.doc”). The end-user can create several analysis from the same runs, each analysis is stored in a separate directory (“___.pp”), which can contain analysis files, plot files and a report.

Figure II.9 : Hierarchical structure of the file types

___.pp ___.doc

___.plan ___.doc

___.gss ___.var

___.qnp ___.adl

___.ams

___.plo ___.tl

___.run ___.sce

___.doc ___.plo

___.ana

I I . 3 . 3 . E x a m p l e o f E d i t i n g a C o m m u n i c a t i o n N e t w o r k AMS should allow the end-user to study examples such as the communication system based on a satellite backbone shown in figure II.10. This system is intended to offer communication services through the efficient use of the satellite networks. It is composed of geographically scattered "Customer Network Facilities" (CNF) interworking through a backbone satellite which will allow direct communication paths between the earth stations located at the CNFs. The CNF consists of a LAN connecting several workstations. The LANs could be High Speed LANs such as FDDI or Medium Speed LANs such as Ethernet. The edition could be done in a top-down manner. Indeed, the system can be broken down into three main components. On one hand, there is a satellite backbone component, and on the other hand, many CNF components. Each CNF is connected via a gateway component to the satellite.

Gateway

Host Gateway

Gateway

Host

Host Host

Host

Satellite

Figure II.10 : Communication system based on a satellite network

Our primary objective in this section is to show that AMS is operational. Hence, we will limit our illustration to a concrete and classical example [43, 44] which is a simplified architecture (figure II.11). It consists of an interconnection network via a satellite backbone for which the network performances are obtained in [43].

Yang and al., evaluated the performance of this system both by analytical and simulation methods based on the QNAP2 package. Let us remind that QNAP2 is the kernel of the AMS simulator.

In this section, two fundamental steps are illustrated through the example : how

the editing of this simplified architecture can be done using the atelier, and how

results can be obtained from the atelier. In order to make the comparison of some

results easier, the performance results we present, are those found in [43]. The objective of simulating this architecture is to study the congestion of the system.

Indeed, congestion can dramatically influence the throughput of the network, the response time, etc.

I I . 3 . 3 . 1 . E d i t i n g

The simplified architecture is composed of a satellite backbone, and two Ethernet networks. Each LAN is connected via a bridge to the satellite, and supports TCP/IP protocols, upon a MAC layer. FTP is the only application that is handled by the workstations associated with each LAN.

The end-user can edit such an architecture in the main window using the simple icons and the generic icons and/or in a hierarchical manner using the sub-model editing facility. In figure II.11, all the available facilities are used. The simple icons are the Ethernet MAC, IP, TCP, FTP and the Satellite repeater; the generic icon is represented by the Ethernet-Satellite bridge; and the sub-model icon is represented by a stack of protocols which is identical to the stack edited in the main window.

Each basic model is characterized by a set of parameters and a set of measurements. When the end-user clicks on any object of the architecture (it may be an icon or link) a dialogue box appears allowing to modify parameters or to set measurements. The end-user may change the predefined parameter values, or defines a sub-set of them to be free. Making a parameter free will allow the definition of different scenarios. The end-user has to choose symbolic names for these parameters. The symbolic names are called free-variables.

In our case, two parameters will be associated with free-variables. They are the congestion window of the TCP sender, and the bit error rate of the satellite repeater. The symbolic names of these two defined free-variables are “congwin”

and “ber” respectively.

Figure II.11 : Simple architecture

Figures II.12 and II.13 show the list of TCP parameters and the list of satellite repeater parameters. Each parameter is associated with either a predefined value or a free-variable.

Figure II.12 : TCP parameters

Figure II.13 : Satellite repeater parameters

Each measurement is associated with a switch initially set to OFF. To have some

measurements, the end-user has to ask explicitly for their computation by setting

to ON their corresponding switches. Figure II.14 shows the list of TCP measurements, some of them are simple and others are more complex; indeed, the mean, the variance, the maximum and the minimum can be processed if the end-user asks for their computation.

Figure II.14 : TCP measurements

I I . 3 . 3 . 2 . P e r f o r m a n c e R e s u l t s

Once the first step is successfully achieved, the QNAP2 code is generated corresponding to the edited architecture. The second step is about how to obtain results from AMS. As we said earlier, the end-user has to ask explicitly for the measurements he wants to obtain. Using the Experimenter, one or several scenarios using a form-like interface can be edited (figure II.15). Either a set of values or a range is assigned to each free-variable.

The Simulator will launch the appropriate number of simulations corresponding to the edited scenarios. For the example of figure II.15, ten simulations will be executed.

The AMS Post-Processor will be used to calculate the throughput which is

defined, in this case, to be the file size divided by the file transfer time. File

transfer time is a measurement of FTP DBM. In our example, its corresponding

switch has to be set to ON.

Figure II.15 : Form-like interface for editing scenarios

Finally, the Plotter will allow us to draw some significant charts, such as the throughput versus congestion window or the throughput versus bit error rate which are the main results found in [43].

The tuning of our system fulfills the conditions chosen by Yang, as follows : the propagation delay on the satellite backbone is equal to 257.6 ms with a bandwidth of 1.544 Mb/s, the bridges are modeled as learning bridges [45] with a packet switching time equal to 0.1 ms, and the Ethernet bandwidth equal to 10Mb/s. Furthermore, a workstation on one LAN is assumed to be actively sending a file with a size of 500 Kbytes to the other workstation on the other LAN via the satellite repeater.

Furthermore, TCP uses a traditional sliding window with a fixed size through the whole life of a connection, its segment size is equal to 1500 bytes, and the timeout is set to 1 second.

Figures II.16 and II.17 show the charts representing the throughput versus the

congestion window for BER = 0 and 10

. We include the results obtained by

AMS and the results found in Yang’s paper. These figures depict that both results

are almost identical. This validates our models on one side and proves that we gain confidence in our AMS atelier on the other side.

BER=0

0 0.1 0.2 0.3 0.4 0.5 0.6 0.7

0 4 8 12 16 20 24 28 32 36 40 44

Window Size

Throughput

AMS Yang

Figure II. 16 : Throughput (Mb/s) Vs. Window size (BER = 0)

BER=1e-05

0 0.05 0.1 0.15 0.2 0.25 0.3

0 4 8 12 16 20 24 28 32 36 40 44

Window Size

Throughput

AMS Yang

Figure II. 17 : Throughput (Mb/s) Vs. Window size (BER = 10

)

I I . 4 . A

D

L

ADL is a language which allows the end-user to describe a complete network architecture. It is used, in the AMS atelier, to separate the editing phase from the simulation phase. It is object-oriented, where mainly the concepts of hierarchy and heritage are used.

ADL has been designed for several reasons, one of them is to be able to express

simply and efficiently any network architecture which will ease the work of any

graphical kernel mainly for the generation of code. The expressiveness of this language is very high, which is quite useful to define complex systems.

ADL has pre-defined objects which are mainly the models (DBMs) available inside the library. It allows an end-user to define generic objects in a hierarchical way. As we will see, later on, each generic object inherits all the characteristics of its components.

This section is structured as follows. First the pre-defined objects of the language are introduced. Then, the structure of a generic object is explained. Finally, we show how a communication network architecture can be described using an ADL program.

Hereafter we give a certain number of written conventions used through this section :

1. The reserved Words are written in bold capital letters.

2. The name of identifiers are in small letters, however the end-user is free to use either small or capital letters to name his identifiers. The language is sensible to the type of letter (small or capital); indeed, two variables which have the same spelling but have a different type of letters are different.

3. The comments are in italic and start by #.

4. The indentations are made in order to read easily the examples, but they are not mandatory.

The exact syntax is not given in this section. Appendix C contains an extended Backus Naur form of ADL syntax.

I I . 4 . 1 . P r e - d e f i n e d O b j e c t s

There are two pre-defined-object classes in ADL : Simple Object class (SIMO)

and Ensemble Object class (ENSO). The database which will contain the

definitions of SIMO and ENSO objects has to be stored into a separate text file,

which is independent of the files where the end-user architectures will be

described.

I I . 4 . 1 . 1 . S i m p l e O b j e c t

A simple object class is a set of DBMs. Each simple object (DBM) has a unique name which is a reserved word. It is associated with a set of parameters and a set of measurements (if any). Each parameter has a name and a pre-defined value

. A particular parameter, called “NAME”, will contain the name of an instance of the object. On the other hand, each measurement has a name and is initially set to OFF. A measurement is either referred as SIMPLE or as STAT. The type STAT means that the MEAN, the VARIANCE, the MAXIMUM, the MINIMUM and the confidence interval can be computed.

The declaration of a SIMO object might contain two parts, a PARAMETERS part and a METRICS part. In the first part, the parameters of the SIMO object are listed with their default values. Only one parameter with its pre-defined value can figure on each line. In the second part, the measurements which can be computed for the SIMO object are listed with their type (SIMPLE or STAT). Only one measurement with its type can figure on each line. Hereafter, we give an example of the SIMO object TCP :

SIMO TCP; # This is an example and not the complete definition of TCP object PARAMETERS

NAME := “tcp_inst”;

SEG_SIZE := 576; # Segment size (bytes)

CONG_WIN := 100; # Congestion window (segments) TIMEOUTX := 2000; # Maximal duration of a timeout (ms) METRICS

WIN_USE := STAT; # Window usage

TRAN_SEG := SIMPLE; # Number of transmitted segments END;

I I . 4 . 1 . 2 . E n s e m b l e O b j e c t

An ensemble object is a set of simple objects which have some common characteristics. Each ensemble object has a unique name which is a reserved word.

10 In ADL, a value is an integer or a real (signed or not) or a string.

At the creation time of an instance of an ensemble object, only one simple object will be chosen and instantiated, then the parameters and measurements of this chosen object will be applied to the ensemble object instance.

The syntax of the declaration of an ENSO object is the following: for each ENSO object the list of SIMO objects is written between two brackets, separated by commas. The SIMO objects have to be defined previously in a database which contains all the pre-defined objects.

Hereafter are examples of ENSO objects (BRIDGE, TPx and MAC). We assume that BRIETET, BRIETSAT, BRIETTR, TP0, TP1, TP2, TP3, TP4, ETMAC, TRMAC, TBMAC and FDDIMAC are SIMO objects :

# BRIdge EThernet EThernet, EThernet SATellite, EThernet Token-Ring

# The different classes of the transport protocol ENSO TPx = {TP0, TP1, TP2, TP3, TP4}

# Different MACs for LANs (Ethernet, Token-Ring, Token-Bus, FDDI) ENSO MAC = {ETMAC, TRMAC, TBMAC, FDDIMAC}

I I . 4 . 1 . 3 . O b j e c t T y p e “ A N Y ”

The object type “ANY” is a type of top level, it is the root of all the object types.

It is not associated with any parameter or measurement. Object ANY and

Ensemble objects will be used to define generic objects. Figure II.18 shows the

hierarchy among the ADL objects.

Figure II.18 : Hierarchy of objects

I I . 4 . 2 . G e n e r i c O b j e c t

A generic object (GENO) is an object which will be defined by the end-user. It can be a combination of pre-defined objects, and/or other generic objects previously defined. It is called ELEMENT. The definition of an ELEMENT might have four parts, the DECLARATION part, which is mandatory, the CONNECTION part, which is mandatory if at least two object instances are declared in the previous part, the SPECIALIZATION and PLAN parts which are not mandatory.

SIMO

FTP TCP

TP4 ... ^ENSO

MAC

BRIDGE

TPx

...

ANY

An ELEMENT contains at least a component. If more than one component are

declared and are of different types, they have to be connected in a right way. In

the SPECIALIZATION part, the end-user can change the default values of some

parameters, set to ON some measurements and/or define more precisely a

variable which was previously declared as an ENSO object or as ANY. The

PLAN part provides a mean for defining simulation experiments (scenarios).

Hereafter, an outline of the definition of an ELEMENT is given : ELEMENT elem_name;

DECLARATION ....

CONNECTION ....

SPECIALIZATION ....

PLAN ....

END;

I I . 4 . 2 . 1 . D E C L A R A T I O N P a r t

In this part, one or several variables (simple or array) can be declared. Their types are either pre-defined objects such as SIMO objects, ENSO objects, ANY, or end-user objects (GENO objects) which were already defined. Hereafter, an example is given where the ELEMENT contains instances of different DBMs, some of them are declared as simple variables, and the others are declared as arrays :

DECLARATION

# four object instances declared as simple variables, two of type ANY and

# the other two of type IP.

ANY a1, a2;

IP i1, i2;

# object instances of types TCP, FTP and MAC declared as arrays

TCP t(5);

FTP f(3);

MAC m(2);

I I . 4 . 2 . 2 . C O N N E C T I O N P a r t

This part is mandatory in the case where the DECLARATION part contains at

least two variables associated with two different objects. The declared variables

must be connected to each other in a right way. There are some restrictions for

connecting SIMO, ENSO and GENO objects together. These restrictions are

explained in chapter III. The end-user can give a connection a symbolic name,

which will be used afterwards to ask measurements on this connection. There are three possible measurements which can be asked by an end-user :

1. NBMESSAG : Number of messages transited through the link 2. NBOCTET : Number of octets transited through the link 3. MESIARV : Messages inter-arrival times.

The first two measurements are of type SIMPLE, and the third one is of type STAT. For each measurement, two values are computed for the two directions.

Furthermore, the end-user can ask to have a TRACE on a link. Clearly, each time a message transits by the link, some information will be stored in a text file. This information is : initial sender address, final receiver address, length and time of arrival of the message on the link. The file containing a TRACE will be treated by routines belonging to the post-processor, in order to characterize the traffic which has transited through the link. TRACE can be seen as a special measurement of a link.

One or several object instances can be connected to another object instance using a three-character terminal symbol “↔“. Hereafter is an example of connections based on the variables declared in sub-section 4.2.1. Moreover, figure II.19 shows the configuration of these connections :

CONNECTION

# connection of two instances m(1) ↔ i(1);

f(1) ↔ t(1);

f(2) ↔ t(2);

a1 ↔ t(3);

a2 ↔ t(5);

# connecting three instances to

# the same instance

t(1), t(2), t(3) ↔ i(1);

t(4), t(5), m(2) ↔ i(2);

# a link has a symbolic name f(3) <link1> t(4);

Figure II.19 : Example of connections

f(1) f(2) a1 f(3) a2

t(1) t(2) t(3) t(4) t(5)

i(1)

m(1)

i(1)

m(1)

I I . 4 . 2 . 3 . S P E C I A L I ZA T I O N P a r t

In this part, the end-user can change the default value of a parameter or define it as a free-variable, set a measurement to ON, and define precisely a variable which is associated with an ENSO object or with ANY.

The parameters and measurements which will be specialized can belong to objects instantiated inside the current ELEMENT or to objects instantiated inside another ELEMENT previously defined which will be a component of the current one.

Based on variables declared in section 4.2.1., the following example illustrates a SPECIALIZATION part:

SPECIALIZATION

# change the default value t(1).SEG_SIZE := 1000;

# define four parameters as free-variables

t(2).SEG_SIZE := segz2; t(3).SEG_SIZE := segz3;

t(4).SEG_SIZE := segz4; t(5).SEG_SIZE := segz5;

# set to ON the MEAN part of this measurement t(1).WIN_USE:MEAN := ON;

# set to ON this simple measurement t(3).TRAN_SEG := ON;

# define these variables as an Ethernet MAC m(1) := ETMAC; m(2) := ETMAC;

# define these variables as Telnet Client and Telnet Server a1 := TELNETC; a2 := TELNETS;

I I . 4 . 2 . 4 . P L A N P a r t

In this part, the free-variables, defined in the SPECIALIZATION part, will be assigned several values (sets or ranges).

ADL provides two types of assignation for creating scenarios, called serial and parallel assignation, respectively. If two or several free-variables have be assigned to the same set of values, in this case, the end-user can either assign separately to each free-variable this set of values or can use the serial assignation.

On the other hand, if two or several free-variables assigned to a set of values by

means of the parallel assignation, then these free-variables will have the same

value at each simulation run. Furthermore, the end-user can mix serial and parallel assignations.

Hereafter, we give an example of a PLAN part where the free-variables were already introduced in the example of section 4.2.1. :

PLAN

# a free-variable is assigned to a set of values segz2 := 300 , 375, 500;

# serial assignation

segz3, segz4 := 500 UNTIL 1000 STEP 100;

# parallel assignation

segz4 || segz5 := 500, 600, 750, 900;

# Here serial and parallel assignation are mixed; segz4 and segz5 are in

# parallel, while segz3 is in series with the two others.

segz3, segz4 || segz5 := 600 UNTIL 1000 STEP 200;.

In the last part of this example, segz3, segz4 and segz5 will be assigned to three values 600, 800 and 1000. Since segz4 and segz5 are in parallel, they will have the same values at each simulation. With these three free-variables, nine simulations will be launched. The table below shows for each simulation the values of the three free-variables.

sim segz3 segz4 segz5 sim segz3 segz4 segz5

1 600 600 600 6 800 1000 1000

2 600 800 800 7 1000 600 600

3 600 1000 1000 8 1000 800 800

4 800 600 600 9 1000 1000 1000

5 800 800 800

I I . 4 . 3 . A D L P r o g r a m

An ADL program contains the whole description of a communication system.

The description can be done hierarchically using the generic objects or in a flat

manner using only the pre-defined objects. Scenarios can also be described using

the ADL language through the usage of PLAN parts of generic objects and the PLAN part of the ADL program.

An ADL program is subdivided into six parts: GLOBAL, DEFINITION, DECLARATION, CONNECTION, SPECIALIZATION and PLAN parts.

The GLOBAL part, which is mandatory, contains mainly the choice of a database containing pre-defined objects, and the list of some constants which can be used in the other parts of the program. The DEFINITION part contains the definition of the end-user objects (the ELEMENTs).

The role of the remaining four parts is the same as for the part of an ELEMENT.

Hereafter, we outline an ADL program : ARCHITECTURE arch_name;

GLOBAL ....

DEFINITION ....

DECLARATION ....

CONNECTION ....

SPECIALIZATION ....

PLAN ....

END.

I I . 4 . 3 . 1 . G L O B A L P a r t

In this part the end-user has to define which set of pre-defined objects (SIMO

and ENSO objects) he wishes to use in his program. Namely, he includes a given

database of pre-defined objects. On the other hand, the end-user can declare one

or several constants. Each constant has an identifier, which can be used inside the

other parts of this ADL program. An example is presented in the following:

GLOBAL

# include the database called predef_obj_base

INCLBASE “home/radouane/library/predef_obj_base”;

# three constants nbtcp := 5;

nbcon := 10;

delay := 0.0034;

I I . 4 . 3 . 2 . D E F I N I T I O N P a r t

In this part, the end-user has to define his ELEMENTs (if any), and he can also include, in the program, some external definitions. Hereafter a simple example of a DEFINITION part :

DEFINITION

# include External definitions

INCLDEF “/home/radouane/definition/def1”;

# definition of an end-user objects ELEMENT st1;

....

END;

ELEMENT st2;

....

END;

A file containing external definitions contains only definitions of end-user objects (ELEMENTs) as shown in the following:

# This file contains external definitions EXTERNAL

ELEMENT elem1;

....

END;

...

ELEMENT elemk;

...

END;

END.

I I . 4 . 3 . 3 . R e m a i n i n g P a r t s

The four other parts, DECLARATION, CONNECTION, SPECIALIZATION and PLAN are to be used identically as those defined for an ELEMENT object, except that the end-user has to use the variables declared inside the DECLARATION part of the program.

I I . 4 . 4 . E x a m p l e

The example which will be described in this sub-section is almost the same as the example edited graphically in sub-section II.3.3.

In this example, we describe a communication network where two Ethernet LANs are interconnected through a satellite backbone. Each LAN is connected to the satellite by a bridge. Two ELEMENTs will be defined as stack and lan_network. We assume that MAC_ETHER, IP, TCP, BUS_ETHER, TELNETC, TELNETS, FTP, and BRIETSAT are SIMO objects; BRIDGE and SOURCE are ENSO objects where SOURCE contains TELNETC, TELNETS, and FTP.

ARCHITECTURE example;

GLOBAL

INCLBASE “home/radouane/library/ObjectBase”;

DEFINITION

#

20

ELEMENT stack;

MAC_ETHER mc;

IP int;

TCP tr;

SOURCE src;

CONNECTION

mc, tr

tr ↔ src;

tr.SEG_SIZE := 1500;

tr.CONG_WIN := congwin;

PLAN

congwin := 8 UNTIL 42 STEP 4;

END;

#

21

ELEMENT lan_network;

BUS_ETHER bus;

stack st(4);

CONNECTION

st(1).mc, st(2).mc

st(3).mc, st(4).mc

st(1).src := TELNETC;

st(2).src := TELNETS;

st(3).src := FTP;

st(4).src := FTP;

st(4).tr.SEG_SIZE := 576;

END;

DECLARATION

#

22 lan_network l1, l2;

BRIDGE br1, br2;

SATELLITE sat;

CONNECTION

l1.bus

l2.bus

br1, br2

SPECIALIZATION

br1 := BRIETSAT;

br2 := BRIETSAT;

sat.BER := ber;

PLAN

ber := 20 UNTIL 30 STEP 2;

END.

Figure II.20 : stack ELEMENT Figure II.21 : lan_network ELEMENT src

tr int

mc

TELNETC TELNETS

FTP FTP

bus

st(2)

st(4) st(3)

st(1)

Figure II.22 : The ADL declared network architecture

l1 l2

sat

br1 br2

I I . 5 . C

We have described the design of AMS, an atelier for modeling and simulation.

This atelier is meant to be able to model and simulate complex communication systems. It consists of four independent phases, each phase involves one or several processes. The adopted division allows a high degree of modularity and hence the portability over several platforms. A prototype of AMS has been developed, on the basis of existing packages which proved their usefulness in their respective field. The capabilities of the prototype have been demonstrated through an example. We shown how a communication system based on a satellite backbone is edited graphically, and how it is tuned before launching simulations meant to assess the performance of this system. Finally, the ADL language was presented and almost the same example was described using this language.

The next chapter will be dedicated to the description of a basic model, its internal

structure, how it can be connected to other basic models, and how it can be

composed with others in order to define generic and composite models.