Transaction Component Interface

Transaction Component Interface

Preface

Security Warning

Permission to use, copy and distribute this documentation without modification, for any purpose and without fee or royalty is hereby granted, provided that both the above copyright notice and this permission notice appears in all copies and that the name of OpenSS7 Corporation not be used in advertising or publicity pertaining to distribution of this documentation or its contents without specific, written prior permission. OpenSS7 Corporation makes no representation about the suitability of this documentation for any purpose. It is provided “as is” without express or implied warranty.

OpenSS7 Corporation disclaims all warranties with regard to this documentation including all implied warranties of merchantability, fitness for a particular purpose, non-infringement, or title; that the contents of the document are suitable for any purpose, or that the implementation of such contents will not infringe on any third party patents, copyrights, trademarks or other rights.. In no event shall OpenSS7 Corporation be liable for any direct, indirect, special or consequential damages or any damages whatsoever resulting from loss of use, data or profits, whether in an action of contract, negligence or other tortious action, arising out of or in connection with any use of this document or the performance or implementation of the contents thereof.

Abstract

This document is a Application Program Interface containing technical details concerning the implementation of the Transaction Component Interface (TCI) for OpenSS7. It contains recommendations on software architecture as well as platform and system applicability of the Transaction Component Interface (TCI).

Purpose

The purpose of this document is to provide technical documentation of the Transaction Component Interface (TCI). This document is intended to be included with the OpenSS7 STREAMS software package released by OpenSS7 Corporation. It is intended to assist software developers, maintainers and users of the Transaction Component Interface (TCI) with understanding the software architecture and technical interfaces which are made available in the software package.

Intent

It is the intent of this document that it act as the primary source of information concerning the Transaction Component Interface (TCI).

Audience

The audience for this document is software developers, maintainers and users and integrators of the Transaction Component Interface (TCI).

Revision History

Take care that you are working with a current version of this documentation: you will not be notified of updates. To ensure that you are working with a current version, check the OpenSS7 Project website for a current version.

A printed (or postscript) version of this document is an UNCONTROLLED version.

1 Introduction

This document specifies a STREAMS-based kernel-level instantiation of the ITU-T Transaction Capabilities Application Part (TCAP) Component (TC) Sub-Layer. The Transaction Component Interface (TCI) enables the user of a component sub-layer service to access and use any of a variety of conforming transaction providers without specific knowledge of the provider's protocol. The service interface is designed to support any transaction protocol but is intended for the ITU-T Recommendation Q.771 Transaction Capabilities Application Part (TCAP) Component (TC) Sub-Layer. This interface only specifies access to transaction component sub-layer services providers, and does not address issues concerning transaction or component sub-layer management, protocol performance, and performance analysis tools.

The specification assumes that the reader is familiar with the ISO reference model terminology, ISO/ITU-T transaction service definitions (ROSE, ACSE, TCAP), and STREAMS.

1.1 Related Documentation

• ITU-T Recommendation X.200 (White Book) — ISO/IEC 7498-1:1994
• ITU-T Recommendation X.219 (White Book) — ISO/IEC
• ITU-T Recommendation X.229 (White Book) — ISO/IEC
• ITU-T Recommendation X.217 (White Book) — ISO/IEC 8649 : 1996
• ITU-T Recommendation X.227 (White Book) — ISO/IEC 8650-1 : 1995
• ITU-T Recommendation X.237 (White Book) — ISO/IEC 10035-1 : 1995
• ITU-T Recommendation Q.771 (White Book)
• System V Interface Definition, Issue 2 - Volume 3

1.1.1 Role

This document specifies an interface that supports the Transaction Component (TC) Sub-Layer services provided by the Transaction Capabilities Application Part (TCAP) as specified in ITU-T Recommendation Q.771. It may also be capable of supporting the transaction component capabilities of the Remote Operations Service Execution (ROSE) for Open Systems Interconnect for CCITT Applications as specified in ITU-T Recommendation X.219 and ISO ????. These specifications are targeted for use by developers and testers of protocol modules that require transaction component sub-layer service.¹

1.2 Definitions, Acronyms, and Abbreviations

Originating TC User

A TC-User that initiates a transaction.

Destination TC User

A TC-User with whom an originating TC user wishes to establish a transaction dialogue.

ISO

International Organization for Standardization

TC User

Kernel level protocol or user level application that is accessing the services of the transaction component sub-layer.

TC Provider

Transaction sub-layer entity/entities that provide/s the services of the transaction component interface.

TCI

Transaction Component Interface

TIDU

Transaction Interface Data Unit

TSDU

Transaction Service Data Unit

OSI

Open Systems Interconnection

QOS

Quality of Service

STREAMS

A communication services development facility first available with UNIX System V Release 3

2 The Transaction Component Sub-Layer

The Transaction Component Sub-Layer provides the means to manage the dialogue of TC-Users into transaction components and dialogues. It is responsible for the routing and management of transaction component exchange within dialogues between TC-user entities.

2.1 Model of the TCI

The TCI defines the services provided by the transaction component sub-layer to the transaction component-user at the boundary between the Transaction Capabilities Application Part (TCAP) user and the Transaction Component (TC) Sub-Layer in the model presented in ITU-T Recommendation Q.771. The interface consists of a set of primitives defined as STREAMS messages that provide access to the component sub-layer services, and are transferred between the TC user entity and the TC provider. These primitives are of two types: ones that originate from the TC user, and others that originate from the TC provider, or respond to an event of the TC provider. The primitives that originate from the TC provider are either confirmations of a request or are indications to the TC user that the event has occurred. Figure 1 shows the model of the TCI.

Figure 1. Model of the TCI

The TCI allows the TC provider to be configured with any component sub-layer user (such as the Mobile Application Part whose upper layer interface is described in About This Manual), that also conforms to the TCI. A transaction component sub-layer user can also be a user program that conforms to the TCI and accesses the TC provider via putmsg(2) and getmsg(2) system calls.

STREAMS messages that are used to communicate transaction component service primitives between the transaction component user and the transaction component provider may have one of the following formats:

1. A M_PROTO message block followed by zero or more M_DATA message blocks. The M_PROTO message block contains the type of service primitive and all relevant arguments associated with the primitive. The M_DATA blocks contain user data associated with the service primitive.
2. One M_PCPROTO message block containing the type of service primitive and all the relevant arguments associated with the primitive.
3. One or more M_DATA message blocks containing user data.

