Chapter III

CHAPTER III

DBM : D ^ETAILED B ^ASIC M ^ODEL

I I I . 1 . I

The purpose of this chapter is twofold. On the one hand, to define precisely the internal structure of a Detailed Basic Model (DBM). A good definition of this structure will help to reuse a DBM several times in different communication architectures. On the other hand, to show how this structure is appropriate to construct generic and composite models.

As we said in the previous chapter, a model of a given architecture will be composed of DBMs. Each DBM model is either a protocol, a network device, a medium, or any component of a communication network. It is instantiated one or several times. The instances are linked together so as to mimic the given architecture. The global model of an architecture will be constructed from a subset of the available DBMs, without changing their codes. This implies that DBMs have to be structured so that they can be composed¹ easily and efficiently.

In the second section of this chapter, we describe the internal structure of a DBM. It is important to realize that, each model has to follow this structure in

1 The composition mechanism will be defined precisely in section III.4.2.

order to be added into the library of DBMs, and thus to be used for constructing communication architectures.

The DBMs will be designed as objects which can be instantiated several times, thus their codes have to be reentrant.

Each DBM is to be detailed so as to reflect the exact behavior of its corresponding target component². Therefore, we have to specify the functions performed by the target component as precisely as possible. This is why basic models are called Detailed Basic Models (DBMs). The main advantage of this approach is to have accurate measurements and to seek the largest possible number of parameters to characterize the target component.

A DBM may have a large number of parameters which will make it flexible from the end-user's point of view. Each parameter belongs to a given class and has an initial value set by the modeler during the modeling phase. This default value will be used if the end-user does not change it. If the end-user wants to change the default values of the parameters, the new values have to belong to defined ranges (if any).

The ultimate goal of the modeling process is to assess the performance of the modeled architecture. Hence, each DBM has to incorporate a certain number of measurements to be computed during the simulation.

Furthermore, as a rule, a DBM cannot be used alone, it must be connected with one or several other DBMs, in order to make up a complex system.

Consequently, a DBM needs one or more interfaces.

For a model to be included into the DBMs library, it is not sufficient that it follows the structure of a DBM, it also has to be verified and validated. Section III.3 of this chapter examines how a DBM can be verified and validated. Section III.4 describes how generic models are defined and how their associated composite models can be constructed. We will show how the internal structure of DBMs is suitable to construct generic and composite models efficiently. Section III.5 explains how a DBM is implemented when using the QNAP2 language. At the end, a conclusion is drawn.

I I I . 2 . I

S

D B M

The internal structure of a DBM is composed of three blocks (figure III.1) : the Behavior Engine Block (BEB), the Interfaces Block (IB) and the Measurements Block (MeB). The structure is designed to meet the following fundamental objectives :

• Each DBM is self-contained, namely the behavior of the target component is modeled inside the DBM, and all the interactions with the outside world take place through interfaces. In other words, the behavior is delimited by means of interfaces.

• We keep in mind that each DBM may be a component of a communication system. Hence, a DBM must be connected to other DBMs; connections are made via interfaces. Interfaces have another important role, which is to free the BEB of messages' exchange between the DBM and the outside world.

This intends that the BEB has to handle only the behavior of the target component and not the issue of how to structure the messages.

• The main objective of modeling is performance assessment. Hence, statistical results are required. They will be processed during the simulation phase. Each DBM is intended to offer one or several measurements, which must be meaningful to an end-user.

A DBM can be characterized by a number of parameters. The parameters are classified into two classes, the configuration parameter's class and the performance parameter's class. The parameters of the first class are transparent for the end-user while the parameters of the second class can be used by the end-user to assess the performance of the DBM.

The following sub-sections explain the internal structure of a DBM more thoroughly. Section III.5 shows how this structure is mapped into the QNAP2 language.

Figure III.1 : Internal structure of a DBM Behavior Engine Block

Interface 1 Interface 2

...

Interface N

Measurements Block

PARAMETRES

ON / OFF Interfaces Block

I I I . 2 . 1 . B e h a v i o r E n g i n e B l o c k

The behavior of a target component is modeled within the BEB of its associated DBM. The BEB is an open network of stations³. Each station includes a queue with limited or unlimited capacity, and one or several servers. The network of stations is open because it receives (respectively, sends) from (respectively, to) the outside, through the interfaces, different messages. The configuration of the network of stations and the services offered by each station are left to the responsibility of the modeler. The complexity of the network of stations heavily depends on the complexity of the target component. In chapter IV, we will describe thoroughly how to define such a network in the case of protocol entities.

The modeler has to use the specification of the network component he wants to model. The specifications are found either in the standards or elsewhere. They are written in English or in a formal description language. Of course, the modeler has to remove from the specification all the details that are irrelevant for his model, i.e., those which do not influence the performance.

I I I . 2 . 1 . 1 . P a r a m e t e r C l a s s e s

The BEB is controlled by a set of parameters. The parameters are categorized into two main classes: the configuration parameter class and the performance parameter class. All the DBMs do not always have these two parameter classes.

III.2.1.1.1. Performance Parameter Class

The parameters of this class are accessible to the end-user, and they may play an important role in the performance of the system where the DBM is instantiated.

The modeler of a DBM chooses pre-defined values of these parameters. An end-user can modify those pre-defined values in order to study their impact on the behavior of the DBM.

For instance, the size of the sliding window is a performance parameter for the HDLC (High level Data Link Control) protocol. It was proved in [48] that the performances of the protocol heavily depend on the values given to this parameter.

III.2.1.1.2. Configuration Parameter Class

The parameters of this class are not accessible to the end-user, so they are transparent for him. Their values depend on the context where the DBM is instantiated and/or on some characteristics of the DBM. Namely, the values of these parameters are set according to the configuration of the network where the DBM is used. In addition, the values may be different for the same parameter when more than one instance of the DBM are used in a communication system.

As an example, the maximal size of the fragments is a transparent parameter in the Internet Protocol (IP), since it depends on the sub-network where IP is used.

If IP is over an Ethernet network, the maximal size of fragments is equal to 1480 octets. On the contrary, if IP is over an FDDI network, the maximal size of fragments is equal to 4480 octets. The value of this parameter will be set by the AMS during the edition of a network where the DBM IP is instantiated.

Remark

The parameters of this class can also influence the performances of the communication system where the DBM is being used.

I I I . 2 . 1 . 2 . P r o c e s s i n g O v e r h e a d A s s e s s m e n t

One of the most difficult aspects of modeling a target component is to assess its processing overhead. The processing overhead of a component is the time necessary to handle an event or to process a message. The processing overhead is hard to assess, because the same target component can be implemented in various environments based on different hardware and software. The assessment becomes even more difficult if the processing overhead also depends on the type of handled job.

