Recommendation X.217

ASSOCIATION CONTROL SERVICE DEFINITION FOR OPEN SYSTEMS INTERCONNECTION FOR CCITT APPLICATIONS

(Melbourne, 1988)

The CCITT,

considering

(a)	that Recommendation X.200 defines the Reference Model of Open Systems Interconnection for CCITT Applications;

(b)	that Recommendation X.210 defines the Open System Interconnection (OSI) Layer Service Definition Conventions;

(c)	that Recommendation X.215 defines the Session Service Definition for Open Systems Interconnection for CCITT Applications;

(d)	that Recommendation X.216 defines the Presentation Service Definition of Open Systems Interconnection for CCITT Applications;

(e) that Recommendation X.220 specifies the use of X.200 series protocols in CCITT Applications;

( f)	that Recommendation X.227 specifies the Association Control Protocol Specification for Open Systems interconnection for CCITT Applications;

(g)	that Recommendation X.410-1984 specifies the protocol for Remote Operation and Reliable Transfer Server for Message Handling Systems; and

(h)	that there is a need for common Association Control to support various applications,

unanimously declares

that this Recommendation defines the Association Control Service of Open Systems Interconnection for CCITT Applications as given in the Scope and Field of Application.

CONTENTS

0	Introduction

1	Scope and field of application

2	References

3	Definitions

3.1	Reference model definitions

3.2	Naming and addressing definitions

3.3	Service conventions definitions

3.4	Presentation service definitions

3.5	ACSE service definitions

4	Abbreviations

5	Conventions

6	Basic concepts

7	Service overview

8	Relationship with other ASEs and lower layer services

8.1	Other application-service-elements

8.2	Presentation-service

8.3	Session-service

9	Service definition

9.1	A-ASSOCIATE service

9.2	A-RELEASE service

9.3	A-ABORT service

9.4	A-P-ABORT service

10	Sequencing Information

10.1	A-ASSOCIATE

10.2	A-RELEASE

10.3	A-ABORT

10.4	A-P-ABORT

Annex A - Usage of ACSE services to achieve compatibility with CCITT Recommendation X.410-1984, and the basic facilities of the 1988 Message Handling series of CCITT Recommendations

A.1	Compatibility requirements

A.2	Principles for ensuring compatibility

A.3	Usage of Association Control services to ensure compatibility with X.410-1984

A.3.1	A-ASSOCIATE

A.3.2	A-RELEASE

A.3.3	A-ABORT

A.3.4	A-P-ABORT

A.3.5	State Table

Appendix I - Differences between Recommendation X.217 and ISO International Standard 8649.

0	Introduction

0.1	This Recommendation is one of a set of Recommendations produced to facilitate the interconnection of information processing systems. It is related to other Recommendations in the set as defined by the Reference Model for Open Systems Interconnection (X.200). The reference model subdivides the area of standardization for interconnection into a series of layers of specification, each of manageable size.

0.2	The goal of Open Systems Interconnection is to allow, with a minimum of technical agreement outside the inter-connection recommendations, the interconnection of information processing systems:

-	from different manufacturers;

-	under different managements;

-	of different levels of complexity; and

-	of different technologies.

0.3	This Recommendation recognizes that application-processes may wish to communicate with each other for a wide variety of reasons. However, any communication will require the performance of certain services independent of the reasons for communication. The application-service-element defined herein provides such services.

0.4	This Recommendation defines services provided by the application service element for application-association control: the Association Control Service Element (ACSE). The ACSE provides basic facilities for the control of an application-association between two application-entities which communicate by means of a presentation-connection.

0.5	The use of services defined in this Recommendation is also governed by the use of the presentation-service (X.216) and the session-service (X.215).

0.6	It is recognized that, with respect to ACSE Quality of Services (QOS), described in S 9, work is still in progress to provide an integrated treatment of QOS across all layers of the OSI Reference Model, and to ensure that the individual treatments in each layer service satisfy overall QOS objectives in a consistent manner. As a consequence, a change may be made to this Recommendation at a later time which reflects further QOS developments and integration.

1	Scope and field of application

This Recommendation defines ACSE services for application-association control in an open systems interconnection environment. The ACSE services are provided by the use of the ACSE protocol (X.227) in conjunction with the presentation-service (X.216). The ACSE services assume as a minimum the use of the presentation-service Kernel functional unit.

This Recommendation does not specify individual implementations or products nor does it constrain the implementation of entities and interfaces within a computer system.

No requirement is made for conformance to this Recommendation.

2	References

Recommendation X.200	Reference Model of Open Systems Interconnection for CCITT applications. (See also ISO 7498-1)

Recommendation X.210	OSI layer service definition conventions. (See also ISO TR8509)

Recommendation X.215	Session service definition for Open Systems Interconnection for CCITT applications. (See also ISO 8326 and ISO 8326 Addendum 2).

Recommendation X.216	Presentation service definition for Open Systems Interconnection for CCITT applications. (See also ISO 8822).

Recommendation X.225	Session protocol specification for Open Systems Interconnection for CCITT applications. (See also ISO 8327 and ISO 8327 Addendum 2).

