Use of XTI with ISO Transport Protocols

General

In general, this Appendix describes the characteristics that the ISO and ISO-over-TCP transport providers have in common, with notes indicating where they differ.

Notes:

1. Protocol address:

   In an ISO environment, the protocol address is the transport address.

2. Sending data of zero octets:

   The transport service definition, both in connection-mode and in connectionless-mode, does not permit sending a TSDU of zero octets. So, in connectionless-mode, if the len parameter is set to zero, the t_sndudata() call will always return unsuccessfully with -1 and t_errno set to [TBADDATA]. In connection-mode, if the nbytes parameter is set to zero, the t_snd() call will return with -1 and t_errno set to [TBADDATA] if either the T_MORE flag is set, or the T_MORE flag is not set and the preceding t_snd() call completed a TSDU or ETSDU (that is, the call has requested sending a zero byte TSDU or ETSDU).

3. An ISO-over-TCP transport provider does not provide the connectionless-mode.

This Appendix also defines the data structures and constants required for ISO and ISO-over-TCP transport providers which are exposed through the <xti_osi.h> header file.

Note:

Applications written to compilation environments earlier than those required by this issue of the specification (see The Compilation Environment) and defining _XOPEN_SOURCE to be less than 500, may have these data structures and constants exposed through the inclusion of <xti.h>.

Options

Options are formatted according to the structure t_opthdr as described in The Use of Options in XTI. A transport provider compliant to this specification supports none, all or any subset of the options defined in Connection-mode Service and Connectionless-mode Service. An implementation may restrict the use of any of these options by offering them only in the privileged or read-only mode. An ISO-over-TCP provider supports a subset of the options defined in Connection-mode Service.

Connection-mode Service

All options are association-related, that is, they are options with end-to-end significance (see The Use of Options in XTI). They may be negotiated in the XTI states T_IDLE and T_INCON, and are read-only in all other states except T_UNINIT.

Options for Quality of Service and Expedited Data

OPT_RATIO is defined as OPT_RATIO = -log₁₀(ratio). The ratio is dependent on the parameter, but is always composed of a number of failures divided by a total number of samples. This may be, for example, the number of TSDUs transferred in error divided by the total number of TSDU transfers (T_TCO_RESERRORRATE).

Absolute Requirements

For the options in Options for Quality of Service and Expedited Data, the transport user can indicate whether the request is an absolute requirement or whether a degraded value is acceptable. For the QOS options based on struct rate an absolute requirement is specified via the field minacceptvalue, if that field is given a value different from T_UNSPEC. The value specified for T_TCO_PROTECTION is an absolute requirement if the T_ABSREQ flag is set. The values specified for T_TCO_EXPD and T_TCO_PRIORITY are never absolute requirements.

Further Remarks

A detailed description of the options for Quality of Service can be found in the ISO 8072:1986 specification. The field elements of the structures in use for the option values are self-explanatory. Only the following details remain to be explained.

• If these options are returned with t_listen(), their values are related to the incoming connection and not to the transport endpoint where t_listen() was issued. To give an example, the value of T_TCO_PROTECTION is the value sent by the calling transport user, and not the value currently effective for the endpoint (that could be retrieved by t_optmgmt() with the flag T_CURRENT set). The option is not returned at all if the calling user did not specify it. An analogous procedure applies for the other options. See also The Use of Options in XTI.

• If, in a call to t_accept(), the called transport user tries to negotiate an option of higher quality than proposed, the option is rejected and the connection establishment fails (see Responding to a Negotiation Proposal).

• The values of the QOS options T_TCO_THROUGHPUT, T_TCO_TRANSDEL, T_TCO_RESERRORRATE, T_TCO_TRANSFFAILPROB, T_TCO_ESTFAILPROB, T_TCO_RELFAILPROB, T_TCO_ESTDELAY, T_TCO_RELDELAY and T_TCO_CONNRESIL have a structured format. A user requesting one of these options might leave a field of the structure unspecified by setting it to T_UNSPEC. The transport provider is then free to select an appropriate value for this field. The transport provider may return T_UNSPEC in a field of the structure to the user to indicate that it has not yet decided on a definite value for this field.

  T_UNSPEC is not a legal value for T_TCO_PROTECTION, T_TCO_PRIORITY and T_TCO_EXPD.