For instance, the processing overhead of a protocol such as TCP (Transfer Control Protocol) depends on : i) the machine on which it runs, ii) the operating system under which it runs, iii) the implementation of the protocol, namely its code, and iv) the kind of event it is processing: is it an arrival of a message from the upper layer or the arrival of a segment from the lower layer ? Clark in [49], analyzed the TCP processing overhead, and showed the difficulty to assess it.

The processing overhead can be viewed as a configuration or performance parameter, depending upon the DBM, and on the knowledge the end-user and/or the modeler may have about it.

I I I . 2 . 2 . I n t e r f a c e s B l o c k

The interfaces block is an important part of a DBM for several reasons. The modularity aspect of a DBM is reinforced by their presence. They allow the modeler to develop a DBM independently of any system from which it can be a component. Well-defined interfaces also promote the reuse of the global model.

Finally, they free the BEB of the message exchange with the outside world.

A DBM can have several interfaces, denoted by N as depicted in figure III.1. N can either be a fixed value known during the modeling phase or it can vary. In the later case, the modeler can progressively add new interfaces to the DBM. A given interface can be instantiated one or several times if an instance of current DBM (denoted C-DBM) is connected to one or several instances of a DBM through this given interface. In sub-section III.2.2.2, we will show how to classify the interfaces.

An interface is represented by means of two stations (figure III.2), each station is

outside, which are meant to be sent later to the BEB. Sout receives messages from the BEB to be sent later to another DBM, which is connected to it. The services inside Sout and Sin both depend on the type of DBM connected to the current DBM, and the type of messages to be handled by the C-DBM.

Sout Sin

BEB Another

DBM

Figure III.2 : A standard interface

It may happen that the message flow between two interconnected DBMs is unidirectional. In this case, one server (either Sout or Sin) will never receive messages, and consequently the corresponding service will never be triggered.

Finally, seen from the outside, all the interfaces are alike. However, they are different in the way they interact with their BEB and with the outside world.

Their main function is to convey messages from a BEB to the outside and vice versa.

Figure III.3 shows a DBM with its BEB and one interface. All the messages exchanged with another DBM transit through this interface.

Behavior Engine

Block I

n t e r f a c e

D BM

Another DBM

Figure III.3 : A DBM with its BEB and one interface

I I I . 2 . 2 . 1 . S t r u c t u r e o f M e s s a g e s

A DBM handles two main classes of messages. Messages handled by the BEB belong to the first class, while messages going into or out of the DBM through the interfaces, belong to the second class.

For the first class, there is no specific structure defined, because the structure heavily depends on the behavior of the target component, and the way it is modeled inside the BEB. Hence, it is left to the responsibility of the modeler.

The messages belonging to the second class are called “transit messages”, and have to comply with a specific structure. Complying with a specific structure has four main advantages :

• The service of the servers, components of an interface, will be easily defined, knowing how to structure a message exiting a DBM and how to handle a message entering a DBM.

• This structure will facilitate the encapsulation of data into the messages, in order to allow a transparent transfer through successive DBMs, which do not have to know the content of those messages.

• This structure will help the modeler to reuse the same interface for connecting different DBMs to the C-DBM.

• Finally, this structure will contribute to harmonize the interaction between DBMs.

The specific structure to be followed by the messages entering or exiting a DBM consists of an object containing two pointers (RFMS and RFCT). The RFMS pointer references an object containing data, while the RFCT pointer references an object containing control data (figure III.4).

The object containing data only has to be transferred. It is not accessible to the intermediate DBMs that receive it, but the recipient DBM can read its content.

Thus, the internal structure of data is transparent for the intermediate DBMs that are used for the transfer. This structure is known to the DBM that sends the message and to the DBM that will receive it.

The object containing control data is used to coordinate the interaction between the two connected DBMs. So, the internal structure of this object has to be known by the two DBMs.

RFMS RFCT

Data 1

Control Data 1

Figure III.4 : The structure of a message entering or exiting a DBM via an interface

The data encapsulation can be done each time a DBM has to send a message to the outside world, namely to one of its connected DBMs. Figure III.5 shows two data objects encapsulated into a transit object. The extraction of data objects is done by the DBMs that are being crossed by the flow of messages.

RFMS RFCT

Data 1 Data 2

Control Data 2 Figure III.5 : Data encapsulation

Figure III.6 shows an example of transit messages’ flow through a certain number of DBMs that form a simplified architecture. DBM 1a represents the source of messages, while DBM 1b represents the sink. DBM 2a, DBM 3a, DBM 3b and DBM 2b are the intermediate DBMs, i.e., they form the path of message flow. This figure shows how the transit messages are created step by step during the transfer of data from the DBM source to the DBM sink. At each step, the control data are exchanged and the data to be transferred are first encapsulated and later extracted by the recipient DBM.

DBM 1a

DBM 2a

DBM 3a DBM 3b

DBM 2b DBM 1b Data 1

Data 1 Data 2

Data 1 Data 2

Data 1 Data 2 Data 1

Control 1

Control 2

Control 3

Control 4 Control 5

Figure III.6 : An example of a flow of transit messages

Remark

The modeling of a transit message is inspired from the encapsulation function of a PDU into an SDU.

I I I . 2 . 2 . 2 . C o n n e c t i o n o f D B M s

Two DBMs can be connected to each other through their respective interfaces (figure III.7). The Sout station of DBM 1 will send transit messages to the Sin station of DBM 2. The opposite is also true, namely, the Sout station of DBM 2 will send transit messages to the Sin station of DBM 1.

As we will see, a given DBM can be connected to different other DBMs by the same interface. This has prompted us to use the following technique called delayed binding. Delayed binding is a mechanism that permits the decision, on what a DBM is connected to, to be deferred from the editing phase to the simulation phase.

Remark

The validity of the interconnection between several DBMs is not checked by the DBMs themselves but with tools developed inside the AMS (Atelier for Modeling and Simulation).

In this sub-section, we introduce some new concepts that will allow better usage of the interface and avoid duplicates.

Behavior Engine of DBM 1

Behavior Engine of DBM 2

Sout Sin

Sin Sout

Figure III.7 : Connection of two DBMs

III.2.2.2.1. Facet Concept

Each DBM can be connected to a variety of other DBMs, but as we will see in this section, all these DBMs can not be connected, at the same time, to the C- DBM. Let us say that C-DBM has several facets, each facet represents a DBM that can be connected to C-DBM.

Consider the following example illustrated in figure III.8. This figure shows that C-DBM can be connected to DBM1 and DBM2. In this case, we say that DBM has two facets which are DBM1 and DBM2. Facet also refers to the application that provides for a given DBM, the set of its facets. For the example below, Facet(C-DBM) = {DBM1, DBM2}.

