Transport Provider Interface (TPI)

TPI

Section: Transport Provider Interface (TPI) (7)
Updated: Tue, 30 Dec 2008 14:53:26 GMT
Index Return to Main Contents

NAME

tpi - Transport Provider Interface

SYNOPSIS

#include <sys/tpi.h>

int tpi_stream = open(tpi_device, flags);
int tpi_xtistr = t_open(tpi_device, flags);
int tpi_socket = socket(pfamily, socktype, protocol);

DESCRIPTION

To support a framework for providing networking products in the UNIX® system, an effort is underway to define service interfaces that map to strategic levels of the Open Systems Interconnection (OSI) Reference Model. These service interfaces hide implementation details of a particular service from the consumer of the service. This enables system programmers to develop software independent of the particular protocol that provides a specific service. The interfaces being specified for UNIX® System V are defined within the STREAMS(4) environment. This document specifies a kernel-level interface that supports the services of the Transport Layer for connection-mode and connectionless mode services. This specification applies to System V Release 4.2 ES/MP.

Transport Provider Interface

The transport interface defines a message interface to a transport provider implemented under STREAMS(4). (It is assumed that the reader of this document is familiar with the concept STREAMS(4).) This version of the transport provider interface supports the XPG4 version of the X/Open Transport Interface (XTI/TLI). A user communicates to a transport provider via a full duplex path known as a stream. This stream provides a mechanism in which messages may be passed to the transport provider from the transport user and vice versa.

STREAMS(4) messages that are used to communicate transport service primitives between the transport user and the transport provider may have one of the following formats:

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

The following sections describe the transport primitives which define both a connection-mode and connectionless-mode transport service. For both types of transport service, two types of primitives exist: primitives which originate from the transport user and primitives which originate from the transport provider. The primitives which originate from the transport user make requests to the transport provider or respond to an event of the transport provider. The primitives which originate from the transport provider are either confirmations of a request or are indications to the transport user that an event has occurred. Section 2 lists the primitive types along with the mapping of those primitives to the STREAMS(4) message types and the transport primitives of the ISO IS 8072 and IS 8072/DAD transport service definitions. The format of these primitives and the rules governing the use of them are described in the sections that follow.

Local Management

The following management primitives are common to all modes of transport service providers. The transport service provider provides the following local management services:

Information Service The information service provides the transport services user with the ability to query the transport service provider concerning options and parameters specific to the transport service provider and associated with the transport connection. The information services use the following primitives:

---: T_INFO_REQ(7): Requests information concerning the transport service provider, limits, modes and options. This primitive requires local acknowledgment with the T_INFO_ACK(7) or T_ERROR_ACK(7) primitives
---: T_INFO_ACK(7): Provides information concerning the transport service provider, limits, modes and options.

Bind Service The bind service provides the transport services user with the ability to bind the requesting stream to a transport endpoint address. The bind service also permits the negotiation of the number of outstanding connection indications on a connection mode transport service provider. The bind service uses the following primitives:

---: T_BIND_REQ(7): Requests the binding of the stream to a transport endpoint address. This primitive requires local acknowledgment with the T_BIND_ACK(7) or T_ERROR_ACK(7) primitives.
---: T_BIND_ACK(7): Provides acknowledgment of the bound transport endpoint address.

Unbind Service The unbind service provides the transport services user with the ability to unbind the requesting stream from the transport endpoint address to which it is currently bound. The unbind service uses the following primitives:

---: T_UNBIND_REQ(7): Requests the stream be unbound from the bound transport endpoint address. This primitive requires local acknowledgment with the T_OK_ACK(7) or T_ERROR_ACK(7) primitives.

Receipt Acknowledgment Service The receipt acknowledgment service provides an indication to the transport service user of the positive or negative acknowledgment of the previous primitive issued by the channel service user. The receipt acknowledgment service uses the following primitives:

---: T_OK_ACK(7): Provides positive acknowledgment of request and response primitives that require acknowledgment.
---: T_ERROR_ACK(7): Provides negative acknowledgment of the request and response primitives that require acknowledgment.

Options Management Service The options management service provides a mechanism whereby the transport service user can query and negotiate parameters associated with transport service provider and the transport connection. The options management service uses the following primitives:

---: T_OPTMGMT_REQ(7): Requests the management of transport service provider options. This primitive requires local acknowledgment using the T_OPTMGMT_ACK(7) or T_ERROR_ACK(7) primitives.
---: T_OPTMGMT_ACK(7): Provides acknowledgment of the management of transport service provider options.

Address Service The address service provides the transport services user with the ability to query bound and connected transport endpoint addresses. The address service uses the following primitives:

---: T_ADDR_REQ(7): Requests the bound and connected endpoint addresses. This primitive requires local acknowledgment using the T_ADDR_ACK(7) or T_ERROR_ACK(7) primitives.
---: T_ADDR_ACK(7): Provides the bound and connected endpoint addresses.