The following sections describe the service primitives which define all operation classes of service.

For all operation classes of service, two types of primitives exist: primitives that originate from the service user and primitives that originate from the service provider. The primitives that originate from the service user make requests to the service provider or response to an event of the service provider. The primitive that originate from the service provider are either confirmations of a request or are indications to the service user that an event has occurred. The primitive types along with the mapping of those primitives to the STREAMS message types and the service primitives of the ISO/IEC xxxxx and service definitions are listed in TCI Primitives. The format of these primitives and the rules governing the use of them are described in Management Primitives, Operation Class 1 through 3 Primitives, and Operation Class 4 Primitives.

2.2 TCI Services

The features of the TCI are defined in terms of the services provided by the TC provider, and the individual primitives that may flow between the TC user and the TC provider.

The services supported by the TCI are based on four distinct classes of transaction, operation classes 1, 2, 3 and 4. In addition, the TCI supports services for local management.

2.2.1 Operation Class 1

The main features of operation class 1 transactions are:

• Operation success is reported.
• Operation failure is reported.

There are three phases to each transaction: Transaction Initiation, Transaction Data Transfer, and Transaction Termination.² Transaction components arrive at their destination in the same order as they departed their source and the data is protected against duplication or loss of data units within some specified quality of service.

2.2.2 Operation Class 2

The main features of operation class 2 transactions are:

• Operation success is not reported.
• Operation failure is reported.

There are three phases to each transaction: Transaction Initiation, Transaction Data Transfer, and Transaction Termination.³ Transaction components arrive at their destination in the same order as they departed their source and the data is protected against duplication or loss of data units within some specified quality of service.

2.2.3 Operation Class 3

The main features of operation class 3 transactions are:

• Operation success is reported.
• Operation failure is not reported.

There are three phases to each transaction: Transaction Initiation, Transaction Data Transfer, and Transaction Termination.⁴ Transaction components arrive at their destination in the same order as they departed their source and the data is protected against duplication or loss of data units within some specified quality of service.

2.2.4 Operation Class 4

The main features of operation class 4 transactions are:

• Operation success is not reported.
• Operation failure is not reported.

Operation class 4 has no structure to the transaction and has no separate phases. Each transaction component is transmitted from source to destination independently, appropriate addressing information is included with each component sequence. As the components are transmitted independently from source to destination, there are, in general, no guarantees of proper sequence and completeness of the data transmission.

2.2.5 Component Handling

2.2.6 Local Management

The TCI specifications also define a set of local management functions that apply to all operation classes. These services have local significance only.

Table 1 and Table 2 summarize the TCI service primitives by their state and service.

3 TCI Services Definition

This section describes the services of the TCI primitives. Time-sequence diagrams ⁵ that illustrate the sequence of primitives are used. The format of the primitives will be defined later in this document.

3.1 Local Management Services Definition

The services defined in this section are outside the scope of the international standards. These services apply to all operation classes. They are involved for the initialization/de-initialization of a stream connected to the TC provider. They are also used to manage options supported by the TC provider and to report information on the supported parameter values.

3.1.1 Transaction Information Reporting Service

This service provides information on the options supported by the TC provider.

• TC_INFO_REQ:

  This primitive request that the TC provider returns the values of all the supported protocol parameters. This request may be invoked during any phase.

• TC_INFO_ACK:

  This primitive is in response to the TC_INFO_REQ primitive and returns the values of the supported protocol parameters to the TC user.

The sequence of primitives for transaction information management is shown in Figure 2.

Figure 2. Sequence of Primitives Transaction Information Reporting Service

3.1.2 TC User Bind Service

This service allows an originating address to be associated with a stream. It allows the TC user to negotiate the number of transaction begin indications that can remain unacknowledged for that TC user (a transaction begin indication is considered unacknowledged while it is awaiting a corresponding transaction response or abort request from the TC user). This service also defines a mechanism that allows a stream (bound to the address of the TC user) to be reserved to handle incoming transactions only. This stream is referred to as the listener stream.

• TC_BIND_REQ:

  This primitive request that the TC user be bound to a particular originating address, and negotiate the number of allowable outstanding transaction indications for that address.

• TC_BIND_ACK:

  This primitive is in response to the TC_BIND_REQ primitive and indicates to the user that the specified TC user has been bound to an originating address.

The sequence of primitives for the TC user bind service is shown in Figure 3.

Figure 3. Sequence of Primitives TC User Bind Service

3.1.3 TC User Unbind Service

This service allows the TC user to be unbound from a network address.

• TC_UNBIND_REQ:

  This primitive requests that the TC user be unbound from the network address it had previously been bound to.

The sequence of primitives for the TC user unbind service is shown in Figure 4.

Figure 4. Sequence of Primitives TC User Unbind & Receipt Acknowledgement Services

3.1.4 Receipt Acknowledgement Service

• TC_OK_ACK:

  This primitive indicates to the TC user that the previous TC user originated primitive was received successfully by the TC provider.

An example showing the sequence of primitives for successful receive acknowledgement is depicted in Figure 4.

3.1.5 Options Mangement Service

This service allows the TC user to manage the QOS parameter values associated with the TC provider.

• TC_OPTMGMT_REQ:

  This primitive allows the TC user to select default values for QOS parameters within the range supported by the TC provider, and to indicate the default selection of return option.

• TC_OPTMGMT_ACK:

Figure 5 shows the sequence of primitives for transaction options management.

Figure 5. Sequence of Primitives Options Management Service

3.1.6 Error Acknowledgement Service

• TC_ERROR_ACK:

  This primitive indicates to the TC user that a non-fatal error has occurred in the last TC user originated request or response primitive (listed in Figure 6) on the stream.

Figure 6 shows the sequence of primitives for the error management primitive.

Figure 6. Sequence of Primitives Error Acknowledgement Service

3.2 Operation Class 1, 2 and 3 Transaction Services Definition

This section describes the required transaction service primitives that define the operation class 1, 2 and 3, structured transaction interface.

The queue model for operation classes 1, 2 and 3 are discussed in more detail in ITU-T X.219 and ITU-T Q.771.

The queue model represents the operation of a transaction dialogue in the abstract by a pair of queues linking two transaction users. There is one queue for each direction of component flow. Each queue represents a flow control function in one direction of transfer. The ability of a user to add objects to a queue will be determined by the behaviour of the user removing objects from that queue, and the state of the queue. The pair of queues is considered to be available for each potential transaction dialogue. Objects that are entered or removed from the queue are either as a result of interactions at the two transaction addresses, or as the result of TC provider initiatives.