The facet concept has been defined to determine which set of DBMs can be connected to a given DBM.

The same III.8 figure shows two connections C and L, between C-DBM and respectively DBM1 and DBM2. These connections are abstract, in the sense that they only show that these DBMs can be connected to each other.

The relation facet is commutative, because one facet of DBM1 is C-DBM, and one facet of DBM2 is C-DBM as well.

DBM1

DBM2 C

C-DBM

L

Figure III.8 : DBM1 and DBM2 are two facets of C-DBM

In conclusion, “facet” denotes three aspects : a relation, an application and a DBM. For the first aspect, we say that DBM1 is related to C-DBM by the facet concept. For the second aspect, we say that {DBM1, DBM2} is the set of facets of C-DBM. And, for the third aspect, DBM1 is a facet of C-DBM.

The Noc function: Number of connections

Several instances of the same C-DBM can be involved in a specific architecture.

We denote c-dbmi (in small letters) the ith instance of C-DBM.

In term of instances, and if we only consider the C connection, the c-dbmi instance can be connected to several instances of the DBM1, denoted dbm1_j (j varies between 1 and mi in figure III.9). The

(

)

1 2

1

2 ...

c c

cm

m c-dbm i

dbm1

dbm1

dbm1 i i

Figure III.9 : m_i instances of the C connection

Let us denote Noc(dbm, FACET) the number of connection instances that have dbm as one extremity and an instance of FACET as the other extremity. For instance, in figure III.9 : Noc(c-dbmi, DBM1) = mⁱ.

Each facet F of a given DBM is associated with two integers m_DBM,F and M_DBM,F that respect the following inequation : m_DBM,F ≤ Noc(dbm_i, F) ≤ M_DBM,F, ∀ dbm_i instance of DBM, m_DBM,F can be zero and M_DBM,F can be infinite⁴. If m_DBM,F is equal to zero, this means that for certain architectures the connection between the DBM and F is not required. If M_DBM,F is greater than 1, this means DBM can play the role of a multiplexer or a demultiplexer, and it is not a source of messages.

Example

Let us consider the following example where we assume that the current DBM is the IP protocol.

TCP UDP

IP

LLC

tcp1 tcp2

ip1

llc1

Figure III.10 : Facet of the DBM IP Figure III.11 : Example of an architecture

IP has three facets which are TCP, UDP and LLC (figure III.10), then Facet(IP)

= {TCP, UDP, LLC}. For the specific architecture shown in figure III.11, where TCP is instantiated twice, IP and LLC are instantiated once, the following relations are computed :

• Noc(ip1, TCP) = 2,

• Noc(ip1, UDP) = 0,

4 MDBM,F can be infinite only in theory, however in practice it is finite bounded by the size of available memory.

• Noc(ip1, LLC) = 1.

For this example, the DBM IP has three types of interfaces, one instantiated once for the connection with llc1, the second instantiated twice for the connections with tcp1 and tcp2, and the third is not instantiated because there is no instance of DBM UDP connected with ip1.

III.2.2.2.2. Superfacet Concept

Let us now introduce the superfacet concept. A superfacet of a C-DBM is a sub-set of its facets; C-DBM has to react identically towards all the facets belonging to the same superfacet. If Facet(C-DBM) = {F₁, ..., F_q} and SF_i is a superfacet of C-DBM, we have SF_i ⊂ Facet(C-DBM).

The aggregation of several facets into what we called a superfacet is possible because the service concept in the world of protocols allows a protocol to provide a particular service which can be used by several other protocols.

Clearly, several protocols can be above another one which behaves in exactly the same way whatever protocol is asking for the service. For instance, the IP protocol reacts identically whether it is used with TCP (Transmission Control Protocol) or UDP (User Datagram Protocol).

The facets belonging to the same superfacet will be associated with the same interface type. Namely, an interface can connect the same C-DBM to several different DBMs. So, the objective of the superfacet concept is to reduce the number of interfaces associated with a DBM.

The superfacet concept divides the set of DBM facets into several superfacets;

nevertheless some facets can remain alone, and cannot belong to any superfacet;

we will say that they belong to the zero-superfacet. So, a zero-superfacet (SF0) contains all the facets that cannot be included in a superfacet.

Let us denote Car(DBM, X) the number of facets of a given DBM, which belong to X; X being a facet or a superfacet :

• If X is a facet then Car(DBM, X) = 1.

• If X is a superfacet then Car(DBM, X)≥2, namely a superfacet contains at least two facets. This constraint is not applicable to the zero-superfacet.

The Noc function, introduced in the previous sub-section, can be extended to the superfacet concept:

• Noc dbm Superfacet

(

)

(

)

Facet_j Superfacet

, = ,

∈

∑

Resume the preceding example where the DBM IP is the C-DBM (figures III.10 and III.11). Let us consider that the TCP and UDP facets of DBM IP are the same since the service offered by IP to TCP and to UDP is the same, these two facets will be the components of the same superfacet. The DBM IP has another facet which is LLC, but this third facet cannot belong to the previous superfacet.

We can say that IP has superfacet SF1 composed of TCP and UDP and zero- superfacet (SF0) composed of LLC. In this case, DBM IP will only have two interfaces, one to connect IP to either TCP or UDP, and the second one to connect IP to LLC.

The following relations are computed :

• Car(IP, SF1) = 2, Car(IP, SF0) = 1.

• Noc(ip1, SF1) = 2, Noc(ip1, SF0) = 1.

In conclusion, each superfacet of a DBM is associated with an interface, and each facet belonging to the zero-superfacet is also associated with an interface.

III.2.2.2.3. Mutual Exclusion

For a given DBM, mutual exclusion can stand inside its set of facets. Namely, when an instance of a DBM is connected to an instance of one of its facets, it cannot be connected to one or several other facets. The mutual exclusion can be expressed in different ways. The simple way is illustrated in the following example :

Let f₁, f₂ and f₃ be three facets of a DBM. To express the fact that they exclude each other mutually we can say :

If ^{Noc dbm f}

(

)

(

)

In other words, if an instance of DBM is connected to one of the f1, f2 or f3 facets, it cannot be connected to the others. So, the number of connections has to be equal to zero for two facets when the third one is different from zero.

We denote E_X(DBM) the exclusion function which gives for DBM with regard to one of its facets, the sub-set of DBM facets which are mutually exclusive.

E_X(DBM) does not include DBM X. Namely, an instance of DBM can be connected to an instance of X if and only if the instance of DBM is not connected to another instance of the DBMs belonging to E_X(DBM). Reciprocally, if an instance of DBM is already connected to an instance of a DBM belonging to E_X(DBM), then this instance of DBM cannot be connected to an instance of X.