Recommendation X.227	Association Control protocol specification for Open Systems Interconnection for CCITT applications. (See also ISO 8650).

Recommendation X.410-1984	CCITT Recommendation X.410: Message Handling Systems: Remote Operation and Reliable Transfer Server.

ISO 7498-3	Information processing systems - Open Systems Interconnection - Basic Reference Model - Part 3: Naming and Addressing.

3	Definitions

3.1	Reference model definitions

This Recommendation is based on the concepts developed in X.200 and makes use of the following terms defined in it:

a)	Application Layer;

b)	application-process;

c)	application-entity;

d)	application-service-element;

e)	application-protocol-data-unit;

f )	application-protocol-control-information;

g)	presentation-service;

h)	presentation-connection;

i)	session-service;

j )	session-protocol;

k)	session-connection.

3.2	Naming and addressing definitions

This Recommendation makes use of the following terms defined in ISO 7498-3;

a)	application-process title;

b)	application-entity qualifier;

c)	application-entity title;

d)	application-process invocation-identifier;

e)	application-entity invocation-identifier; and

f )	presentation address.

3.3	Service conventions definitions

This Recommendation makes use of the following terms defined in X.210:

a)	service-provider;

b)	service-user;

c)	confirmed service;

d)	non-confirmed service;

e)	provider-initiated service;

f )	primitive;

g)	request (primitive);

h)	indication (primitive);

i)	response (primitive); and

j )	confirm (primitive).

3.4	Presentation service definitions

This Recommendation makes use of the following terms defined in Recommendation X.216:

a)	abstract syntax;

b)	abstract syntax name;

c)	default context;

d)	defined context set;

e)	functional unit [presentation];

f )	normal mode [presentation];

g)	presentation context;

h)	presentation data value; and

i)	X.410-1984 mode [presentation].

3.5	ACSE service definitions

For the purpose of this Recommendation, the following definitions apply:

3.5.1	application-association; association

A cooperative relationship between two application-entities, formed by their exchange of application-protocol-control-information through their use of presentation-services.

3.5.2	application context

An explicitly identified set of application-service-elements, related options and any other necessary information for the interworking of application-entities on an application-association.

Note - This definition is subject to refinement as a result of ongoing work in the area of the Application Layer structure.

3.5.3	Association Control Service Element

The particular application-service-element defined in this Recommendation.

3.5.4	ACSE service-user

The part of the application-entity which makes use of ACSE services.

3.5.5	ACSE service-provider

An abstraction of the totality of those entities which provide ACSE services to peer ACSE service-users.

3.5.6	requestor

The ACSE service-user which issues the request primitive for a particular ACSE service. For a confirmed service, it also receives the confirm primitive.

3.5.7	acceptor

ffor a particular ACSE service. For a confirmed service, it also issues the response primitive.

3.5.8	association-initiator

The ACSE service-user which initiates a particular association, i.e. the requestor of the A-ASSOCIATE service which establishes the association.

3.5.9	association-responder

The ACSE service-user which is not the initiator of a particular association, i.e. the acceptor of the A-ASSOCIATE service which establishes the association.

3.5.10	normal mode

The mode of ACSE operation which results in the transfer of ACSE semantics, using the presentation-service.

3.5.11	X.410-1984 mode

The mode of ACSE operation which allows ACSE service-users to interwork using the protocol specified in CCITT Recommendation X.410-1984. The use of this mode results in no transfer of ACSE semantics.

3.5.12	disrupt

A service procedure is disrupted by another service procedure if the second service results in service primitives not being used as specified for the procedure of the first service.

4	Abbreviations

The following abbreviations are used in this Recommendation.

ACSE	Association Control Service Element

AE	application-entity

ASE	application-service-element

OSI	Open Systems Interconnection

QOS	Quality of Service

5	Conventions

5.1	This Recommendation defines services for the ACSE following the descriptive conventions defined in Recommendation X.210. In ' 9, the definition of each ACSE service includes a table which lists the parameters of its primitives. For a given primitive, the presence of each parameter is described by one of the following values.

blank	not applicable

C	conditional

M	mandatory

P	subject to conditions defined in X.216

U	user option

iis semantically equal to the value to its left in the table.

6	Basic concepts

6.1	The reference model (X.200) represents communication between a pair of application-processes (APs) in terms of communication between their application-entities (AEs) using the presentation-service. The functionality of an AE is factored into a number of application-service-elements (ASEs). The interaction between AEs is described in terms of the use of their ASEs' services.

6.2	This Recommendation introduces the additional modelling concepts of application-association and application context.

6.3	An application-association is a cooperative relationship between two AEs. It provides the necessary frame of reference between the AEs in order that they may interwork effectively. This relationship is formed by the exchange of application-protocol-control-information between the application-entities through their use of presentation-services.

6.4 An application context is an explicitly identified set of application-service-elements, related options and any other necessary information for the interworking of application-entities on an application association.

7	Service overview

7.1	This Recommendation defines the following services for the control of a single association

