ISO/IECÊ9805 CCITT Draft Rec. X.852 INFORMATION TECHNOLOGY Ñ OPEN SYSTEMS INTERCONNECTION Ñ PROTOCOL SPECIFICATION FOR THE COMMITMENT, CONCURRENCY AND RECOVERY SERVICE ELEMENT1) CCITT Recommendation X.852 ISO/IEC 9805 Foreword Eventually the foreword, provided by ISO/IEC ITTF, will go here. Annexes A and B form an integral part of this International Standard. Introduction This protocol Specification is one of a set of CCITT Recommendations and International Standards produced to facilitate the interconnection of information processing systems. It is related to other Specifications in the set as defined by the Reference Model for Open Systems Interconnection (CCITT Rec. X.200). The Reference Model subdivides the area of standardization for interconnection into a series of layers of specification, each of manageable size. 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. This protocol Specification specifies the protocol for the application-service-element for commitment, concurrency, and recovery (CCR). These services are intended to be applicable to a wide range of application-process communication requirements. The CCR protocol specification consists of the following main components: a)the specification of the CCR APDUs using Abstract Syntax One (ASN.1, CCITT Rec.ÊX.208); b)the elements of procedure for issuing CCR service indication and confirm primitives to the CCR service-user when CCR APDUs are received and for the sending of CCR APDUs when CCR service request and indication primitives are received from the CCR service-user; c)the CCR protocol machine specified in terms of a state table; and d)the presentation services (CCITT Rec. X.216) used for sending and receiving CCR APDUs. The CCR protocol shares the presentation-service with other application-service-elements. The requirement to provide support for CCR together with other application-service-elements is satisfied by reference to this protocol Specification. Annex A contains the definitions of the structure of the CCR APDUs. Annex B describes the transfer of CCR APDUs as the values of a special parameter of another referencing application-service- element. Such an application-service-element is called a co- operating main service. INTERNATIONAL STANDARD ISO/IEC 9805 CCITT RECOMMENDATION X.852 INFORMATION TECHNOLOGY Ñ OPEN SYSTEMS INTERCONNECTION Ñ PROTOCOL SPECIFICATION FOR THE COMMITMENT, CONCURRENCY AND RECOVERY SERVICE ELEMENT 1 Scope This protocol Specification is to be applied by reference from other specifications. This is done within such specifications by reference to the CCR services defined in CCITT Rec. X.851. A reference to a CCR service invokes the procedures of this protocol Specification to cause external effects. This protocol Specification applies whenever the use of CCR services does not encompass any communication activity which makes direct or indirect use of the session activity management services defined in CCITT Rec. X.215. It can be used inside a session activity, and on a session-connection where the session activity functional unit is not in use. It can also be applied when the S- ACTIVITY service is used through the mechanisms of annex B. This protocol Specification specifies the static and dynamic conformance requirements for systems implementing these procedures. It does not contain tests which can be used to demonstrate conformance. This document specifies CCR Protocol Version 2. NOTE Ñ CCR Protocol Version 1 is specified in International Standard ISO/IECÊ9805:1990. 2 Normative references The following standards contain provisions which, through reference in this text, constitute provisions of this protocol Specification. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this protocol Specification are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Members of IEC and ISO maintain registers of currently valid International Standards. The CCITT Secretariat maintains a list of the currently valid CCITT Recommendations. Recommendation X.200, Reference model of open systems interconnection for CCITT applications. (see also ISOÊ7498) Recommendation X.208, Specification of abstract syntax notation one (ASN.1). (see also ISOÊ8824) Recommendation X.209, Specification of basic encoding rules for abstract syntax notation one (ASN.1). (see also ISOÊ8825) Recommendation X.210, Open systems interconnection 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) Recommendation X.217, Information Technology Ð Open Systems Interconnection Ð Service definition for the Association Control Service Element Association control service definition for open systems interconnection for CCITT applications. (see also ISOÊ8649) Recommendation X.216, Presentation service definition for open systems interconnection for CCITT applications. (see also ISOÊ8822) Recommendation X.851, Information Technology Ð Open Systems Interconnection Ð Service definition for the Commitment, Concurrency and Recovery Service Element Commitment, Concurrency and Recovery service definition for Open Systems Interconnection for CCITT Applications. (see also ISO/IECÊ9804) ISO 7498-3:1989, Information processing systems - Open Systems Interconnection Ð Basic Reference Model Ð Part 3: Naming and addressing. ISO 8326:1987/Add.2:Ñ2), Information processing systems Ð Open Systems Interconnection Ð Basic connection oriented session service definition Ð Addendum 2: Unlimited user data. ISO 8326/AM3:Ñ2), Information processing systems Ð Open Systems Interconnection Ð Basic connection oriented session service definition Ð Amendment 3 to incorporate additional synchronization functionality. ISO 8822/AM5:Ñ2), Information processing systems Ð Open Systems Interconnection Ð Connection oriented presentation service definition Ð Amendment 5 to deliver additional synchronization functionality to the Presentation Service User. ISO/IEC 9545:1989, Information technology Ð Open Systems Interconnection Ð Application Layer structure. ISO/IEC 9804/AM2:Ñ2), Information technology Ð Open Systems Interconnection Ð Service definition for the Commitment, Concurrency and Recovery service element, Amendment 2: Session Mapping changes. 3 Definitions 3.1 Reference model definitions This protocol Specification makes use of the following terms defined in CCITT Rec. X.200: a)Application Layer; b)application association; association; c)application-process; d)application-entity; e)presentation-service; f)presentation-connection; g)session-service; and h)session-connection. 3.2 Naming and addressing definitions This protocol Specification makes use of the following terms defined in ISO 7498-3: a)application-process title; b)application-entity qualifier; c)application-entity title; 3.3 Service conventions definitions This protocol Specification makes use of the following terms defined in CCITT Rec. X.210: a)service-provider; b)service-user; c)confirmed service; d)non-confirmed service; e)primitive; f)request (primitive); g)indication (primitive); h)response (primitive); and i)confirm (primitive). 3.4 Presentation service definitions This protocol Specification makes use of the following terms defined in CCITT Rec. X.216: a)abstract syntax; b)abstract syntax name; c)defined context set; d)presentation context; and e)presentation data value. 3.5 ACSE service definitions This protocol Specification makes use of the following terms defined in CCITT Rec. X.217: a)association-initiator; and b)association-responder. 3.6 Application Layer Structure definitions This protocol Specification makes use of the following terms defined in ISO/IEC 9545: a)application-entity-invocation; b)application-service-element; c)multiple association control function; d)single association control function; and e)single association object. 3.7 CCR service definitions This protocol Specification makes use of the following terms defined in CCITT Rec. X.851: 1)acceptor; 2)application failure; 3)atomic action; 4)atomic action branch; branch; 5)atomic action branch identifier; branch identifier; 6)atomic action data; 7)atomic action identifier; 8)atomic action tree; 9)atomicity; 10) bound data; 11) CCR service-provider; 12) CCR service-user; 13) commitment of an atomic action branch; commitment; 14) communication failure; 15) concurrency control; 16) cooperating main service; 17) distributed application; 18) doubt period; 19) durability; 20) final state; 21) heuristic decision; 22) initial state; 23) intermediate CCR service-user; intermediate; 24) intermediate state; 25) interrupted branch; 26) isolation; 27) leaf CCR service-user; leaf; 28) local commitment procedures; 29) local rollback procedures; 30) master CCR service-user; master; 31) offer of commitment of an atomic action branch; offer of commitment; 32) order of commitment of an atomic action branch; order of commitment; 33) phase I; 34) phase II; 35) presumed rollback; 36) recovery control; 37) recovery responsibility for an atomic action branch; recovery responsibility; 38) referencing specification; 39) requestor; 40) rollback of an atomic action branch; rollback; 41) subordinate of an atomic action branch; subordinate; and 42) superior of an atomic action branch; superior. 3.8 CCR protocol specification definitions For the purpose of this protocol Specification, the following definitions apply. 3.8.1 accepting CCR protocol machine: The CCR protocol machine whose service-user is the acceptor for a particular CCR service. 3.8.2 CCR protocol machine: The protocol machine of the CCR application-service-element specified in this protocol Specification. 3.8.3 requesting CCR protocol machine: The CCR protocol machine whose service-user is the requestor for a particular CCR 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 given to the application- protocol-data-units defined in this protocol Specification. C-BEGIN-RI C-BEGIN-RC C-PREPARE-RI C-READY-RI C-ROLLBACK-RI C-ROLLBACK-RC C-COMMIT-RI C-COMMIT-RC C-RECOVER-RI C-RECOVER-RC 4.3 Other abbreviations The following abbreviations are used in this protocol Specification. ACSE Association Control Service Element AEapplication-entity AEI application-entity invocation APapplication-process APDU application-protocol-data-unit ASE application-service-element ASN.1Abstract Syntax Notation One CCR Commitment, concurrency, and recovery application- service-element CCRPMCCR protocol machine cnf confirm primitive ind indication primitive OSI Open Systems Interconnection req request primitive rsp response primitive 5 Conventions 5.1 This protocol Specification employs a tabular presentation of its APDU fields. In clause 7, tables are presented for each CCR APDU. Each field is summarized using the following notation: M presence is mandatory O presence is CCRPM option U presence is CCR service-user option req source is the related request primitive ind sink is the related indication primitive rsp source is the related response primitive cnf sink is the related confirm primitive CCRPMsource or sink is the CCRPM 5.2 The structure of each CCR APDU is specified in annex A using the abstract syntax notation of ASN.1 (CCITT Rec. X.208). 5.3 CCR allows the concatenation of some of its APDUs. In clause 9 an ASN.1-like notation is used to express the allowed concatenations. 6 Overview of the CCR protocol 6.1 Service support The protocol specified in this protocol Specification supports the services defined in CCITT Rec. X.851. These services are listed in table 1. TABLE 1 CCR services Service Type Requestor C-BEGIN Optionally Superior confirmed C-PREPARE Non-confirmed Superior C-READY Non-confirmed Subordinate C-COMMIT Confirmed Superior C-ROLLBACK Confirmed Superior or subordinate C-RECOVER Confirmed or Superior Optionally Subordinate confirmed 6.2 Constraints on ACSE services 6.2.1 An application-entity invocation (AEI) establishes an association to exchange CCR APDUs with another AEI by using the A- ASSOCIATE service of ACSE (CCITT Rec. X.217). 6.2.2 When establishing the association, the following Presentation and Session Requirements must be specified on the A- ASSOCIATE service: presentation kernel functional unit session kernel functional unit session typed data functional unit session major synchronize functional unit session minor synchronize functional unit session resynchronize functional unit 6.2.3 When establishing the association, the following optional parameters of the ACSE A-ASSOCIATE service must be specified: a)Calling AP title b)Calling AE qualifier c)Responding AP title d)Responding AE qualifier 6.3 Use of the presentation service 6.3.1 CCR uses the following presentation (CCITT Rec. X.216) services: P-DATA P-TYPED-DATA P-SYNC-MAJOR P-SYNC-MINOR P-RESYNCHRONIZE(restart) P-RESYNCHRONIZE(abandon) 6.3.2 CCR APDUs are passed in the User Data parameters of the above presentation services as one or more presentation data values. The value of the ASN.1 data type for each CCR APDU is specified in annex A. If more than one ASN.1 data type is sent, a corresponding number of presentation data values are included. 6.3.3 If other presentation data values are present on a presentation service primitive, the referencing specification shall specify sequencing rules. These rules ensure that the CCR semantics are maintained and comply with the concatenation and mapping rules specified in clauses 9 and 10. NOTE Ð The use of presentation-service parameters other than User Data is specified in clause 9. 6.3.4 It is the responsibility of the CCR service-user to control the presentation contexts available in the defined context set of the underlying presentation-connection. 6.4 Relationship to the session-service and the transport-service. 6.4.1 The session functional units required for the session- connection that supports 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. The required session functional units are given in 6.2. 6.4.2 The rules of the session-service affect the operation of the CCRPM and its service-user. The CCR service-user must be aware of these constraints. This protocol Specification assumes that a local mechanism enforces them. For example, it is the responsibility of the CCR service-user to control the possession of the available session tokens. 6.4.3 If the Transport-expedited service is used by the session layer, the CCR service-user: a)shall respond to a C-BEGIN indication with a C-BEGIN response; and b)following a C-BEGIN request, shall not issue C-ROLLBACK request until after receipt of a C-BEGIN confirmation. If the Transport-expedited service is not used by the session layer, these restrictions do not apply. NOTE Ñ The use of the session resynchronize service for C- ROLLBACK is liable to cause purging of user data outside the atomic action. If the Transport-expedited service is used by session and the above restrictions are not followed, the C-BEGIN can be purged and user-data preceeding it. It is expected that a future change to session will prevent this possibility and thus allow the removal of this requirement. 6.4.3 4 CCR requires use of session unlimited user data (see CCITT Rec. X.215 | ISO 8326 : 1987/Add.2). 6.5 Operation of the CCRPM 6.5.1 The protocol specification for CCR is presented in this protocol Specification as a protocol machine. This protocol machine is referred to as the CCR protocol machine (CCRPM). 6.5.2 A CCRPM is used for a protocol exchange sequence for one atomic action branch on an existing association. A CCRPM is also used for a sequence of atomic action branches in which the completion (commitment or rollback) of one overlaps with the beginning of the next one. The procedures of a CCRPM are performed in co-operation with the overall CCR service-user. The CCRPM shares the presentation-connection that supports the association with other ASEs. 6.5.3 A CCR service primitive is issued by a CCR service-user within a sequence of application or presentation service primitives on a single association, as defined in CCITT Rec. X.851. 6.5.4 The procedures specified in clause 7 are carried out as a result of the request and response primitives issued in conformance with the CCRPM State Table defined in clause 8 and as a result of the receipt of presentation service primitives carrying data values in the CCR presentation context. The parameters of the CCR service primitives are structured according to annex A to produce CCR APDUs. These APDUs are transferred using the presentation-service according to the specification given in clauses 7, 9, and 10. 6.5.5 The value of a CCR APDU is transferred as a presentation data value from the CCR presentation context. The abstract syntax for data types transferred in this context are defined in annex A by specifying the complete set of CCR APDUs using Abstract Syntax Notation One (ASN.1, CCITT Rec. X.208). 7 Elements of procedures The CCR protocol consists of the following procedures: a)begin branch; b)prepare subordinate; c)offer commitment; d)order commitment; e)rollback; f)branch recovery; g)order commitment and begin new branch; and h)rollback and begin new branch. The following subclauses describe these procedures. The descriptions include the specification of presentation service primitives normally used to carry CCR APDUs. However, for concatenated CCR APDUs, the presentation service mapping specified in clause 10 applies. Figures 1 to 6 show the ASN.1 structure of the CCR APDUs. The complete ASN.1 module, containing these definitions and those of the supporting datatypes, is in annex A. 7.1 Begin branch procedure 7.1.1Purpose This procedure is used to begin a new atomic action branch between two CCR-service users. It supports the C-BEGIN service defined in CCITT Rec. X.851. 7.1.2APDUs used The procedure uses the following CCR APDUs: C-BEGIN-RI PC-BEGIN-RC The structure of these APDUs is shown in figure 1. C-BEGIN-RI ::= [1] SEQUENCE { atomic-action-identifier [0] ATOMIC-ACTION-IDENTIFIER, branch-suffix [1] BRANCH-SUFFIX, user-data User-data OPTIONAL } C-BEGIN-RC ::= [2] SEQUENCE { user-data User-data OPTIONAL } FIGURE 1 C-BEGIN APDUs The C-BEGIN-RI APDU fields are listed in table 2. The C-BEGIN- RC APDU field is listed in table 3. TABLE 2 C-BEGIN-RI fields Field name Presenc Source Sink e atomic-action- M req ind identifier branch-suffix M req ind user-data U req ind TABLE 3 C-BEGIN-RC field Field name Presenc Source Sink e user-data U req ind 7.1.3Prerequisite requirements 7.1.3.1 For the requestor, the use of this procedure requires that no other atomic action branch is active on the association. 7.1.3.2 The requestor of the C-BEGIN request primitive shall be the owner of the session synchronize-minor token. 7.1.4Procedure operation This procedure is driven by the following events: a)C-BEGIN request primitive from the requestor; b)C-BEGIN-RI APDU received by the accepting CCRPM; c)C-BEGIN response primitive from the acceptor; and d)C-BEGIN-RC APDU received by the requesting CCRPM. The events c) and d) are optional and may occur later. 7.1.4.1 C-BEGIN request primitive The requesting CCRPM forms a C-BEGIN-RI APDU from parameter values of the C-BEGIN request primitive. If the C-BEGIN-RI is not concatenated with other CCR APDUs, the CCRPM issues a P-SYNC-MINOR request primitive with the APDU as a data value of the primitive's User Data parameter. If the CCRPM concatenates the C-BEGIN-RI APDU with another CCR APDU, it issues the appropriate presentation service primitive as specified in clause 10, with the C-BEGIN-RI APDU as a data value in the user data parameter. 7.1.4.2 C-BEGIN-RI APDU The accepting CCRPM receives a C-BEGIN-RI APDU from its peer as user data on a P-SYNC-MINOR indication primitive, if the APDU is unconcatenated. If the APDU is concatenated with other CCR APDUs, the C-BEGIN-RI APDU will be received as user data on the appropriate presentation primitive as specified in clause 10. In either case, the CCRPM issues a C-BEGIN indication primitive with parameter values derived from the APDU. 7.1.4.3 C-BEGIN response primitive The accepting CCRPM forms a C-BEGIN-RC APDU from the parameter value of the C-BEGIN response primitive. If the C-BEGIN-RC is not concatenated with other CCR APDUs, the CCRPM issues a P-SYNC-MINOR response primitive with the APDU as a data value of the primitive's User Data parameter. If the CCRPM concatenates the C-BEGIN-RC APDU with another CCR APDU, it issues the appropriate presentation service primitive as specified in clause 10, with the C-BEGIN-RC APDU as a data value in the user data parameter. 7.1.4.4 C-BEGIN-RC APDU The requesting CCRPM receives a C-BEGIN-RC APDU from its peer as user data on a P-SYNC-MINOR confirm primitive, if the APDU is unconcatenated. If the APDU is concatenated with other CCR APDUs, the C-BEGIN-RC APDU will be received as user data on the appropriate presentation primitive as specified in clause 10. In either case, the CCRPM issues a C-BEGIN confirm primitive with the parameter value derived from the APDU. 7.1.5Use of the C-BEGIN-RI APDU fields For the requesting CCRPM: the fields of the C-BEGIN-RI APDU are directly mapped from the corresponding parameters on the C- BEGIN request primitive as specified in table 4. TABLE 4 Mapping of C-BEGIN req/ind parameters APDU field name Parameter name atomic-action- Atomic Action Identifier - identifier Master's Name {masters-name} atomic-action- Atomic Action Identifier - identifier Suffix {atomic-action- suffix} Ñ Branch Identifier - Superior's Name branch-suffix Branch Identifier - Suffix user-data User Data The C-BEGIN request includes the Branch Identifier - Superior's Name parameter on the request primitive. The parameter value is the requestor's AE title which was passed in the A- ASSOCIATE service used to establish the supporting association and is not mapped to a field of the C-BEGIN-RI APDU. For the accepting CCRPM: the fields of the C-BEGIN-RI APDU are directly mapped to the corresponding parameters on the C-BEGIN indication primitive as specified in table 4. The accepting CCRPM also includes the Branch Identifier - Superior's Name parameter on the indication primitive. The parameter value is the requestor's AE title passed in the A- ASSOCIATE service used to establish the supporting association. 7.1.6Use of the C-BEGIN-RC APDU field For the accepting and requesting CCRPM: the C-BEGIN-RC APDU field is directly mapped to and from the corresponding parameter on the C-BEGIN response and confirm primitives as specified in table 5. TABLE 5 Mapping of C-BEGIN rsp/cnf parameters APDU field name Parameter name user-data User Data 7.1.7 Collisions A collision of a C-BEGIN-RI APDU with another CCR APDU cannot occur. NOTE Ñ Collisions between two C-BEGIN-RI APDUs cannot occur because the CCR service-user must own the synchronize-minor token when issuing C-BEGIN request (except when issued with C-ROLLBACK or C-COMMIT). The requirement to own the token before issuing C- RECOVER request (except when replying to a C-RECOVER indication) makes collisions of C-BEGIN-RI APDUs and C-RECOVER-RI APDUs impossible. 7.2 Prepare subordinate procedure 7.2.1 Purpose The prepare subordinate procedure is used by the superior to request that the subordinate complete processing for the atomic action branch and use the offer commitment procedure (see 7.3) to complete the atomic action branch. If offering commitment is not possible, the subordinate uses the rollback procedure (see 7.5) to force completion of the atomic action branch. The prepare subordinate procedure supports the C-PREPARE service defined in CCITT Rec. X.851. 7.2.2 APDU used The procedure uses the following CCR APDU. C-PREPARE-RI The structure of this APDU is shown in figure 2. C-PREPARE-RI ::= [3] SEQUENCE { user-data User-data OPTIONAL } FIGURE 2 C-PREPARE APDU The C-PREPARE-RI APDU field is listed in table 6. TABLE 6 C-PREPARE-RI field Field name Presenc Source Sink e user-data U req ind 7.2.3 Prerequisite requirements None. 7.2.4 Prepare subordinate procedure This procedure is driven by the following events: a) C-PREPARE request primitive from the requestor; and b) C-PREPARE-RI APDU received by the accepting CCRPM. 7.2.4.1 C-PREPARE request primitive The requesting CCRPM forms a C-PREPARE-RI APDU from the parameter value of the C-PREPARE request primitive. If the C- PREPARE-RI is not concatenated with other CCR APDUs, the CCRPM issues a P-TYPED-DATA request primitive with the APDU as a data value of the primitive's User Data parameter. If the CCRPM concatenates the C-PREPARE-RI APDU with another CCR APDU, it issues the appropriate presentation service primitive as specified in clause 10, with the C-PREPARE-RI APDU as a data value in the user data parameter. 7.2.4.2 C-PREPARE-RI APDU The accepting CCRPM receives a C-PREPARE-RI APDU from its peer as user data on a P-TYPED-DATA indication primitive, if the APDU is unconcatenated. If the APDU is concatenated with other CCR APDUs, the C-PREPARE-RI APDU will be received as user data on the appropriate presentation primitive as specified in clause 10. In either case, the CCRPM issues a C-PREPARE indication primitive with the parameter value derived from the APDU. 7.2.5 Use of the C-PREPARE-RI APDU field For the requesting and accepting CCRPM: the field of the C- PREPARE-RI APDU is directly mapped to and from the corresponding parameter on the C-PREPARE request and indication primitives as specified in table 7. TABLE 7 Mapping of C-PREPARE req/ind parameters APDU field name Parameter name user-data User Data 7.2.6 Collisions 7.2.6.1 The prepare subordinate procedure and the commitment offer procedure may be used simultaneously by the superior and the subordinate, respectively. This results in a collision of a C- PREPARE-RI APDU and a C-READY-RI APDU. Both events are treated normally, resulting in the issue of the appropriate indication primitives. 7.2.6.2 The prepare procedure and the rollback procedure can be used simultaneously by the CCR service-users. The collision is resolved in favour of the rollback procedure. 7.2.6.3 A CCR service-user can initiate the rollback procedure immediately after initiating the prepare procedure. In this case the rollback can disrupt the prepare procedure. 7.3 Offer commitment procedure 7.3.1 Purpose The offer commitment procedure is used by the subordinate to inform its superior that it is offering commitment. The procedure supports the C-READY service defined in CCITT Rec. X.851. 7.3.2 APDU used This procedure uses the following CCR-APDU. C-READY-RI The structure of this APDU is shown in figure 3. C-READY-RI ::= [4] SEQUENCE { user-data User-data OPTIONAL } FIGURE 3 C-READY APDU The C-READY-RI APDU field is listed in table 8. TABLE 8 C-READY-RI field Field name Presenc Source Sink e user-data U req ind 7.3.3 Prerequisite requirements For the requestor, the use of this procedure requires that atomic action data for this branch are accessible in stable storage. 7.3.4 Offer commitment procedure This procedure is driven by the following events: a) C-READY request primitive from the requestor; and b) C-READY-RI APDU received by the accepting CCRPM. 7.3.4.1 C-READY request primitive The requesting CCRPM forms the C-READY-RI APDU from the parameter value of the C-READY request primitive. If the C-READY- RI is not concatenated with other CCR APDUs, the CCRPM issues a P- TYPED-DATA request primitive with the APDU as a value of the primitive's User Data parameter. If the CCRPM concatenates the C- READY-RI APDU with another CCR APDU, it issues the appropriate presentation service primitive as specified in clause 10, with the C-READY-RI APDU as a data value in the user data parameter. 7.3.4.2 C-READY-RI APDU The accepting CCRPM receives a C-READY-RI APDU from its peer as user data on a P-TYPED-DATA indication primitive, if the APDU is unconcatenated. If the APDU is concatenated with other CCR APDUs, the C-READY-RI APDU will be received as user data on the appropriate presentation primitive as specified in clause 10. In either case, the CCRPM issues a C-READY indication primitive with the parameter value derived from the APDU. 7.3.5 Use of the C-READY-RI APDU field For the requesting and accepting CCRPM: the field of the C- READY-RI APDU is directly mapped to and from the corresponding parameter on the C-READY request and indication primitives as specified in table 9. TABLE 9 Mapping of C-READY req/ind parameters APDU field name Parameter name user-data User Data 7.3.6 Collisions The commitment offer procedure and the prepare subordinate procedure may be used simultaneously by the subordinate and the superior, respectively. This results in a collision of a C-READY- RI APDU and a C-PREPARE-RI APDU. Both events are treated normally, resulting in the issue of the appropriate indication primitives. 7.4 Order commitment 7.4.1 Purpose The order commitment procedure is used by a superior to request its subordinate to release its bound data in their final state. It supports the C-COMMIT service defined in CCITT Rec. X.851. 7.4.2 APDUs used The procedure uses the following CCR APDUs. C-COMMIT-RI C-COMMIT-RC The structure of these APDUs is shown in figure 4. C-COMMIT-RI ::= [5] SEQUENCE { user-data User-data OPTIONAL } C-COMMIT-RC ::= [6] SEQUENCE { user-data User-data OPTIONAL } FIGURE 4 C-COMMIT APDUs The C-COMMIT-RI APDU and the C-COMMIT-RC APDU field are listed in table 10 and table 11, respectively. TABLE 10 C-COMMIT-RI field Field name Presenc Source Sink e user-data U req ind TABLE 11 C-COMMIT-RC field Field name Presenc Source Sink e user-data U req ind 7.4.3 Prerequisite requirements For the requestor to issue the C-COMMIT request primitive, it is required that atomic action data for this branch are accessible in stable storage. The requestor shall also be the owner of the session synchronize-minormajor/activity token. For the acceptor to issue the C-COMMIT response primitive, it is required that no atomic action data for this branch are accessible in stable storage. 7.4.4 Order commitment procedure This procedure is driven by the following events: a) C-COMMIT request primitive from the requestor; and b) C-COMMIT-RI APDU received by the accepting CCRPM; and c) C-COMMIT response primitive from the acceptor; and d) C-COMMIT-RC APDU received by the requesting CCRPM. 7.4.4.1 C-COMMIT request primitive The requesting CCRPM forms a C-COMMIT-RI APDU from the parameter value of the C-COMMIT request primitive. It issues a P- SYNC-MINORP-SYNC-MAJOR request primitive with the APDU as a data value of the primitive's User Data parameter. 7.4.4.2 C-COMMIT-RI APDU The accepting CCRPM receives a C-COMMIT-RI APDU from its peer as user data on a P-SYNC-MINORP-SYNC-MAJOR indication primitive. It issues a C-COMMIT indication primitive with the parameter value derived from the APDU. 7.4.4.3 C-COMMIT response primitive The accepting CCRPM forms a C-COMMIT-RC APDU from the parameter value of the C-COMMIT response primitive. It issues a P- SYNC-MINORP-SYNC-MAJOR response primitive with the APDU as a data value of the primitive's User Data parameter. 7.4.4.4 C-COMMIT-RC APDU The requesting CCRPM receives a C-COMMIT-RC APDU from its peer as user data on a P-SYNC-MINORP-SYNC-MAJOR confirm primitive. It issues a C-COMMIT confirm primitive with the parameter value derived from the APDU. 7.4.5 Use of the C-COMMIT-RI APDU fields For the requesting and accepting CCRPM: the C-COMMIT-RI APDU field is directly mapped to and from the corresponding parameter on the C-COMMIT request and indication primitives as specified in table 12. TABLE 12 Mapping of C-COMMIT req/ind parameters APDU field name Parameter name user-data User Data 7.4.6 Use of the C-COMMIT-RC APDU field For the accepting and requesting CCRPM: the C-COMMIT-RC APDU field is directly mapped to and from the corresponding parameter on the C-COMMIT response and confirm primitives as specified in table 13. TABLE 13 Mapping of C-COMMIT rsp/cnf parameters APDU field name Parameter name user-data User Data 7.4.7 Collision None. 7.5 Rollback 7.5.1 Purpose The rollback procedure is used to force completion of an atomic action branch. It supports the C-ROLLBACK service defined in CCITT Rec. X.851. 7.5.2 APDUs used The procedure uses the following CCR APDUs. C-ROLLBACK-RI C-ROLLBACK-RC The structure of these APDUs is shown in figure 5. C-ROLLBACK-RI ::= [7] SEQUENCE { user-data User-data OPTIONAL } C-ROLLBACK-RC ::= [8] SEQUENCE { user-data User-data OPTIONAL } FIGURE 5 C-ROLLBACK APDUs The C-ROLLBACK-RI APDU field is listed in table 14. The C- ROLLBACK-RC APDU field is listed in table 15. TABLE 14 C-ROLLBACK-RI field Field name Presenc Source Sink e user-data U req ind TABLE 15 C-ROLLBACK-RC field Field name Presenc Source Sink e user-data U req ind 7.5.3 Prerequisite requirements For the requestor, the use of this procedure requires either a) no atomic action data for this branch are accessible in stable storage; or b) the CCR service-user has been ordered to rollback by its superior. 7.5.4 Rollback procedure This procedure is driven by the following events: a) C-ROLLBACK request primitive from the requestor; b) C-ROLLBACK-RI APDU received by the accepting CCRPM; c) C-ROLLBACK response primitive from the acceptor; and d) C-ROLLBACK-RC APDU received by the requesting CCRPM. 7.5.4.1 C-ROLLBACK request primitive The requesting CCRPM forms a C-ROLLBACK-RI APDU from the parameter value of the C-ROLLBACK request primitive. It issues a P- RESYNCHRONIZE(abandon)P-RESYNCHRONIZE(restart) request primitive with the APDU as a data value of the primitive's User Data parameter. 7.5.4.2 C-ROLLBACK-RI APDU The accepting CCRPM receives a C-ROLLBACK-RI APDU from its peer as user data on a P-RESYNCHRONIZE(abandon)P- RESYNCHRONIZE(restart) indication primitive. It issues a C- ROLLBACK indication primitive with the parameter value derived from the APDU. For the acceptor, if atomic action data for this branch are accessible in stable storage, then it is required that these data will be forgotten. 7.5.4.3 C-ROLLBACK response primitive The accepting CCRPM forms a C-ROLLBACK-RC APDU from the parameter value of the C-ROLLBACK response primitive. It issues a P-RESYNCHRONIZE(abandon)P-RESYNCHRONIZE(restart) response primitive with the APDU as a data value of the primitive's User Data parameter. 7.5.4.4 C-ROLLBACK-RC APDU The requesting CCRPM receives a C-ROLLBACK-RC APDU from its peer as user data on a P-RESYNCHRONIZE(abandon)P- RESYNCHRONIZE(restart) confirm primitive. It issues a C-ROLLBACK confirm primitive with the parameter value derived from the APDU. 7.5.5 Use of the C-ROLLBACK-RI APDU fields For the accepting and requesting CCRPM: the C-ROLLBACK-RI APDU field is directly mapped to and from the corresponding parameter on the C-ROLLBACK request and indication primitives as specified in table 16. TABLE 16 Mapping of C-ROLLBACK req/ind parameters APDU field name Parameter name user-data User Data 7.5.6 Use of the C-ROLLBACK-RC APDU field For the accepting and requesting CCRPM: the C-ROLLBACK-RC APDU field is mapped to and from the corresponding parameter on the C- ROLLBACK response and confirm primitives as specified in table 17. TABLE 17 Mapping of C-ROLLBACK rsp/cnf parameters APDU field name Parameter name user-data User Data 7.5.7 Disruptive effects Because the C-ROLLBACK service is mapped on the P- RESYNCHRONIZE(restart) service, CCR APDUs other than a C-ROLLBACK- RI from the association-initiator are discarded (by the underlying session service-provider). This mapping guarantees that rollback takes precedence over all other allowed CCR protocol procedures. 7.5.8 Collision with a C-ROLLBACK-RI APDU If two C-ROLLBACK-RI APDUs collide, the C-ROLLBACK-RI APDU from the association-responder is discarded by the underlying session service-provider. That is, the association-initiator wins. Therefore, for the association-responder, the delivery of its user data to the peer is not guaranteed. 7.6 Branch recovery procedure 7.6.1 Purpose 7.6.1.1 The branch recovery procedure is used to recover an atomic action branch after the branch was disrupted by an application or communication failure. The procedure supports the C-RECOVER service defined in CCITT Rec. X.851. 7.6.1.2 This procedure either a) makes a specific, previously disrupted branch active on the association; or b) is used by the superior of a branch that is in the process of recovery on the association. Case b) occurs when the superior uses the procedure to send a C-RECOVER-RI(commit) APDU to the subordinate in response to a C- RECOVER-RI(ready) from the subordinate. 7.6.2 APDUs used The procedure uses the following CCR APDUs. C-RECOVER-RI C-RECOVER-RC The structure of these APDUs is shown in figure 6. C-RECOVER-RI ::= [9] SEQUENCE { atomic-action-identifier [0] ATOMIC-ACTION- IDENTIFIER, branch-identifier [1] BRANCH-IDENTIFIER, recovery-state [2] CHOICE {commit [1] NULL, ready [2] NULL }, user-data User-data OPTIONAL } C-RECOVER-RC::= [10] SEQUENCE { atomic-action-identifier [0] ATOMIC-ACTION- IDENTIFIER, branch-identifier [1] BRANCH-IDENTIFIER, recovery-state [2] CHOICE {done [1] NULL, unknown [2] NULL, retry-later [3] NULL }, user-data User-data OPTIONAL } FIGURE 6 C-RECOVER APDUs The fields of the C-RECOVER-RI APDU are listed in table 18. The fields of the C-RECOVER-RC APDU are listed in table 19. TABLE 18 C-RECOVER-RI fields _______________________________ 1) Recommendation X.852 and ISO/IECÊ9805 (Information Technology - Open Systems Interconnection - Protocol specification for the Commitment, Concurrency and Recovery service element) were developed in close collaboration and are technically aligned. 2To be published.