erent for control layers and connectivity layers: For control layers it is assumed that meta-primitives are defined and AMLs is used for defining operations on the LSM level. An AMLp tool is assumed to be used to generate a single message type for invokes, including all possible param- eters and considering only possible length constraints of parameters defined by the invoke specification. The tool also creates suitable message types for associ- ation control primitives in SAGs (if any). Code generation comprises only encoding algorithms, control that valid message types are used, message struc- tures do not violate the message type specification, and parameter values are within defined value range. The tool can be designed for message error indica- tions to actors and remote agents. A basic assumption in this method is that ASN.1 is used for data typing, both of parameters of LSM-ASPs and of parameters of SAG primitives. A variant of this scheme is therefore that more compact data types are used (including encod- ing algorithms defined by users), and the tool user can edit message type specifi- cations that are suggested by the tool. Thereby, message formats that require fewer bits to be transmitted, or result in more efficient message processing, can be created. You can read more about this subject in Muth (2001). The previous method assumes that the agent layer protocol runs on a connectiv- ity layer that is 100% reliable and offers unlimited length message size. If that is not the case, the agent layer must be regarded as a connectivity layer as well. A framework for asynchronous connectivity protocols that includes encoding can be generated by AMLp if the SAC primitives (relay and terminate) between the agent and the relaying actor are specified, and AMLp data types are used. However, most of the properties of the layer depend on the difference between the properties of services the layer offers and the services it uses, and of optimi- zation issue. The layer may have to deal with many different issues, such