a)	A-ASSOCIATE;

b)	A-RELEASE;

c)	A-ABORT; and

d)	A-P-ABORT.

7.2	The A-ASSOCIATE service causes the start of use of an association by those ASE procedures identified by the value of Application Context Name parameter.

Note - The use of an association by several ASEs is the subject of ongoing work.

7.3	The A-RELEASE service, if successful, causes the completion of the use of an association by those ASE procedures identified by the application context which is in effect without loss of information in transit. However, the success of the A-RELEASE service optionally may be negotiated.

7.4	The A-ABORT service causes the abnormal release of the association with the possible loss of information in transit.

7.5	The A-P-ABORT service indicates the abnormal release of the association as a result of action by the underlying presentation-service with the possible loss of information in transit.

oof the following modes:

a)	normal mode; or

b)	X.410-1984 mode.

7.7	The normal mode of operation allows the ACSE service-user to take full advantage of the functionality provided by both ACSE and the presentation-service (X.216). In this mode the ACSE service-provider transfers its semantics using the normal mode of the presentation-service.

7.8	The X.410-1984 mode of operation allows the ACSE service-user to interwork with a peer using the protocol specified by the CCITT Recommendation X.410-1984. In this mode, the ACSE service-provider does not transfer any semantics of its own and uses the X.410-1984 mode of the presentation-service.

8	Relationship with other ASEs and lower layer services

8.1	Other application-service-elements

8.1.1	The ACSE is intended to be used with other ASEs in order to support a specific information processing task. Therefore, it is expected that the ACSE will be included in all application context specifications.

8.1.2	The collection of the ACSE and other ASE(s) included in an application context are required to use the facilities of the presentation-service in a coordinated manner.

8.2	Presentation-service

8.2.1	A one-to-one correspondence exists between an application-association and a presentation-connection.

8.2.2	The ACSE services require access to the P-CONNECT, P-RELEASE, P-U-ABORT and P-P-ABORT services. The ACSE services neither use nor constrain the use of any other presentation service.

8.2.3	The requestor and acceptor of the A-ASSOCIATE service determine the mode, the default presentation context, and the initial defined context set of the underlying presentation-connection using the following A-ASSOCIATE parameter:

- Mode;

- Presentation Requirements;

- Presentation Context Definition List;

- Presentation Context Definition Result List;

- Default Presentation Context Name; and

- Default Presentation Context Result.

spe

specified in X.227 for the ACSE application-protocol-data-units.

Note - The ACSE service-provider is aware of the presentation context which contains its abstract syntax by a local mechanism.

8.2.5	If the requestor specifies the value ;X.410-1984+ for the Mode parameter, the ACSE service-provider does not transfer ACSE semantics and therefore does not require a presentation context for its abstract syntax. Any user information which the ACSE service-provider transfers for its service-user uses the unnamed default presentation context for the X.410-1984 mode of the presentation-service (X.216).

Note - Table 2/X.217 indicates the A-ASSOCIATE service parameters which are not used in the X.410-1984 mode. None of the presentation context related parameters are used.

8.3	Session-service

8.3.1	Using the Session Requirements parameter, the A-ASSOCIATE service requestor and acceptor determine the functional units for the underlying session-service (X.215).

8.3.2	The rules and parameter value length restrictions of the underlying session-service affect ACSE services. The ACSE service-user must be aware of these constraints.

Note - Some examples of these constraints are:

a)	Version 1 of the session-protocol (X.225) imposes user data length restrictions which affect ACSE primitive parameters. Some special considerations apply to the A-ABORT services (see ' 9.3).

b)	The choice of session functional units for a particular association affects the rules for the use of ACSE services. For example, the selection of session tokens controls the possibilities of negotiated release and release collisions.

9	Service definition

The ACSE services are listed in Table 1/X.217.

TABLE 1/X.217

ACSE-services

Service

Type

A-ASSOCIATE

Confirmed

A-RELEASE

Confirmed

A-ABORT

Non-confirmed

A-P-ABORT

Provider-initiated

9.1	A-ASSOCIATE Service

The A-ASSOCIATE service is used to cause the beginning of the use of an association; it is a confirmed service.

9.1.1	A-ASSOCIATE Parameters

Table 2/X.217 lists the A-ASSOCIATE service parameters. In addition, groups of parameters are defined for reference by other ASEs as follows:

a)	Calling AE Title is the composite of the Calling AP Title and the Calling AE Qualifier parameters;

b)	Called AE Title is the composite of the Called AP Title and the Called AE Qualifier parameters;

c)	Responding AE Title is the composite of the Responding AP Title and the Responding AE Qualifier parameters;

The two components of the AE title (AP title and AE qualifier) are defined in ISO 7498-3.

Table 2/X.217 [T2.217], p.

TABLE 2/X.217

A-ASSOCIATE parameters

Parameter name

Request

Indicat

ion

Respons

e

Confirm

ation

Mode

U

M (=)

Application context name a)

M

M (=)

M

M (=)

Calling AP title a)

U

C (=)

Calling AE qualifier a)

U

C (=)

