Figure 1. Model of the TRI
This document is a Application Program Interface containing technical details concerning the implementation of the Transaction Interface (TRI) for OpenSS7. It contains recommendations on software architecture as well as platform and system applicability of the Transaction Interface (TRI).
The purpose of this document is to provide technical documentation of the Transaction Interface (TRI). 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 Interface (TRI) with understanding the software architecture and technical interfaces which are made available in the software package.
It is the intent of this document that it act as the primary source of information concerning the Transaction Interface (TRI).
The audience for this document is software developers, maintainers and users and integrators of the Transaction Interface (TRI).
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.
Only the texinfo or roff source is controlled. A printed (or postscript) version of this document is an UNCONTROLLED VERSION.
This document specifies a STREAMS-based kernel-level instantiation of the ITU-T Transaction Capabilities Application Part (TCAP) Transaction (TR) Sub-Layer. The Transaction Interface (TRI) enables the user of a transaction 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. This interface only specifies access to transaction sub-layer services providers, and does not address issues concerning transaction 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.
This document specifies an interface that supports the service provided by the Association Control Service Element (ACSE) for Open Systems Interconnect for ITU-T Applications as specified in ITU-T Recommendation X.217 (ISO/IEC 8649). It is also intended to support the Transaction Sub-layer provided by the Transaction Capabilities Application Part (TCAP) for Signalling System Number 7 (SS7) as specified in ITU-T Recommendation Q.771. These specifications are targeted for use by developers and testers of protocol modules that require transaction sub-layer service.1
The Transaction Sub-Layer provides the means to manage the association of TR-User into transactions. It is responsible for the routing and management of transaction associations between TR-user entities.
The TRI defines the services provided by the transaction sub-layer to the transaction-user at the boundary between the Transaction Component (TC) Sub-Layer and the Transaction (TR) 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 transaction sub-layer services, and are transferred between the TR user entity and the TR provider. These primitives are of two types: ones that originate from the TR user, and others that originate from the TR provider, or respond to an event of the TR provider. The primitives that originate from the TR provider are either confirmations of a request or are indications to the NS user that the event has occurred. Figure 1 shows the model of the TRI.
|
Figure 1. Model of the TRI
|
The TRI allows the TR provider to be configured with any transaction sub-layer user (such as the Transaction Component (TC) Sub-Layer) that also conforms to the TRI. A transaction sub-layer user can also be a user program that conforms to the TRI and accesses the TR provider via putmsg(2) and getmsg(2) system calls.
STREAMS messages that are used to communicate transaction service primitives between the transaction user and the transaction provider may have one of the following formats:
The following sections describe the service primitives which define both connection-mode and connectionless-mode service.
For both types 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 TRI Primitives. The format of these primitives and the rules governing the use of them are described in Management Primitives, Connection-Oriented Mode Primitives, and Connectionless Mode Primitives.
The features of the TRI are defined in terms of the services provided by the service provider, and the individual primitives that may flow between the service user and the service provider.
The services supported by the TRI are based on two distinct modes of communication, connection-mode transaction service (COTS) and connectionless transaction service (CLTS). Also, the TRI supports services for local management.
The main features of the connection mode communication are:
There are three phases to each instance of communication: Transaction Establishment, Data Transfer, and Transaction Release. Units of data arrive at the 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.
The main features of the connectionless mode communication are:
Connectionless mode communication has no separate phases. Each unit of data is transmitted from source to destination independently, appropriate addressing information is included with each unit of data. As the units of data are transmitted independently from source to destination, there are, in general, no guarantees of proper sequence and completeness of the data stream.
The TRI specifications also define a set of local management functions that apply to both COTS and CLTS modes of communication. These services have local significance only.
Table 1 and Table 2 summarizes the TRI service primitives by their state and service.
This section describes the services of the TRI primitives. Time-sequence diagrams 3 that illustrate the sequence of primitives are used. The format of the primitives will be defined later in this document.
The services defined in this section are outside the scope of the international standards. These services apply to both connection-mode as well as connectionless modes of communication. They are involved for the initialization/de-initialization of a stream connected to the TR provider. They are also used to manage options supported by the TR provider and to report information on the supported parameter values.
This service provides information on the options supported by the TR provider.
The sequence of primitives for transaction information management is shown in Figure 2.
 Figure 2. Sequence of Primitives
Transaction Information Reporting Service
|
This service allows an originating address to be associated with a stream. It allows the TR user to negotiate the number of transaction begin indications that can remain unacknowledged for that TR user (a transaction begin indication is considered unacknowledged while it is awaiting a corresponding transaction response or abort request from the TR user). This service also defines a mechanism that allows a stream (bound to the address of the TR user) to be reserved to handle incoming transactions only. This stream is referred to as the listener stream.
The sequence of primitives for the TR user bind service is shown in Figure 3.
 Figure 3. Sequence of Primitives
TR User Bind Service
|
This service allows the TR user to be unbound from a protocol address.
The sequence of primitives for the TR user unbind service is shown in Figure 4.
 Figure 4. Sequence of Primitives
TR User Unbind and Receipt Acknowledgement Services
|
An example showing the sequence of primitives for successful receive acknowledgement is depicted in Figure 4.
This service allows the TR user to manage the QOS parameter values associated with the TR provider.
Figure 5 shows the sequence of primitives for transaction options management.
 Figure 5. Sequence of Primitives
Options Management Service
|
Figure 6 shows the sequence of primitives for the error management primitive.
 Figure 6. Sequence of Primitives
Error Acknowledgement Service
|
This section describes the required transaction service primitives that define the connection mode interface.
The queue model for connection-oriented services are discussed in more detail in ITU-T X.217 and ITU-T Q.771.
The queue model represents the operation of a transaction association in the abstract by a pair of queues linking two transaction users. There is one queue for each direction of data 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 association. 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 TR provider initiatives.
Table 3 shows the ordering relationships among the queue model objects.
A pair of queues is associated with a transaction association between two transaction users when the TR provider receives a TR_BEGIN_REQ primitive at one of the TR users resulting in a begin object being entered into the queue. The queues will remain associated with the transaction until a TR_END_REQ or TR_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 TR user, objects can be entered into the queue only after the begin object associated with the TR_BEGIN_RES has been entered into the queue. Alternatively, the destination TR 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 TR provider is unable to establish a transaction association, or if the destination TR user is unable to accept the TR_BEGIN_IND (see Transaction Termination primitive definition in TR_END_IND).
The following user primitives support COTS Phase I (Transaction Establishment) services:
The following provider primitives support COTS Phase I (Transaction Establishment) services:
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 TR_BIND_REQ, and TR_BIND_ACK).
 Figure 8. Sequence of Primitives:
