eneric association control primitives (defined by AMLn). Connectivity layers: The specification looks more like a conventional protocol, describing a number of messages and how their parameters are encoded. In addition, a message-based state-machine description is required. AMLn defines a number of generic primitives for the actor-agent interface (relay, terminate, etc.). The protocol specification defines the translation between these events and messages. It will most likely also include other messages that are used for error and flow control, checking the status of a used connection, etc. These messages have no correspondence in events of the actor-agent interface. Focusing behavior specification on interfaces is a universal principle (at least in AML), which is also the reason that an AMLn model is built by identifying inter- faces. After all, we do not want functional elements to be too concerned about other interfaces on which another element depends. However, sooner or later we want to specify how certain elements behave, e.g., for being able to run a model in simulation, or for generating code. We therefore regard an element specification, which considers all interfaces on which an element relies, as a secondary behavior description. Such a specification is an attribute of the very functional element. It is designed by specifying the relation between events (and/or messages) in different interfaces that concern the element. This principle is equally applicable on ele- ments of an LPM and an LSM. We need a specification language for being able to design behavior specifica- tions for an AMLn model. AMLn does not prescribe any particular language, since 1 Introduction to Network System Modeling behavior specifications are just attributes to the model, which implies that any suit- able language can be used. We can, however, list a few requirements on such a lan- guage, considering what an AMLn model look like: 1. Obviously, the language must allow behavior to be specified in terms of asyn- chronous events, suc