h as the events of abstract protocols (message communica- tion is, by definition, asynchronous). 2. The language must also allow for asynchronous events to be defined as parts of operations, since that is an expanding form of communication in networks. Furthermore, since sometimes it is convenient to associate operations to objects (e.g., the MOs used by management systems), the language must allow a certain behavior to be associated to an object. 4. Finally, the language must support a behavior to be described in terms of a state machine. This is due to the fact that a major part of all functions in a network system deal with controlling the state of things, e.g., the services given to users and the state of resources used. The author developed such a language more then 10 years ago, as the first part of AML. We now call it AMLs. AMLs is a language that you may use to describe everything about an LSM. It is a common-value language, i.e., it can be used for describing behavior of systems in any system domain. It therefore does not use the specific names (LSM, ESM, MO, etc.) of state machines that AMLn introduces, but calls all of them abstract machines that may or may not include abstract objects. AMLs is described in details in Muth (2001). For readers who do not need all details of AMLs, a brief overview is given in Appendix D. You also need to specify LPM behavior, which comprises the messages of an agent layer protocol and the behavior of the agents. For specifying actor-agent interfaces and layer interfaces that agents use, you may use AMLs as well. How- ever, for describing message types and the mapping between events in actor-agent interfaces and messages, AMLs is of no use. The author therefore developed a method some years ago for generating such mapping descriptions, based on con- straints defined by a protocol designer. We now call that method AMLp. AMLp can be regarded as a method for LPM specification. Since messages as well as parameters of events are data structures, AMLp must rely on some data typ