ode platform, it is decided which SAPI to send each message type, from each log- ical node, unless the optional SAPI address is used. This information is recorded by the platform in terms of a destination table for each logical node. There is no need for a discrimination function in this case. This method of implementing logical node communication has proven very effi- cient for real-time applications. However, it is also very rigid, since functional modifications that require changes to the set of message types in the logical net- work will affect the node platform tables. Overcoming this problem has engaged quite a few ingenious engineers over the years. One such method is based on mes- sage relaying within protocol networks, see Sect. 5.6. 5 Protocol Network Modelling 5.3.4 Connection and Association Handling With the exception of discrimination based on connection endpoint identifiers (CEI), the discrimination methods that were discussed are example of methods that work for permanently existing service elements in a logical node. When a logical network must handle service elements that have a temporary existence in the DC- plane, some extra mechanism for handling temporary service elements must be implemented as part of the integrator. There are basically two choices: connection handling or association handling. The differences between these methods are: When two service elements are interconnected over an association, they have the right to assume that they can communicate according to the same protocol. If they are interconnected over a connection, the mechanism that interconnects them leaves no such guarantee. In a logical node that bases discrimination on connections alone, all service ele- ments are of the same type (i.e. handle the same protocol). If discrimination is based on associations, service elements can be of the same or different types, since the association mechanism checks that the service elements to be con- nected are compatible before the association is established. The simplest way to pro