• A queue is empty until a transaction object has been entered and can be returned to this state, with loss of its contents, by the TC provider.
• Objects may be entered into a queue as a result of the actions of the source TC user, subject to control by the TC provider.
• Objects may also be entered into a queue by the TC provider.
• Objects are removed from the queue under the control of the TC user in the same order as they were entered except:

1. If the object is of type defined to be able to advance ahead of the preceding object (however, no object is defined to be able to advance ahead of another object of the same type), or
2. If the following object is defined to be destructive with respect to the preceding object on the queue. If necessary, the last object on the queue will be deleted to allow a destructive object to be entered - they will therefore always be added to the queue. For example, “abort” objects are defined to be destructive with respect to all other objects.

Table 3 shows the ordering relationships among the queue model objects.

3.2.1 Transaction Initiation

A pair of queues is associated with a transaction dialogue between two transaction users when the TC provider receives a TC_BEGIN_REQ primitive at one of the TC users resulting in a begin object being entered into the queue. The queues will remain associated with the transaction until a TC_END_REQ or TC_ABORT_REQ primitive (resulting in an end or abort object) is either entered or removed from a queue. Similarly, in the queue from the destination TC user, objects can be entered into the queue only after the begin object associated with the TC_BEGIN_RES has been entered into the queue. Alternatively, the destination TC user can enter an end or abort object into the queue instead of the begin object to terminate the transaction.

The transaction establishment procedure will fail if the TC provider is unable to establish a transaction dialogue, or if the destination TC user is unable to accept the TC_BEGIN_IND (see Transaction Termination primitive definition in TC_END_IND).

3.2.1.1 User Primitives for Successful Transaction Establishment

The following user primitves support Operation Class 1, 2, or 3 Phase I (Transaction Establishment) services:

• TC_BEGIN_REQ:

  This primitive requests that the TC provider form a transaction dialogue with the specified destination TC user.

• TC_BEGIN_RES:

  This primitive requests that the TC provider accept a previous transaction indication.

3.2.1.2 Provider Primitives for Successful Transaction Establishment

The following provider primitives support Operation Class 1, 2, or 3 Phase I (Transaction Establishment) services:

• TC_BEGIN_IND:

  This primitive indicates to the TC user that a transaction dialogue request has been made by a user at the specified source address.

• TC_BEGIN_CON:

  This primitive indicates to the TC user that a transaction initiation request has been confirmed on the specified responding address.

The sequence of primitives in a successful transaction initiation is defined by the time sequence diagrams as shown in Figure 7.

Figure 7. Sequence of Primitives: Successful Transaction Initiation

The sequence of primitives for the transaction initiation response token value determination is shown in Figure 8 (procedures for transaction initiation response token value determination are discussed in TC_BIND_REQ, and TC_BIND_ACK).

Figure 8. Sequence of Primitives: Transaction Response Token Value Determination

3.2.2 Transaction Component Transfer

Flow control on the transaction dialogue is done by management of the queue capacity, and by allowing objects of certain types to be inserted to the queues, as shown in Table 4.

3.2.2.1 Primitives for Component Transfer

The following primitives support Operation Class 1, 2, or 3 Phase II (Transaction Component Transfer) services:

• TC_CONT_REQ:

  This primitive requests that the TC provider transfer the specified components.

• TC_CONT_IND:

  This primitive indicates to the TC user that this message contains components.

Figure 9 shows the sequence of primitives for successful component transfer. The sequence of primitives may remain incomplete if a `TC_END_REQ', `TC_ABORT_REQ', or `TC_ABORT_IND' primitive occurs.

Figure 9. Sequence of Primitives: Component Transfer

3.2.3 Transaction Termination

The transaction dialogue procedure is initialized by insertion of an end or abort object (associated with a TC_END_REQ or TC_ABORT_REQ) into the queue. As shown in Table?, the termination procedure is destructive with respect to other objects in the queue, and eventually results in the emptying of queues and termination of the transaction dialogue.

The sequence of primitives depends on the origin of the termination action. The sequence may be:

1. invoked by on TC user, with a request from that TC user leading to an indication to the other;
2. invoked by both TC users, with a request from each of the TC users;
3. invoked by the TC provider, with an indication to each of the TC users;
4. invoked independently by one TC user and the TC provider, with a request from the originating TC user and an indication to the other.

3.2.3.1 Primitives for Transaction Termination

The following primitives support Operation Class 1, 2, or 3 Phase III (Transaction Termination) services:

• TC_END_REQ:

  This primitive requests that the TC provider deny an outstanding request for a transaction dialogue or normal termination of an existing transaction.

• TC_ABORT_REQ:

  This primitive requests that the TC provider deny an outstanding request for a transaction dialogue or abnormal termination of an existing transaction.

• TC_END_IND:

  This primitive indicates to the TC user that either a request for transaction initiation has been denied or an existing transaction has been terminated normally.

• TC_ABORT_IND:

  This primitive indicates to the TC user that either a request for transaction initiation has been denied or an existing transaction has been terminated abnormally.

The sequence of primitives are shown in the time sequence diagrams in the figures that follow:

Figure 10. Sequence of Primitives: TC User Invoked Termination

Figure 11. Sequence of Primitives: Simultaneous TC User Invoked Termination

Figure 12. Sequence of Primitives: TC Provider Invoked Termination

Figure 13. Sequence of Primitives: Simultaneous TC User and TC Provider Invoked Termination

A TC user may reject a transaction initiation attempt by issuing a `TC_ABORT_REQ'. The originator parameter in the `TC_ABORT_REQ' will indicate TC user invoked termination. The sequence of primitives is shown in Figure 14.

Figure 14. Sequence of Primitives: TC User Rejection of a Transaction Initiation Attempt