Example : The LLC DBM can be connected to a MAC Ethernet and a MAC FDDI (figure III.12). Namely, MAC Ethernet and MAC FDDI are two facets of DBM LLC, but an instance of DBM LLC can be connected either to one instance of DBM MAC Ethernet, or one instance of DBM MAC FDDI. So, DBM MAC Ethernet and DBM MAC FDDI are two facets that are mutually excluded.

Figure III.12 : Example of mutual exclusion

LLC llc1

mac1 Ethernet

llc1

I I I . 2 . 3 . M e a s u r e m e n t s B l o c k

Measurement is the mechanism that allows an end-user to observe, to understand and to predict the system’s behavior.

The measurements block contains two types of measures. The first type reflects the behavior of a DBM, and it is associated with the BEB. The second type is associated with the interfaces, and it mainly shows the data flow entering and exiting the DBM.

The modeler of a DBM defines a list of measurements. The measurements must be meaningful to an end-user who is not specialized in the field of queuing networks. All the aspects related to this field are transparent. These measurements must be related to some metrics currently used in the field of communication systems, e.g. throughput, response delay, etc.

MAC Etherne

MAC FDDI

mac1 FDDI t

They are managed by a set of ON/OFF switches. Namely, each measurement is associated with a switch. If the switch is set to ON, the associated measurement is computed, otherwise it is not considered. This policy has two advantages : 1. The end-user is not submerged by a long list of measurements which may not

all be useful for his study.

2. The simulation time is reduced if some measurements are not computed.

In addition, for certain measurements, mean, variance, maximum, minimum and confidence intervals are meaningful, and hence can be computed.

I I I . 2 . 3 . 1 . L o c a l v e r s u s G l o b a l M e a s u r e m e n t s

The measurements defined inside the MeB are local, in the sense that they depend on the instance of the DBM which they belong to, we call them local measurements. Besides, measurements can depend on the communication architecture which is being simulated. These are called global measurement, and can be computed from the local ones. The computation can be made by a specific tool which is part of the AMS atelier.

I I I . 2 . 3 . 2 . S t e a d y - S t a t e v e r s u s T r a n s i e n t S t a t e

We mainly focus on measurements which are computed when the system is in a steady-state. But, in general, when it begins to function, the system is in a transient state. The effect of this state on the measurements can be diminished if the simulation time is long enough, and/or if the simulator allows to start computing the measurements only when the steady-state has been reached.

I I I . 2 . 4 . I n s t a n t i a t i n g a D B M

Each DBM can be instantiated one or several times in one simulation model of a communication system. Each instance inherits from its DBM all the parameters and measurements. It can have its own set of parameter values, possibly different from those of the other instances. Besides, each instance of a DBM is associated with a combination of the set of measurement switches. Indeed, not the same measurements are asked for all the instances; only those for which the switches are set to ON will be computed.

Concerning the interfaces, their types and number depend on the context where the instance is used. In any case, each instance has to take into account the facets of the DBM and the number of allowed connections. As we mentioned before, the validity of the connection is not checked by the DBM itself, and hence not by its instances. The choice of the interfaces depends also on the superfacets of the DBMs. Actually, an interface can be used twice even if the instance is connected to two different DBM instances; in this case, these two different DBMs belong to the same superfacet.

Each instance, when created, lives its live independently of others (if any), even if they share the same source code. Each instance behaves according to the values of its parameters and how it is connected to the external world.

I I I . 3 . V

V

D B M

Each DBM has to be verified and validated before it is included into the library.

The Simulation model has to be proved good. This is done by measuring how similar the model and the real system [50] . Indeed, verification establishes if the implementation is running as intended, and validation establishes if the desired level of accuracy between the model and the real system is reached. So, verification is the process of checking that the simulation program operates as the model implementer thinks it does; on other word, it insures that the program is free of bugs and consistent with the model. Validation is the process of checking that the simulation model, correctly implemented, is sufficiently close to reality . While the verification techniques are well defined, the validation techniques are not well stabilized and there is no recipe for doing it [51]. This is all the more exacerbated in our context because the validation of a DBM cannot be done stand-alone. Indeed, on the one hand, a DBM has to be connected to other ones to construct a self-contained system, and on the other hand, the validation of the target DBM assumes that the others have already been validated.

In general, verification and validation are intertwined [52]. They are not steps which are taken at the end of the modeling. Instead, they are part of a process which starts at the beginning of the modeling and continues through model building and model use.

Balci in [53], summarizes by saying that model verification deals with building the model right and model validation deals with building the right model.

In what follows, we denote DBM_V the DBM that has to be verified and validated.

I I I . 3 . 1 . V e r i f i c a t i o n o f a D B M

Network model verification is the process through which the modeler establishes that the model indeed captures the logic and data that were initially meant to be captured in the model. In other words, the model verification process should show that the model formulation is correct, independently of whether the model is a meaningful representation of the real network.

In the world of protocols, we can make an analogy with the protocol's conformance testing techniques [54, 55]. Considering this analogy, three classes of protocol verification can be defined :

1. Basic interconnection verification : this verification is required to prove that communication can be achieved between the DBM_V and their facets, or in general with the outside world. This verification can act as an initial screening tool. It will detect severe bugs. This type of verification is done in earlier stages.

2. Capability verification : this type of verification is intended to reveal that the functions which must be supported by the model have been implemented.

3. Behavior verification : this verification class verifies that the model behaves correctly towards valid and invalid input data.

We do not intend to present the simulation model verification techniques in this sub-section. There is a considerable literature on verification and validation, a long list of references can be found in [56].

Let us just say that the implementation of a model may do exactly what the modeler intended, yet it may not represent the real system. So, it is an invalid model.

I I I . 3 . 2 . V a l i d a t i o n o f a D B M

Network model validation is the process through which the modeler establishes that the model is in fact a realistic and satisfactory representation of the network operating under actual traffic conditions. Validation is a difficult task, but it must be performed before the simulation model can be used.

As mentioned above, the validation of a DBM cannot be done stand-alone, since, instances of DBM_V have to be part of a system in order to be validated.

We define a Basic Architecture for Validation (BAV) as a communication architecture which includes one or several instances of DBM_V, and/or instances of DBMs that have already been verified and validated, and/or simple additional objects which do not have to be validated but only verified, and were developed for the validation purpose only.

Remarks

• For validating a DBM, several BAVs can be defined.

• We assume that the model associated with a given network architecture containing only verified and validated DBMs is valid if the DBMs are connected properly and parametrized correctly. On the other hand, if some errors occur in a BAV or if erroneous measurements are produced at the end of a simulation, then only the DBM_V has to be checked.

