Association Control Service Element (ACSE) is the OSI method for establishing a call between two application programs. ACSE checks the identities and contexts of the application entities, and could apply an authentication security check.
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
To set up and maintain an application Association between two co-operating Application Processes [i.e. Two application specific ASEs (SASEs)]
And more specifically between two Application Entities (AEs : Set of Application Service Elements (ASEs)) which are responsible for communication between the APs on different open systems.
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:
One for handling the set-up of the association
One for handling graceful termination of the association
Two for handling abnormal terminations.
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
This sets up an association.
A single primitive is provided.
31 possible parameters => it is exceedingly complex.
We will discuss only a few classes of parameter here:
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:
Various parameters are included to identify the peer Application Process (AP). For both the calling and called Open System, the AP-title, AE-qualifier, and the AP and AE invocation identifiers are specified in the request. This identifies both the application and the specific instance to be used in this association. The latter is necessary since (for example) FTAM (File Transfer Access > Management) may be running simultaneously in association with several different open systems and files; in the event of failure, we need to identify which instance of FTAM is to be recovered.
The responding values are returned in the response variant. Whereas the called values identify the intended acceptor, the responding values may indicate that a different one has actually been used. One possibility is that a generic acceptor was requested, and the responding details indicate a specific identity.
Various parameters are included which allow the presentation details to be established. These include the responding presentation address, presentation contexts, and a default presentation context ( which may be used if there is no defined context set ).
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:
Communication Quality of Service (QOS).
Connection identifier.
Session requirements are specified, including initial SPSN and token assignments.
In addition, user data is specified: Typically, the SASE Initialise-PDU.
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
This terminates the association.
The primitive is much simpler than the associate.
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.
Provider Abort
- This is reported by the presentation service.
- A single primitive is used:
A-P-ABORT.indication (Reason, Data)
This could result from some underlying failure which cannot be recovered by the transport protocol without unduly degrading the QOS, or because of some protocol violation detected by an underlying layer.
On receipt of each service primitive from the SASE, the ACSE protocol machine (entity) creates a corresponding PDU. This, together with other parameters from the service primitive, is then passed to the correspondent ACSE entity in the user data parameter of the corresponding presentation service primitive. The PDUs associated with the ACSE protocol machine, together with the appropriate presentation service pimitives are shown Here.
Other APs communicate using names or titles. Consequently, before initialising a particular service, the user AP must obtain the corresponding fully qualified addresses of the two correspondent AEs (to which the user APs are attached) - These are obtained from the local Directory Service Agent (DSA). Subsequent service calls to other SASEs then normally have both the names and corresponding addresses of the two AEs as parameters.
The OSI presentation layer protocol (ISO-PP) is for the information transit between open systems using connection oriented or connectionless mode transmission at the presentation layer of the OSI 7 layer model. An application protocol is specified in terms of the transfer of presentation data values between application entities (PS users), using the User data parameter of presentation service primitives.The Presentation Layer has two functions it carries out on behalf of PS users:
- negotiation of transfer syntaxes;
- transformation to and from transfer syntax.
A set of presentation data value definitions associated with an application protocol constitutes an abstract syntax. For two application entities to communicate successfully they must have an agreement on the set of abstract syntaxes they intend to use. During the course of communication they may decide to modify this agreement. As a consequence, the set of abstract syntaxes in use may be changed. The abstract syntax specification identifies the information content of the set of presentation data values. It does not identify the transfer syntax to be used while presentation data values are transferred between presentation entities, nor is it concerned with the local representation of presentation data values.
The Presentation Layer exists to ensure that the information content of presentation data values is preserved during transfer. It is the responsibility of cooperating application entities to determine the set of abstract syntaxes they employ in their communication and inform the presentation entities of this agreement. Knowing the set of abstract syntaxes to be used by the application entities, the presentation entities are responsible for selecting mutually acceptable transfer syntaxes that preserve the information content of presentation data values.
For connectionless mode transmission, the abstract syntaxes used are determined by the sending application entity. For successful communication to take place, these must be acceptable to the receiving application entity.
For connectionless mode transmission, the presentation entities do not negotiate transfer syntaxes. The transfer syntaxes used are determined by the sending application entity. For successful communication to take place, these must be acceptable to the receiving application entity. The abstract syntaxes and the associated transfer syntaxes may be explicitly stated in the Presentation context definition list?parameter as a user option.
Presentation entities support protocols that enhance the OSI session service in order to provide a presentation service. The PS user is provided with access to the session service which permits full use to be made of that service. This includes negotiation of and access to the session functional units. The role of the Presentation Layer in providing this access includes representation of presentation data values in the User data parameters of session service primitives.
/ Protocol Structure - ISO-PP: OSI Presentation Layer Protocol (X.226, X.216, ISO 8823, 8822)
OSI Presentation Layer Protocol Primitives:
Connection Release Primitive / Token Handling Primitive
P-RELEASE request
P-RELEASE indication
P-RELEASE response
P-RELEASE confirm / P-TOKEN-GIVE request
P-TOKEN-GIVE indication
P-TOKEN-PLEASE request
P-TOKEN-PLEASE indication
P-CONTROL-GIVE request
P-CONTROL-GIVE indication
Presentation Exception Reporting Primitive / Activity Management Primitive
P-P-EXCEPTION-REPORT indication
P-U-EXCEPTION-REPORT request
P-U-EXCEPTION-REPORT indication / P-ACTIVITY-START request
P-ACTIVITY-START indication
P-ACTIVITY-RESUME request
P-ACTIVITY-RESUME indication
P-ACTIVITY-INTERRUPT request
P-ACTIVITY-INTERRUPT indication
P-ACTIVITY-NTERRUPT response
P-ACTIVITY-INTERRUPT confirm
P-ACTIVITY-DISCARD request
P-ACTIVITY-DISCARD indication
P-ACTIVITY-DISCARD response
P-ACTIVITY-DISCARD confirm
P-ACTIVITY-END request
P-ACTIVITY-END indication
P-ACTIVITY-END response
P-ACTIVITY-END confirm
ACSE: Association Control Service Element
Association Control Service Element (ACSE), an application layer protocol in the OSI model defined by ISO, is designed to establish and release an application-association between two AEIs and to determine the application context of that association. The ACSE supports two modes of communication: connection-oriented and connectionless. For the connection-oriented mode, the application association is established and released by the reference of ACSE connection-oriented services. For the connectionless mode, the application association exists during the invocation of the single ACSE connectionless mode service, A UNIT-DATA.
Standard Organization: ISO / ITU-T