If the TC provider is unable to establish a transaction, it indicates this to the requester by an `TC_ABORT_IND'. The originator of the primitive indicates a TC provider invoked release. This is shown in Figure 15.

Figure 15. Sequence of Primitives: TC Provider Rejection of a Transaction Initiation Attempt

3.3 Operation Class 4 Transaction Services Definition

The operation class 4 service allows for the transfer of transaction components in one and both directions simultaneously without establishing a transaction dialogue. A set of primitives are defined that carry transaction components and control information between the TC user and the TC provider entities. The primitives are modelled as requests initiated by the TC user and indications initiated by the TC provider. Indications may be initiated by the TC provider independently from requests by the TC user. The operation class 4 transaction service consists of one phase.

3.3.1 Request and Response Primitives

• TC_UNI_REQ:

  This primitive requests that the TC provider send the transaction components to the specified destination.

• TC_UNI_IND:

  This primitive indicates to the TC user that a component sequence has been received from the specified originating address.

Figure 16 shows the sequence of primitives for the operation class 4 mode of transfer.

Figure 16. Sequence of Primitives: Operation Class 4 Component Transfer

• TC_NOTICE_IND:

  This primitive indicates to the TC user that the components with the specified destination address and QOS parameters produced an error. This primitive is specific to operation class 4.

Figure 17 shows the sequence of primitives for the operation class 4 error management primitive.

Figure 17. Sequence of Primitives: Operation Class 4 Error Indication Service

3.4 Component Handling Services Definition

3.4.1 Component Invoke Service

• TC_INVOKE_REQ:
• TC_INVOKE_IND:

3.4.2 Component Return Result Service

• TC_RESULT_REQ:
• TC_RESULT_IND:

3.4.3 Component Error Service

• TC_ERROR_REQ:
• TC_ERROR_IND:

3.4.4 Component Cancel Service

• TC_CANCEL_REQ:
• TC_CANCEL_IND:

3.4.5 Component Reject Service

• TC_REJECT_REQ:
• TC_REJECT_IND:

4 TCI Primitives

This section describes the format and parameters of the TCI primitives (Appendix A shows the mapping of TCI primitives to the primitives defined in ITU-T Q.771). In addition, it discusses the states in which the primitive is valid, the resulting state, and the acknowledgement that the primitive expects. (The state/event tables for these primitives are shown in Appendix B. The precedence tables for the TCI primitives are shown in Appendix C.) Rules for SS7 conformance are described in Addendum 1 to this document. The following tables provide a summary of the TC primitives and their parameters.

4.1 Management Primitives

These primitives apply to all operation classes.

4.1.1 Transaction Information

4.1.1.1 Transaction Information Request

TC_INFO_REQ

This primitive request the TC provider to return the values of all supported protocol parameters (see TC_INFO_ACK), and also the current state of the TC provider (as defined in State/Event Tables). This primitive does not affect the state of the TC provider and does not appear in the state tables.

Format

The format of the message is one `M_PCPROTO' message block and its structure is as follows:

     typedef struct TC_info_req {
             ulong PRIM_type;                /* Always TC_INFO_REQ */
     } TC_info_req_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_INFO_REQ'.

Valid States

This primitive is valid in any state where a local acknowledgement is not pending.

New State

The new state remains unchanged.

Rules

For the rules governing the requests made by this primitive, see the `TC_INFO_ACK' primitive described in TC_INFO_ACK.

Acknowledgements

This primitive requires the TC provider to generate one of the following acknowledgements upon receipt of the primitive:

• Successful:

  Acknowledgement of the primitive is indicatd with the TC_INFO_ACK primitive described in TC_INFO_ACK.

• Non-fatal Errors:

  These errors will be indicated with the TC_ERROR_ACK primitive described in TC_ERROR_ACK. The allowable errors are as follows:

  There are no errors associated with the issuance of this primitive.

4.1.1.2 Transaction Information Acknowledgement

TC_INFO_ACK

This primitive indicates to the TC user any relevant protocol-dependent parameters.⁶ It should be initiated in response to the TC_INFO_REQ primitive described above under TC_INFO_REQ.

Format

The format of the message is one `M_PCPROTO' message block and its structure is as follows:

     typedef struct TC_info_ack {
             long PRIM_type;                 /* always TC_INFO_ACK */
             long TSDU_size;                 /* maximum TSDU size */
             long ETSDU_size;                /* maximum ETSDU size */
             long CDATA_size;                /* connect data size */
             long DDATA_size;                /* disconnect data size */
             long ADDR_size;                 /* maximum address size */
             long OPT_size;                  /* maximum options size */
             long TIDU_size;                 /* transaction interface data size */
             long SERV_type;                 /* service type */
             long CURRENT_state;             /* current state */
             long PROVIDER_flag;             /* provider flags */
             long TCI_version;               /* TCI version */
     } TC_info_ack_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_INFO_ACK'.

TSDU_size

Specifies the maximum size (in octets) of Transaction Service User Data supported by the TR provider.

ETSDU_size

Specifies the maximum size (in octets) of Expedited Transaction Service User Data supported by the TR provider.

CDATA_size

Specifies the maximum number of octets of data that may be associated with a transaction initiation primitive.

DDATA_size

Specifies the maximum number of octets of data that may be associated with a transaction termination primitive.

ADDR_size

Specifies the maximum size (in decimal digits) of a network address.

ADDR_length, ADDR_offset

Specifies the length in bytes and offset from the beginning of the M_PCPROTO message block of the network address bound on the stream on which the TC_INFO_REQ was issued (a network address is bound to a stream via a TC_BIND_REQ).

QOS_length, QOS_offset

QOS_range_length, QOS_range_offset

OPTIONS_flags

TIDU_size

SERV_type

CURRENT_state

PROVIDER_type

NODU_size

PROTOID_length, PROTOID_offset

TCI_version

4.1.2 Transaction Protocol Address Management

4.1.2.1 Transaction Bind Request

TC_BIND_REQ

Format

     typedef struct TC_bind_req {
             ulong PRIM_type;
             ulong ADDR_length;              /* address length */
             ulong ADDR_offset;              /* address offset */
             ulong XACT_number;              /* maximum outstanding transaction reqs. */
             ulong BIND_flags;               /* bind flags */
     } TC_bind_req_t;
     
     typedef struct TC_subs_bind_req {
             ulong PRIM_type;
     } TC_subs_bind_req_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_BIND_REQ'.

ADDR_length

ADDR_offset

XACT_number

BIND_flags

Flags

Valid State

New State

Rules

Acknowledgement

4.1.2.2 Transaction Bind Acknowledgement

TC_BIND_ACK

Format

     typedef struct TC_bind_ack {
             ulong PRIM_type;
             ulong ADDR_length;
             ulong ADDR_offset;
             ulong XACT_number;
             ulong TOKEN_value;
     } TC_bind_ack_t;
     
     typedef struct TC_subs_bind_ack {
             ulong PRIM_type;
     } TC_subs_bind_ack_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_BIND_ACK'.