The problem which can arise when we want to validate a DBM is the use of another DBM which has not yet been validated. Namely, we cannot find a BAV for the current DBM_V. To overcome this problem, it is preferable to begin validating protocol models with the lower layer protocols and access methods, transport protocols, and finally applications. In other words, working along the lines of protocol layers upward through to the application. In this way, problems in the communication models can be more easily isolated and corrected. For instance, if we want to validate several DBMs forming a stack of protocols (e.g.

MAC Ethernet, LLC 1, IP, TCP and FTP), we have to start by validating the DBM MAC Ethernet, followed by DBM LLC 1, DBM IP, DBM TCP and finally DBM FTP.

Validation techniques

The techniques can be classified into three main classes [50] :

Expert intuition : It is the most practical and common way to validate a model.

Actually, expert analysis can point out errors in simulation by simply looking at the simulation outputs.

Real system measurements : Comparison with real systems is the most reliable and preferred way to validate a simulation model. However, in practice, this is often unfeasible, either because the real system may not exist, or because the measurements may be too expensive to carry out.

Theoretical results : In some cases, the system can be analytically modeled under simplified assumptions. In such cases, the similarity of theoretical results and simulation results is used to validate the simulation model. Validating by comparing theoretical and simulation results should be used with care as both may be invalid in the sense that both may fail to represent the behavior of the real system.

Remark

We must point out that a "fully validated model" is a myth. Actually, it is only possible to show that the model is not invalid for some of the compared situations. To prove that the model produces the same results as the original system under all circumstances would generally require an inordinate amount of resources. The validation exercise is therefore limited to a few scenarios selected so as to cover all important cases. This helps to increase the degree of confidence in the model’s results.

I I I . 4 . G

C

M

In this section, we will show how to build hierarchically complex models from DBMs, and how the internal structure of a DBM plays an important part in facilitating the building. Hierarchical modeling will be based on the composition mechanism.

This section starts by defining a DBM Class, then the application of the composition mechanism to build coupled models is explained in detail. Complex models will be constructed in a generic way; this will lead us to construct what is

called a Generic Model (GeM), which is described in the third sub-section. Each GeM can be specialized in what is called Composite Models (CoMs), which is explained in the last sub-section.

I I I . 4 . 1 . D B M C l a s s

Definition 1 : A DBM Class is a set of at least two DBMs, having one or several common characteristics. For instance, they belong to either the same OSI layer, the same network device type, or, in general, to the same communication component. A DBM Class is denoted -DBM.

Definition 2 : An instance of a -DBM is an instance of one of the DBMs belonging to this Class. Clearly, one of the DBMs composing the class is chosen and instantiated. The choice is done by the modeler.

Examples

• The transport layer is a -DBM that may comprise DBM TCP, DBM OSI TP, DBM VMTP⁵, etc.

• The MAC sub-layer is a -DBM, made up of the DBM MAC Ethernet, DBM MAC FDDI, DBM MAC Token-Ring, etc.

Facet of a -DBM

The Facet concept, defined in sub-section III.2.2.2.1, can be extended to a -DBM. If -DBM is composed of {DBM1, ..., DBMn}, the facets of -DBM are defined as follows :

Facet( -DBM) =

∩

∈ −

DBM DBM i

i

Facet DBM

C ^{( )}, i = 1, ..., n.

The facets of a -DBM are defined by the intersection of all the sets of facets with regard to the DBMs belonging to -DBM. The intersection should not to be empty, otherwise it means that -DBM was wrongly defined; indeed, the modeler has to accurately construct a -DBM.

I I I . 4 . 2 . C o m p o s i t i o n M e c h a n i s m

Hierarchical modeling is based upon the mechanism of basic model composition.

We will first use the composition mechanism to define a coupled model. Suppose that A and B are DBMs in the library (figure III.13). If these models can be connected to each other, the resulting model, called a coupled model (CM), can in its turn be seen from outside as a new DBM. It is obvious that if this condition is not met, there is no point in applying the composition mechanism.

Figure III.13 : Composition of two DBMs

A B

The composition mechanism can be applied to a DBM and a -DBM or to two -DBMs (figures III.14 and III.15). The resulting model is also called a coupled model.

Figure III.14 : Composition of a DBM and a -DBM

Figure III.15 : Composition of two - DBMs

DBM -DBM -DBM -DBM

Definition 3 : A Coupled Model (CM) is a composition of either two DBMs, a DBM and a -DBM, or two -DBMs.

Definition 4 : An instance of a CM is defined by the instances of the two components composing the coupled model. Each component is instantiated only once; the two instances are linked to each other via their interfaces.

Hereafter, we will discuss under which conditions the composition mechanism

can be applied. To compose two DBMs, or a DBM and a -DBM or two -DBMs, there are constraints to be complied with depending on the components

to compose. Let us denote X and Y the two components concerned; they can be composed if one of the constraints below is complied with :

• (X and Y are two DBMs) and (X ∈ Facet(Y)).

Namely, to compose two DBMs, one has to be the facet of the other, and vice versa. Since X ∈ Facet(Y), then by commutativity Y ∈ Facet(X).

• (X is a DBM and Y is a -DBM) and (X ∈ Facet(Y)).

Namely, to compose a DBM and a -DBM, the DBM has to be a facet of -DBM.

Property : Because X is a DBM and Y is a -DBM : X ∈ Facet(Y) if and only if Y ⊆ Facet(X).

Proof :

Let Y {DBM1, ..., DBMn}, and Facet(Y) = ∩

∈

DBM Y i

i

Facet DBM( ), i = 1,..,n.

X ∈ Facet(Y) ⇔ ∀ i = 1, ..., n, X ∈ Facet(DBM_i)

⇔ ∀ i = 1, ..., n, DBM_i ∈ Facet(X) (by commutativity)

⇔ {DBM₁, ..., DBMn} ⊆ Facet(X)

⇔ Y ⊆ Facet(X) †

• (X and Y are two -DBMs) and (X ⊆ Facet(Y)).

Namely, to compose two -DBMs, one has to be included into the set of facets

of the other, and vice versa. Since X ⊆ Facet(Y), then by symmetry Y ⊆ Facet(X).

Facets of a Coupled Model

The composition mechanism can also be applied to a coupled model and a DBM or a -DBM (figures III.16 and III.17).

Figure III.16 : Composition of a CM and a DBM

Figure III.17 : Composition of a CM and a -DBM

There are constraints to be complied with for this composition to make sense. To define these constraints, we have to extend the notion of Facet to a coupled model.

Let us denote CM = <X, Y>, X and Y are either DBMs or -DBMs, then : Facet(CM) = Facet(<X, Y>) = (Facet(X) ∪ Facet(Y)) - MEX(CM) where MEX(CM) is a set of DBMs. MEX depends on the values of MX,Y, MY,X6

, and/or EX Y . Namely, when a connection is instantiated between two DBMs, other connections may be excluded, either because the number of allowed connections is equal to 1, or because some DBMs have to be excluded.

