Association Control

In the discussion of CO and CL communications services above we noted that it was sometimes desirable that two (maybe more) application entities should form a long-term association. Most of the OSI applications defined to date assume that this is desirable. The Association Control Service Elements (ACSE) are designed to manage these associations. There are four elements, shown in table #tbacse#1496>.

#table1497#
Table: ACSE Service Primatives

The last three are concerned with breaking associations by agreement, by fiat from one end, and as a result of some inadequacy of the service provider respectively. The most important parameters of an A.ASSOCIATE.req are:

The P-SAP Address to which the remote Application entity is attached
The Application Context Name, which specifies the activity in which we are about to engage (File Transfer, Electronic Mail etc.)
Presentation Context information, which is concerned with how information is to be represented in transit. This is considered in the next section.
User data. Since A.ASSOCIATE is used to set up an association on behalf of some application, there will usually be some application-specific initialisation data to be transferred.

In practice, A.ASSOCIATE does little more than collect together the parameters to be placed in a P.CONNECT.req. In future it may do more; it would be an excellent place to implement Application Entity mutual authentication for example.