ADDR_length

ADDR_offset

XACT_number

TOKEN_value

Flags

Valid State

New State

Rules

Acknowledgement

4.1.2.3 Transaction Unbind Request

TC_UNBIND_REQ

Format

     typedef struct TC_unbind_req {
             ulong PRIM_type;                /* Always TC_UNBIND_REQ */
     } TC_unbind_req_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_UNBIND_REQ'.

Flags

Valid State

New State

Rules

Acknowledgement

4.1.2.4 Transaction Protocol Address Request

TC_ADDR_REQ

Format

Parameters

The primitive has the following arguments:

Flags

Valid State

New State

Rules

Acknowledgement

4.1.2.5 Transaction Protocol Address Acknowledgement

TC_ADDR_ACK

Format

The format of the message is one `M_PCPROTO' message block structured as follows:

Parameters

The primitive has the following arguments:

Flags

Valid State

New State

Rules

Acknowledgement

4.1.3 Transaction Options Management

4.1.3.1 Transaction Options Management Request

TC_OPTMGMT_REQ

Format

     typedef struct TC_optmgmt_req {
             ulong PRIM_type;
             ulong OPT_length;
             ulong OPT_offset;
             ulong MGMT_flags;
     } TC_optmgmt_req_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_OPTMGMT_REQ'.

OPT_length

Indicates the length of the protocol options associated with the primitive.

OPT_offset

Indicates the offset from the beginning of the `M_PROTO' message block where the protocol options begin.

MGMT_flags

Flags

Valid State

New State

Rules

Acknowledgement

4.1.3.2 Transaction Options Management Acknowledgement

TC_OPTMGMT_ACK

Format

The format of the message is one `M_PCPROTO' message block structured as follows:

     typedef struct TC_optmgmt_ack {
             ulong PRIM_type;
             ulong OPT_length;
             ulong OPT_offset;
             ulong MGMT_flags;
     } TC_optmgmt_ack_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_OPTMGMT_ACK'.

OPT_length

Indicates the length of the protocol options associated with the primitive.

OPT_offset

Indicates the offset from the beginning of the `M_PROTO' message block where the protocol options begin.

MGMT_flags

Flags

Valid State

New State

Rules

Acknowledgement

4.1.4 Transaction Error Management

4.1.4.1 Transaction Successful Receipt Acknowledgement

TC_OK_ACK

Format

The format of the message is one `M_PCPROTO' message block structured as follows:

     typedef struct TC_ok_ack {
             ulong PRIM_type;
             ulong CORRECT_prim;
     } TC_ok_ack_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_OK_ACK'.

CORRECT_prim

Flags

Valid State

New State

Rules

Acknowledgement

4.1.4.2 Transaction Error Acknowledgement

TC_ERROR_ACK

Format

The format of the message is one `M_PCPROTO' message block structured as follows:

     typedef struct TC_error_ack {
             ulong PRIM_type;
             ulong ERROR_prim;
             ulong TRPI_error;
             ulong UNIX_error;
             ulong DIALOG_id;
             ulong INVOKE_id;
     } TC_error_ack_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_ERROR_ACK'.

ERROR_prim

TRPI_error

UNIX_error

DIALOG_id

Indicates the dialogue identifier which uniquely identifies this transaction dialogue within the stream. Dialogue identifiers assigned by the component user must have the high bit set to one (1); those assigned by the component provider have the high bit set to zero (0).

INVOKE_id

Flags

Valid State

New State

Rules

Acknowledgement

4.2 Operation Class 1, 2 and 3 Primitives

This section describes the operation class 1, 2, and 3 dialogue handling primitives. Primitives are grouped into phases:

1. Transaction Establishment Phase

   See Transaction Establishment Phase.

2. Transaction Data Transfer Phase

   See Transaction Data Transfer Phase.

3. Transaction Termination Phase

   See Transaction Termination Phase.

4.2.1 Transaction Establishment Phase

The transaction begin service provides means to start a transaction dialogue between two TC-users. This may be accompanied by the transfer of components previously accumulated using the component handling primitives described in Component Handling Primitives.

4.2.1.1 Transaction Begin Request

TC_BEGIN_REQ

This primitive requests that the transaction component provider form a transaction dialogue to the specified destination protocol address, from the specified source protocol address, using the specified options. Any components that have been accumulated using the component handling primitives (see Component Handling Primitives), will accompany the primitive.

Format

The format of the message is one `M_PROTO' message block followed by zero or more `M_DATA' message blocks containing raw transaction user information. The `M_PROTO' message block is structured as follows:

     typedef struct TC_begin_req {
             ulong PRIM_type;                /* Always TC_BEGIN_REQ */
             ulong SRC_length;               /* Source address length */
             ulong SRC_offset;               /* Source address offset */
             ulong DEST_length;              /* Destination address length */
             ulong DEST_offset;              /* Destination address offset */
             ulong OPT_length;               /* Options associated with the primitive */
             ulong OPT_offset;               /* Options associated with the primitive */
             ulong DIALOG_id;                /* Dialog Identifier */
             ulong COMP_flags;               /* For use with ANSI QWP/QWOP */
     } TC_begin_req_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Specifies the primitive type. Always `TC_BEGIN_REQ'.

SRC_length

Specifies the length of the source protocol address associated with the primitive.

SRC_offset

Specifies the offset from the beginning of the `M_PROTO' message block where the source protocol address begins. Proper alignment of the protocol address in the `M_PROTO' message block is not guaranteed.

DEST_length

Specifies the length of the destination protocol address associated with the primitive.

DEST_offset

Specifies the offset from the beginning of the `M_PROTO' message block where the destination protocol address begins. Proper alignment of the protocol address in the `M_PROTO' message block is not guaranteed.

OPT_length

Specifies the length of the protocol options associated with the primitive.

OPT_offset

Specifies the offset from the beginning of the `M_PROTO' message block where the protocol options begin.

DIALOG_id

Specifies the dialogue identifier which uniquely identifies this transaction dialogue within the stream. Dialogue identifiers assigned by the component user must have the high bit set to one (1); those assigned by the component provider have the high bit set to zero (0).

COMP_flags

Specifies additional information about the components. See “Flags” below. Component flags may be provider specific.

Flags

The COMP_flags field can contain any of the following flags:

COMPONENTS_PRESENT

Specifies, when set, that components previously accumulated with the component handling primitives (see Component Handling Primitives) are to be associated with the primitive.

NO_PERMISSION

Specifies, when set, that the the peer is not granted permission to end the transaction upon the receipt of the corresponding `TC_BEGIN_IND' primitive.