• T_TCO_THROUGHPUT and T_TCO_TRANSDEL
  If avgthrpt (average throughput) is not defined (both fields set to T_UNSPEC), the transport provider considers that the average throughput has the same values as the maximum throughput (maxthrpt). An analogous procedure applies to T_TCO_TRANSDEL.

• The ISO specification ISO 8073:1986 does not differentiate between average and maximum transit delay. Transport providers that support this option adopt the values of the maximum delay as input for the CR TPDU.

• T_TCO_PROTECTION
  This option defines the general level of protection. The symbolic constants in the following list are used to specify the required level of protection:

  T_NOPROTECT

  No protection feature.

  T_PASSIVEPROTECT

  Protection against passive monitoring.

  T_ACTIVEPROTECT

  Protection against modification, replay, addition or deletion.

  Both flags T_PASSIVEPROTECT and T_ACTIVEPROTECT may be set simultaneously but are exclusive with T_NOPROTECT. If the T_ACTIVEPROTECT or T_PASSIVEPROTECT flags are set, the user may indicate that this is an absolute requirement by also setting the T_ABSREQ flag.

• T_TCO_PRIORITY
  Five priority levels are defined by XTI:

  T_PRIDFLT

  Lower level.

  T_PRILOW

  Low level.

  T_PRIMID

  Medium level.

  T_PRIHIGH

  High level.

  T_PRITOP

  Higher level.

• It is recommended that transport users avoid expedited data with an ISO-over-TCP transport provider, since the RFC 1006 treatment of expedited data does not meet the data reordering requirements specified in ISO 8072:1986, and may not be supported by the provider.

The number of priority levels is not defined by ISO 8072:1986. The parameter only has meaning in the context of some management entity or structure able to judge relative importance.

Management Options

These options are parameters of an ISO transport protocol according to ISO 8073:1986. They are not included in the ISO transport service definition ISO 8072:1986, but are additionally offered by XTI. Transport users wishing to be truly ISO-compliant should thus not adhere to them. T_TCO_LTPDU is the only management option supported by an ISO-over-TCP transport provider.

Avoid specifying both QOS parameters and management options at the same time.

Absolute Requirements

A request for any of these options is considered an absolute requirement.

Further Remarks

• If these options are returned with t_listen() their values are related to the incoming connection and not to the transport endpoint where t_listen() was issued. That means that t_optmgmt() with the flag T_CURRENT set would usually yield a different result (see The Use of Options in XTI).

• For management options that are subject to peer-to-peer negotiation the following holds: If, in a call to t_accept(), the called transport user tries to negotiate an option of higher quality than proposed, the option is rejected and the connection establishment fails (see Responding to a Negotiation Proposal).

• A connection-mode transport provider may allow the transport user to select more than one alternative class. The transport user may use the options T_ALTCLASS1, T_ALTCLASS2, etc. to denote the alternatives. A transport provider only supports an implementation-dependent limit of alternatives and ignores the rest.

• The value T_UNSPEC is legal for all options in Management Options. It may be set by the user to indicate that the transport provider is free to choose any appropriate value. If returned by the transport provider, it indicates that the transport provider has not yet decided on a specific value.

• Legal values for the options T_PREFCLASS, T_ALTCLASS1, T_ALTCLASS2, T_ALTCLASS3 and T_ALTCLASS4 are T_CLASS0, T_CLASS1, T_CLASS2, T_CLASS3, T_CLASS4 and T_UNSPEC.

• If a connection has been established, T_TCO_PREFCLASS will be set to the selected value, and T_ALTCLASS1 through T_ALTCLASS4 will be set to T_UNSPEC, if these options are supported.

• Warning on the use of T_TCO_LTPDU: Sensible use of this option requires that the application programmer knows about system internals. Careless setting of either a lower or a higher value than the implementation-dependent default may degrade the performance.

  Legal values for an ISO transport provider are T_UNSPEC and multiples of 128 up to 128*(2³² - 1) or the largest multiple of 128 that will fit in a t_uscalar_t. Values other than powers of 2 between 2⁷ and 2¹³ are only supported by transport providers that conform to the 1992 update to ISO 8073.

  Legal values for an ISO-over-TCP provider are T_UNSPEC and any power of 2 between 2**7 and 2**11, and 65531.

  The action taken by a transport provider is implementation-dependent if a value is specified which is not exactly as defined in ISO 8073:1986 or its addendums.