Transaction Response Token Value Determination
|
Flow control on the transaction association 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.
The following primitives support COTS Phase II (Transaction Data Transfer) services:
Figure 9 shows the sequence of primitives for successful user data transfer. The sequence of primitives may remain incomplete if a TR_END_REQ, TR_END_IND, TR_ABORT_REQ, or TR_ABORT_IND primitive occurs.
 Figure 9. Sequence of Primitives:
Data Transfer
|
The transaction association procedure is initialized by insertion of an end or abort object (associated with a TR_END_REQ or TR_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 association.
The sequence of primitives depends on the origin of the termination action. The sequence may be:
The following primitives support CONS Phase III (Transaction Termination) services:
The sequence of primitives are shown in the time sequence diagrams in the figures that follow:
 Figure 10. Sequence of Primitives:
TR User Invoked Termination
|
 Figure 11. Sequence of Primitives:
Simultaneous TR User Invoked Termination
|
 Figure 12. Sequence of Primitives:
TR Provider Invoked Termination
|
 Figure 13. Sequence of Primitives:
Simultaneous TR User and TR Provider Invoked Termination
|
A TR user may reject a transaction initiation attempt by issuing a TR_ABORT_REQ. The originator parameter in the TR_ABORT_REQ will indicate TR user invoked termination. The sequence of primitives is shown in Figure 14.
 Figure 14. Sequence of Primitives:
TR User Rejection of a Transaction Initiation Attempt
|
If the TR provider is unable to establish a transaction, it indicates this to the requester by an TR_ABORT_IND. The originator of the primitive indicates a TR provider invoked release. This is shown in Figure 15.
 Figure 15. Sequence of Primitives:
TR Provider Rejection of a Transaction Initiation Attempt
|
The connectionless mode service allows for the transfer of transaction user data in one and both directions simultaneously without establishing a transaction dialogue. A set of primitives are defined that carry transaction user data and control information between the TR user and the TR provider entities. The primitives are modelled as requests initiated by the TR user and indications initiated by the TR provider. Indications may be initiated by the TR provider independently from requests by the TR user.
The connectionless mode service consists of one phase.
Figure 16 shows the sequence of primitives for the connectionless mode of transfer.
 Figure 16. Sequence of Primitives:
Connectionless Mode Data Transfer
|
Figure 17 shows the sequence of primitives for the CLTS error management primitive.
 Figure 17. Sequence of Primitives:
CLTS Error Indication Service
|
This section describes the format and parameters of the TRI primitives. In addition, it discusses the states in which the primitive is valid, the resulting state, and the acknowledgement that the primitive expects.
The mapping of TRI of TRI primitives to the primitives defined in ITU-T Q.771, ITU-T X.219 and ANSI T1.114 are shown in Mapping TRI Primitives. The state/event tables for these primitives are shown in State/Event Tables. The precedence tables for the TRI primitives are shown in Primitive Precedence Tables.
The following tables provide a summary of the TR primitives and their parameters.
These primitives apply to all transaction modes.
This primitive request the TR provider to return the values of all supported protocol parameters (see TR_INFO_ACK), and also the current state of the TR provider (as defined in State/Event Tables). This primitive does not affect the state of the TR provider and does not appear in the state tables.
The format of the message is one `M_PCPROTO' message block and its structure is as follows:
typedef struct TR_info_req {
ulong PRIM_type; /* Always TR_INFO_REQ */
} TR_info_req_t;
The primitive has the following arguments:
This primitive is valid in any state where a local acknowledgement is not pending.
The new state remains unchanged.
For the rules governing the requests made by this primitive, see the `TR_INFO_ACK' primitive described in TR_INFO_ACK.
This primitive requires the TR provider to generate one of the following acknowledgements upon receipt of the primitive:
TR_INFO_ACK primitive described in TR_INFO_ACK.
TR_ERROR_ACK primitive described
in TR_ERROR_ACK. The allowable errors are as follows:
There are no errors associated with the issuance of this primitive.
This primitive indicates to the TR user any relevant protocol-dependent parameters.4 It should be initiated in response to the TR_INFO_REQ primitive described above under TR_INFO_REQ.
The format of the message is one `M_PCPROTO' message block and its structure is as follows:
typedef struct TR_info_ack {
long PRIM_type; /* Always TR_INFO_ACK */
long ASDU_size; /* maximum ASDU size */
long EASDU_size; /* maximum EASDU size */
long CDATA_size; /* connect data size */
long DDATA_size; /* discon data size */
long ADDR_size; /* address size */
long OPT_size; /* options size */
long TIDU_size; /* transaction i/f data unit size */
long SERV_type; /* service type */
long CURRENT_state; /* current state */
long PROVIDER_flag; /* type of TR provider */
long TRI_version; /* version # of tri that is supported */
} TR_info_ack_t;
The primitive has the following arguments:
This primitive requests that the TR provider bind a protocol address to the stream, negotiate the number of dialogue indications allowed to be outstanding by the TR provider for the specified protocol address, and activate5 the stream associated with the protocol address.
The format of the message is one `M_PROTO' message block. The format of the `M_PROTO' message block is as follows:6
typedef struct TR_bind_req {
ulong PRIM_type; /* Always TR_BIND_REQ */
ulong ADDR_length; /* address length */
ulong ADDR_offset; /* address offset */
ulong XACT_number; /* maximum outstanding transaction reqs. */
ulong BIND_flags; /* bind flags */
} TR_bind_req_t;
The primitive has the following arguments:
This primitive is valid in state `TRS_UNBND'.
The new state is `TRS_WACK_BREQ'.
For the rules governing the requests made by this primitive, see the
TR_BIND_ACK primitive described in TR_BIND_ACK.
This primitive requires the TR provider to generate one of the following acknowledgements upon receipt of the primitive:
TR_BIND_ACK primitive described in TR_BIND_ACK.
TR_ERROR_ACK primitive described
in TR_ERROR_ACK. The allowable errors are as follows:
TRBAADDRTRNOADDRTRACCESTROUTSTATETRSYSERRTRADDRBUSYThis primitive indicates to the TR user that the specified protocol address has been bound to the stream, that the specified number of dialogue indications are allowed to be queued by the TR provider for the specified protocol address, and that the stream associated with the specified protocol address has been activated.
The format of the message is one `M_PCPROTO' message block. The format of the `M_PCPROTO' message block is as follows:
typedef struct TR_bind_ack {
ulong PRIM_type; /* Always TR_BIND_ACK */
ulong ADDR_length; /* address length */
ulong ADDR_offset; /* address offset */
ulong XACT_number; /* open transactions */
ulong TOKEN_value; /* value of "token" assigned to stream */
} TR_bind_ack_t;
The primitive has the following arguments:
This primitive is issued in response to a `TR_BIND_REQ' and is valid in state `TRS_WACK_BREQ'.
On success, the new state is `TRS_IDLE'; on error, `TRS_UNBND'.
The following rules apply to the binding of the specified protocol address to the stream:
The following rules apply to negotiating the XACT_number argument:
If the above rules result in an error condition, then the TR provider must issue a `TR_ERROR_ACK' primitive to the TR user specifying the error as defined in the description of the `TR_BIND_REQ' primitive, TR_BIND_REQ.
This primitive requests that the TR provider unbind the protocol address previously associated with the stream and deactivate the stream.
The format of the message is one `M_PROTO' message block structured as follows:
typedef struct TR_unbind_req {
ulong PRIM_type; /* Always TR_UNBIND_REQ */
} TR_unbind_req_t;
The primitive has the following arguments:
This primitive is valid in state `TRS_IDLE'.
The new state is `TRS_WACK_UREQ'.
This primitive requires the TR provider to generate one of the following acknowledgements upon receipt of the primitive:
TR_OK_ACK
primitive described in TR_OK_ACK.
TR_ERROR_ACK primitive described
in TR_ERROR_ACK. The allowable errors are as follows:
This primitive requests that the TR provider return the local protocol address that is bound to the stream and the address of the remote ASE if a transaction association has been established.
The format of the message is one `M_PROTO' message block structured as follows:
typedef struct TR_addr_req {
long PRIM_type; /* always TR_ADDR_REQ */
ulong TRANS_id; /* Transaction id */
} TR_addr_req_t;
The primitive has the following arguments:
This primitive is valid in any state where a local acknowledgement is not pending.
The new state is unchanged.
For the rules governing the requests made by this primitive, see the
TR_ADDR_ACK primitive described in TR_ADDR_ACK.
This primitive requires the TR provider to generate one of the following acknowledgements upon receipt of the primitive:
TR_ADDR_ACK primitive described in TR_ADDR_ACK.
TR_ERROR_ACK primitive described
in TR_ERROR_ACK. The allowable errors are as follows:
This primitive indicates to the TR user the addresses of the local and remote ASE. The local address is the protocol address that has been bound to the stream. If an transaction association has been established, the remote address is the protocol address of the remote ASE.
The format of the message is one `M_PCPROTO' message block structured as follows:
typedef struct TR_addr_ack {
long PRIM_type; /* always TR_ADDR_ACK */
long LOCADDR_length; /* length of local address */
long LOCADDR_offset; /* offset of local address */
long REMADDR_length; /* length of remote address */
long REMADDR_offset; /* offset of remote address */
} TR_addr_ack_t;
The primitive has the following arguments:
The proper alignement of the addresses in the `M_PCPROTO' message block is not guaranteed.
Both connection-mode and connectionless-mode.
Transaction provider.
This primitive is issued in response to a `TR_ADDR_REQ' primitive and is valid in any state where a response is pending to a `TR_ADDR_REQ'.
The new state remains unchanged.
The following rules apply:
The format of the message is one `M_PCPROTO' message block structured as follows:
typedef struct TR_optmgmt_req {
ulong PRIM_type; /* Always TR_OPTMGMT_REQ */
ulong OPT_length; /* options length */
ulong OPT_offset; /* options offset */
ulong MGMT_flags; /* options data flags */
} TR_optmgmt_req_t;
The primitive has the following arguments:
For the rules governing the requests made by this primitive, see the TR_OPTMGMT_ACK primitive described in TR_OPTMGMT_ACK.
This primitive requires the TR provider to generate one of the following acknowledgements upon receipt of the primitive:
The format of the message is one `M_PCPROTO' message block structured as follows:
typedef struct TR_optmgmt_ack {
ulong PRIM_type; /* Always TR_OPTMGMT_ACK */
ulong OPT_length; /* options length */
ulong OPT_offset; /* options offset */
ulong MGMT_flags; /* options data flags */
} TR_optmgmt_ack_t;
The primitive has the following arguments:
This primitive indicates to the TR user that the previous TR-user-originated primitive was received successfully by the TR provider. It does not indicate to the TR user any TR protocol action taken due to the issuance of the last primitive. This may only be initiated as an acknowledgement for those primitives that require one.
The format of the message is one `M_PCPROTO' message block structured as follows:
typedef struct TR_ok_ack {
ulong PRIM_type; /* Always TR_OK_ACK */
ulong CORRECT_prim; /* correct primitive */
} TR_ok_ack_t;
The primitive has the following arguments:
Valid in any state where a local acknowledgement requiring `TR_OK_ACK' response is pending.
Depends on the current state; see State/Event Tables.
This primitive indicates to the TR user that a non-fatal11 error has occurred in the last TR-user-originated primitive. This may only be initiated as an acknowledgement for those primitives that require one. It also indicates to the TR user that no action was taken on the primitive that cause the error.
The format of the message is one `M_PCPROTO' message block structured as follows:
typedef struct TR_error_ack {
ulong PRIM_type; /* Always TR_ERROR_ACK */
ulong ERROR_prim; /* primitive in error */
ulong TRI_error; /* TRI error code */
ulong UNIX_error; /* UNIX error code */
ulong TRANS_id; /* Transaction id */
} TR_error_ack_t;
The primitive has the following arguments:
This primitive is valid in any state where a local acknowledgement is pending and an error has occurred.
The new state is the state that the interface was in before the primitive in error was issued, see State/Event Tables.
The TR provider is allowed to return any of the following TR error codes:
The transaction begin service provides means to start a transaction between two TR-users. This may be accompanied by the transfer of TR-user information contained in `M_DATA' message blocks accompanying the primitive.
This primitive requests that the TR provider form an transaction association to the specified destination protocol address.
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks if any user data is specified by the TR user. The format of the `M_PROTO' message block is as follows:
typedef struct TR_begin_req {
ulong PRIM_type; /* Always TR_BEGIN_REQ */
ulong CORR_id; /* Correlation Id */
ulong ASSOC_flags; /* Association flags */
ulong DEST_length; /* Destination address length */
ulong DEST_offset; /* Destination address offset */
ulong ORIG_length; /* Originating address length */
ulong ORIG_offset; /* Originating address offset */
ulong OPT_length; /* Options structure length */
ulong OPT_offset; /* Options structure offset */
} TR_begin_req_t;
The primitive has the following arguments:
This primitive is valid in transaction state TRS_IDLE. This primitive is only valid in connection-oriented mode.
The new state for the interface is TR_WACK_CREQ.
The following rules apply to the specification of parameters to this primitive:
This primitive requires the transaction provider to generate one of the following acknowledgements upon receipt of the primitive:
This primitive indicates to the destination TR user that a transaction association begin request has been made by the user at the specified source protocol address.
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks containing user data for the association, structured as follows:
typedef struct TR_begin_ind {
ulong PRIM_type; /* Always TR_BEGIN_IND */
ulong TRANS_id; /* Transaction id */
ulong ASSOC_flags; /* Association flags */
ulong DEST_length; /* Destination address length */
ulong DEST_offset; /* Destination address offset */
ulong ORIG_length; /* Originating address length */
ulong ORIG_offset; /* Originating address offset */
ulong OPT_length; /* Options structure length */
ulong OPT_offset; /* Options structure offset */
} TR_begin_ind_t;
The primitive has the following arguments:
This primitive is valid in state TRS_IDLE. This primitive is only valid in connection-oriented mode.
The new state for the identified transaction is TR_WRES_CIND.
The following rules apply to the issuance of this primitive by the transaction provider:
This primitive allows the destination TR user to request that the transaction provider accept a previous transaction association begin indication.
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks containing user data for the association, structured as follows:
typedef struct TR_begin_res {
ulong PRIM_type; /* Always TR_BEGIN_RES */
ulong TRANS_id; /* Transaction id */
ulong ASSOC_flags; /* Association flags */
ulong ORIG_length; /* Originating address length */
ulong ORIG_offset; /* Originating address offset */
ulong OPT_length; /* Options structure length */
ulong OPT_offset; /* Options structure offset */
} TR_begin_res_t;
The primitive has the following arguments:
This primitive is valid in transaction state TR_WRES_CIND. This primitive is only valid in connection-oriented mode.
The new state for the specified transaction is TRS_DATA_XFER.
This primitive requires the TR provider to generate one of the following acknowledgements upon receipt of the primitive:
TR_OK_ACK
primitive described in TR_OK_ACK.
TR_ERROR_ACK primitive described
in TR_ERROR_ACK. The allowable errors are as follows:
TRBADFTRBADOPTTRACCESTROUTSTATETRBADDATATRBADSEQTRSYSERRTRRESADDRTRBADADDRThis primitive indicates to the source transaction user that a previous transaction association begin request has been confirmed on the specified responding protocol address.
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks containing user data for the association, structured as follows:
typedef struct TR_begin_con {
ulong PRIM_type; /* Always TR_BEGIN_CON */
ulong CORR_id; /* Correlation Id */
ulong TRANS_id; /* Transaction id */
ulong ASSOC_flags; /* Association flags */
ulong ORIG_length; /* Originating address length */
ulong ORIG_offset; /* Originating address offset */
ulong OPT_length; /* Options structure length */
ulong OPT_offset; /* Options structure offset */
} TR_begin_con_t;
The primitive has the following arguments:
The proper alignment of the responding address and options in the `M_PROTO' message block is not guaranteed.
The following association flags are defined:
This primitive is only valid in connection-oriented mode.
Transaction provider.
This primitive is valid in transaction state TRS_WCON_CREQ.
The new state for the transaction is TRS_DATA_XFER.
The following rules apply to the issuance of this primitive:
The data transfer service primitives provide for an exchange of transaction user data known as TSDUs, in either direction or in both directions simultaneously on a transaction association. The transaction service preserves both the sequence and the boundaries of the TSDUs.
This user-originated primitive specifies to the transaction provider that this message contains transaction user data. It allows the transfer of transaction user data between transaction users, without modification by the transaction provider.
The transaction user must send an integral number of octets of data greater than zero. In a case where the size of the TSDU exceeds the TIDU (as specified by the size of the TIDU_size parameter of the `TR_INFO_ACK' primitive described in TR_INFO_ACK), the TSDU may be broken up into more than one TIDU. When a TSDU is broken up into more than one TIDU, the `T_MORE' flag will be set on each TIDU except the last one.
The format of the message is one or more `M_DATA' message blocks. Use of a `M_PROTO' message block is optional. The `M_PROTO' message block is used for two reasons:
typedef struct TR_cont_req {
ulong PRIM_type; /* Always TR_CONT_REQ */
ulong TRANS_id; /* Transaction id */
ulong ASSOC_flags; /* Association flags */
ulong OPT_length; /* Options structure length */
ulong OPT_offset; /* Options structure offset */
} TR_cont_req_t;
The following guidelines must be followed with respect to the user of the `M_PROTO' message block:
The primitive has the following arguments:
This primitive is valid in transaction state TRS_DATA_XFER. This primitive is only valid in connection-oriented mode.
The new state for the transaction remains unchanged.
This primitive does not require acknowledgement. If a non-fatal error occurs, it is the responsibility of the peer ASE to report it within the upper-layer protocol or using the TR_ABORT_IND primitive (see TR_ABORT_IND). Fatal errors are indicated with the `M_ERROR' message type which results in the failure of all operating system service routines on the stream. The allowable fatal errors are as follows:
NOTE: If the interface is in the TRS_IDLE state when the provider receives the `TR_CONT_REQ' primitive, then the transaction provider should discard the request without generating a fatal error.
This transaction provider originated primitive indicates to the transaction user that this message contains transaction user data. As in the `TR_CONT_REQ' primitive (see TR_CONT_REQ), the TSDU can eb segmented into more than one TIDU. The TIDUs are assocated with the TSDU by using the TR_MORE_DATA_FLAG. The TR_RC_FLAG and TR_NO_PERMISSION flags are allowed to be set only on the last TIDU. Use of the `M_PROTO' message blocks is optional (see guidelines describe in see TR_CONT_REQ).
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks containing user data for the association, structured as follows:
typedef struct TR_cont_ind {
ulong PRIM_type; /* Always TR_CONT_IND */
ulong TRANS_id; /* Transaction id */
ulong ASSOC_flags; /* Association flags */
ulong OPT_length; /* Options structure length */
ulong OPT_offset; /* Options structure offset */
} TR_cont_ind_t;
The primitive has the following arguments:
This primitive is valid in transaction state TRS_DATA_XFER. This primitive is only valid in connection-oriented mode.
The new state for the transaction is unchanged.
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks containing user data for the association, structured as follows:
typedef struct TR_end_req {
ulong PRIM_type; /* Always TR_END_REQ */
ulong TRANS_id; /* Transaction id */
ulong TERM_scenario; /* Termination scenario */
ulong OPT_length; /* Options structure length */
ulong OPT_offset; /* Options structure offset */
} TR_end_req_t;
The primitive has the following arguments:
This primitive is valid in transaction state TRS_DATA_XFER. This primitive is only valid in connection-oriented mode.
The new state of the transaction is TRS_IDLE.
This primitive requires the TR provider to generate one of the following acknowledgements upon receipt of the primitive:
TR_OK_ACK
primitive described in TR_OK_ACK.
TR_ERROR_ACK primitive described
in TR_ERROR_ACK. The allowable errors are as follows:
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks containing user data for the association, structured as follows:
typedef struct TR_end_ind {
ulong PRIM_type; /* Always TR_END_IND */
ulong CORR_id; /* Correlation id */
ulong TRANS_id; /* Transaction id */
ulong OPT_length; /* Options structure length */
ulong OPT_offset; /* Options structure offset */
} TR_end_ind_t;
The primitive has the following arguments:
This primitive is valid in transaction states TRS_WCON_CREQ or TRS_DATA_XFER. This primitive is only valid in connection-oriented mode.
The new state for the transaction is TRS_IDLE.
The following rules apply to the issuance of this primitive:
The format of the message is one `M_PROTO' message block structured as follows:
typedef struct TR_abort_req {
ulong PRIM_type; /* Always TR_ABORT_REQ */
ulong TRANS_id; /* Transaction id */
ulong ABORT_cause; /* Cause of the abort */
ulong OPT_length; /* Options structure length */
ulong OPT_offset; /* Options structure offset */
} TR_abort_req_t;
The primitive has the following arguments:
This primitive is only valid in connection-oriented mode.
Transaction user.
This primitive is valid in any connection oriented transaction state other than TRS_IDLE.
The new state for the transaction is TRS_IDLE.
This primitive requires the TR provider to generate one of the following acknowledgements upon receipt of the primitive:
TRBADDATATRBADIDTRNOTSUPPORTTROUTSTATETRSYSERRThe transport provider should not generate an error if it receives this primitive in the TRS_IDLE state for the transaction.
This primitive indicates to the user that either a request for association has been denied or an existing association has been aborted.
The format of the message is one `M_PROTO' message block structured as follows:
typedef struct TR_abort_ind {
ulong PRIM_type; /* Always TR_ABORT_IND */
ulong CORR_id; /* Correlation id */
ulong TRANS_id; /* Transaction id */
ulong OPT_length; /* Options structure length */
ulong OPT_offset; /* Options structure offset */
ulong ABORT_cause; /* Cause of the abort */
ulong ORIGINATOR; /* Originator P or U */
} TR_abort_ind_t;
The primitive has the following arguments:
TR_USER
or
TR_PROVIDER
or
TR_UNSPECIFIED.
This primitive is only valid in connection-oriented mode.
Transaction provider.
This primitive is valid in any connection oriented transaction state other than TRS_IDLE.
The new state for the transaction is TRS_IDLE.
This primitive requests that the TR provider send the specified unidirectional (connectionless) message to the specified destination with the specified options and optional originating protocol address.
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks containing user data for the association, structured as follows:
typedef struct TR_uni_req {
ulong PRIM_type; /* Always TR_UNI_REQ */
ulong DEST_length; /* Destination address length */
ulong DEST_offset; /* Destination address offset */
ulong OPT_length; /* Options structure length */
ulong OPT_offset; /* Options structure offset */
ulong ORIG_length; /* Originating address length */
ulong ORIG_offset; /* Originating address offset */
} TR_uni_req_t;
The primitive has the following arguments:
This primitive is valid in state `TRS_IDLE'. This primitive is only valid in connectionless mode.
The new state remains unchanged.
This primitive does not require an acknowledgement.12 If a non-fatal error occurs, it is the responsibility of the TR provider to report it with the `TR_NOTICE_IND' indication. Fatal errors are indicated with the `M_ERROR' message type which results in the failure of all operating system service routines on the stream. The allowable fatal errors are as follows:
This primitive indicates to the TR user that a unidirectional invocation has been received from the specified source address.
The format of the message is one `M_PROTO' message block, followed by zero or more `M_DATA' message blocks containing user data for the association, where each `M_DATA' message block contains at least one byte of data, structured as follows:
typedef struct TR_uni_ind {
ulong PRIM_type; /* Always TR_UNI_REQ */
ulong DEST_length; /* Destination address length */
ulong DEST_offset; /* Destination address offset */
ulong ORIG_length; /* Originating address length */
ulong ORIG_offset; /* Originating address offset */
ulong OPT_length; /* Options structure length */
ulong OPT_offset; /* Options structure offset */
} TR_uni_ind_t;
The primitive has the following arguments:
This primitive is only issued in state `TRS_IDLE'. This primitive is only valid in connectionless mode.
The new state remains unchanged.
The proper alignment of the destination address, originating address and protocol options in the `M_PROTO' message block is not guaranteed.
The format of the message is one `M_PCPROTO' message block, followed by zero or more `M_DATA' message blocks containing user data for the association, structured as follows:
typedef struct TR_notice_ind {
ulong PRIM_type; /* Always TR_NOTICE_IND */
ulong CORR_id; /* Correlation id */
ulong TRANS_id; /* Transaction id */
ulong REPORT_cause; /* SCCP return cause */
} TR_notice_ind_t;
The primitive has the following arguments:
This primitive is only valid in connectionless mode.
There are two error handling facilities available to the TR user: one to handle non-fatal errors and one to handle fatal errors.
The non-fatal errors are those that a TR user can correct, and are reported in the form of an error acknowledgement to the appropriate primitive in error. Only those primitive which require acknowledgements may generate a non-fatal error acknowledgement. These acknowledgements always report syntactical error in the specified primitive when the TR provider receives the primitive. The primitive descriptions13 define those primitive and rules regarding acknowledgement for each primitive. These errors are reported to the TR user with the `TR_ERROR_ACK' primitive, (see TR_ERROR_ACK), and give the TR user the option of reissuing the TR service primitive that cause the error. The `TR_ERROR_ACK' primitive also indicates to the TR user that no action was taken by the TR provider upon receipt of the primitive which cause the error.
These errors do not change the state of the TR service interface as seen by the TR user. The state of the interface after the issuance of a `TR_ERROR_ACK' primitive should be the same as it was before the TR provider receive the interface primitive that was in error.
The allowable errors that can be reported on the receipt of a TR initiated primitive are presented in the description of the appropriate primitives, see TRI Primitives.
Fatal errors are those that cannot be corrected by the TR user, or those errors that result in an uncorrectable error in the interface or in the TR provider.
The most common of these errors are listed under the appropriate primitives (see TRI Primitives). The transaction provider should issue fatal errors only if the transaction user cannot correct the condition that caused the error or if the transaction provider has no means of reporting a transaction user correctable error. If the transaction provider detects an uncorrectable non-protocol error internal to the transaction provider, the provider should issue a fatal error to the user.
Fatal errors are indicated to the transaction user with the STREAMS message type M_ERROR with the UNIX System error `EPROTO'. This is the only type of error that the transaction provider should use to indicate a fatal protocol error to the transaction user. The message M_ERROR will result in the failure of all the operating system service routines on the stream. The only way for the user to recover from a fatal error is to ensure that all processes close the file associated with the stream. Then the user may reopen the file associated with the stream.
The allowable sequence of primitives are described in the state diagrams and tables for both the connection-oriented and connectionless mode mode transaction services described in State/Event Tables.
The following are rules regarding the maintenance of the state of the interface:
The following rules apply only to the connection-oriented mode transaction services:
The following rules apply to the precedence of transaction interface primitives with respect to their position on a stream:15
The following rules apply only to the connection-oriented transaction services:
The following rules pertain to flushing of stream queues: (No other flushes should be needed to keep the queues in the proper condition.)
The following rules apply only to the connection-oriented transaction services:
This section describes the formats and rules that are specified to ITU-T Q.771 operation. The addendum must be used along with the generic TRI as defined in the main document when implementing a TR provider that will be configured with the ITU-T Q.771 (TCAP) Transaction Sub-Layer.
The “Quality of Service” characteristics apply to both connection-oriented and connectionless transaction services.
QoS (Quality of Service) is described in terms of QoS parameters. There are two types of QoS parameters:
The following rules apply to the TRI primitives for ITU-T Q.771 (TCAP) compatibility:
TCAP uses SCCP formatted addresses instead of ISO Presentation Layer addresses.
The address format for a TCAP address is as follows:
The TCAP interface uses protocol level T_SS7_SCCP for options at the SCCP level. SCCP QoS parameters are communicated to the underlying transaction provider using the option name T_SCCP_QOS. There are three QoS structure that can be used in this fashion as follows:
Quality of service struct N_qos_sel_sccp_t has the following fields:
The following discusses the values which may be returned in a TR_INFO_ACK primitive in response to a TR_INFO_REQ primitive.
This section describes the formats and rules that are specified to ANSI T1.114 operation. The addendum must be used along with the generic TRI as defined in the main document when implementing a TR provider that will be configured with the ANSI T1.114 (TCAP) Transaction Sub-Layer.17
The “Quality of Service” characteristics apply to both connection-oriented and connectionless transaction services.
QoS (Quality of Service) is described in terms of QoS parameters. There are two types of QoS parameters:
The following rules apply to the TRI primitives for ANSI T1.114 (TCAP) compatibility:
TCAP uses SCCP formatted addresses instead of ISO Presentation Layer addresses.
The address format for a TCAP address is as follows:
The TCAP interface uses protocol level T_SS7_SCCP for options at the SCCP level. SCCP QoS parameters are communicated to the underlying transaction provider using the option name T_SCCP_QOS. There are three QoS structure that can be used in this fashion as follows:
Quality of service struct N_qos_sel_sccp_t has the following fields:
The following discusses the values which may be returned in a TR_INFO_ACK primitive in response to a TR_INFO_REQ primitive.
Copyright © 2000 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA 02111-1307, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
The purpose of this License is to make a manual, textbook, or other written document free in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of “copyleft”, which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.
This License applies to any manual or other work that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. The “Document”, below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as “you”.
A “Modified Version” of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A “Secondary Section” is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.
A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, whose contents can be viewed and edited directly and straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup has been designed to thwart or discourage subsequent modification by readers is not Transparent. A copy that is not “Transparent” is called “Opaque”.
Examples of suitable formats for Transparent copies include plain ascii without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF, proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, “Title Page” means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3.
You may also lend copies, under the same conditions stated above, and you may publicly display copies.
If you publish printed copies of the Document numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects.
If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages.
If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a publicly-accessible computer-network location containing a complete Transparent copy of the Document, free of added material, which the general network-using public has access to download anonymously at no charge using public-standard network protocols. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public.
It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.
You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles.
You may add a section entitled “Endorsements”, provided it contains nothing but endorsements of your Modified Version by various parties—for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.
You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice.
The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of Invariant Sections in the license notice of the combined work.
In the combination, you must combine any sections entitled “History” in the various original documents, forming one section entitled “History”; likewise combine any sections entitled “Acknowledgments”, and any sections entitled “Dedications”. You must delete all sections entitled “Endorsements.”
You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects.
You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an “aggregate”, and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.
If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one quarter of the entire aggregate, the Document's Cover Texts may be placed on covers that surround only the Document within the aggregate. Otherwise they must appear on covers around the whole aggregate.
Translation is considered a kind of modification, so you may distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License provided that you also include the original English version of this License. In case of a disagreement between the translation and the original English version of this License, the original English version will prevail.
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.
The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License “or any later version” applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
To use this License in a document you have written, include a copy of the License in the document and put the following copyright and license notices just after the title page:
Copyright (C) year your name.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1
or any later version published by the Free Software Foundation;
with the Invariant Sections being list their titles, with the
Front-Cover Texts being list, and with the Back-Cover Texts being list.
A copy of the license is included in the section entitled ``GNU
Free Documentation License''.
If you have no Invariant Sections, write “with no Invariant Sections” instead of saying which ones are invariant. If you have no Front-Cover Texts, write “no Front-Cover Texts” instead of “Front-Cover Texts being list”; likewise for Back-Cover Texts.
If your document contains nontrivial examples of program code, we recommend releasing these examples in parallel under your choice of free software license, such as the GNU General Public License, to permit their use in free software.
| SDLI | Signalling Data Link Interface
|
| SDL | Signalling Data Link
|
| SDL SDU | Signalling Data Link Service Data Unit
|
| ITU-T | International Telecommunications Union - Telecom Sector
|
| PPA | Physical Point of Attachment
|
ABORT_cause: TR_ABORT_INDABORT_cause: TR_ABORT_REQADDR_length: TR_BIND_ACKADDR_length: TR_BIND_REQADDR_length: TR_INFO_ACKADDR_offset: TR_BIND_ACKADDR_offset: TR_BIND_REQADDR_offset: TR_INFO_ACKADDR_size: Addendum for ANSI ConformanceADDR_size: Addendum for ITU-T ConformanceADDR_size: TR_INFO_ACKASDU_size: Addendum for ANSI ConformanceASDU_size: Addendum for ITU-T ConformanceASDU_size: TR_INFO_ACKASSOC_flags: TR_CONT_INDASSOC_flags: TR_CONT_REQASSOC_flags: TR_BEGIN_CONASSOC_flags: TR_BEGIN_RESASSOC_flags: TR_BEGIN_INDASSOC_flags: TR_BEGIN_REQBIND_flags: TR_BIND_REQCDATA_size: Addendum for ANSI ConformanceCDATA_size: Addendum for ITU-T ConformanceCDATA_size: TR_INFO_ACKCORR_id: TR_NOTICE_INDCORR_id: TR_ABORT_INDCORR_id: TR_END_INDCORR_id: TR_BEGIN_CONCORR_id: TR_BEGIN_REQCORRECT_prim: TR_OK_ACKCURRENT_state: Addendum for ANSI ConformanceCURRENT_state: Addendum for ITU-T ConformanceCURRENT_state: TR_INFO_ACKDDATA_size: Addendum for ANSI ConformanceDDATA_size: Addendum for ITU-T ConformanceDDATA_size: TR_INFO_ACKDEST_length: TR_UNI_INDDEST_length: TR_UNI_REQDEST_length: TR_BEGIN_INDDEST_length: TR_BEGIN_REQDEST_offset: TR_UNI_INDDEST_offset: TR_UNI_REQDEST_offset: TR_BEGIN_INDDEST_offset: TR_BEGIN_REQEASDU_size: Addendum for ANSI ConformanceEASDU_size: Addendum for ITU-T ConformanceEASDU_size: TR_INFO_ACKERROR_prim: TR_ERROR_ACKLOCADDR_length: TR_ADDR_ACKLOCADDR_offset: TR_ADDR_ACKMGMT_flags: TR_OPTMGMT_ACKMGMT_flags: TR_OPTMGMT_REQNODU_size: TR_INFO_ACKOPT_length: TR_UNI_INDOPT_length: TR_UNI_REQOPT_length: TR_ABORT_INDOPT_length: TR_ABORT_REQOPT_length: TR_END_INDOPT_length: TR_END_REQOPT_length: TR_CONT_INDOPT_length: TR_CONT_REQOPT_length: TR_BEGIN_CONOPT_length: TR_BEGIN_RESOPT_length: TR_BEGIN_INDOPT_length: TR_BEGIN_REQOPT_length: TR_OPTMGMT_ACKOPT_length: TR_OPTMGMT_REQOPT_offset: TR_UNI_INDOPT_offset: TR_UNI_REQOPT_offset: TR_ABORT_INDOPT_offset: TR_ABORT_REQOPT_offset: TR_END_INDOPT_offset: TR_END_REQOPT_offset: TR_CONT_INDOPT_offset: TR_CONT_REQOPT_offset: TR_BEGIN_CONOPT_offset: TR_BEGIN_RESOPT_offset: TR_BEGIN_INDOPT_offset: TR_BEGIN_REQOPT_offset: TR_OPTMGMT_ACKOPT_offset: TR_OPTMGMT_REQOPT_size: Addendum for ANSI ConformanceOPT_size: Addendum for ITU-T ConformanceOPTIONS_flags: TR_INFO_ACKORIG_length: TR_UNI_INDORIG_length: TR_UNI_REQORIG_length: TR_BEGIN_CONORIG_length: TR_BEGIN_RESORIG_length: TR_BEGIN_INDORIG_length: TR_BEGIN_REQORIG_offset: TR_UNI_INDORIG_offset: TR_UNI_REQORIG_offset: TR_BEGIN_CONORIG_offset: TR_BEGIN_RESORIG_offset: TR_BEGIN_INDORIG_offset: TR_BEGIN_REQORIGINATOR: TR_ABORT_INDPRIM_type: TR_NOTICE_INDPRIM_type: TR_UNI_INDPRIM_type: TR_UNI_REQPRIM_type: TR_ABORT_INDPRIM_type: TR_ABORT_REQPRIM_type: TR_END_INDPRIM_type: TR_END_REQPRIM_type: TR_CONT_INDPRIM_type: TR_CONT_REQPRIM_type: TR_BEGIN_CONPRIM_type: TR_BEGIN_RESPRIM_type: TR_BEGIN_INDPRIM_type: TR_BEGIN_REQPRIM_type: TR_ERROR_ACKPRIM_type: TR_OK_ACKPRIM_type: TR_OPTMGMT_ACKPRIM_type: TR_OPTMGMT_REQPRIM_type: TR_ADDR_ACKPRIM_type: TR_ADDR_REQPRIM_type: TR_UNBIND_REQPRIM_type: TR_BIND_ACKPRIM_type: TR_BIND_REQPRIM_type: TR_INFO_ACKPRIM_type: TR_INFO_REQPROTOID_length: TR_INFO_ACKPROTOID_offset: TR_INFO_ACKPROVIDER_flag: Addendum for ANSI ConformancePROVIDER_flag: Addendum for ITU-T ConformancePROVIDER_type: TR_INFO_ACKQOS_length: TR_INFO_ACKQOS_offset: TR_INFO_ACKQOS_range_length: TR_INFO_ACKQOS_range_offset: TR_INFO_ACKREMADDR_length: TR_ADDR_ACKREMADDR_offset: TR_ADDR_ACKREPORT_cause: TR_NOTICE_INDSERV_type: Addendum for ANSI ConformanceSERV_type: Addendum for ITU-T ConformanceSERV_type: TR_INFO_ACKTERM_scenario: TR_END_REQTIDU_size: Addendum for ANSI ConformanceTIDU_size: Addendum for ITU-T ConformanceTIDU_size: TR_INFO_ACKTOKEN_value: TR_BIND_ACKTR_abort_ind_t: TR_ABORT_INDTR_abort_req_t: TR_ABORT_REQTR_addr_ack_t: TR_ADDR_ACKTR_addr_req_t: TR_ADDR_REQTR_begin_con_t: TR_BEGIN_CONTR_begin_ind_t: TR_BEGIN_INDTR_begin_req_t: TR_BEGIN_REQTR_begin_res_t: TR_BEGIN_RESTR_bind_ack_t: TR_BIND_ACKTR_bind_req_t: TR_BIND_REQTR_cont_ind_t: TR_CONT_INDTR_cont_req_t: TR_CONT_REQTR_end_ind_t: TR_END_INDTR_end_req_t: TR_END_REQTR_error_ack_t: TR_ERROR_ACKTR_info_ack_t: TR_INFO_ACKTR_info_req_t: TR_INFO_REQTR_MORE_DATA_FLAG: TR_CONT_INDTR_MORE_DATA_FLAG: TR_CONT_REQTR_NO_PERMISSION: TR_CONT_INDTR_NO_PERMISSION: TR_CONT_REQTR_NO_PERMISSION: TR_BEGIN_CONTR_NO_PERMISSION: TR_BEGIN_RESTR_NO_PERMISSION: TR_BEGIN_INDTR_NO_PERMISSION: TR_BEGIN_REQTR_notice_ind_t: TR_NOTICE_INDTR_ok_ack_t: TR_OK_ACKTR_optmgmt_ack_t: TR_OPTMGMT_ACKTR_optmgmt_req_t: TR_OPTMGMT_REQTR_RC_FLAG: TR_CONT_INDTR_RC_FLAG: TR_CONT_REQTR_SEQ_ASSURANCE: TR_CONT_REQTR_SEQ_ASSURANCE: TR_BEGIN_RESTR_SEQ_ASSURANCE: TR_BEGIN_REQTR_unbind_req_t: TR_UNBIND_REQTR_uni_ind_t: TR_UNI_INDTR_uni_req_t: TR_UNI_REQTRACCES: TR_BEGIN_RESTRACCES: TR_BEGIN_REQTRACCES: TR_BIND_REQTRADDRBUSY: TR_BIND_REQTRANS_id: TR_NOTICE_INDTRANS_id: TR_ABORT_INDTRANS_id: TR_ABORT_REQTRANS_id: TR_END_INDTRANS_id: TR_END_REQTRANS_id: TR_CONT_INDTRANS_id: TR_CONT_REQTRANS_id: TR_BEGIN_CONTRANS_id: TR_BEGIN_RESTRANS_id: TR_BEGIN_INDTRANS_id: TR_ERROR_ACKTRANS_id: TR_ADDR_REQTRBAADDR: TR_BIND_REQTRBADADDR: TR_BEGIN_RESTRBADADDR: TR_BEGIN_REQTRBADDATA: TR_ABORT_REQTRBADDATA: TR_BEGIN_RESTRBADDATA: TR_BEGIN_REQTRBADF: TR_BEGIN_RESTRBADID: TR_ABORT_REQTRBADID: TR_ADDR_REQTRBADOPT: TR_BEGIN_RESTRBADOPT: TR_BEGIN_REQTRBADSEQ: TR_BEGIN_RESTRI_error: TR_ERROR_ACKTRI_version: Addendum for ANSI ConformanceTRI_version: Addendum for ITU-T ConformanceTRI_version: TR_INFO_ACKTRNOADDR: TR_BIND_REQTRNOTSUPPORT: TR_ABORT_REQTRNOTSUPPORT: TR_ADDR_REQTROUTSTATE: TR_ABORT_REQTROUTSTATE: TR_END_REQTROUTSTATE: TR_BEGIN_RESTROUTSTATE: TR_BEGIN_REQTROUTSTATE: TR_OPTMGMT_REQTROUTSTATE: TR_UNBIND_REQTROUTSTATE: TR_BIND_REQTRRESADDR: TR_BEGIN_RESTRSYSERR: TR_ABORT_REQTRSYSERR: TR_END_REQTRSYSERR: TR_BEGIN_RESTRSYSERR: TR_BEGIN_REQTRSYSERR: TR_OPTMGMT_REQTRSYSERR: TR_ADDR_REQTRSYSERR: TR_UNBIND_REQTRSYSERR: TR_BIND_REQUNIX_error: TR_ERROR_ACKXACT_number: TR_BIND_ACKXACT_number: TR_BIND_REQ[1] For an alternative interface, see Introduction, or Introduction.
[2] That is, it supports TCAP operation classes 1, 2, and 3; ROSE operation classes 1, 2, 3 and 4.
[3] Conventions for the time-sequence diagrams are defined in ITU-T X.210, ISO/IEC 10731:1994.
[4]
[5] A stream is viewed as active when the transaction provider may receive and transmit APDUs (ACSE protocol data units) associated with the stream.
[6] The format of the TR_BIND_REQ primitive is chosen to be as consistent as possible with the equivalent TPI and NPI primitives.
[7] All lengths, offsets and sizes in all structures refer to the number of octets.
[8] This field should be ignored by TR providers providing only a unidirectional (TCAP operation class 4, ROSE operation class 5) service.
[9] If the number of outstanding “begin” indications equals XACT_number, the TR provider need not discard further incoming “begin” indications, but may choose to queue them internally until the number of outstanding “begin” indications dropts below XACT_number.
[10] This field does not apply to unidirectional TR providers.
[11] For an overview of the error handling capabilities available to the TR provider, see Diagnostics Requirements.
[12] This is a TCAP operations class 4 or a ROSE operations class 5 transaction that requires neither a positive or negative acknowledgement.
[13] See TRI Primitives.
[14] This is not really true for either TRI or TPI. The accepting stream can be bound or unbound, and for some protocols may be bound to an address different or the same as the stream upon which the begin indication was issued.
[15] The stream queue which contains a transaction user initiated primitives is referred to as the stream write queue. The stream queue which contains the transaction provider initiated primitives is referred to as the stream read queue.
[16] The connectionless transaction services do not support end-to-end QoS parameter negotiation.
[17] It should be noted that ANSI T1.114 does not provide a distinction between the TC and TR Sub-Layers of TCAP, and do not specify a TC-User or TR-User interface at all. However, as it is still based on ITU-T Recommendation X.219, there can exist an identifiable TR Sub-Layer interface within ANSI TCAP.
[18] The connectionless transaction services do not support end-to-end QoS parameter negotiation.