Valid State

This primitive is valid in transaction state TC_IDLE.

New State

The new state for the transaction is TC_WACK_CREQ.

Rules

The following rules apply to the specification of parameters to this primitive:

• When the source address is not specified, SRC_length and SRC_offset must be specified as zero (0).
• When the SRC_length and SRC_offset are zero (0), the source protocol address is the local address that is implicitly associated with the access point from the local bind service (see TC_BIND_REQ).
• The destination protocol address must be specified and the TC provider will return error `TCNOADDR' if the DEST_length and DEST_offset are zero (0).

Acknowledgement

This primitive requires the transaction provider to generate one of the following acknowledgements upon receipt of the primitive:

• Successful Dialogue Establishment: This is indicated with the `TC_BEGIN_CON' primitive described in TC_BEGIN_REQ. This results in the TC_DATA_XFER state for the transaction. Successful establishment and tear down can also be indicated with the `TC_END_IND' primitive described in TC_END_IND. This results in the TC_IDLE state for the transaction.
• Unsuccessful Dialogue Establishment: This is indicated with the `TC_ABORT_IND' primitive described in TC_ABORT_IND. For example, an dialogue may be rejected because either the called transaction user cannot be reached, or the transaction provider or the called transaction user did not agree on the specified options. This results in the TC_IDLE state for the transaction.
• Successful: Correct acknowledgement of the primitive is indicated with the `TC_OK_ACK' primitive described in TC_OK_ACK.
• Non-fatal errors: These are indicated with the `TC_ERROR_ACK' primitive. The applicable non-fatal errors are defined as follows:

  TCACCES

  This indicates that the user did not have proper permissions for the use of the requested protocol address or protocol options.

  
  

  TCBADADDR

  This indicates that the protocol address was in an incorrect format or the address contained illegal information. It is not intended to indicate protocol connection errors, such as an unreachable destination. Those types of errors are indicated with the `TC_ABORT_IND' primitive described in TC_ABORT_IND.

  
  

  TCBADOPT

  This indicates that the options were in an incorrect format or they contained illegal information.

  
  

  TCOUTSTATE

  The primitive would place the transaction interface out of state.

  
  

  TCBADDATA

  The amount of user data specified was illegal (see TC_INFO_ACK).

  
  

  TCBADFLAG

  The flags specified were incorrect, not supported by the provider, or contained illegal information.

  
  

  TCBADSEQ

  The specified dialogue identifier DIALOG_id was incorrect, or contained illegal information. This error would normally occur if the TC user selected a dialogue identifier reserved for the provider (high bit set to 0).

  
  

  TCSYSERR

  A system error has occured and the UNIX System error is indicated in the primitive.

4.2.1.2 Transaction Begin Indication

TC_BEGIN_IND

The transaction indication service primitive indicates that a peer TC user has initiated a transaction dialogue, the source protocol address associated with the peer TC user, the destination address to which the transaction dialogue is initiated, the options for the dialogue.

Format

The format of the message is one `M_PROTO' message block structured as follows:

     typedef struct TC_begin_ind {
             ulong PRIM_type;                /* Always TC_BEGIN_IND */
             ulong SRC_length;               /* Source address length */
             ulong SRC_offset;               /* Source address offset */
             ulong DEST_length;              /* Destination address length */
             ulong DEST_offset;              /* Destination address offset */
             ulong OPT_length;               /* Options associated with the primitive */
             ulong OPT_offset;               /* Options associated with the primitive */
             ulong DIALOG_id;                /* Dialog Identifier */
             ulong COMP_flags;               /* For use with ANSI QWP/QWOP */
     } TC_begin_ind_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_BEGIN_IND'.

SRC_length

Indicates the length of the source protocol address associated with the primitive.

SRC_offset

Indicates the offset from the beginning of the `M_PROTO' message block where the source protocol address begins.

DEST_length

Indicates the length of the destination protocol address associated with the primitive.

DEST_offset

Indicates the offset from the beginning of the `M_PROTO' message block where the destination protocol address begins.

OPT_length

Indicates the length of the protocol options associated with the primitive.

OPT_offset

Indicates the offset from the beginning of the `M_PROTO' message block where the protocol options begin.

DIALOG_id

Indicates the dialogue identifier which uniquely identifies this transaction dialogue within the stream. Dialogue identifiers assigned by the component user must have the high bit set to one (1); those assigned by the component provider have the high bit set to zero (0).

COMP_flags

Indicates additional information about the components. See “Flags” below. Component flags may be provider specific.

Flags

The COMP_flags field can contain any of the following flags:

TC_COMPONENTS_PRESENT

Indicates, when set, that component handling primitives representing the components associated with the begin indication follow this primitive.

TC_NO_PERMISSION

Indicates, when set, that the TC user is not permitted to end the dialogue upon receipt of this primitive, nor when issuing a response.

Valid State

This primitive is valid in transaction state TC_IDLE.

New State

The new state of the transaction is TC_WRES_CIND.

Rules

The following rules apply to the issuance of this primitive by the transaction provider:

• The dialogue identifier provided by the transaction provider uniquely identifies this transaction begin indication within the stream upon which the primitive is issued. This must be a positive, non-zero value. The high bit of the transaction identifier is reserved for exclusive use by the transaction user in generating correlation identifiers.
• It is not necessary to indicate a destination address in DEST_length, and DEST_offset when the protocol address to which the begin indication corresponds is the same as the local protocol address to which the listening stream is bound. In the case that the destination protocol address is not provided, DEST_length and DEST_offset must both be set to zero (0). When the local protocol address to which the begin indication corresponds is not the same as the bound address for the stream, the transaction provider must indicate the destination protocol address using DEST_length and DEST_offset.
• The source protocol address is a mandatory field. The transaction provider must indicate the source protocol address corresponding to the begin indication using the SRC_length and SRC_offset fields.
• Any indicated options are included in the OPT_length and OPT_offset fields.
• When the `TC_NO_PERMISSION' flag is set, the TC user must not issue a `TC_END_REQ' primitive in response to this indication.

4.2.1.3 Transaction Begin Response

TC_BEGIN_RES