• The management options are not independent of one another, and not independent of the options defined in Options for Quality of Service and Expedited Data. A transport user must take care not to request conflicting values. If conflicts are detected at negotiation time, the negotiation fails according to the rules for absolute requirements (see The Use of Options in XTI). Conflicts that cannot be detected at negotiation time will lead to unpredictable results in the course of communication. Usually, conflicts are detected at the time the connection is established.

Some relations that must be obeyed are:

• If T_TCO_EXP is set to T_YES and T_TCO_PREFCLASS is set to T_CLASS2, T_TCO_FLOWCTRL must also be set to T_YES.

• If T_TCO_PREFCLASS is set to T_CLASS0, T_TCO_EXP must be set to T_NO.

• The value in T_TCO_PREFCLASS must not be lower than the value in T_TCO_ALTCLASS1, T_TCO_ALTCLASS2, and so on.

• Depending on the chosen QOS options, further value conflicts might occur.

Connectionless-mode Service

All options are association-related, that is, they are options with end-to-end significance (see The Use of Options in XTI). They may be negotiated in all XTI states but T_UNINIT.

Options for Quality of Service

Absolute Requirements

A request for any of these options is an absolute requirement.

Further Remarks

A detailed description of the options for Quality of Service can be found in ISO 8072/Add.1:1986. The field elements of the structures in use for the option values are self-explanatory. Only the following details remain to be explained.

• These options are negotiated only between the local user and the local transport provider.

• The meaning, type of option value, and the range of legal option values are identical for T_TCO_RESERRORRATE and T_TCL_RESERRORRATE, T_TCO_PRIORITY and T_TCL_PRIORITY, T_TCO_PROTECTION and T_TCL_PROTECTION (see Options for Quality of Service and Expedited Data, ISO 8072:1986).

• T_TCL_TRANSDEL and T_TCO_TRANSDEL are different. T_TCL_TRANSDEL specifies the maximum transit delay expected during a datagram transmission. Note that the type of option value is a struct rate contrary to the struct transdel of T_TCO_TRANSDEL. The range of legal option values for each field of struct rate is the same as that of T_TCO_TRANSDEL.

• If these options are returned with t_rcvudata() their values are related to the received datagram and not to the transport endpoint where t_rcvudata() was issued. On the other hand, t_optmgmt() with the flag T_CURRENT set returns the values that are currently effective for outgoing datagrams.

• The function t_rcvuderr() returns the option value of the data unit previously sent that produced the error.

Management Options

This option is a parameter of an ISO transport protocol, according to ISO 8602. It is not included in the ISO transport service definition ISO 8072/Add.1:1986, but is an additional offer by XTI. Transport users wishing to be truly ISO-compliant should thus not adhere to it.

Avoid specifying both QOS parameters and this management option at the same time.

Absolute Requirements

A request for this option is an absolute requirement.

Further Remarks

T_TCL_CHECKSUM

This is the option allows disabling/enabling of the checksum computation. The legal values are T_YES (checksum enabled) and T_NO (checksum disabled).

If this option is returned with t_rcvudata(), its value indicates whether or not a checksum was present in the received datagram.

The advisability of turning off the checksum check is controversial.

Functions

t_accept()

The parameter call->udata.len must be in the range 0 to 32. The user may send up to 32 octets of data when accepting the connection.

If fd is not equal to resfd, resfd should either be in state T_UNBND or be in state T_IDLE and be bound to the same address as fd with the qlen parameter set to 0.

A process can listen for an incoming indication on a given fd and then accept the connection on another endpoint resfd which has been bound to the same or a different protocol address with the qlen parameter (of the t_bind() function) set to 0. The protocol address bound to the new accepting endpoint (resfd) should in general be the same as the listening endpoint (fd), because at the present time, the ISO transport service definition (ISO 8072:1986) does not authorise acceptance of an incoming connection indication with a responding address different from the called address, except under certain conditions (see ISO 8072:1986 paragraph 12.2.4, Responding Address), but it also states that it may be changed in the future.

