 of the communication: the left EVH requests the right EVH to connect two users, identified by the SAPIs a and b. This is a rather simple way of describing communication. To describe communi- cation by messages is normally much more complicated. As a minimum, the corre- sponding message contains data type definitions for all parameters (type SAPI in Fig. 2.18). It also contains a number of overhead parameters (the type Ovh in Fig. 2.18) to support different kinds of message handling problems (e.g. fragmentation and error control). The MEHs must also have a representation of the operation name connect (data type OPid), and of the primitive type Request (data type Prim- Type). All these message handling functions can be defined in a common way for a par- ticular protocol or for a set of protocols through the design of a suitable MEH. An example of such a common message handling mechanism is TCAP, see recommen- dations ITU-T Q.771-775. When a common MEH mechanism is used, the design efforts can be restricted to designing abstract protocols only. This subject is dealt with in detail in Sect. 5.4. To separate abstract protocols from message protocols, and thereby EVHs from MEHs, is very beneficial in the context of frequent network technology changes. Since an abstract protocol is independent of message handling, it defines communi- cation in a distribution-transparent way, similar to how interfaces are described in object-oriented languages. EVHs can therefore be reused in many different types of networks. 2.3.4 Substructures If we were never allowed to look inside a unit, i.e. a black box, it would be impossible to develop the structural depth of a model. So, we recursively define 2 Foundations of Sysnet Modelling internal structures of units, substructures, until we reach a structural level where the units are reasonably complex and where unit specifications can be taken as requirements on the components of the implemented system, as shown in Fig. 2.19. A substructure shows an internal structure of units that are r