Association Control Service Elements (ACSEs)
Introduction
The Application layer is divided into two sub-layers:
SASE (Specific Application Service Elements) application specific service elements.
CASE" (Common Application Service Elements) application support service elements.
Logically, specific applications are users of support applications.
CASE originally included the basic 'CASE kernel' for setting up and terminating application connections, known as application Associations.
The CASE kernel was later modified and renamed as ACSE.
Association Control Service Elements provide a mechanism for setting up a logical link between two Application Entities (Association), on different open systems, and for releasing this Association when it is no longer needed.
Application Entities (AEs)
A number of functions are common to many applications, the approach adopted by ISO is to implement such functions as separate Application Service Elements (ASEs) which are then linked with selected application specific ASEs when the appropriate support service is required. The combined entity, the Application Entity (AE) is linked with the user Application Process (AP).Purpose of ACSE
Normally, an Association is established in response to a request from a client user Application Process for access to a particular networked service, such as a file server. To perform such services in an open way, a separate SASE is associated with each service present in the application layer in each networked system (computer). At one side it is known as the client ASE and at the other as the server ASE.
A single ASE in each open system will use ACSE, possibly on behalf of 'Superior' ASEs in the same open system.
Normally on the receipt of an initial service request from the client user Application Process, the client SASE first creates its own initialise (connection-receipt) PDU (Protocol Data Unit) and then uses the services provided by the ACSE to establish an Association with the correspondent (called) SASE. The initialise PDU, together with other information such as address of the calling and called SASEs, are passed with the ACSE associate request service primitive.
Application Association
This is a co-operative relation-ship between two ASEs and defines their terms of reference. The association determines which application protocols will communicate, and how they will do so; including their use of the presentation service.
Once an association has been established, ACSE does not feature in the subsequent SASE dialogue until the latter requests that the association be released (disconnected).
We will now look at the service primitives associated with ACSE.
ACSE Service
As is usual with OSI SEs, various services are defined in terms of service primitives. ACSE offers services:
At present, each service is associated with a single service primitive, although mechanisms for the provision of additional facilities, which the association details during its currency, are currently under consideration.
Associate Service
Request
A-ASSOCIATE.request( Calling application entity title
Called application entity title
Application context name
User information
Calling PSAP * (Presentation Service Access Point)
Called PSAP *
Single presentation context
Presentation context definition list
Default presentation context name *
Quality of Service **
Presentation requirements *
Session requirements **
Serial number **
Tokens **
Session connection identifier ** )
A-ASSOCIATE.indication( Calling application entity title
Called application entity title
Application context name
User information
Calling PSAP *
Called PSAP *
Single presentation context
Presentation context definition list
Presentation context definition result
Default presentation context name *
Default presentation context result *
Quality of Service **
Presentation requirements *
Session requirements **
Serial number **
Tokens **
Session connection identifier ** )
Response
A-ASSOCIATE.response( Responding application entity title
Application context name
User information
Result
Responding PSAP *
Presentation context definition result
Default presentation context result *
Quality of Service **
Presentation requirements *
Session requirements **
Serial number **
Tokens **
Session connection identifier ** )
A-ASSOCIATE.confirm( Responding application entity title
Application context name
User information
Result
Responding PSAP *
Presentation context definition result
Default presentation context result *
Quality of Service **
Presentation requirements *
Session requirements **
Serial number **
Tokens **
Session connection identifier ** )
* Mapped directly onto presentation service.
** Mapped directly onto session service.
Note on Parameters:
A presentation address is of the following form:
presentation address ::=
sequence { pSelector[0] OCTET STRING OPTIONAL;
sSelector[1] OCTET STRING OPTIONAL;
tSelector[2] OCTET STRING OPTIONAL;
nSelector[3] SET OF (1..MAX) OCTET STRING;
}
Other Parameters:
The standard specifies 3 association classes. These define the relationships between the entities, in terms of which entity or entities can invoke remote operations of the ROSE (Remote Operations Service Elements) type.
1. Class 1 association: Only the AE initiating the association may invoke operations.
2. Class 2 association: Only the AE responding to the association may invoke operations.
3. Class 3 association: Cutter AE may invoke operations.
Both the presentation and session requirements map onto the appropriate parameters of a P-CONNECT, which in turn maps onto a S-CONNECT. Other parameters (including many which have not been mentioned) map onto user data. ACSE use of the presentation service has a defined presentation context which is different from that of other ASEs' control information or ASE data. It is clear that, in general, several different presentation contexts will be required. Procedures are being developed for registering context sets, and this will ultimately result in some simplifications by being able to refer to standard names for common types of association. (It is proving to be a difficult area to standardise).
Release Service
Request
A-RELEASE.request (Reason, User information)
A-RELEASE.indication (Reason, User information)
Response
A-RELEASE.response (Reason, User information, Result)
A-RELEASE.confirm (Reason, User information, Result)
In the request, Reason may be
- Normal
- Urgent
- 'User defined'
In the response, the Reason may be
- Normal
- Not finished
- 'User defined'
This of course implies that the release is negotiated.
The Result, which appears only in the response, indicates whether the release was accepted (affirmative) or rejected (negative).
An affirmative response coupled with a not finished Result indicates that the association is terminated, but that the recipient of the request was in some way 'Unhappy' about this, generally because it still had information to send or receive.
Abort Services
There are two Abort services, User & Provider Abort. These map onto the presentation (and hence session) abort services.
User Abort
This is a the request of either service user, which is the ASE nominated as the sole user of ACSE (Only one ASE may use the services of ACSE). It is also possible for ACSE to issue an abort on its own initiative, in which case it relays a request to the peer open system, (where it becomes an indication), and an indication to its own service user. The association is released with possible loss of information.The primitive is as follows:
A-ABORT.request (User information)
A-ABORT.indication (Abort source, User information)
The User information (which is optional) is presumably understood by the peer ASE and/or the ACSE service user. As usual, if abort requests from both systems collide, this information will be lost.
The Abort source indicates either that ACSE itself has aborted (in which case there was no request), or that the service user (some nominated ASE) requested the abort.