t_bind()

The addr field of the t_bind() structure represents the local TSAP.

t_close()

The t_close() call will cause a close() call to be made on the descriptor of this XTI communication endpoint. If there are no other descriptors in this process or any other process which reference this communication endpoint, the close() call will perform an abortive release on any connection associated with this endpoint.

t_connect()

The sndcall->addr structure specifies the remote called TSAP. In the present version, the returned address set in rcvcall->addr will have the same value.

The setting of sndcall->udata is optional for ISO connections, but with no data, the len field of udata must be set to 0. The maxlen and buf fields of the netbuf structure, pointed to by rcvcall->addr and rcvcall->opt, must be set before the call.

t_getinfo()

The information returned by t_getinfo() reflects the characteristics of the transport connection or, if no connection is established, the maximum characteristics a transport connection could take on using the underlying transport provider. In all possible states except T_DATAXFER, the function t_getinfo() returns in the parameter info the same information as was returned by t_open(). In T_DATAXFER, however, the information returned may differ from that returned by t_open(), depending on:

• the transport class negotiated during connection establishment (ISO transport provider only)

• the negotiation of expedited data transfer for this connection.

---

In T_DATAXFER, the etsdu field in the t_info structure is set to T_INVALID (-2) if no expedited data transfer was negotiated, and to 16 otherwise. The remaining fields are set according to the characteristics of the transport protocol class in use for this connection, as defined in the following table.

Parameters	Before Call	After Call
		_	_	_
		Connection	Connection	Connectionless	ISO-over-TCP
		Class 0	Class 1-4
fd	x	/	/	/	/
info->addr		x	x	x	x
info->options	/	x Note 1	x Note 1	x Note 1	x Note 1
info->tsdu	/	x Note 2	x Note 2	0->63488	x Note 2
info->etsdu	/	T_INVALID	16 /	T_INVALID	16 /
			T_INVALID		T_INVALID
			see Note 3		see Note 3
info->connect	/	T_INVALID	32	T_INVALID	32 /
					T_INVALID
info->discon	/	T_INVALID	64	T_INVALID	64 /
					T_INVALID
info->servtype	/	T_COTS	T_COTS	T_CLTS	T_COTS
info->flags	/	0	0	0	0

Note 1:

`x' equals T_INVALID (-2) or an integral number greater than zero.

Note 2:

`x' equals T_INFINITE (-1) or an integral number greater than zero.

Note 3:

Depending on the negotiation of expedited data transfer.
For RFC 1006 (ISO over TCP) support, the value of info->etsdu depends on the negotiation of expedited data transfer.

t_listen()

The call->addr structure contains the remote calling TSAP. Since, at most, 32 octets of data will be returned with the connection indication, call->udata.maxlen should be set to 32 before the call to t_listen().

If the user has set qlen greater than 1 (on the call to t_bind()), the user may queue up several connection indications before responding to any of them. The user should be forewarned that the ISO transport provider may start a timer to be sure of obtaining a response to the connection request in a finite time. So if the user queues the connection indications for too long before responding to them, the transport provider initiating the connection will disconnect it.

t_open()

The function t_open() is called as the first step in the initialisation of a transport endpoint. This function returns various default characteristics associated with the different classes. According to ISO 8073:1986, an OSI transport provider supports one or several out of five different transport protocols, class 0 through class 4. The default characteristics returned in the parameter info are those of the highest-numbered protocol class the transport provider is able to support. If, for example, a transport provider supports classes 2 and 0, the characteristics returned are those of class 2. If the transport provider is limited to class 0, the characteristics returned are those of class 0.

---

The following table gives the characteristics associated with the different classes.

Parameters	Before Call	After Call
		_	_	_	_
		Connection	Connection	Connectionless	ISO-over-TCP
		Class 0	Class 1-4
