ing language. An easy way is to use a standardized language (ASN.1 types defined in IDL, or C++), since then you also have access to all encoding algorithms you need to implement in agents. This is not always possible, however, since such methods do create quite a few overhead bits. This may not be acceptable for all protocols, especially not for some switching, transport, and trans- mission protocols. AMLp therefore also suggests other data types that provide less overhead. AMLp is described in details in Muth (2001). For readers who do not need all details of AMLp, a brief overview is included in Appendix D. As already indicated, a number of other languages could serve the purpose of AMLs and AMLp as well. For example, both UML and SDL are (in some sense) similar common-value languages, and IDL (the CORBA interface language) can be 1.4 Modeling Network Systems in AMLn used for interface specification. However, all these languages are initially devel- oped for software system modeling. They therefore fulfill the general four require- ments that were listed previously to various degrees. It is beyond the scope of this book to discuss this matter, however, 1.4.6 The Modeling Dimensions In AMLn, the complexity of models is handled by defining modeling dimensions. These are not just an arbitrary way of separating properties of network systems, but represent important generic architectural structures as well. The purpose with these dimensions is threefold: 1. It gives AMLn users a mental high level image of what network systems look like. 2. It defines model types that are relatively simple, each described by using very few symbols. 3. It defines major partitions of a model in a database. Model dimensions are defined on two levels. The top level dimension is the management dimension (M) in which we model the relations between two separate planes: traffic plane and management plane (see Figs. 1.32 and 1.33). The M dimension defines two types of relations: managed resource control points (mrCP) and connectivity service