Calling AP invocation-identifier a)

U

C (=)

Calling AE invocation-identifier a)

U

C (=)

Called AP title a)

U

C (=)

Called AE qualifier a)

U

C (=)

Called AP invocation-identifier a)

U

C (=)

Called AE invocation-identifier a)

U

C (=)

Responding AP title a)

U

C (=)

Responding AE qualifier a)

U

C (=)

Responding AP invocation-identifier a)

U

C (=)

Responding AE invocation-identifier a)

U

C (=)

User information

U

C (=)

U

C (=)

Result

M

M (=)

Result source

M

Diagnostic a)

U

C (=)

Calling presentation address

P

P

Called presentation address

P

P

Responding presentation address

P

P

Presentation context definition list a)

P

P

Presentation context definition result list a)

P

P

P

Default presentation context name a)

P

P

Default presentation context result a)

P

P

Quality of service

P

P

P

P

Presentation requirements a)

P

P

P

P

Session requirements

P

P

P

P

Initial synchronization point serial number

P

P

P

P

Initial assignment of tokens

P

P

P

P

Session-connection identifier a)

P

P

P

P

a) Not used in X.410-1984 mode.

9.1.1.1 Mode

This parameter specifies the mode in which the ACSE services will operate for this association. It takes one of the following symbolic values:

- normal; or

- X.410-1984.

If this parameter is not included on the request primitive, the default value of normal½ is used by the ACSE service provider. This parameter is always present on the indication primitive.

9.1.1.2	Application Context Name

This parameter identifies the application context proposed by the requestor. The acceptor returns either the same or a different name. The returned name specifies the application context to be used for this association.

Note - The offer of an alternate application context by the acceptor provides a possible mechanism for limited negotiation. However, the semantics and rules for this exchange are entirely user specific. If the requestor cannot operate in the acceptor's application context, it may issue an A-ABORT request primitive.

9.1.1.3	Calling AP Title

This parameter identifies the AP which contains the requestor of the A-ASSOCIATE service.

9.1.1.4	Calling AE Qualifier

This parameter identifies the particular AE of the AP which contains the requestor of the A-ASSOCIATE service.

9.1.1.5	Calling AP Invocation-identifier

This parameter identifies the AP invocation which contains the requestor of the A-ASSOCIATE service.

9.1.1.6	Calling AE Invocation-identifier

This parameter identifies the AE invocation which contains the requestor of the A-ASSOCIATE service.

9.1.1.7	Called AP Title

This parameter identifies the AP which contains the intended acceptor of the A-ASSOCIATE service.

9.1.1.8	Called AE Qualifier

This parameter identifies the particular AE of the AP which contains the intended acceptor of the A-ASSOCIATE service.

9.1.1.9	Called AP Invocation-identifier

This parameter identifies the AP invocation which contains the intended acceptor of the A-ASSOCIATE service.

9.1.1.10	Called AE Invocation-identifier

This parameter identifies the AE invocation which contains the intended acceptor of the A-ASSOCIATE service.

9.1.1.11	Responding AP Title

This parameter identifies the AP which contains the actual acceptor of the A-ASSOCIATE service.

9.1.1.12	Responding AE Qualifier

This parameter identifies the particular AE of the AP which contains the actual acceptor of the A-ASSOCIATE service.

9.1.1.13	Responding AP Invocation-identifier

This parameter identifies the AP invocation which contains the actual acceptor of the A-ASSOCIATE service.

9.1.1.14	Responding AE Invocation-identifier

This parameter identifies the AE invocation which contains the actual acceptor of the A-ASSOCIATE service.

9.1.1.15	User Information

Either the requestor or the acceptor may optionally include user information. Its meaning depends on the application context which accompanies the primitive.

Note - For example, this parameter may be used to carry the initialization information of other ASEs included in the application context specified by the value of the accompanying Application Context Name parameter.

9.1.1.16	Result

This parameter is provided by either the acceptor, by the ACSE service-provider, or by the presentation service-provider. It indicates the result of using the A-ASSOCIATE service. It takes one of the following symbolic values:

- accepted;

- rejected (permanent); or

- rejected (transient).

9.1.1.17	Result Source

The value of the parameter is supplied by the ACSE service-provider. It identifies the creating source of the Result parameter and the Diagnostic parameter, if present. It takes one of the following symbolic values:

- ACSE service-user;

- ACSE service-provider; or

- presentation service-provider.

If the Result parameter has the value accepted½, the value of this parameter is ACSE service-user½.

9.1.1.18	Diagnostic

This parameter is only used if the Result parameter has the value of rejected (permanent)½ or rejected (transient)½. Optionally, it can be used to provide diagnostic information about the result of the A-ASSOCIATE service.

If the Result Source parameter has the value ACSE service-provider½, it takes one of the following symbolic values:

- no reason given; or

- no common ACSE version.

If the Result Source parameter has the value ACSE service-user½, it takes one of the following symbolic values:

- no reason given;

- application context name not supported;

- calling AP title not recognized;

- calling AE qualifier not recognized;

- calling AP invocation-identifier not recognized;