name	x	/	/	/	/
oflag	x	/	/	/	/
info->addr	/	x	x	x	x
info->options	/	x Note 1	x Note 1	x Note 1	x Note 1
info->tsdu	/	x Note 2	x Note 2	0->63488	x Note 2
info->etsdu	/	T_INVALID	16	T_INVALID	16/T_INVALID
info->connect	/	T_INVALID	32	T_INVALID	32/T_INVALID
info->discon	/	T_INVALID	64	T_INVALID	64/T_INVALID
info->servtype	/	T_COTS	T_COTS	T_CLTS	T_COTS
info->flags	/	0	0	0	0

Note 1:

`x' equals T_INVALID (-2) or an integral number greater than zero.

Note 2:

`x' equals T_INFINITE (-1) or an integral number greater than zero.

t_rcv()

If expedited data arrives after part of a TSDU has been retrieved, receipt of the remainder of the TSDU will be suspended until the ETSDU has been processed. Only after the full ETSDU has been retrieved (T_MORE not set), will the remainder of the TSDU be available to the user.

t_rcvconnect()

On return, the call->addr structure contains the remote calling TSAP. Since, at most, 32 octets of data will be returned to the user, call->udata.maxlen should be set to 32 before the call to t_rcvconnect().

t_rcvdis()

Since, at most, 64 octets of data will be returned to the user, discon->udata.maxlen should be set to 64 before the call to t_rcvdis().

t_rcvudata()

The unitdata->addr structure specifies the remote TSAP. If the T_MORE flag is set, an additional t_rcvudata() call is needed to retrieve the entire TSDU. Only normal data is returned via the t_rcvudata() call. This function is not supported by an ISO-over-TCP transport provider.

t_rcvuderr()

The uderr->addr structure contains the remote TSAP.

t_snd()

Zero byte TSDUs are not supported. The T_EXPEDITED flag is not a legal flag unless expedited data has been negotiated for this connection.

t_snddis()

Since, at most, 64 octets of data may be sent with the disconnect, call->udata.len will have a value less than or equal to 64.

t_sndudata()

The unitdata->addr structure specifies the remote TSAP. The ISO connectionless-mode transport service does not support the sending of expedited data. This function is not supported by an ISO-over-TCP transport provider.

The <xti_osi.h> Header File

The data definitions and macros specified in this section need not be contained in <xti_osi.h> itself, but must be available to the application when <xti.h> is included and <xti_osi.h> is included after <xti.h>.

Note:

Applications written to compilation environments earlier than those required by this issue of the specification (see The Compilation Environment) and defining _XOPEN_SOURCE to be less than 500 may have the data structures and constants of this header automatically exposed by the inclusion of <xti.h> for compatibility.

Certain symbols may be exposed to applications including <xti_osi.h> for compatibility with applications transitioning from older issues of this specification where their semantics are specified. Exposing these symbols is allowed but not required. Symbols that may be exposed in this implementation-dependent manner are:

T_LTPDUDFLT
ISO_TP
TCO_THROUGHPUT
TCO_TRANSDEL
TCO_RESERRORRATE
TCO_TRANSFFAILPROB
TCO_ESTFAILPROB
TCO_RELFAILPROB
TCO_ESTDELAY
TCO_RELDELAY
TCO_CONNRESIL
TCO_PROTECTION
TCO_PRIORITY
TCO_EXPD
TCL_TRANSDEL
TCL_RESERRORRATE
TCL_PROTECTION
TCL_PRIORITY
TCO_LTPDU
TCO_ACKTIME
TCO_REASTIME
TCO_EXTFORM
TCO_FLOWCTRL
TCO_CHECKSUM
TCO_NETEXP
TCO_NETRECPTCF
TCO_PREFCLASS
TCO_ALTCLASS1
TCO_ALTCLASS2
TCO_ALTCLASS3
TCO_ALTCLASS4
TCL_CHECKSUM

There is an example <xti_osi.h> header file in Example XTI Header Files.

Footnotes

1.

The mapping for ISO-over-TCP that is referred to here is that defined by RFC-1006: ISO Transport Service on top of the TCP, Version 3, May 1987, Marshall T Rose and Dwight E Cass, Network Working Group, Northrop Research & Technology Center. See also The Open Group publication: Guide to IPS-OSI Coexistence and Migration , Document Number G140; the relevant sections are 4.6.2 (Implementation of OSI Services over IPS) and 4.6.3 (Comments).