ndent of whether the logical node is a CON- CSP or a CNL-CSP and whether the SEs are connected over connections or associ- ations. It is therefore wise to implement SEs separately from integrators, since such SEs will be portable between different types of CSPs. The properties of associations make this method of connecting service elements especially attractive in open environments, as was the target for the OSI develop- ment. OSI also defined association handling as a separate mechanism in the appli- cation layer, called the Association Control Service Element (ACSE), see ITU-T X.217 (ACSE service) and X.227 (ACSE protocol). However, ACSE suffers from severe structural problems. It is transparent to presentation and session layers serv- ices in the sense that ACSE requires SEs to deliver parameters for both the presen- tation and session layers, i.e. parameters that have nothing to do with association handling. In proprietary architectures where real-time properties are essential, association handling may not be an option. Some kind of association handling is, however, always needed when logical nodes provide message relaying, see Sect. 5.6. Message Handling 5.4.1 Introduction Protocol elements, by definition, communicate according to mutually agreed rules that are specified in a protocol specification. Thus, when we refer to a proto- col, we refer to a description of those rules. When we refer to a protocol element, we refer to a unit in the D-dimension that is expected to behave in all aspects according to a particular protocol. A protocol specification consists of two parts: a description of all interaction elements (messages, ASPs, etc.) and a description of behaviour. The latter describes which sequences of interaction elements are allowed, how the protocol 5 Protocol Network Modelling element shall react on a received interaction element and perhaps how a protocol element shall react when its peer does not behave as expected. However, there are considerable differences between the type of interaction ele- 