, which are: 1. The LPM part, i.e., the definition of message types, their encoding and any addi- tional function that deals with pure message handling (e.g., error detection and fragmentation). 2. The LSM part, i.e., the activities that lie behind sending a message and are an effect of receiving a correct message. Note, however, that this separation concerns control layers only. Connectivity layers are LPMs only. Both LPMs and LSMs have a behavior, each with its own states. Both aspects are often described in a single protocol specification based only on messages. The A number of other languages could serve the purpose as well. For example, both UML and SDL are intended for similar purposes. IDL, the CORBA interface language, can be used for inter- face specification. However, all these languages are initially developed for software system modeling, and therefore exhibit some assumptions that become unwanted constraints in the context of network system modeling, e.g., software object-orientation and week support for asynchronous communication. result may be that LSM and LPM states multiply, with a very complex specifica- tion as a result. When the specification of an OSI layer is separated into LSMs and an LPM, it can be divided into the following five parts, (see the figure below). Note that this principle is valid for every control protocol, not only for protocols that rely on a common agent layer (such as TCAP). Layer state machine Abstract protocol (AMLs) (LSM) ESM in Message protocol (AMLp) Layer protocol machine (LPM) invoke Used-connectivity- layer element 1. A specification of the LSMs (a single LPM can support many LSMs). 2. A specification of meta-primitives for the SAG (i.e., I-invoke and r-invoke), also using AMLs. Meta-primitives must be designed with the actual LSM descrip- tion language in mind. The generic primitives defined in AMLn are designed to support the AMLs abstract machine system and abstract object structures, including AMLs operation classes. However, the important thing is not which s