- calling AE invocation-identifier not recognized;

- called AP title not recognized;

- called AE qualifier not recognized;

- called AP invocation-identifier not recognized; or

- called AE invocation-identifier not recognized.

9.1.1.19	Calling Presentation Address

This parameter is as defined in Recommendation X.216.

9.1.1.20	Called Presentation Address

This parameter is as defined in Recommendation X.216.

9.1.1.21	Responding Presentation Address

This parameter is as defined in Recommendation X.216.

9.1.1.22	Presentation Context Definition List

This parameter is as defined in Recommendation X.216.

9.1.1.23	Presentation Context Definition Result List

This parameter is as defined in Recommendation X.216.

9.1.1.24	Default Presentation Context Name

This parameter corresponds to the Default Context Name parameter defined in Recommendation X.216.

9.1.1.25	Default Presentation Context Result

This parameter corresponds to the Default Context Result parameter defined in Recommendation X.216.

9.1.1.26	Quality of Service

This parameter is as defined in Recommendation X.216.

9.1.1.27	Presentation Requirements

This parameter is as defined in Recommendation X.216.

9.1.1.28	Session Requirements

This parameter is as defined in Recommendation X.216.

9.1.1.29	Initial Synchronization Point Serial Number

This parameter is as defined in Recommendation X.216.

9.1.1.30	Initial Assignment of Tokens

This parameter is as defined in Recommendation X.216.

9.1.1.31	Session Connection Identifier

This parameter is as defined in Recommendation X.216.

9.1.2	A-ASSOCIATE service procedure

9.1.2.1	The A-ASSOCIATE service procedure has a one-to-one correspondence with the P-CONNECT service defined in Recommendation X.216. When the A-ASSOCIATE service is used, the association is created simultaneously with the creation of the underlying presentation-connection.

9.1.2.2	An ACSE service-user which desires to establish an association issues an A-ASSOCIATE request primitive. The called AE is identified by parameters of the request primitive. The requestor cannot issue any primitives except an A-ABORT request primitive until it receives an A-ASSOCIATE confirm primitive.

9.1.2.3	The ACSE service-provider issues an A-ASSOCIATE indication primitive to the acceptor.

9.1.2.4	The acceptor accepts or rejects the association by sending an A-ASSOCIATE response primitive with an appropriate Result parameter. ACSE service-provider issues an A-ASSOCIATE confirm primitive having the same Result parameter. The Result Source parameter is assigned the symbolic value of ACSE service-user½.

9.1.2.5	If the acceptor accepts the association, the association is available for use. Requestors in both AEs may now use any service provided by the ASEs included in the application context which in effect (with the exception of A-ASSOCIATE).

9.1.2.6	If the acceptor rejects the association, the association is not established.

9.1.2.7	The ACSE service-provider may not be capable of supporting the requested association. In this situation, it returns an A-ASSOCIATE confirm primitive to the requestor with an appropriate RESULT parameter. The Result Source parameter is appropriately assigned either the symbolic value of ACSE service-provider½ or presentation service-provider½. The indication primitive is not issued. The association is not established.

9.1.2.8	A requestor in either AE may disrupt the A-ASSOCIATE service procedure by issuing an A-ABORT request primitive. The acceptor receives an A-ABORT indication primitive. The association is not established.

9.2	A-Release service

The A-RELEASE service is used by a requestor in either AE to cause the completion of the use of an association; it is a confirmed service. If the session Negotiated Release functional unit was selected for the association, the acceptor may respond negatively (see S 8.3.2). This causes the unsuccessful completion of the A-RELEASE service and the continuation of the association without loss of information in transit.

9.2.1	A-RELEASE parameters

Table 3/X.217 lists the A-RELEASE parameters.

TABLE 3/X.217

A-RELEASE parameters

Parameter name

Request

Indication

Response

Confirmatio

n

Reason a)

U

C (=)

U

C (=)

User information a)

U

C (=)

U

C (=)

Result

M

M (=)

a) Not used in X.410-1984 mode.

9.2.1.1	Reason

When used on the request primitive, this parameter identifies the

general level of urgency of the request. It takes one of the following

symbolic values:

- normal;

- urgent; or

- user defined.

Note - For example, if the session Negotiated Release functional

unit was selected for the association, the value urgent½ may be

used on the request primitive when the requestor desires to urgently

release the association.

When used on the response primitive, this parameter identifies informatio

n about why the acceptor accepted or rejected the release request.

It takes one of the following symbolic values:

- normal;

- not finished; or

- user defined.

Note - For example, if the session Negotiated Release functional

unit was not selected for the association, the value not finished½

may be used on the response primitive when the acceptor is forced to

release the association but wishes to give a warning that it has

additional information to send or receive.

9.2.1.2	User information

Either the requestor or acceptor may optionally include user informatio

n on the request or response primitive. Its meaning depends on the

application context which is in effect.

9.2.1.3	Result

This parameter is used by the acceptor to indicate if the request

to release the association normally is acceptable. It takes one of

the following symbolic values:

- affirmative; or

- negative.