How to determine MEX will be described in this sub-section just after describing the constraints.

(Y), E (X)⁷

CM and a DBM or a CM and a -DBM (figures III.16 and III.17) can be composed easily if one of the constraints below is satisfied. Let us denote X the model which will be composed with a CM :

• (X is a DBM) and (X ∈ Facet(CM)).

CM DBM CM -DBM

Namely, to compose a DBM and a CM, the DBM has to be a facet of CM, i.e., it can be connected to one of the components of CM.

• (X is a -DBM) and (Facet(X) ⊆ Facet(CM)).

6 MY,X ≥ Noc(y,X) and M_X,Y ≥ Noc(x,Y), where x and y in small letters are instances of respectively X and Y

7 Let’s remind that EX(Y) refers to the exclusion function which gives for Y with regard to one of its facets, X, the sub-set of DBM facets which are mutually excluded.

Namely, whatever the DBM chosen when instantiating -DBM, this DBM is a facet of CM and hence can be connected to one of the components of CM.

Determining MEX

In order to determine the components of the MEX set accurately, we extend Noc, the upper limit, and Exclusion functions to a -DBM.

Let us denote -DBM = {DBM₁, ..., DBM_n}, and Y a facet of -DBM. We know that the number of connections between an instance of DBM_i (denoted dbm_i in small letters) and facet Y is bounded by M , namely,

Noc(dbm

DBM , Y_i i, Y) ≤ M_{DBM , Y}

i . The extensions of function Noc, the upper limit, and the set of mutually excluded facets are defined as follows :

• Noc(c-dbm, Y) = number of connection instances that have c-dbm (instance of -DBM) as one extremity, and instance of Y as the other extremity.

Noc(c-dbm, Y) is bounded by M -DBM,Y, hereafter its definition.

• M -DBM,Y = minimum(M_{DBM , Y}, ..., M

1 DBM , Y_n ). Namely, the number of connections between an instance of -DBM and its facet Y is the smaller M_{DBM , Y}

i with i = 1, .., n.

• E_Y( -DBM) = E

i n

U

Let CM = <X, Y>; the following algorithm exactly determines the MEX(CM) set; Facet(CM) can then be computed :

BEGIN

& Initialization of MEX MEX := ∅;

& If the number of allowed connections between x instance of X and an

& instance of Y is equal to one, then an instance of CM cannot be

& connected to an instance of Y because the only possible connection

& is already being used inside the instance of CM.

If MX,Y = 1 then MEX := MEX ∪ {Y};

& If the number of allowed connections between y instance of Y and an

& connected to an instance of X because the only possible connection

& is already being used inside the instance of CM.

If MY,X = 1 then MEX := MEX ∪ {X};

& MEX also includes mutually excluded facets of X and Y MEX := MEX ∪ EX(Y) ∪ EY(X);

END;

Hierarchically, when a CM is connected to a DBM or a -DBM, the resulting model can be seen as a new coupled Model. This new CM can in its turn be connected to a DBM or a -DBM, and the result is another new CM. This involves, a new definition of a coupled Model :

Definition 5 : A Coupled Model (CM) is a composition of either two DBMs, or a DBM and a -DBM, or two -DBMs, or another CM and a DBM, or another CM and a -DBM.

The computation of Facet(CM = <X, Y>) remains nearly the same as previously described. The change is the determination of MEX(CM) where CM is the result of the composition of another coupled model (denoted CM_o) and a DBM or a

-DBM. In this case, the algorithm to determine MEX(CM) has to be run for X = DBM or -DBM, and for Y = the DBM or -DBM component of CM_o which will be connected to X.

I I I . 4 . 3 . G e n e r i c M o d e l ( G e M )

Definition 6 : A Generic Model (GeM) is a collection of components, structured by means of the composition mechanism. The components might be :

1. One or several DBM classes, 2. Zero, one or several DBMs, and

3. If necessary a specific object (denoted SPECOBJ). As we will see in the next sub-section, SPECOBJ, when present inside a GeM, is either active or passive.

Namely, it plays or does not play a role in interconnecting the GeM components.

To define the components of a GeM and its structure, we use the following syntax, which is made up of two parts. The DECLARE part lists the components

of the GeM; each component is associated with a symbolic name (var_name) and declared as a DBM or a DBM Class. The CONNECT part lists the allowed connections between the components and/or outside (the key-word OUT is used), and/or SPECOBJ (if present and necessary).

& Definition of a Generic Model GeM gem_name;

& Declaration of the components of the GeM DECLARE

+{DBM_CLASS var_name;}⁸ & At least one declaration of this type {DBM var_name;}

& Connection of the components to each other, and/or with the specific object, & and/or with the outside

CONNECT

{var_name ↔ var_name;}

{var_name ↔ SPECOBJ;} & For connecting the GeM components with

& the specific object

+{var_name ↔ OUT;} & For connecting the GeM with the outside

END;

I I I . 4 . 3 . 1 . S p e c i f i c O b j e c t o f a G e M

Each GeM, if necessary, has a specific object that may play the role of glue between its components. The structure and the importance of the role of a specific object heavily depend on the GeM. Two situations can occur :

1. The specific object plays an active role, namely it is used to interconnect the components of the GeM. In this case, it can be parametrized and measurements can be defined. Furthermore, its structure is to be defined by the modeler if possible.

2. The specific object plays a passive role, namely it is not used to interconnect the components of the GeM. Therefore, it cannot be parametrized, but measurements can still be defined. In this case, the presence of the specific object is only useful to define measurements.

8 +{x} : this notation means that x is present at least once.

Active Specific Object

The structure of SPECOBJ is not defined, partly defined or fully defined. In the first case, the structure cannot de defined by the modeler because it heavily depends on the components of the GeM; generally, most of them, are DBM Classes. In the second case, only the structure is defined in terms of a network of stations, but one or several services remain undefined. For the third case, the structure is fully defined, which means that the network of stations and their services are all known at this level.

The parameters of SPECOBJ, as well as measurements, are to be specified only if its structure is partly defined or fully defined.

Passive Specific Object

No structure has to be defined in this case. SPECOBJ can be seen as an algorithmic block for coding measurements to be added to the GeM.

I I I . 4 . 3 . 2 . C o n n e c t i o n s i n s i d e a G e M

The components of a GeM are interconnected using the composition mechanism.

Of course, the constraints on the interconnections between the DBMs and the DBM classes have to be complied with. These constraints have been defined in the previous sections. Indeed, a GeM can be seen when SPECOBJ is passive or not present as a coupled model. In the case where SPECOBJ is active, GeM can generally be seen as one or several coupled models connected to SPECOBJ.

On the other hand, the validity of the interconnections between SPECOBJ (if any) and the other components of a GeM has to be checked by the modeler and heavily depends on the GeM being modeled.