This primitive allows the destination TC user to request that the TC provider accept a previous transaction dialogue begin indication, either on the current stream or on a specified acceptor stream.

Format

The format of the message is one `M_PROTO' message block structured as follows:

     typedef struct TC_begin_res {
             ulong PRIM_type;                /* Always TC_CONT_REQ */
             ulong SRC_length;               /* Source address length */
             ulong SRC_offset;               /* Source address offset */
             ulong OPT_length;               /* Options associated with the primitive */
             ulong OPT_offset;               /* Options associated with the primitive */
             ulong DIALOG_id;                /* Dialog Identifier */
             ulong COMP_flags;               /* For use with ANSI CWP/CWOP */
     } TC_begin_res_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Specifies the primitive type. Always `TC_BEGIN_RES'.

SRC_length

Specifies the length of the source protocol address associated with the primitive.

SRC_offset

Specifies the offset from the beginning of the `M_PROTO' message block where the source protocol address begins. Proper alignment of the protocol address in the `M_PROTO' message block is not guaranteed.

OPT_length

Specifies the length of the protocol options associated with the primitive.

OPT_offset

Specifies the offset from the beginning of the `M_PROTO' message block where the protocol options begin.

DIALOG_id

Specifies the dialogue identifier which uniquely identifies this transaction dialogue within the stream. Dialogue identifiers assigned by the component user must have the high bit set to one (1); those assigned by the component provider have the high bit set to zero (0).

COMP_flags

Specifies additional information about the components. See “Flags” below. Component flags may be provider specific.

Flags

The COMP_flags field can contain any of the following flags:

TC_COMPONENTS_PRESENT

Specifies, when set, that component handling primitives representing the components associated with the begin indication precede this primitive.

TC_NO_PERMISSION

Specifies, when set, that the TC user peer is not permitted to end the dialogue upon receipt of this primitive, nor when issuing a response.

Valid State

This primitive is valid in transaction state TC_WRES_CIND.

New State

The new state of the transaction is TC_DATA_XFER.

Rules

Acknowledgement

This primitive requires the TC provider to generate one of the following acknowledgements upon receipt of the primitive:

• Successful: Correct acknowledgement of the primitive is indicated with the TC_OK_ACK primitive described in TC_OK_ACK.
• Unsuccessful (Non-fatal errors): These errors will be indicated with the TC_ERROR_ACK primitive described in TC_ERROR_ACK. The allowable errors are as follows:

  TCBADF

  The token specified is not associated with an open stream.

  
  

  TCBADOPT

  The options were in an incorrect format, or they contained illegal information.

  
  

  TCACCES

  The user did not have proper permissions for the use of the responding protocol address or protocol options.

  
  

  TCOUTSTATE

  The primitive would place the transaction interface out of state for the indicated transaction.

  
  

  TCBADDATA

  The amount of user data specified was outside the range supported by the transaction provider.

  
  

  TCBADFLAG

  The flags specified were incorrect, not supported by the provider, or contained illegal information.

  
  

  TCBADSEQ

  The specified dialogue identifier DIALOG_id was incorrect, or contained illegal information. This error would normally occur if the TC user selected a dialogue identifier reserved for the provider (high bit set to 0).

  
  

  TCSYSERR

  A system error occurred and the UNIX System error is indicated in the primitive.

  
  

  TCRESADDR

  The transaction provider requires that the responding stream is bound to the same address as the stream on which the transaction dialogue begin indication was received.

  
  

  TCBADADDR

  This indicates that the protocol address was in an incorrect format or the protocol address contained illegal information.

4.2.1.4 Transaction Begin Confirm

TC_BEGIN_CON

Format

The format of the message is one `M_PROTO' message block structured as follows:

     typedef struct TC_begin_con {
             ulong PRIM_type;                /* Always TC_CONT_IND */
             ulong OPT_length;               /* Options associated with the primitive */
             ulong OPT_offset;               /* Options associated with the primitive */
             ulong DIALOG_id;                /* Dialog Identifier */
             ulong COMP_flags;               /* For use with ANSI CWP/CWOP */
     } TC_begin_con_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_BEGIN_CON'.

OPT_length

Indicates the length of the protocol options associated with the primitive.

OPT_offset

Indicates the offset from the beginning of the `M_PROTO' message block where the protocol options begin.

DIALOG_id

Indicates the dialogue identifier which uniquely identifies this transaction dialogue within the stream. Dialogue identifiers assigned by the component user must have the high bit set to one (1); those assigned by the component provider have the high bit set to zero (0).

COMP_flags

Indicates additional information about the components. See “Flags” below. Component flags may be provider specific.

Flags

Valid State

New State

Rules

Acknowledgement

4.2.2 Transaction Data Transfer Phase

The component transfer service primtiives provide for an exchange of component user data known as TSDUs, in either direction or in both directions simultaneously on a transaction dialogue. The transaction service preserves both the sequence and the boundaries of the TSDUs.

4.2.2.1 Transaction Continue Request

TC_CONT_REQ

Format

The format of the message is one `M_PROTO' message block structured as follows:

     typedef struct TC_cont_req {
             ulong PRIM_type;                /* Always TC_CONT_REQ */
             ulong OPT_length;               /* Options associated with the primitive */
             ulong OPT_offset;               /* Options associated with the primitive */
             ulong DIALOG_id;                /* Dialog Identifier */
             ulong COMP_flags;               /* For use with ANSI CWP/CWOP */
     } TC_cont_req_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Specifies the primitive type. Always `TC_CONT_REQ'.

OPT_length

Specifies the length of the protocol options associated with the primitive.

OPT_offset

Specifies the offset from the beginning of the `M_PROTO' message block where the protocol options begin.

DIALOG_id

Specifies the dialogue identifier which uniquely identifies this transaction dialogue within the stream. Dialogue identifiers assigned by the component user must have the high bit set to one (1); those assigned by the component provider have the high bit set to zero (0).

COMP_flags

Specifies additional information about the components. See “Flags” below. Component flags may be provider specific.

Flags

Valid State

New State

Rules

Acknowledgement

4.2.2.2 Transaction Continue Indication

TC_CONT_IND

Format

