assoc.pcl55ACSE Protocol Machine showing association establishment and normal release
The ACSE protocol is very closely related to the ACSE services.
A-ASSOCIATE, A-RELEASE, and A-ABORT each has a corresponding protocol
data unit (PDU) conveyed to the ACSE peer service provider. The ACSE protocol
machine is shown in Figure 
, using the format and notation
conventions introduced in Section .
Receipt of A-ASSOCIATE.request
causes the ACSE service provider to send
the ACSE PDU AARQ to its peer on the
responding machine. AARQ
carries as parameters the information required by its ACSE peer to
perform the work expected of ACSE. This information is contained in
four of the A-ASSOCIATE.request parameters: the Application Context
Name, the calling AE information, the called AE information, and user
data. More details about the parameters appear in the chapter appendix
in Figure .
All the other A-ASSOCIATE.request parameters
go to the lower layer service providers to be used in
establishing the type connection required to support the association.
Figure shows the distribution of the parameters received in
A-ASSOCIATE.request between the APDU AARQ and the P-CONNECT.request.
Note that user data provided in A-ASSOCIATE.request becomes part of the
parameter list of AARQ; it is used to communicate between ACSE users.
However, there is still a user data parameter in P-CONNECT.request. This
user data carries communication between the peer ACSEs. In particular,
it is this user data parameter that actually carries AARQ from the
initiating ACSE to the responding ACSE. The other parameters constitute
communication between ACSE (in behalf of its service user) and the lower
layer service providers (the Presentation entity and through the
Presentation entity to the Session entity).
ch7aparm.pcl55Distribution of parameters provided in A-ASSOCIATE.request ACSE and its users are not conscious of a separation of function between the Presentation and Session entities. They are only aware of the type of connection needed with their peers and they provide the necessary descriptive information so that connection can be established and maintained by the appropriate service providers.
Other APDUs are similarly closely related to ACSE service primitives.
AARE goes from the responding ACSE to the initiating ACSE when
A-ASSOCIATE.response arrives from the responding ACSE user. It carries
information needed by the peer ACSEs and optional user data to be
delivered to the initiating ACSE service user. It is carried in the
user data field of the P-CONNECT.response primitive. RLRQ is the APDU
sent from initiating ACSE to responding ACSE to request a release of
the association. The response is RLRE. ABRT is the APDU sent from one
ACSE to its peer to demand immediate termination of the association, in
response to A-ABORT.request. Each of these APDUs is carried as user
data in an appropriate Presentation service primitive. The complete
mapping is shown in Figure . There is no APDU
corresponding to the A-P-ABORT service, because there is no exchange
between the ACSE service providers involved in this service. Instead,
an indication is received from the Presentation entity that the connection
is irretrievably lost and the word is passed to the ACSE user. No
protocol data units are involved.
Figure: Mapping ACSE primitives, APDUs, and Presentation Primitives
Many OSI protocols and a number of the newer protocols in the TCP/IP
suite are specified using ASN.1. Figures
and show the ASN.1 definition of ACSE. The
definition contains the same information as
Figures , , and
in an appendix to this chapter. Comparing the two presentations will
clarify the use of ASN.1 in specifying protocols and also provide a
complete and detailed presentation of ACSE.
Figure: ASN.1 specification of ACSE: the APDUs
Figure: ASN.1 specification of ACSE: Supporting Definitions
This section introduced the cornerstone of all connection-oriented Application Layer protocols. Once ACSE has done its job, cooperating peer Application processes have agreed to interact and have established a context to give meaning to their communications. In the remaining sections of this chapter, we address some of the most basic needs of cooperating processes executing on separated systems. The next section provides the ability to cause a remote system to execute a specified instruction and return a result or an error message.