9.2.2	A-RELEASE service procedure

9.2.2.1	The A-RELEASE service procedure has a one-to-one correspond

ence with the P-RELEASE service defined in Recommendation X.216.

When the A-RELEASE service is used, the association is released

simultaneously with the release of the underlying presentati

on-connection.

9.2.2.2	An ACSE service-user which desires to release the associatio

n issues an A-RELEASE request primitive. This requestor cannot

issue any further primitives other than an A-ABORT request primitive

until it receives an A-RELEASE confirm primitive.

9.2.2.3	In order to issue an A-RELEASE request primitive, the requestor

is required to meet all the requirements for issuing a P-RELEASE

request (see S 8.2).

9.2.2.4	The ACSE service-provider issues an A-RELEASE indication primitive

to the acceptor. The acceptor then cannot issue any ACSE primitives

other than an A-RELEASE response primitive or an A-ABORT request primitive.

9.2.2.5	The acceptor replies to the A-RELEASE indication primitive by

issuing an A-RELEASE response primitive with a Result parameter which has

a value of affirmative½ or negative½. The acceptor may give a

negative response only if the session Negotiated Release functional

unit was selected for the association (see S 8.3).

9.2.2.6	If the acceptor gives a negative reponse, it may once again use any

service provided by the ASEs included in the application context

which in effect (with the exception of the A-ASSOCIATE service).

If it gave a positive response, it cannot issue any further primitives

for the association.

9.2.2.7	The ACSE service-provider issues an A-RELEASE confirm primitive

with an affirmative½ or negative½ value for the Result parameter.

If the value is negative½, the requestor may once again use any

of the services provided by the ASEs of the application context

which is in effect (with the exception of A-ASSOCIATE).

9.2.2.8	If the value of the Result parameter is affirmative½, the associatio

n and the underlying presentation-connection have been released.

9.2.2.9	A requestor in either AE may disrupt the A-RELEASE service procedure

by issuing an A-ABORT request. The acceptor receives an A-ABORT

indication. The association is released with the possible loss of

information in transit.

9.2.2.10	An A-RELEASE service procedure collision results when requestors

in both AEs simultaneously issue an A-RELEASE service primitive.

This can occur only when no session tokens are available on the

association (see S 8.3). In this situation, both ACSE service-users

receive an unexpected A-RELEASE indication primitive. The following

sequence then occurs to complete the normal release of the associatio n.

a)	The association-initiator issues an A-RELEASE response primitive.

b)	The association-responder waits for an A-RELEASE confirm primitive from its peer. When it receives one, it then issues an A-RELEASE response primitive.

c)	The association-initiator receives an A-RELEASE confirm primitive.

9.2.2.11	The association is released when both ACSE service-users have

received an A-RELEASE confirm primitive.

9.3	A-ABORT service

The A-ABORT service is used by a requestor in either AE to cause the

abnormal release of the association. It is a non-confirmed service.

However, because of the possibility of an A-ABORT service procedure

collision (see S 10.3.5), the delivery of the indication primitive

is not guaranteed. However, both AEs are aware that the associatio

n has been released.

9.3.1	A-ABORT parameters

Table 4/X.217 lists the A-ABORT parameters.

TABLE 4/X.217

A-ABORT parameters

Parameter name

Request

Indication

Abort source a)

M

User information

U

C (=)

a)	Not used in X.410-1984 mode.

9.3.1.1	Abort Source

This parameter, whose value is supplied by the ACSE service-provider, indicates the initiating source of this abort. It takes one of the following symbolic values:

- ACSE service-user; or

- ACSE service-provider.

9.3.1.2	User Information

The requestor may optionally include user information on the request primitive. Its meaning depends on the application context which is in effect.

Note - When ACSE is supported with version 1 of the session-protocol (X.225), this parameter is subject to length restrictions mentioned in S 8.3. For use with version 1, the A-ABORT service procedure does not transfer any of its own semantics, thus allowing the maximum possible length for presentation data value(s) of the User Information parameter. In this situation, the Abort Source parameter of the A-ABORT indication primitive always indicates ACSE service-user½.

9.3.2	A-ABORT service procedure

9.3.2.1	The A-ABORT service procedure has a one-to-one correspondence with the P-U-ABORT service defined in Recommendation X.216. When the A-ABORT service is used, the association is abnormally released simultaneously with the abnormal release of the underlying presentation-connection.

9.3.2.2	An ACSE service-user which desires to abnormally release the association issues the A-ABORT request primitive. This requestor cannot issue any further primitives for the association.

9.3.2.3	The ACSE service-provider issues an A-ABORT indication primitive to the acceptor. The ACSE service-provider assigns the value of ACSE service-user½ for the Abort Source parameter. The association and the underlying presentation-connection have been released.

9.3.2.4	The ACSE service-provider may itself cause the abnormal release of the association because of internal errors detected by it. In this case, the ACSE service-provider issues A-ABORT indication primitives to acceptors in both AEs. The ACSE service-provider assigns the value of ACSE service-provider½ to the Abort Source parameter. The User Information parameter is not used.