The format of the message is one `M_PROTO' message block structured as follows:

     typedef struct TC_cont_ind {
             ulong PRIM_type;                /* Always TC_CONT_IND */
             ulong OPT_length;               /* Options associated with the primitive */
             ulong OPT_offset;               /* Options associated with the primitive */
             ulong DIALOG_id;                /* Dialog Identifier */
             ulong COMP_flags;               /* For use with ANSI CWP/CWOP */
     } TC_cont_ind_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_CONT_IND'.

OPT_length

Indicates the length of the protocol options associated with the primitive.

OPT_offset

Indicates the offset from the beginning of the `M_PROTO' message block where the protocol options begin.

DIALOG_id

Indicates the dialogue identifier which uniquely identifies this transaction dialogue within the stream. Dialogue identifiers assigned by the component user must have the high bit set to one (1); those assigned by the component provider have the high bit set to zero (0).

COMP_flags

Indicates additional information about the components. See “Flags” below. Component flags may be provider specific.

Flags

Valid State

New State

Rules

Acknowledgement

4.2.3 Transaction Termination Phase

4.2.3.1 Transaction End Request

TC_END_REQ

Format

The format of the message is one `M_PROTO' message block structured as follows:

     typedef struct TC_end_req {
             ulong PRIM_type;                /* Always TC_END_REQ */
             ulong OPT_length;               /* Options associated with the primitive */
             ulong OPT_offset;               /* Options associated with the primitive */
             ulong DIALOG_id;                /* Dialog Identifier */
             ulong TERM_scenario;            /* Reason for termination */
     } TC_end_req_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Specifies the primitive type. Always `TC_END_REQ'.

OPT_length

Specifies the length of the protocol options associated with the primitive.

OPT_offset

Specifies the offset from the beginning of the `M_PROTO' message block where the protocol options begin.

DIALOG_id

Specifies the dialogue identifier which uniquely identifies this transaction dialogue within the stream. Dialogue identifiers assigned by the component user must have the high bit set to one (1); those assigned by the component provider have the high bit set to zero (0).

TERM_scenario

Flags

Valid State

New State

Rules

Acknowledgement

4.2.3.2 Transaction End Indication

TC_END_IND

Format

The format of the message is one `M_PROTO' message block structured as follows:

     typedef struct TC_end_ind {
             ulong PRIM_type;                /* Always TC_END_IND */
             ulong OPT_length;               /* Options associated with the primitive */
             ulong OPT_offset;               /* Options associated with the primitive */
             ulong DIALOG_id;                /* Dialog Identifier */
             ulong COMP_flags;               /* Components present flag */
     } TC_end_ind_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_END_IND'.

OPT_length

Indicates the length of the protocol options associated with the primitive.

OPT_offset

Indicates the offset from the beginning of the `M_PROTO' message block where the protocol options begin.

DIALOG_id

Indicates the dialogue identifier which uniquely identifies this transaction dialogue within the stream. Dialogue identifiers assigned by the component user must have the high bit set to one (1); those assigned by the component provider have the high bit set to zero (0).

COMP_flags

Indicates additional information about the components. See “Flags” below. Component flags may be provider specific.

Flags

Valid State

New State

Rules

Acknowledgement

4.2.3.3 Transaction Abort Request

TC_ABORT_REQ

Format

The format of the message is one `M_PROTO' message block structured as follows:

     typedef struct TC_abort_req {
             ulong PRIM_type;                /* Always TC_ABORT_REQ */
             ulong OPT_length;               /* Options associated with the primitive */
             ulong OPT_offset;               /* Options associated with the primitive */
             ulong DIALOG_id;                /* Dialog Identifier */
             ulong ABORT_reason;             /* Abort reason */
     } TC_abort_req_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Specifies the primitive type. Always `TC_ABORT_REQ'.

OPT_length

Specifies the length of the protocol options associated with the primitive.

OPT_offset

Specifies the offset from the beginning of the `M_PROTO' message block where the protocol options begin.

DIALOG_id

Specifies the dialogue identifier which uniquely identifies this transaction dialogue within the stream. Dialogue identifiers assigned by the component user must have the high bit set to one (1); those assigned by the component provider have the high bit set to zero (0).

ABORT_reason

Flags

Valid State

New State

Rules

Acknowledgement

4.2.3.4 Transaction Abort Indication

TC_ABORT_IND

Format

The format of the message is one `M_PROTO' message block structured as follows:

     typedef struct TC_abort_ind {
             ulong PRIM_type;                /* Always TC_ABORT_IND */
             ulong OPT_length;               /* Options associated with the primitive */
             ulong OPT_offset;               /* Options associated with the primitive */
             ulong DIALOG_id;                /* Dialog Identifier */
             ulong ABORT_reason;             /* Abort reason */
             ulong ORIGINATOR;               /* Either User or Provider originated */
     } TC_abort_ind_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Indicates the primitive type. Always `TC_ABORT_IND'.

OPT_length

Indicates the length of the protocol options associated with the primitive.

OPT_offset

Indicates the offset from the beginning of the `M_PROTO' message block where the protocol options begin.

DIALOG_id

Indicates the dialogue identifier which uniquely identifies this transaction dialogue within the stream. Dialogue identifiers assigned by the component user must have the high bit set to one (1); those assigned by the component provider have the high bit set to zero (0).

ABORT_reason

ORIGINATOR

Flags

Valid State

New State

Rules

Acknowledgement

4.3 Operation Class 4 Primitives

4.3.1 Transaction Phase

4.3.1.1 Transaction Unidirectional Request

TC_UNI_REQ

Format

The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any components are specified by the TC user. The format of the `M_PROTO' message block is as follows:

     typedef struct TC_uni_req {
             ulong PRIM_type;                /* Always TC_UNI_REQ */
             ulong SRC_length;               /* Source address length */
             ulong SRC_offset;               /* Source address offset */
             ulong DEST_length;              /* Destination address length */
             ulong DEST_offset;              /* Destination address offset */
             ulong OPT_length;               /* Options associated with the primitive */
             ulong OPT_offset;               /* Options associated with the primitive */
             ulong DIALOG_id;                /* Dialog Identifier */
     } TC_uni_req_t;
     

Parameters

The primitive has the following arguments:

PRIM_type

Specifies the primitive type. Always `TC_UNI_REQ'.

SRC_length

Specifies the length of the source protocol address associated with the primitive.

SRC_offset

Specifies the offset from the beginning of the `M_PROTO' message block where the source protocol address begins.

DEST_length

Specifies the length of the destination protocol address associated with the primitive.

DEST_offset

Specifies the offset from the beginning of the `M_PROTO' message block where the destination protocol address begins.

OPT_length

Specifies the length of the protocol options associated with th