Collection of Internet

home *** CD-ROM | disk | FTP | other *** search

/ Collection of Internet / Collection of Internet.iso / protocol / standard / iso / iso8650_.asc < prev next >

Wrap

Text File | 1993-07-14 | 67.5 KB | 1,230 lines

Recommendation X.227 ASSOCIATION CONTROL PROTOCOL SPECIFICATION FOR OPEN SYSTEMS INTERCONNECTION FOR CCITT APPLICATIONS 1 (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.208 specifies Abstract Syntax Notation One (ASN.1) for the specification of the abstract syntax of protocols; (c) that Recommendation X.209 specifies the basic encoding rules for Abstract Syntax Notation One; (d) that Recommendation X.210 defines the Open Systems Interconnection (OSI) layer service definition conventions; (e) that Recommendation X.215 defines the Session service definition for Open Systems Interconnection for CCITT applications; (f) that Recommendation X.216 defines the Presentation service definition of Open Systems Interconnection for CCITT applications; (g) that Recommendation X.217 defines Association Control service definition for Open Systems Interconnection for CCITT applications; (h) that Recommendation X.220 specifies the use of X.200 series protocols in CCITT applications; (i) that Recommendation X.410-1984 specifies the protocol for Remote Operation and Reliable Transfer Server for Message Handling Systems; and (j) that there is a need for common Association Control support for various applications, unanimously declares that this Recommendation defines the Association Control specification 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 3.6 Association Control protocol specification definitions 4 Symbols and abbreviations 4.1 Data units 4.2 Types of application-protocol-data-units 4.3 Other abbreviations 5 Conventions 6 Overview of the protocol 6.1 Service provision 6.2 Use of the presentation-service 6.3 Relationship to the session-service 6.4 Model 7 Elements of procedure 7.1 Association establishment 7.2 Normal release of an association 7.3 Abnormal release of an association 7.4 Rules for extensibility 8 Mapping to the presentation-service 8.1 Association establishment (normal mode) 8.2 Normal release of an association (normal mode) 8.3 Abnormal release of an association (normal mode) 1 Recommendation X.227 and ISO 8650 [Information processing systems - Open Systems Interconnection - Protocol specification for the Association Control Service Element] were developed in close collaboration and are technically aligned, except for the differences noted in Appendix I. Rec. X.227 PAGE1 8.4 Association establishment (X.410-1984 mode) 8.5 Normal release of an association (X.410-1984 mode) 8.6 Abnormal release of an association (X.410-1984 mode) 9 Structure and encoding of ACSE APDUs 10 Conformance 10.1 Statement requirements 10.2 Static requirements 10.3 Dynamic requirements Annex A - ACPM state table for normal mode of operation A.1 General A.2 Conventions A.3 Actions to be taken by the ACPM A.3.1 Invalid intersections A.3.2 Valid intersections A.4 Relationship to Presentation and other ASEs Annex B - ACPM state table for X.410-1984 mode of operation B.1 General B.2 Conventions B.3 Actions to be taken by the ACPM B.3.1 Invalid intersections B.3.2 Valid intersections B.4 Relationship to Presentation and other ASEs Appendix I - Differences between Recommenation X.227 and ISO International Standard 8650 Appendix II - Summary of Assigned Object Identifier Values 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 interconnection standards, 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 specifies the protoc l for the application-service- element for application-association control: the Association Control Service Element (ACSE). The ACSE provides services for establishing and releasing application-associations. These services are intended to be applicable to a wide range of application-process communication requirements. 0.4 This Recommendation includes two annexes which describe the protocol machine of ACSE in terms of a state table for normal mode of operation and for X.410-1984 mode of operation. This protocol machine is referred to as the Association Control Protocol Machine (ACPM). 0.5 The protocol defined in this Recommendation is also governed by the use of the presentation-service (X.216) and the session-service (X.215). 0.6 Quality of Services (QOS) is a parameter of the A-ASSOCIATE service. Work is still in progress to provide an integrated treatment of QOS across all of the 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 The procedures defined in this Recommendation are applicable to instances of communication between systems which wish to interconnect in an open systems interconnection environment. This Recommendation specifies: a) procedures for the transfer of information relating to the application association control between application entities; and b) the abstract syntax for the representation of the ACSE APDUs. The ACSE procedures are defined in terms of: PAGE22 Rec. X.227 a) the interactions between peer ACSE protocol machines through the use of presentation-services; and b) the interaction between an ACSE protocol machine and its service user. This Recommendation also specifies conformance requirements for systems implementing these procedures. It does not contain tests which can be used to demonstrate conformance. 2 References Recommendation X.200 - Reference Model of Open Systems Interconnection for CCITT applications (see also ISO 7498-1). Recommendation X.208 - Specification of Abstract Syntax Notation One (see also ISO 8824). Recommendation X.209 - Basic Encoding Rules for Abstract Syntax Notation One (see also ISO 8825). Recommendation X.210 - OSI Layer Service Definition Conventions (see also ISO TR 8509). 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.217 - Association Control service definition for Open Systems Interconnection for CCITT applications (see also ISO 8649). Recommendation X.225 - Session protocol specification for Open Systems Interconnection for CCITT applications (see also ISO 8327 and ISO 8327 Addendum 2). Recommendation X.410 - CCITT Recommendation X.410: Message Handling Systems: Remote Operations and Reliable Transfer Server (1984). 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-service protocol; and k) session-connection. 3.2 Naming and addressing definitions This Recommendation makes use of the following terms defined n ISO 7498- 3: a) application-process title; b) application-entity qualifier; c) application-entity title2 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; 2 As defined in ISO 7498-3, an application-entity title is composed of an application- process title and an application-entity qualifier. The ACSE protocol provides for the transfer of an application-entity title value by the transfer of its component values. Rec. X.227 PAGE1 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 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 This Recommendation makes use of the following terms defined in X.217. a) application-association; association; b) application context; c) Association Control Service Element; d) ACSE service-user; e) ACSE service-provider; f ) requestor; g) acceptor; h) association-initiator; i) association-responder; j ) normal mode; k) X.410-1984 mode; and j) disrupt. 3.6 Association Control protocol specification definitions The following terms are introduced in this Recommendation. 3.6.1 Association Control Protocol Machine The protocol machine for the Association Control Service Element specified in this Recommendation. 3.6.2 requesting Association Control Protocol Machine The Association Control Protocol Machine whose service-user is the requestor of a particular Association Control Service Element service. 3.6.3 accepting Association Control Protocol Machine The Association Control Protocol Machine whose service-user is the acceptor for a particular Association Control Service Element service. 4 Symbols and abbreviations 4.1 Data units APDU application-protocol-data-unit 4.2 Types of application-protocol-data-units The following abbreviations have been giv n to the application-protocol- data-units defined in this Recommendation. AARQ A-ASSOCIATE-REQUEST application-protocol-data-unit AARE A-ASSOCIATE-REQUEST application-protocol-data-unit RLRQ A-RELEASE-REQUEST application-protocol-data-unit RLRE A-RELEASE-RESPONSE application-protocol-data-unit ABRT A-ABORT application-protocol-data-unit 4.3 Other abbreviations The following abbreviations are used in this Recommendation: ACPM Association Control Protocol Machine ACSE Association Control Service Element AE application-entity AP application-process APCI application-protocol-control-information ASE application-service-element ASN.1 Abstract Syntax Notation One OSI Open Systems Interconnection QOS quality of service 5 Conventions PAGE22 Rec. X.227 5.1 This Recommendation employs a tabular presentation of its APDU fields. In S 7, tables are presented for each ACSE APDU. Each field is summarized using the following notation: M presence is mandatory O presence is ACPM option U presence is ACSE service-user option req source is related request primitive ind sink is related indication primitive rsp source is related response primitive cnf sink is related confirm primitive sp source or sink is the ACPM 5.2 The structure of each ACSE SPDU is specified in S 9 using the abstract syntax notation of ASN.1 (X.208). 6 Overview of the protocol 6.1 Service provision The protocol specified in this Recommendation provides the services defined in X.217. These services are listed in Table 1/X.227. For a particular association, the ACSE services operate either in the normal mode or in the X.410 1984 mode. The mode of operation is determined by the Mode paramet r on the A- ASSOCIATE request primitive. TABLE 1/X.227 Service summary Service Type A-ASSOCIATE Confirmed A-RELEASE Confirmed A-ABORT Non-confirmed A-P-ABORT Provider-initiated 6.2 Use of the presentation-service 6.2.1 ACE's use of the presentation-service (X.216) is determined by ACSE's mode of operation for an association as specified below: a) ACSE normal mode: The ACPM uses the normal mo e of the presentation- service. The ACPM uses the presentation-service Kernel functional unit to exchange its APCI and, optionally, ACSE service-user information (i.e., ACSE APDUs) with its peer. The use of additional presentation-service functional units is an ACSE service-user choice. This choice does not affect the operation of the ACPM. b) ACSE X.410-1984 mode: The ACPM uses the X.410-1984 mode of the presentation-service. Only the Kernel functional unit is available when using the presentation-service X.410-1984 mode. In this mode, the ACPM does not exchange its own APCI with its peer. It simply passes through information supplied to it by the ACSE service-user or by the presentation-service. 6.2.2 This Recommendation assumes that the ACPM s the sole user of the P- CONNECT, P-RELEASE, P-U-ABORT, and P-P-ABORT services. The ACSE neither uses nor constrains the use of any other presentation service. 6.2.3 When supported by version 1 of the session-protocol (X.225), the presentation-service is subject to length restrictions for its user-data parameters. This Recommendation assumes that a local mechanism detects violations of these constraints and makes the ACSE service-user aware of them. An encoding optimization is specified for A-ABORT to mitigate this problem (see S 7.3.3.1). 6.3 Relationship to the session-service 6.3.1 The functional units of the session-service (X.215) required for the session-connection which support the presentation-connection (that in turn supports the association) are determined by the A-ASSOCIATE service requestor and acceptor. They accomplish this using the Session Requirements parameter on the A ASSOCIATE primitives. 6.3.2 The rules of the session-service affect the operation of the ACPM and its service-user. The ACSE service-user must be aware of these constraints. This Recommendation assumes that a local mechanism enforces them. Some examples of session-service constraints which affect the ACSE service-user are: a) the availability of negotiated release; and b) the possibility of release collisions. 6.4 Model 6.4.1 The Association control Protocol Machine (ACPM) is modeled as a finite state machine whose specification is given in this Recommendation. The ACPM Rec. X.227 PAGE1 communicates with its service-user by means of the ACSE service primitives defined in X.217. The ACPM communicates with its presentation service-provider by means of the presentation services defined in X.216. 6.4.2 The ACPM is driven by the receipt of input events from i s ACSE service- user and from its presentation service-provider for the underlyi g presentation- connection which supports the association. The input events from the ACSE service user are ACSE request and response primitives. The input events from its presentation service-provider are presentation indication and confirm primitives. 6.4.3 The ACPM responds to input events by issuing output events to its presentation-service-provider and to its ACSE service-user. The output events to its presentation-service-provider are presentation request and response primitives. The output events to its ACSE service-user are ACSE indication and confirm primitives. 6.4.4 The receipt of an input event, the generation of dependent actions, and the resultant output event are considered to be an indivisible action. 6.4.5 During the establishment of an association between two AEs, the existence of invocations of both the requesting and responding AEs is presumed. How they are created is outside of the scope of this Recommendation. 6.4.6 A new invocation of an ACPM is employed upon the receipt of an A-ASSOCIATE request primitive or a P-CONNECT indication primitive. Each such invocation controls exactly one association. Note - Each association may be identified in an end system by a local mechanism so that the ACSE service-user and the ACPM can refer to the association. 6.4.7 The ACPM is modeled to operate in either one of two modes for a given association: the normal mode, and the X.410-1984 mode, as specified below. a) When operating in the normal mode, an APCM communicates with its peer ACPM in support of an association by transferring ACSE application protocol data u s (APDUs) defined in S 93. An ACSE APDU is transferred as a presentation data value in the User Data parameter of the presentati n primitive used on the underlying presentation- connection. b) When operating in the X.410-1984 mode, an ACPM does not transfer ACSE APDUs with its peer. In this situation, the sending and receiving of presentation primitives are in themselves significant protocol events. 7 Elements of procedure The ACSE protocol consists of the following procedures: a) association establishment; b) normal release of an association; and c) abnormal release of an association. In this clause, a summary of each of these elements of procedure is presented. This consists of a summary of the relevant APDUs, and a high-level overview of the relationship between the ACSE services, the APDUs involved, and the presentation service which is used. The use of the parameters of the presentation primitives are described in S 8. A detailed specification of the ACSE APDUs using the ASN.1 notation (X.208) is described in S 9. Annex A specifies the state table for the ACPM for normal mode of operation. Annex B specifies the state table for the ACPM for X.410-1984 mode of operation. 7.1 Association establishment 7.1.1 Purpose The association establishment procedure is used to establish an association between two AEs. It supports the A-ASSOCIATE service. 7.1.2 APDUs used The association establishment procedure uses the A-ASSOCIATE-REQUEST (AARQ) and the A-ASSOCIATE-RESPONSE (AARE) APDUs. The fields of the AARQ PDU are listed in Table 2/X.227. The fields of the AARE APDU are listed in Table 3/X.227. TABLE 2/X.227 AARQ APDU fields Field name Presence Source Sink Protocol Version O sp sp Application Context Name M req ind Calling AP Title U req ind Calling AE Qualifier U req ind Calling AP Invocation- U req ind identifier 3 This is true with one exception. If the association is supported by version 1 of the session-protocol (X.225), the requesting ACPM does not pass ACSE APCI as user data on a P U-ABORT request primitive. The absence of ACSE APCI in this situation does not imply that the association is operating in the X.410-1984 mode (see SS 6.4.6 and 7.3.3.1). PAGE22 Rec. X.227 Calling AE Invocation- U req ind identifier Called AP Title U req ind Called AE Qualifier U req ind Called AP Invocation- U req ind identifier Called AE Invocation- U req ind identifier Implementation information O sp sp User information U req ind TABLE 3/X.227 AARE APDU fields Field name Presence Source Rec. X.227 PAGE1 Sink Protocol Version O sp sp Application Context Name M rsp cnf Responding AP Title U rsp cnf Responding AE Qualifier U rsp cnf Responding AP Invocation- U rsp cnf identifier Responding AE Invocation- U rsp cnf identifier Result M rsp/sp cnf Result Source - Diagnostic M rsp/sp cnf PAGE22 Rec. X.227 Implementation Information O sp sp User Information U rsp cnf 7.1.3 Association establishment procedure This procedure is driven by the following events: a) an A-ASSOCIATE request primitive from the requestor; b) an AARQ APDU as user data on a P-CONNECT indication primitive; c) an A-ASSOCIATE response primitive from the acceptor; and d) a P-CONNECT confirm primitive (that may or may not contain an AARE APDU). 7.1.3.1 A-ASSOCIATE request primitive 7.1.3.1.1 The requesting ACPM forms an AARQ APDU from parameter values of t e A- ASSOCIATE request primitive and optionally, the Protocol Version and implementation information. It issues a P-CONNECT request primitive also using information from the A-ASSOCIATE request primitive. The User Data parameter of the P-CONNECT request primitive contains the AARQ APDU. 7.1.3.1.2 The requesting ACPM waits for a primitive from the presentation service provider and does not accept any other primitive from the requestor other than an A-ABORT request primitive. 7.1.3.2 AARQ APDU 7.1.3.2.1 The accepting ACPM receives an AARQ APDU from its peer as user data on a P-CONNECT indication primitive. 7.1.3.2.2 The ACPM determines if the AARQ ADPU is acceptable based on the rules for extensibility (see S 7.4). If the AARQ APDU is not acceptable, a protocol error results (see S 7.3.3.4). The association establishment procedure is disrupted. An A-ASSOCIATE indication primitive is not issued. The association is not established. 7.1.3.2.3 The ACPM next inspects the value of the Protocol Version field 4of t AARQ APDU. If the ACPM does not support a common protocol version, it forms an AARE APDU with the following assigned fields: a) Protocol Version field (optional) with the value which indicates the protocol version(s) which it could support (see S 7.1.5.1); b) Application Context Name field with the same value as on the AARQ APDU; c) Result field with the value ╗rejected (permanent)½; and d) Result Source-Diagnostic field with the values ╗ACSE service-provider½ and ╗not common ACSE version½. In this case, the ACPM sends the AARE APDU as user data on a P-CONNECT response primitive with a Result parameter which has the value ╗user rejection½. The ACPM does not issue an A-ASSOCIATE indication primitive. The association is not established. 7.1.3.2.4 If the P-CONNECT indication primitive and its AARQ APDU are acceptable, the ACPM issues an A-ASSOCIATE indicati n primitive to the acceptor. The A- ASSOCIATE indication primitive parameters are derived from the AARQ APDU and the P-CONNECT indication primitive. The ACPM waits for a primitive from the acceptor. 7.1.3.3 A-ASSOCIATE response primitive 7.1.3.3.1 When the accepting ACPM receives the A-ASSOCIATE response primitive, the Result parameter specifies whether the service-user has accepted or rejected the association. The ACPM forms an AARE APDU using the A-ASSOCIATE response primitive parameters. The ACPM sets the Result Source-Diagnostic field to ╗ACSE service-user½ and the value derived from the Diagnostic parameter of the response primitive. The AARE APDU is sent as the User Data parameter on the P-CONNECT response primitive. 7.1.3.3.2 If the acceptor accepted the association resquest, the Result parameter on the related P-CONNECT response primitive specifies ╗acceptance½, and the Result field of the outgoing AARE APDU specifies ╗accepted½. The association is established. 7.1.3.3.3 If the acceptor rejected the association request, the Result parameter on the related P-CONNECT response primitive specifies ╗user-rejection½, and the Result field of the AARE APDU contains the appropriate rejection value. The association is not established. 7.1.3.4 P-CONNECT confirm primitive 7.1.3.4.1 The requesting ACPM receives a P-CONNECT confirm primitive. The following situations are possible: a) the association has been accepted; 4 If the Protocol Version field is not present in the AARQ APDU, version 1 is assumed Rec. X.227 PAGE1 b) the accepting ACPM or the acceptor has rejected the association; or c) the representation service-provider has rejected the related presentation connection. 7.1.3.4.2 If the association was accepted, the P-CONNECT confirm primitive Result parameter specifies ╗acceptance½. The User Data parameter contains an AARE APDU. The Result field of the AARE APDU specifies ╗accepted½. The requesting ACPM issues an A-ASSOCIATE confirm primitive to the requestor derived from parameters from the P-CONNECT confirm primitive and the AARE APDU. The A-ASSOCIATE confirm primitive Result parameter specifies ╗accepted½. The association is established. 7.1.3.4.3 If the association was rejected by either the accepting ACPM or by the acceptor, the related P-CONNECT confirm primitive Result parameter specifies ╗user-rejection½. The User Data parameter contains an AARE APDU. 7.1.3.4.4 The requesting ACPM issues an A-ASSOCIATE confirm primitive to the requestor derived from prameters from the P-CONNECT confirm primitive and the AARE APDU. The A-ASSOCIATE confirm primitive Result parameter indicates ╗rejected (transient)½ or ╗rejected (permanent)½. The Result Source parameter indicates ╗ACSE service-user½ or ╗ACSE service-provider½. The association is not established. 7.1.3.4.5 If the presentation-connection was rejected by the presentation service provider, the P-CONNECT confirm primitive Result paramet r specifies ╗provider- rejection½. In this situation, the User Data field is not used. The requesting ACPM issues an A-ASSOCIATE confirm primitive with the Result parameter indicating ╗rejected (permanent)½. The Result Source parameter indicates ╗presentation service-provider½5 The association is not established. 7.1.4 Use of the AARQ APDU fields The AARQ APDU fields are used by the requesting and accepting ACPMs as specified below. 7.1.4.1 Protocol Version For the requesting ACPM: The value assigned to this field is determined within the implementation of the ACPM. It is a variable length bit string where each bit that is set to one indicates the version of ACSE protocol that this ACPM supports. Bit 0 represents version 1; bit 1 represents version 2; etc.. Multiple bits may be set indicating support of multiple versions. No trailing bits higher than the highest version of this Recommendation which the requesting ACPM supports are included. That is, the last bit of the string is set to one. For the accepting ACPM: The ACPM ignores trailing bits of this field which are higher than the one indicating the latest version of this Recommendation which it supports. 7.1.4.2 Application Context Name For the requesting ACPM: This value is determined by the value of the Application Context Name parameter of the A-ASSOCIATE request primitive. For the accepting ACPM: This value is used to determine the value of the Application Context Name parameter of the A-ASSOCIATE indication primitive, if issued. 7.1.4.3 Calling AP Title For the requesting ACPM: This value is determined by the value of the Calling AP Title parameter of the A-ASSOCIATE request primitive. For the accepting ACPM: This value is used to determine the value of the Calling AP Title parameter of the A-ASSOCIATE indication primitive, if issued. 7.1.4.4 Calling AE Qualifier For the requesting ACPM: This value is determined by the value of the Calling AE Qualifier parameter of the A-ASSOCIATE request primitive. For the accepting ACPM: This value is used to determine the value of the Calling AE Qualifier parameter of the A-ASSOCIATE indication primitive, if issued. 7.1.4.5 Calling AP Invocation-identifier For the requesting ACPM: This value is determined by the value of the Calling AP Invocation-identifier parameter of the A-ASSOCIATE request primitive. For the accepting ACPM: This value is used to derive the value of the 5 The presentation-service (Rec. X.216) currently does not define a Diagnostic parameter on the P-CONNECT response. However, work is still in progress to provide an integrated treatment of the ╗result½ related parameters across all layers of the OSI Reference Model. As a consequence, a change may be made to this Recommendation at a later time that reflects further developments and integration. PAGE22 Rec. X.227 Calling AP Invocation-identifier parameter of the A-ASSOCIATE indication primitive, if issued. 7.1.4.6 Calling AE Invocation-identifier For the requesting ACPM: This value is determined by the value of the Calling AE Invocation-identifier parameter of the A-ASSOCIATE request primitive. For the accepting ACPM: This value is used to derive the value of the Calling AE Invocation-identifier parameter of the A-ASSOCIATE indication primitive, if issued. 7.1.4.7 Called AP Title For the requesting ACPM: This value is determined by the value of the Called AP Title parameter of the A-ASSOCIATE request primitive. For the accepting ACPM: This value is used to determine the value of the Called AP Title parameter of the A-ASSOCIATE indication primitive, if issued. 7.1.4.8 Called AE Qualifier For the requesting ACPM: This value is determined by the value of the Called AE Qualifier parameter of the A-ASSOCIATE request primitive. For the accepting ACPM: This value is used to determine the value of the Called AE Qualifier parameter of the A-ASSOCIATE indication primitive, if issued. 7.1.4.9 Called AP invocation-identifier For the requesting ACPM: This value is determined by the value of the Called AP Invocation-identifier parameter of the A-ASSOCIATE request primitive. For the accepting ACPM: This value is used to determine the value of the Called AP Invocation-identifier parameter of the A-ASSOCIATE indication primitive, if issued. 7.1.4.10 Called AE Invocation-identifier For the requesting ACPM: This value is determined by the value of the Called AE Invocation-identifier parameter of the A-ASSOCIATE request primitive. For the accepting ACPM: This value is determined by the value of the Called AE Invocation-identifier parameter of the A-ASSOCIATE indication primitive, if issued. 7.1.3.11 Implementation Information For the requesting ACPM: The value assigned to this field is determined within the implementation of the ACPM. It contains information specific to the individual implementation of that ACPM. It is not used in negotiation. For the accepting ACPM: This field does not affect the operation of the ACPM. Any use depends on a common understanding between the requesting and accepting ACPMs. 7.1.4.12 User Information For the requesting ACPM: This value is determined by the value of the User Information parameter of the A-ASSOCIATE request primitive. For the accepting ACPM: This value is used to determine the value of the User Information parameter of the A-ASSOCIATE indication primitive, if issued. 7.1.5 Use of the AARE APDU fields The AARE APDU fields are used by the accepting and requesting ACPMs as specified below. 7.1.5.1 Protocol Version For the accepting ACPM: The value of this field assigned by the ACPM depends on whether the association request is accepted or rejected by the ACPM and the acceptor as specified below. a) If the association is accepted, the value assigned by the ACPM is a variable length bit string which indicates the protocol version selected by the ACPM from those proposed in the AARQ APDU. Only the bit indicating the version selected is set to one. That bit is the last bit in the string. b) If the association is rejected, the value assigned by the ACPM is a variable length bit string which indicates the protocol version(s) of this Recommendation which could be supported by the ACPM. For the requesting ACPM: The use of the value in this field depends on whether the association request is accepted or rejected. a) If the association is accepted, this value defines the protocol version of this Recommendation to be used for this association. b) If the association is rejected, the use of this value is a local option. 7.1.5.2 Application Context Name For the accepting ACPM: This value determined by the value of the Rec. X.227 PAGE1 Application Context Name parameter of the A-ASSOCIATE response primitive. For the requesting ACPM: This value is used to determine the value of the Application Context Name parameter of the A-ASSOCIATE confirm primitive. 7.1.5.3 Responding AP Title For the accepting ACPM: This value is determined by the value of the Responding AP Title parameter of the A-ASSOCIATE response primitive. For the requesting ACPM: This value is used to determine the value of the Responding AP Title parameter of the A-ASSOCIATE confirm primitive, if issued. 7.1.5.4 Responding AE Qualifier For the accepting ACPM: This value is determined by the value of the Responding AE Qualifier parameter of the A-ASSOCIATE response primitive. For the requesting ACPM: This value is used to determine the value of the Responding AE Qualifier parameter of the A-ASSOCIATE confirm primitive, if issued. 7.1.5.5 Responding AP Invocation-Identifier For the accepting ACPM: This value is determined by the value of the Responding AP Invocation- identifier parameter of the A-ASSOCIATE response primitive. For the requesting ACPM: This value is used to determine the value of the Responding AP Invocation-identifier parameter of the A-ASSOCIATE confirm primitive, if issued. 7.1.5.6 Responding AE Invocation-identifier For the accepting ACPM: This value is determined by the value of the Responding AE Invocation- identifier parameter of the A-ASSOCIATE response primitive. For the requesting ACPM: This value is used to determine the value of the Responding AE Invocation-identifier parameter of the A-ASSOCIATE confirm primitive, if issued. 7.1.5.7 Result For the accepting ACPM: The value is determined by the ACPM or by the acceptor as specified below. a) If the AARQ APDU is rejected by the ACPM (i.e., an A-ASSOCIATE indication primitive is not issued to the acceptor), the value of ╗rejected (permanent)½ or ╗rejected (transient)½ is assigned by the ACPM. b) Otherwise, the value is determined by the Result paramet r of the A- ASSOCIATE response primitive. For the requesting ACPM: This value is used to determine the value of the Result parameter of the A-ASSOCIATE confirm primitive. 7.1.5.8 Result Source-Diagnostic This field contains both the Result Source value and the Diagnostic value. 7.1.5.8.1 Result Source value For the accepting ACPM: This value is assigned by the ACPM as specified below. a) If the AARQ APDU is rejected by the ACPM (i.e., an A-ASSOCIATE indication primitive is not issued to the acceptor), it assigns the value ╗ACSE service-provider½. b) Otherwise, the ACPM assigns the value ╗ACSE service-user½. For the requesting ACPM: This value is used to determine the value of the Result Source parameter of the A-ASSOCIATE confirm primitive. 7.1.5.8.2 Diagnostic value For the accepting ACPM: This value is determined by the ACPM or by the acceptor as specified below. a) If the AARQ APDU is rejected by the ACPM (i.e., an A-ASSOCIATE indication primitive is not issued to the acceptor), the appropriate value is assigned by the ACPM. b) Otherwise, the value is determined by the value of the Diagnostic parameter of the A-ASSOCIATE response primitive. If the Diagnostic parameter is not included on the response primitive, the ACPM assigns the value of ╗null½. For the requesting ACPM: This value is used to determine the value of the Diagnostic parameter of the A-ASSOCIATE confirm primitive, unless it has the value of ╗null½. In this case, a Diagnostic value is not included. 7.1.5.9 Implementation Information PAGE22 Rec. X.227 For the accepting ACPM: The value assigned to this field is determined within the implementation of the ACPM. It contains information specific to the individual implementation of that ACPM. It is not used in negotiation. For the requesting ACPM: This field does not affect the operation of the ACPM. Any use depends on a common understanding between the accepting and requesting ACPMs. 7.1.5.10 User Information For the accepting ACPM: This value is determined by the value of the User Information parameter of the A-ASSOCIATE response primitive. For the requesting ACPM: This value is used to determine the value of the User Information parameter of the A-ASSOCIATE confirm primitive. 7.1.6 Collisions and interactions 7.1.6.1 A-ASSOCIATE service For a given ACPM, an A-ASSOCIATE collision cannot occur (see S 6.4.6). For a given AE, two distinct ACPMs would be involved which represent the processing for two distinct associations: a) an ACPM which processes the initial A-ASSOCIATE request primitive which results in the sending of an AARQ as user data on a P-CONNECT request primitive; and b) an ACPM which processes the subsequently received AARQ APDU as user data on a P-CONNECT indication primitive. 7.1.6.2 A-ABORT, P-U-ABORT, or P-P-ABORT service If an ACPM receives and A-ABORT request primitive, a P-U-ABORT indication primitive, or a P-P-ABORT indication primitive, it discontinues the normal association establishment procedure, and instead follows the abnormal release procedure. 7.2 Normal release of an association 7.2.1 Purpose This procedure is used for the normal release of an association by an AE without loss of information in transit. It supports the A-RELEASE service. 7.2.2 APDUs used The normal release procedure uses the A-RELEASE-REQUEST (RLRQ) APDU and the A-RELEASE-RESPONSE (RLRE) APDU. The fields of the RLRQ APDU are listed in Table 4/X.227. The fields of the RLRE APDU are listed in Table 5/X.227. TABLE 4/X.227 RLRQ APDU fields Field name Presence Source Sink Reason U req ind User Information U req ind TABLE 5/X.227 RLRE APDU fields Field name Presence Source Sink Reason U rsp cnf User Information Rec. X.227 PAGE1 U rsp cnf 7.2.3 Normal release procedure This procedure is driven by the following events: a) an A-RELEASE request primitive from the requestor; b) an RLRQ APDU as user data on a P-RELEASE indication primitive; c) an A-RELEASE response primitive from the acceptor, or d) an RLRE APDU as user data on P-RELEASE confirm primitive. 7.2.3.1 A-RELEASE request primitive 7.2.3.1.1 When an A-RELEASE request primitive is received, the ACPM sends an RLRQ APDU as user data on a P-RELEASE request primitive using the parameters from the A-RELEASE request primitive. Note - The requestor is required to meet the presentation (and session) requirements in order to issue an A-RELEASE request primitive (see S 6.2 and 6.3). 7.2.3.1.2 The requesting ACPM now waits for a primitive from the presentation service-provider. It does not accept any primitives from the requestor other than an A-ABORT request primitive. 7.2.3.2 RLRQ APDU When the accepting ACPM receives the RLRQ APDU as user data on a P-RELEASE indication primitive, it issues an A-RELEASE indication primitive to the acceptor. It does not accept any ACSE primitives from its service-user other than an A-RELEASE response primitive or an A-ABORT request primitive. 7.2.3.3 A-RELEASE response primitive The Result parameter on the A-RELEASE response primitive specifies whether the acceptor accepts or rejects the release of the association. The accepting ACPM forms an RLRE APDU from the response primitive parameters. The RLRE APDU is sent as user data on a P-RELEASE response primitive. a) If the acceptor accepted the release, the Result paramet r of the P- RELEASE response primitive has a Result parameter value of ╗affirmative½. The association is released. b) If the acceptor rejected the release, the Result paramet r of the P- RELEASE response primitive has a Result parameter value of ╗negative½. The association continues. Note - To give a negative response, the acceptor is required to meet the related presentation (and session) requirements (see S 6.3). 7.2.3.4 RLRE APDU The requesting ACPM receives a P-RELEASE confirm primitive containing an RLRE APDU from its peer. The Result parameter on the P-RELEASE confirm primitive specifies either that the acceptor agrees or disagrees that the association may be released. The requesting ACPM forms an A-RELEASE confirm primitive from the RLRE APDU fields. a) If the Result parameter on the P-RELEASE confirm primitive specifies ╗affirmative½, the association is released. b) If the Result parameter on the P-RELEASE confirm primitive specifies ╗negative½, the association continues. The requesting ACPM again accepts primitives from its service-user. 7.2.3.5 A-RELEASE service collision 7.2.3.5.1 An A-RELEASE service collision occurs when an ACPM has sent out an RLRQ APDU as the user data of a P-RELEASE request primitive (as a result of receiving an A-RELEASE request primitive from its service-user). Instead of receiving the expected RLRE APDU as uset data on a P-RELEASE confirm primitive from its peer, it receives an RLRQ APDU as the user data of a P-RELEASE indication primitive. 7.2.3.5.2 The ACPM issues an A-RELEASE indication primitive to its service-user. The procedure then followed by an ACPM depends on whether its service-user was the association-initiator or the association-responder. a) For the association-initiator: 1) The ACPM waits for an A-RELEASE response primitive from its service user. When it receives the response primitive, it forms an RLRE APDU from the response primitive's parameters. The RLRE is sent as user data on a P-RELEASE response primitive. The association continues. 2) This ACPM now waits for an RLRE from its peer as user data on a P- RELEASE confirm primitive. It does not accept any primitive from its service-user other than an A-ABORT request primitive. PAGE22 Rec. X.227 3) When the ACPM receives the RLRE, it forms an A-RELEASE confirm primitive from the RLRE fields and isssues it to its service-user. The association is released. In summary, the sequence of events which drive the ACPM of the association initiator are: - A-RELEASE request primitive; - RLRQ APDU (causing the collision); - A -RELEASE response primitive; and finally - RLRE APDU. b) For the association-responder: 1) The ACPM waits for an RLRE from its pe r as user data on a P- RELEASE confirm primitive. It does not accept a primitive from its service-user other than an A-ABORT request primitive. 2) When this ACPM receives the RLRE, it forms an A-RELEASE confirm primitive from the RLRE fields. The association continues. 3) The ACPM now waits for an A-RELEASE response primitive from its service-user. When it receives the response primitive, it forms an RLRE APDU from the respone primitive's parameters. The RLRE is sent as user data on a P-RELEASE response primitive. The association is released. In summary, the sequence of events which drive the ACPM of the association responder are: - A-RELEASE request primitive; - RLRQ APDU (causing the collision); - RLRE APDU; and finally - A-RELEASE response primitive. 7.2.4 Use of the RLRQ APDU fields The RLRQ APDU fields are used by the requesting and accepting ACPMs as specified below. 7.2.4.1 Reason For the requesting ACPM: This value is determined by the value of the Reason parameter of the A-RELEASE request primitive. For the accepting ACPM: This value is used to determine the value of the Reason parameter of the A-RELEASE indication primitive. 7.2.4.2 User Information For the requesting ACPM: This value is determined by the value of the User Information parameter of the A-RELEASE request primitive. For the accepting ACPM: This value is used to determine the value of the User Information parameter of the A-RELEASE indication primitive. 7.2.5 Use of the RLRE APDU fields The RLRE APDU fields are used by the accepting and requesting ACPMs as specified below. 7.2.5.1 Reason For the accepting ACPM: This value is determined by the value of the Reason parameter of the A-RELEASE response primitive. For the requesting ACPM: This value is used to determine the value of the Reason parameter of the A-RELEASE confirm primitive. 7.2.5.2 User Information For the accepting ACPM: This value is determined by the value of the User Information parameter of the A-RELEASE response primitive. For the requesting ACPM: This value is used to determine the value of the User Information parameter of the A-RELEASE confirm primitive. 7.2.6 Collisions and interactions 7.2.6.1 A-RELEASE service For a given ACPM, an A-RELEASE service collision can occur. The processing for such a collision is described in S 7.2.3.5. Note - An A-RELEASE service collision can only occur if no session tokens were selected for the association. 7.2.6.2 A-ABORT service, P-U-ABORT, or P-P-ABORT service If an ACPM receives an A-ABORT request primitive, a P-U-ABORT indication primitive, or a P-P-ABORT indication primitive, it disrupts the normal association release procedure, and instead follows the abnormal release procedure. 7.3 Abnormal release of an association Rec. X.227 PAGE1 7.3.1 Purpose The Abnormal Release procedure can be used at any time to force the abrupt release of the association by a requestor in either AE, by either ACPM or by the presentation service-provider. When the abnormal release procedure is applied during an attempt to establish an association, the association is not established. The abnormal release procedure supports the A-ABORT and A-P-ABORT services. 7.3.2 APDUs used The abnormal release procedure uses the A-ABORT (ABRT) APDU. The fields of the ABRT APDU are listed in Table 6/X.227. Note - No APDUs are defined for the A-P-ABORT service since it is directly mapped from the P-P-ABORT service. TABLE 6/X.227 ABRT APDU fields Field name Presence Source Sink Abort Source M sp ind User Information U req ind 7.3.3 Abnormal release procedure This procedure is driven by the following events: a) an A-ABORT request primitive from the requestor; b) a P-U-ABORT indication primitive; c) a P-P-ABORT indication primitive; or d) a protocol error detected by an ACPM. 7.3.3.1 A-ABORT request primitive When an ACPM receives an A-ABORT request primitive from its service-user, the processing which it performs depends on the version of the underlying session protocol (X.225) which supports the association as specified below. a) For version 1, the ACPM does not send any of its APCI to its peer. It simply issues a P-U-ABORT request primitive. If the user information is included on the A-ABORT request primtive, that user information is passed as user data on the P-U-ABORT request primitive. The association is released. b) For other versions, the ACPM sends an ABRT APDU as user data on a P-U- ABORT request primitive. The Abort Source field is specified as ╗ACSE service-user½. If the User Information parameter is included on t e A- ABORT request primitive, it is included in the ABRT APDU. The association is released. 7.3.3.2 P-U-ABORT indication primitive When an ACPM receives a P-U-ABORT indication primitive, the User Data parameter may contain6 an ABRT APDU: a) If the indication primitive does not contain an ABRT APDU, the ACPM issues an A-ABORT indication primitive with the Abort Source parameter specified as ╗ACSE service-user½. If a user data is contained on the P U-ABORT indication primitive, it is included as the User Information parameter of the A-ABORT indication primitive. The association is released. b) If the indication primitive does contain an ABRT ADPU, the ACPM issues an A-ABORT indication primitive using the Abort Source field of the ABRT APDU. If a User Information field is contained in the ABRT APDU, it is included on the A-ABORT indication primitive. The association is released. 7.3.3.3 P-P-ABORT indication primitive When an ACPM receives a P-P-ABORT indication primitive, the ACPM issues an A-P-ABORT indication primitive to the acceptor. The association is released. 7.3.3.4 Protocol errors 7.3.3.4.1 Two types of ACSE protocol errors are possible: a) for a particular ACPM state, an unexpected APDU is received; or b) an invalid field is encountered during the processing of an incoming APDU (see S 7.4). 7.3.3.4.2 If an unexpected APDU is received, the abnormal release procedure is 6 If an association is supported by version 1 of the session-protocol (Rec. X.225), the User Data parameter does not contain an ABRT ADPU (see S 7.3.3.1). The absence of an APDU in this situation does not imply that the application is operating n the X.410- 1984 mode. PAGE22 Rec. X.227 invoked. If an invalid field is detected by an ACSE procedure that procedure is disrupted and the abnormal release procedure is invoked. 7.3.3.4.3 As part of the abnormal release procedure, the ACPM issues an A-ABORT indication primitive to its service-user, unless the error occurred during the association establishment procedure7 as the result of receiving an invalid A (see S 7.4). If an indication primitive is issued, the value of the Abort Source is ╗ACSE service-provider½. The User Information parameter is not used. 7.3.3.4.4 The subsequent ACPM processing performed depends on the version of the underlying session-protocol (X.225) which supports the association as specified below. a) For version 1, the ACPM issues a P-U-ABORT request primitive. No user information is included. b) For other versions, the ACPM sends an ABRT APDU as user data on a P-U- ABORT request primitive. The Abort Source field is specified as ╗ACSE service-provider½. The User Information field is not used. 7.3.3.4.5 In either case, the association is released. 7.3.4 Use of the ABRT APDU fields The ABRT APDU fields are used by the requesting and accepting ACPMs as specified below. 7.3.4.1 Abort Source For the requesting ACPM: This value is assigned by the ACPM as specified below. a) If the ACPM initiated the abort procedure, the ACPM assigns the value of ╗ACSE service-provider½. b) Otherwise, the ACPM assigns the value of ╗ACSE service-user½. For the accepting ACPM: This value is used to determine the value of the Abort Source parameter of the A-ABORT indication primitive. 7.3.4.2 User Information For the requesting ACPM: This value is determined by the value of the User Information parameter of the A-ABORT request primitive. For the accepting ACPM: This value is used to determine the value of the User Information parameter of the A-ABORT indication primitive. 7.3.5 Collisions and interactions The abnormal release procedure may be used whenever an association is established, is in the process of being established, or is being normally released. This procedure disrupts any other currently acti e procedure. A P-P- ABORT indication primitive can disrupt the A-ABORT procedure with loss of t e A- ABORT information. Collisions of ABRT APDUs are governed by the P-U-ABORT services (X.216). 7.4 Rules for extensibility 7.4.1 When processing an incoming AARQ, the accepting ACPM shall: a) ignore all tagged values which are not defined in the abstract syntax of this Recommendation; and b) ignore all unknown bit name assignments within a bit string. 7.4.2 After the association has been established or during the establishment of an association, only those ACSE APDUs and related ADPU fields defined in the ASN.1 description of the negotiated version of this Recommendation shall be issued. 7.4.3 A received APDU or field within an APDU which is not defined in the ASN.1 description of the negotiated version of this Recommendation shall be treated as a protocol error. 7 Since an A-ASSOCIATE indication primitive is not issued, an A-ABORT indication primitive would have no meaning, and, therefore, it is not issued. Rec. X.227 PAGE1