9.4	A-P-ABORT service

The A-P-ABORT service is used by the ACSE service-provider to signal the abnormal release of the association due to problems in services below the Application Layer. This occurrence indicates the possible loss of information in transit. A-P-ABORT is a provider-initiated service.

9.4.1	A-P-ABORT parameter

Table 5/X.217 lists the A-P-ABORT parameter.

TABLE 5/X.217

A-P-ABORT parameter

Parameter name

Indication

Provider reason

P

Provider Reason: This parameter is as defined in Recommendation X.216.

9.4.2	A-P-ABORT service procedure

When the ACSE service-provider detects an error reported by the underlying presentation-service, it issues A-P-ABORT indication primitives to acceptors in both AEs. The association is abnormally released. Requestors in both AEs cannot issue any further primitives for the association.

10	Sequencing information

This clause defines the interaction among the ACSE service procedures for a particular association.

10.1	A-ASSOCIATE

10.1.1	Type of service

A-ASSOCIATE is a confirmed service.

10.1.2	Usage restrictions

The A-ASSOCIATE service is not used on an established association.

10.1.3	Disrupted service procedures

The A-ASSOCIATE service procedure does not disrupt any other service procedure.

10.1.4	Disrupting service procedures

The A-ASSOCIATE service procedure is disrupted by the A-ABORT service procedures.

10.1.5	Collisions

An A-ASSOCIATE service procedure collision results when requestors in both AEs simultaneously issue an A-ASSOCIATE request primitive for each other. Both ACSE service-users are issued A-ASSOCIATION indication primitives which represent distinct associations. Both can choose to accept or reject the indicated association by issuing an A-ASSOCIATE response primitive with the appropriate value for its Result parameter. This will result in the establishment of none, one or two associations.

Note - If an AE has several concurrent associations, a local mechanism is needed to distinguish between them.

10.2	A-RELEASE

10.2.1	Type of service

A-RELEASE is a confirmed service.

10.2.2	Usage restrictions

The A-RELEASE service is only used on an established association.

10.2.3	Disrupted service procedures

The A-RELEASE service procedure does not disrupt any other service procedure, except that an A-ABORT indication is suppressed following issuance of an A-RELEASE response, and that an A-P-ABORT indication is suppressed following issuance of an A-RELEASE response or confirm.

10.2.4	Disrupting service procedures

The A-RELEASE service procedure is disrupted by the A-ABORT or A-P-ABORT service procedures.

10.2.5	Collisions

An A-RELEASE service procedure collision results when requestors in both AEs simultaneously issue an A-RELEASE request primitive. The processing of A-RELEASE service procedure collisions is described in S 9.2.2. 10.2.6 Further sequencing information The use of the A-RELEASE service is subject to the constraints on the S-RELEASE service defined in Recommendation X.215 (see S 8.3).

10.3	A-ABORT

10.3.1	Type of service

A-ABORT is a non-confirmed service.

10.3.2	Usage restrictions

The A-ABORT service has effect only when used on an association in the process of establishment, on an established association, or on an association in the process of being released.

10.3.3	Disrupted service procedures

The A-ABORT service procedure disrupts the A-ASSOCIATE, A-RELEASE and A-P-ABORT service procedures.

10.3.4	Disrupting service procedures

The A-ABORT service procedure is disrupted by the A-P-ABORT service procedure and by the issuance of an A-RELEASE response.

10.3.5	Collisions

An A-ABORT service procedure collision results when requestors in both AEs simultaneously issue the A-ABORT request primitive. The collision processing is governed by the P-U-ABORT service defined in Recommendation X.216. In this situation, neither A-ABORT indication primitive is issued.

10.3.6	Further sequencing information

Any use of the A-ABORT service results in the abnormal release of the association, or the abnormal termination of the A-ASSOCIATE service procedure or the A-RELEASE service procedure with possible loss of information.

10.4	A-P-ABORT

10.4.1	Type of service

A-P-ABORT is a provider-initiated service.

10.4.2	Usage restrictions

No restrictions are placed on the occurrence of this service.

10.4.3	Disrupted service procedures

The A-P-ABORT service procedure disrupts all other service procedures.

10.4.4	Disrupting service procedures

The A-P-ABORT service procedure is disrupted by the A-ABORT service procedure and by the issuance of an A-RELEASE response or confirm.

ANNEX A

(to Recommendation X.217)

Usage of ACSE services to achieve compatibility with CCITT Recommendation X.410-1984, and the basic facilities of the 1988 Message Handling series of CCITT Recommendations

A.1	Compatibility requirements

Recommendation X.410, which was adopted by CCITT in 1984, has been used in a number of Recommendation X.400 Message Handling products available or under development.

It is essential that the systems following Recommendation X.410-1984 be able to interwork with OSI systems. This principle has been guiding the development of the OSI ACSE and Presentation service and protocol, which has been conducted in very close cooperation between CCITT and ISO.

This Annex shows how the ACSE service is to be used to achieve compatibility with Recommendation X.410-1984, and to support the basic facilities of the 1988 Message Handling series of CCITT Recommendations.