Capability Service The capability service provides the transport services user with the ability to query bound and connected transport addresses, token values associated with the requesting stream, and other optional transport capabilities. The capability service uses the following primitives:

---: T_CAPABILITY_REQ(7): Requests information concerning the capabilities of the transport service provider, limits, modes, tokens and options. This primitive requires local acknowledgment using the T_CAPABILITY_ACK(7) or T_ERROR_ACK(7) primitives.
---: T_CAPABILITY_ACK(7): Provides information concerning the capabilities of the transport service provider, limits, modes, tokens and options.

Connectionless Data Transfer

The transport service provider provides the following connectionless data transfer services:

Data Transfer Service The connectionless mode data transfer service provides the ability to transfer connectionless mode data between the transport services user to the transport services provider. It also provides indication to the transport services user of some protocol errors related to the transmission of unit data. The data transfer service uses the following primitives:

---: T_UNITDATA_REQ(7): Requests the transmission of connectionless data.
---: T_UNITDATA_IND(7): Provides indication of the reception of connectionless data.
---: T_UDERROR_IND(7): Provides indication of errors encountered in the transmission of connectionless data.

Connection Establishment

The following primitives establish a transport connection with a connection oriented transport service provider. The transport service provider provides the following connection establishment services:

Connection Service The connection service provides the transport services user with the ability to form outgoing transport connections as well as acceppt or reject incoming transport connections. THe connection service uses the following primitives:

---: T_CONN_REQ(7): Requests connection to a peer transport endpoint.
---: T_CONN_CON(7): Provides confirmation of connection to a peer transport endpoint.
---: T_CONN_IND(7): Provides indication of a connection request from a peer transport endpoint.
---: T_CONN_RES(7): Responds to an outstanding connection indication.

Connection Data Transfer

The following primitives provider for the transfer of data with a connection oriented transport service provider. The transport service provider provides the following connection mode data transfer services:

Data Transfer Service The connection mode data transfer service provides the ability to transfer normal connection mode data between the transport services user and the transport service provider. It also provides the ability to exchange data in transport inteface data units smaller that the overall transport service data unit. The connection mode data transfer service uses the following primitives:

---: T_DATA_REQ(7): Requests the transmission of data on a transport connection.
---: T_DATA_IND(7): Provides indication of the reception of data on a transport connection.

Expedited Data Transfer Service The connection mode data transfer service provides the ability to transfer expedited connection mode data between the transport services user and the transport service provider. It also provides the ability to exchange data in transport inteface data units smaller that the overall expedited transport service data unit. The connection mode data transfer service uses the following primitives:

---: T_EXDATA_REQ(7): Requests the transmission of expedited data on a transport connection.
---: T_EXDATA_IND(7): Provides indication of the reception of expedited data on a transport connection.

Options Data Transfer Service The connection mode options data transfer service provides that ability to transfer normal or expedited connection mode data with options between the transport services user and the transport services provider. It also provides the ability to exchange data in transport interface data units smaller than the overall normal or expedited transport service data unit. The connection mode options data transfer service uses the following primitives:

---: T_OPTDATA_REQ(7): Requests the transmission of data with options on a transport connection.
---: T_OPTDATA_IND(7): Provides indication of the reception of data with options on a transport connection.

Connection Release

The transport service provider provides the following connection release services:

Release Service The release service provides the transport services user with the ability to generate an abortive release of an existing transport connection, refuse an incomin transport connection, or accept the release of a transport connection. The release service uses the following primitives:

---: T_DISCON_REQ(7): Requests that a transport connection be released.
---: T_DISCON_IND(7): Provides indication that a transport connection has been released.

Orderly Release Service The orderly release service provides the transport services user with the ability to perform or accept an orderly release of an existing transport connection. The orderly release service uses the following primitives:

---: T_ORDREL_REQ(7): Requests that a transport connection be released in an orderly fashion.
---: T_ORDREL_IND(7): Provides indication that a transport connection is to be released in an orderly fashion.

HISTORY

The Transport Provider Interface first appeared in SVR 4[1].

CONFORMANCE

This interface conforms to TPI Version 2, Draft 2[2].

REFERENCES

[1]: SVR 4, UNIX® System V Release 4 Programmer's Manual, 1990, (Englewood Cliffs, New Jersey), AT&T UNIX System Laboratories, Inc., Prentice Hall.
[2]: TPI Revision 2.0.0, Open Group CAE Specification: Transport Provider Interface (TPI) Specification, Revision 2.0.0, Draft 2, 1999, (Berkshire, UK), OpenGroup, Open Group Publication. <http://www.opengroup.org/onlinepubs/>
[3]: Magic Garden, The Magic Garden Explained: The Internals of UNIX® System V Release 4 / An Open Systems Design, 1994, (Australia), B. Goodheart, J. Cox, Prentice Hall. [ISBN 0-13-098138-9]
[4]: Advanced Programming in the UNIX®Environment, 15th edition, December 1997, (Reading, Massachusetts), W. R. Stevens, Addison Wesley. [ISBN 0-201-56317-7]