An equation in the source document has not been converted to HTML.
Previous section.
Technical Standard: Networking Services (XNS), Issue 5.2 Draft 2.0
Copyright © 1999 The Open Group
Use of XTI with ISO Transport Protocols
General
This appendix describes the protocol-specific information that is relevant
for ISO transport providers.
This appendix also describes the protocol-specific information that
is relevant when ISO transport services are provided over a TCP
network1.
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:
-
Protocol address:
In an ISO environment, the protocol address is the transport address.
-
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).
-
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
The protocol level of all subsequent options is ISO_TP.
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
These options are all defined in the ISO 8072:1986 transport
service definition (see the ISO Transport references).
The definitions are not repeated here.
Option Name
| Type of Option
| Legal
| Meaning
|
| Value
| Option Value
|
|
T_TCO_THROUGHPUT
| struct thrpt
| octets per second
| throughput
|
T_TCO_TRANSDEL
| struct transdel
| time in milliseconds
| transit delay
|
T_TCO_RESERRORRATE
| struct rate
| OPT_RATIO
| residual error rate
|
T_TCO_TRANSFFAILPROB
| struct rate
| OPT_RATIO
|
transfer failure
probability
|
T_TCO_ESTFAILPROB
| struct rate
| OPT_RATIO
|
connection establ.
failure probability
|
T_TCO_RELFAILPROB
| struct rate
| OPT_RATIO
|
connection release
failure probability
|
T_TCO_ESTDELAY
| struct rate
| time in milliseconds
|
connection establ.
delay
|
T_TCO_RELDELAY
| struct rate
| time in milliseconds
|
connection release
delay
|
T_TCO_CONNRESIL
| struct rate
| OPT_RATIO
| connection resilience
|
T_TCO_PROTECTION
| t_uscalar_t
| see text
| protection
|
T_TCO_PRIORITY
| t_uscalar_t
| see text
| priority
|
T_TCO_EXPD
| t_uscalar_t
| T_YES/T_NO
| expedited data
|
Table: Options for Quality of Service and Expedited Data
OPT_RATIO is defined as OPT_RATIO = -log10(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.
Option Name
| Type of Option
| Legal
| Meaning
|
| Value
| Option Value
|
|
T_TCO_LTPDU
| t_uscalar_t
| length in octets
| maximum length of TPDU
|
T_TCO_ACKTIME
| t_uscalar_t
| time in milliseconds
| acknowledge time
|
T_TCO_REASTIME
| t_uscalar_t
| time in seconds
| reassignment time
|
T_TCO_PREFCLASS
| t_uscalar_t
| see text
| preferred class
|
T_TCO_ALTCLASS1
| t_uscalar_t
| see text
| 1st alternative class
|
T_TCO_ALTCLASS2
| t_uscalar_t
| see text
| 2nd alternative class
|
T_TCO_ALTCLASS3
| t_uscalar_t
| see text
| 3rd alternative class
|
T_TCO_ALTCLASS4
| t_uscalar_t
| see text
| 4th alternative class
|
T_TCO_EXTFORM
| t_uscalar_t
| T_YES/T_NO/T_UNSPEC
| extended format
|
T_TCO_FLOWCTRL
| t_uscalar_t
| T_YES/T_NO/T_UNSPEC
| flowctrl
|
T_TCO_CHECKSUM
| t_uscalar_t
| T_YES/T_NO/T_UNSPEC
| checksum
|
T_TCO_NETEXP
| t_uscalar_t
| T_YES/T_NO/T_UNSPEC
| network expedited data
|
T_TCO_NETRECPTCF
| t_uscalar_t
| T_YES/T_NO/T_UNSPEC
|
use of network
receipt confirmation
|
Table: Management Options
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*(232 - 1) or the largest
multiple of 128 that will fit in a t_uscalar_t. Values
other than powers of 2 between 27 and 213 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
The protocol level of all subsequent options is ISO_TP (as in
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 all XTI states but T_UNINIT.
Options for Quality of Service
These options are all defined in the ISO 8072/Add.1:1986
transport service definition (see the ISO Transport references).
The definitions are not repeated here.
None of these options are supported by an ISO-over-TCP transport
provider, since it does not support connectionless-mode.
Option Name
| Type of Option
| Legal
| Meaning
|
| Value
| Option Value
|
|
T_TCL_TRANSDEL
| struct rate
| time in milliseconds
| transit delay
|
T_TCL_RESERRORRATE
| struct rate
| OPT_RATIO
| residual error rate
|
T_TCL_PROTECTION
| t_uscalar_t
| see text
| protection
|
T_TCL_PRIORITY
| t_uscalar_t
| see text
| priority
|
Table: 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.
Option Name
| Type of Option
| Legal
| Meaning
|
| Value
| Option Value
|
|
T_TCL_CHECKSUM
| t_uscalar_t
| T_YES/T_NO
| checksum computation
|
Table: Management Option
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
This section describes the effects of including the
<xti_osi.h>
header file, which is made
available by each XTI implementation that supports use of XTI over OSI,
and is included
by applications that use the XTI functions
for communication via the OSI protocol suite.
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).