that there exist only one actor per actor layer in each layer element (if there are more than one, the actor suffixes of detectors and generators must be given in messages as well). I-invokeRep(3, LSMeventinfo, Common agent {1, 3, ...} r-invokeOrd(2, LSMeventInfo, AAli<->ALi T-ROa {1, 1, ...} Network address invoke syntax: to a remote agent r-invokeRep(detectorAs, LSMeventInfo,. ) Message format: I-invokeRep(generatorAs, LSMeventInfo,...) {ALi, generatorAs, } Fig. 2.32 Identifying actors when a common agent layer is used The model shows one of the common agents from Fig. 2.31, and the actors it connects. We assume that when an actor is initially configurated to an actor-agent interface, the agent relates the identity of this interface (a local identifier called actor-agent interface identifier (AAli)) to the name of the actor layer to which the actor belongs. This is done in a table (called T-AL) that associates an AAli to an ALi. Another part of the configuration activity may be to store information about which remote agents will be addressed for each remote actor of interest to the agent's own actors. By storing this information, actors do not need to know network addresses to remote agents, which protects actors from configuration changes on the network level. This information is stored in two tables, called T-ROa and T-RE in models, where T-ROa is used to translate an actor address to a route endpoint identifier 2.3 Agents and Actors (REi), and T-RE to translate an REi to a network address. You can read more about these identifiers and tables in Chap. 3 and Appendix C. The message-reception scenario of Fig. 2.32 is as follows: The agent receives a message from actor 13. The agent looks up its T-AL table and finds the AAI in its own layer element that connects an actor of actor layer 1 (which is the actor 11 in the model). It gener- ates an I-invokeRep in that AAI that includes the generating actor suffix 3. The message-sending scenario is as follows: As a result of detecting the LSM event from actor 13, actor