see Fig. 5.26) that could carry AML-ASPs. We also found that as long as all ASPs are described by the same abstract language, a general message format can always be defined. For- mats based on different abstract languages (AML, ROSE, IDL) are, however, not compatible, i.e. they require different message formats. In any network, one can expect interfaces where protocols are specified according to different abstract languages. This may sometimes require a translation between represen- tations of ASPs, as we saw in Sect. 5.6.3, Fig. 5.45. A protocol element that per- forms such translations does event relaying. The benefit of a common message format is that designers can focus on designing abstract protocols, and integrate message formatting and encoding functions as library units. Considering the formatting and encoding complexity of many telecom protocols, this represents a major improvement in designing distributed applications. This is the rationale for concepts like TCAP and CORBA. In Sect. 5.5, the EIA553 case, we saw the opposite approach. Here every ASP had a message format of its own. Existing standardized encoding algorithms were also not used. However, we managed to define formats and encoding by using ASN. 1 syntax and the AML set of data types. The benefit of this method is that designers have much better control of the formats, and thereby of the number of bits (SDUs) that must be transported for the messages. In cases where capacity is scare, this might be the only solution. 5 Protocol Network Modelling These types of protocols can often be implemented in hardware. Even if they are software implemented, they can be expected to be much faster, since general formats and encoding are capacity demanding. No matter which type of protocol and which formatting method is preferred, the abstract protocol level can (and should) always be defined. Although a single abstract language (preferably AML) can be used for all types of protocols, it is a fact of life that we will have to cope with several abstract langu