As explained in section 2.2.2, a DBM is connected to the outside world through an interface, and some references are left undefined by means of the delayed binding mechanism. Inside a GeM, some of these undefined references, associated with connections between DBMs or between DBMs and SPECOBJ⁹, are defined exactly by the modeler. Nevertheless, the references associated with

9 SPECOBJ has to be active, partly defined or fully defined.

connections between DBMs, on the one hand, and DBM classes, on the other hand, remain undefined.

I I I . 4 . 3 . 3 . C o n n e c t i o n s o u t s i d e a G e M

The external connections of a GeM have to take its facets into account, and all the connections to the outside (defined by the key-word OUT in the definition of the GeM) have to be used. Clearly, all the undefined references are to be determined when the GeM will be instantiated as part of a given network architecture.

Facet of a GeM

Inside the CONNECT part of a GeM definition, some GeM components are connected to OUT, a reserved word which means outside the GeM. The facets of these components will determine the facets of the GeM.

Let “type_of” be a function that for a variable (var_name) declared inside the DECLARE part of the GeM definition, returns the name of DBM or DBM Class associated with this variable.

The extension of Facet to a GeM is defined as follows :

Facet(GeM) = - MEX(GeM)

var_

( _ (var_

name OUT

Facet type of name

∪

As defined earlier, MEX is a set of DBMs. MEX depends on the GeM, namely on its components and the way they are linked. In this case where GeM contains an active SPECOBJ, MEX(GeM) cannot be determined by an algorithm, because the determination has to take into account how the components of GeM are connected to SPECOBJ and the way SPECOBJ is modeled.

I I I . 4 . 3 . 4 . P a r a m e t e r s a n d M e a s u r e m e n t s o f a G e M

For an end-user, a GeM is a model which may have a set of parameters and/or a set of measurements. These parameters/measurements can be partly inherited from the sets of the DBMs it is composed of. Moreover, some other ones can be added, and in this case, they will be coded inside SPECOBJ.

Generally, from the DBM Classes, a GeM cannot inherit either parameters or measurements, because, generally, the DBMs composing a DBM Class have different parameters and different measurements.

Not all the parameters/measurements of a DBM are inherited by a GeM. The modeler can decide to hide some of them from the end-user. He has to set the value of each hidden parameter, and set the switches associated with the hidden measurements to OFF.

I I I . 4 . 3 . 5 . E x a m p l e s

Hereafter, we present two examples of GeMs, in the first one, SPECOBJ plays an active role, namely, it is used to connect the components of the GeM. In the second GeM, SPECOBJ is not used for connecting its components. In these examples, MAC is a DBM Class composed of DBM MAC Ethernet, DBM MAC FDDI and DBM MAC Token-Ring.

III.4.3.5.1. First Example : Bridge

A GeM Bridge is defined as the composition of the two MACs and the specific object. It can be connected to the outside by its MACs. In this example, the role of SPECOBJ is to change the format of messages transiting through the Bridge.

It incorporates an algorithm defined by the modeler as a learning algorithm.

GeM Bridge;

DECLARE MAC X;

MAC Y;

CONNECT

X ↔ SPECOBJ;

Y ↔ SPECOBJ;

X ↔ OUT;

Y ↔ OUT;

END;

MAC (X) MAC (Y) SPECOBJ

SPECOBJ¹⁰ (figure III.18) can be modeled by a set of three stations QL, QR and QSW¹¹. QL and QR receive messages from the MACs (in the GeM definition,

10 It is also called a relay

they are denoted X and Y). QSW routes the messages coming from QL to MAC Y, and the messages sent by QR to MAC X. Figure III.19 shows how the components of the GeM Bridge are connected through the interfaces.

Relay QSW

QL QR

Figure III.18 : The specific object for a Bridge

MAC BE MAC BE Relay

Figure III.19 : How connections inside the Bridge are made

III.4.3.5.2. Second Example : Router

In this example, LLC (Logical Link Control) may be a DBM or a DBM Class depending on the way the modeling has been performed. If the LLC type¹² is a parameter and LLC is modeled by only one object then it is a DBM, otherwise it is a DBM Class, and each LLC type is a DBM. This example represents a router between a LAN and a WAN (the HDLC¹³ protocol is assumed to be the data link

12 The 802 LAN standards include four types of service for LLC users:

Type 1 : Unacknowledged connectionless service Type 2 : Connection-oriented service

Type 3 : Acknowledge connectionless service Type 4 : All of the above services

13 HDLC : High level Data Link Control

protocol used by the WAN). This GeM does not use a specific object to connect its components.

GeM Router;

DECLARE MAC X;

LLC Y;

HDLC Z;

IP T CONNECT X ↔ Y;

Y ↔ T;

T ↔ Z;

X ↔ OUT;

Z ↔ OUT;

END;

MAC (X)

HDLC (Z) LLC (Y)

IP (T)

The interconnections of the components of the GeM Router are valid if the following two constraints are complied with and if we assume that LLC has been modeled as a DBM :

1. {LLC, HDLC} ⊂ Facet(IP), 2. LLC ∈ Facet(MAC)

Figure III.20 shows how the components of the GeM Router are connected through the interfaces. All the undefined references of the DBM IP are now exactly defined. Besides, some undefined references of the DBM LLC and DBM HDLC remain undefined because the former is connected to the DBM MAC class, and the latter is connected to the outside.

IP BE

LLC BE

M AC BE

HDLC BE

Figure III.20 : How connections are done inside the Router

I I I . 4 . 4 . C o m p o s i t e M o d e l ( C o M )

Definition 7 : A Composite Model (CoM) is a specialization of a GeM. Namely, all the variables defined as DBM Classes have to be defined exactly and thus associated with DBMs.

To define a CoM, we use the following syntax, which is composed of only one part. In this part, each GeM component declared as DBM Class is assigned to a DBM belonging to its class. The header of this part indicates the name of the CoM and which GeM it is the specialization.

Gem_name Com_name;

+{var_name_of_a_DBM_Class := name_of_a_DBM;}

END;

Remarks

1. The facets of a CoM are those of its GeM, because the determination of the set of facets of a GeM takes into account all the possible specializations.

2. All the specializations of a GeM are not useful, because the different assignations can lead to a composite component which is not a communication component, because it has no associated component in the reality. Besides, a specialization may be erroneous, even if all the local constraints are complied with. Hence, it is up to the modeler to choose all the specializations correctly.

I I I . 4 . 4 . 1 . S p e c i f i c O b j e c t o f a C o M

If a GeM has a specific object associated with it, then all the CoM specializations of this GeM contain this specific object. Furthermore, if the specific object is active (respectively, passive) in the GeM, it remains active (respectively, passive) for all the specializations.

If the CoM specific object is active, and partly or fully defined, its structure is the same as the structure defined in the corresponding GeM. If the specific object is partly or fully defined, the modeler has to define exactly all the services of the stations composing the CoM specific object.

I I I . 4 . 4 . 2 . P a r a m e t e r s a n d M e a s u r e m e n t s o f a C o M

All the parameters and measurements defined at the GeM level are inherited by all the CoMs associated with this GeM. Other parameters and/or measurements can be added to a given CoM, they depend on the different specializations chosen for the DBM Class(es) declared inside the GeM.

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

Let us resume the two examples of section III.4.3.5, in which the GeM Bridge and the GeM Router are defined.

III.4.4.3.1. Specialization of the GeM Bridge

In order to define a specialization of a GeM Bridge, the two MACs have to be specified. In the example below (figure III.21), one MAC is set to an Ethernet MAC, and the other MAC is set to an FDDI MAC.

Bridge BETHERFDDI; & Bridge Ethernet-FDDI X := MAC_ETHER;

Y := MAC_FDDI;

END;

Figure III.21 : Bridge Between an Ethernet and an FDDI MAC

ETHER

MAC FDDI Relay

Ethernet Bus FDDI

Ring

III.4.4.3.2. Specialization of the GeM Router

In order to define a specialization of a GeM Router, the MAC has to be specified.

In the example below (figure III.22), the MAC is set to an Ethernet MAC.

Router RETHERWAN; & Router Ethernet-WAN X := MAC_ETHER;

END;

Figure III.22 : Router between an Ethernet and a WAN

I I I . 5 . Q N A P 2 I

D B M

MAC ETHER

HDLC (Z) LLC (Y)

IP (T)

Ethernet Bus WAN

This section focuses on how to specify a DBM using QNAP2 Language. More technical details can be found in [57].

I I I . 5 . 1 . D B M a s a Q N A P 2 O b j e c t

A DBM will be represented as an object whose name is unique. This object, called DBM-object, has to contain the following declarations :

• Queues representing the BEB of the DBM,

• Queues representing the interfaces,

• Variables representing the parameters of this DBM,

• Internal variables which are required for the execution of the different services,

• Variables which are dedicated to measurements,

• A variable indicating the instance number of the DBM.

For a given DBM, each instance involved in building the system under study can be connected to different DBMs, more precisely to several instances of those different DBMs. The numbers implied differ from one instance to another. To allow a modeler to use the same structure to declare any DBM, we suggest giving

example, two instances of the same DBM, with different values for these arguments.

So, the arguments of each DBM-object are the numbers of interfaces, which depend on the number of superfacets the DBM has and the number of facets belonging to the zero-superfacet.

& Declaration of a DBM as an object.

OBJECT DBM_name (sf1,.., sfp, f1,..., fq);

& Number of instances for each interface corresponding to the superfacets of the DBM.

& We assume that a DBM has p superfacets with p≥0.

INTEGER sf1,.., sfp; & if p=0 this line does not exist

& Number of instances for each interface corresponding to the facets of the DBM

& which are included in the zero-superfacet.

& We assume that Car(DBM_name, SF0)=q with q≥0.

INTEGER f1,.., fq; & if q = 0 this line does not exist

& declaration of queues which model the BEB, their number depends on the model QUEUE BEB_queues

& declaration of queues which model the interfaces associated with superfacets QUEUE IFINSF1(sf1), IFOUTSF1(sf1);

...

QUEUE IFINSFp(sfp), IFOUTSFp(sfp);

& declaration of queues which model the interfaces associated with zero-superfacet QUEUE IFINF1(f1), IFOUTF1(f1);

...

QUEUE IFINFq(fq), IFOUTFq(fq);

& declaration of reference to queues which will be defined exactly during the

& creation of an architecture; we called this mechanism “delayed binding”.

REF QUEUE DBSF1(sf1), ..., DBSFp(sfp);

REF QUEUE DBF1(f1), ..., DBFq(fq);

& declaration of parameters and internal variables useful for the execution of

& the different station services. All the features of QNAP2 are allowed.

...

& declaration of measurement variables and their associated Boolean variables

& which will contain the measurement choices of the end-user. A measurement

& can be simple or watched; on the other hand, it can be integer or real.

...

& declaration of an integer variable which determines the DBM instance INTEGER INSTANCE;

END;

Each queue belonging to the DBM object has to be associated with a station. A station in QNAP2 is composed of a queue with finite or infinite capacity, and one or several (can be infinite) servers. If the station has more than one server, the service associated with them is the same. A simple declaration of a station is shown hereafter, for a precise statement see [14] :

& Declaration of a station /STATION/

NAME = *DBM_name.queue_name;

& Declaring if the station is composed of several servers or an infinite number

& of servers. On the other hand, this line does not exist if there is only one

& server.

TYPE = MULTIPLE (nbservers) ⏐ INFINITE;

& Declaring the maximum number of customers allowed in the station.

& This line does not exist if the capacity is infinite CAPACITY = nbmaxcustomer;

& The service of the station is contained in a procedure SERVICE = name_of_procedure;

I I I . 5 . 2 . M e s s a g e M o d e l i n g

A DBM message is a QNAP2 customer. A customer is a predefined object for which a certain number of attributes are added to define the fields of the message. A customer can be created dynamically by a server. It can be served by one or several servers, so, it can be routed across the queuing network modeling the DBM. Hereafter, it is shown how a simple message and a transit message have to be declared :

& Declaration of a message as a QNAP2 customer /DECLARE/

CUSTOMER OBJECT message_name;

& definition of the fields of the message. They can be integers, reals,

& references to other customers or objects, etc.

...

END;

& Declaration of a transit message as a QNAP2 customer /DECLARE/

CUSTOMER OBJECT CUST_TT;

14 RFMS; & The pointer referencing data REF ANY

REF ANY RFCT; & The pointer referencing control data END;

I I I . 5 . 3 . D B M U s e r ’ s I n t e r f a c e

The modeler of a DBM has to write a User’s Interface (UI) for his DBM. This UI will be used to create an instance of a DBM, to set up its parameters, and to ask for measurements.

I I I . 5 . 3 . 1 . C r e a t i n g a n I n s t a n c e o f a D B M

Each instance of a DBM can be created by means of a procedure. The name of this procedure is DBMCRT<DBM-id>^15,16, the number and the type of parameters are not restricted. The body of this procedure has to be declared inside the code of a DBM.

14 ANY is a type of top level, it is the root of all types. A pointer of this type can reference any object

15 Each DBM is associated with a unique identifier, denoted <DBM-id>. It is a two-character word, each character can be a letter (small or capital) or a digit.

16 The names of the procedures used for the DBM user’s interface are reserved words, and the modeler has to use them only for this purpose.