Reference is also made to a companion Annex attached to the OSI Presentation service (Recommendation X.216) which shows how OSI Presentation service is to be used in order to achieve compatibility with Recommendation X.410-1984.

A.2	Principles for ensuring compatibility

The ACSE X.410-1984 mode of operation can be activated resulting in full encoding alignment with X.410-1984 at the session user data level. Its effect is to suppress the generation of explicit ACSE APDUs while maintaining an active ACPM state machine (see Recommendation X.227, Annex B).

The layered structure of both protocols, which conforms with the OSI Reference Model, makes it possible to distinguish the Presentation Layer functions and parameters from those of the Application Layer. Based on this layering, the following principles are used to ensure the required compatibility:

a)	The functions and the corresponding protocol elements of X.410-1984 which belong to the Presentation Layer are integrated into the OSI Presentation protocol, which remains consistent and satisfies the requirements of the whole set of OSI applications.

b)	The additional functions and protocol elements of X.410-1984 are placed in the Application Layer. They are generated by the Reliable Transfer Service Element (RTSE, see Recommendations X.218 and X.228 also Recommendation X.410-1984). They are passed transparently by the ACSE service-provider during association establishment and release by making direct use of the Presentation services.

A.3	Usage of Association Control services to ensure compatibility with Recommendation X.410-1984

The following Association Control services are used:

A-ASSOCIATE

A-RELEASE

A-ABORT

A-P-ABORT

The use of these services is explained in SS A.3.1-A.3.5.

Note - RTORQ, RTOAC, RTORJ and RTAB are names given to APDUs generated by the RTSE protocol machine.

A.3.1	A-ASSOCIATE

An association is established and the X.410-1984 mode of ACSE operation is activated with the following combination of A-ASSOCIATE service parameters:

a)	Mode parameter must be set to X.410-1984½ on request primitive;

b)	Presentation Requirements parameter must specify the kernel.

c)	Session Requirements parameter must be set according to X.410-1984; and

d)	User Information:

1)	On the request and indication primitives, this parameter must contain an RTORQ APDU.

2)	On the response and confirmation primitives, it must contain a RTOAC APDU if the association has been accepted, or a RTORJ APDU if the association has been rejected.

3)	If the ACSE service-provider has rejected the request, then this parameter is not used.

All other A-ASSOCIATE parameters must be absent or as defined by the Presentation Service and its Annex concerning its use for X.410-1984 compatibility (Recommendation X.216).

Following the occurrence of an A-ABORT or A-P-ABORT service event, the initiating RTSE may use the A-ASSOCIATE service an implementation dependent number of times to attempt recovery. This use of the service has all parameters absent except for Presentation User Data which must contain the recovery data from the RT-OPEN service.

A.3.2	A-RELEASE

The association is released by the use of this service with only the Result parameter present. The rules governing the use of A-RELEASE are as in the main body of this document and are identical to those for P-RELEASE.

A.3.3	A-ABORT

Either ACSE service-user may signal to its peer that it has a problem and attempt to force the release of an association by using A-ABORT service with all parameters absent except for the Presentation User data parameter, which must contain an RTAB APDU. The association is released, and the initiating RTSE may use the A-ASSOCIATE service to attempt to obtain a new association over which it can execute its recovery procedures.

A.3.4	A-P-ABORT

Either ACSE service-provider may signal that it has a problem (internally or with the services which underlie it) to its peer and force the release of an association by using the A-P-ABORT service as defined in Recommendation X.216. The association is released, and the initiating RTSE may use the A-ASSOCIATE service to attempt to obtain a new association over which it can execute its recovery procedures.

A.3.5	State Table

The state table which governs the operation of the ACSE in X.410-1984 mode is given in Annex B of Recommendation X.227.

APPENDIX I

(to Recommendation X.217)

Differences between Recommendation X.217 and ISO International Standard 8649

I.1	Recommendation X.217 and ISO 8649 are technically aligned, with the following minor exceptions:

I.2	In S 10 on Sequencing Information this Recommendation states that the A-ABORT and A-P-ABORT services are mutually disruptive, when they collide (see SS 10.3.3 and 10.4.4). ISO 8649 states that A-P-ABORT cannot be disrupted (see SS 10.3.3 and 10.4.4).

I.3	In S 10 on Sequencing Information this Recommendation states that an A-ABORT indication is suppressed following issuance of an A-RELEASE response, and that an A-P-ABORT indication is suppressed following issuance of an A-RELEASE response or confirm (see SS 10.2.3, 10.3.4 and 10.4.4). ISO 8649 states that the A-RELEASE service procedure does not disrupt any other service procedure (see SS 10.2.3, 10.3.4 and 10.4.4).

I.4	This Recommendation contains an Annex A, which has not been included in ISO 8649. Annex A shows how the OSI Association Control service is to be used in order to achieve compatibility with Recommendation X.410-1984 and to support the basic facilities of the 1988 message handling services of CCITT Recommendations (the X.400 series).

I.5	There is no equivalent of this Appendix I in ISO 8649.