dlpi.7.man

This a separate release of the OpenSS7 X/Open XTI/TLI library, TLI modules (timod, tirdwr) and the I

problems can result in this scenario.  To obviate the need for tying up system
resources for all possible destination DLSAPs, a "connection management
stream" utility is defined in
.BR DLPI .
A connection management stream is one that receives any connect requests that
are not destined for currently bound DLSAPs capable of receiving connect
indications.  With this mechanism, a special listener can handle incoming
connect requests intended for a set of DLSAPs by opening a connection
management stream to the DLS provider that will retrieve all connect requests
arriving through a particular PPA.  In the model, then, there may be a
connection management stream per PPA.
.\"
.\"
.SS "DLPI SERVICES"
The various features of the
.B DLPI
interface are defined in terms of the services provided by the DLS provider,
and the individual primitives that may flow between the DLS user and DLS
provider.
.\"
.\"
.PP
The data link provider interface supports three modes of service: connection,
connectionless and acknowledged connectionless.  The connection mode is
circuit-oriented and enables data to be transferred over an established
connection in a sequenced manner.  The connectionless mode is message-oriented
and supports data transfer in self-contained units with no logical
relationship required between units.  The acknowledged connectionless mode is
message-oriented and guarantees that data units will be delivered to the
destination user in the order in which they were sent.  This specification
also defines a set of local management functions that apply to all modes of
service.  The XID and TEST services that are supported by
.B DLPI
are listed below.  The DLS User can issue an XID or TEST request to the DLS
Provider.  The Provider will transmit an XID or TEST frame to the peer DLS
Provider.  On receiving a response, the DLS Provider sends a confirmation
primitive to the DLS User.  On receiving an XID or TEST frame from the peer
DLS Provider, the local DLS Provider sends up an XID or TEST indication
primitive to the DLS User.  The User must respond with an XID or TEST response
frame to the Provider.
.\"
.\"
.\"
.\"
.\"
.SS "Local Management Services"
.PP
The local management services apply to the connection, connectionless and
acknowledged connectionless modes of transmission.  These services, which fall
outside the scope of standards specifications, define the method for
initializing a stream that is connected to a DLS provider.  DLS provider
information reporting services are also supported by the local management
facilities.
.PP
.B Information Reporting Service
.RS 4
This service provides information about the
.B DLPI
stream to the DLS user.  The
message
.BR DL_INFO_REQ (7)
requests the DLS provider to return operating information about the stream.
The DLS provider returns the information in a
.BR DL_INFO_ACK (7)
message.
.RE
.PP
.B Attach Service
.RS 4
The attach service assigns a physical point of attachment (PPA) to a stream.
This service is required for style 2 DLS providers (see section 2.3.1,
Physical Attachment Identification) to specify the physical medium over which
communication will occur.  The DLS provider indicates success with a
.BR DL_OK_ACK (7);
failure with a
.BR DL_ERROR_ACK (7).
.PP
A PPA may be disassociated with a stream using the
.BR DL_DETACH_REQ (7).
.RE
.PP
.B Bind Service
.RS 4
The bind service associates a data link service access point (DLSAP) with a
stream.  The DLSAP is identified by a DLSAP address. 
.BR DL_BIND_REQ (7)
requests that the DLS provider bind a DLSAP to a stream.  It also notifies the
DLS provider to make the stream active with respect to the DLSAP for
processing connectionless and acknowledged connectionless data transfer and
connection establishment requests.  Protocol-specifications taken during
activation should be described in DLS provider-specific addenda.  The DLS
provider indicates success with a
.BR DL_BIND_ACK (7);
failure with a
.BR DL_ERROR_ACK (7).
.PP
Certain DLS providers require the capability of binding on multiple DLSAP
addresses. 
.BR DL_SUBS_BIND_REQ (7)
provides that added capability.  The DLS provider indicates success with a
.BR DL_SUBS_BIND_ACK (7);
failure with a
.BR DL_ERROR_ACK (7).
.PP
.BR DL_UNBIND_REQ (7)
requests the DLS provider to unbind all DLSAP(s) from a stream.  The
.BR DL_UNBIND_REQ (7)
also unbinds all the subsequently bound DLSAPs that have not been unbound.
The DLS provider indicates success with a
.BR DL_OK_ACK (7);
failure with a
.BR DL_ERROR_ACK (7).
.PP
.BR DL_SUBS_UNBIND_REQ
requests the DLS Provider to unbind the subsequently bound DLSAP.  The DLS
Provider indicates success with a
.BR DL_OK_ACK (7);
failure with a
.BR DL_ERROR_ACK (7).
.PP
.BR DL_ENABMULTI_REQ
requests the DLS Provider to enable specific multicast addresses on a per
stream basis.  The Provider indicates success with a
.BR DL_OK_ACK (7);
failure with a
.BR DL_ERROR_ACK (7).
.PP
.BR DL_DISABMULTI_REQ
requests the DLS Provider to disable specific multicast addresses on a per
Stream basis.  The Provider indicates success with a
.BR DL_OK_ACK (7);
failure with a
.BR DL_ERROR_ACK (7).
.PP
.BR DL_PROMISCON_REQ
requests the DLS Provider to enable promiscuous mode on a per Stream basis,
either at the physical level or at the SAP level.  The Provider indicates
success with a
.BR DL_OK_ACK (7);
failure with a
.BR DL_ERROR_ACK (7).
.PP
.BR DL_PROMISCOFF_REQ
requests the DLS Provider to disable promiscuous mode on a per Stream
basis,either at the physical level or at the SAP level.  The Provider
indicates success with a
.BR DL_OK_ACK (7);
failure with a
.BR DL_ERROR_ACK (7).
.RE
.SS "Connection-mode Services"
.PP
The connection-mode services enable a DLS user to establish a data link
connection, transfer data over that connection, reset the link, and release
the connection when the conversation has terminated.
.PP
.B Connection Establishment Service
.RS 4
The connection establishment service establishes a data link connection
between a local DLS user and a remote DLS user for the purpose of sending
data.  Only one data link connection is allowed on each stream.
.PP
.B Normal Connection Establishment
.PP
In the connection establishment model, the calling DLS user initiates
connection establishment, while the called DLS user waits for incoming
requests. 
.BR DL_CONNECT_REQ (7)
requests that the DLS provider establish a connection. 
.BR DL_CONNECT_IND (7)
informs the called DLS user of the request, which
may be accepted using
.BR DL_CONNECT_RES (7).
.BR DL_CONNECT_CON (7)
informs the calling DLS user that the connection has been established.
.PP
Once the connection is established, the DLS users may exchange user data using
.BR DL_DATA_REQ (7)
and
.BR DL_DATA_IND (7).
.PP
The DLS user may accept an incoming connect request on either the stream where
the connect indication arrived or an alternate, responding stream.  The
responding stream is indicated by a token in the
.BR DL_CONNECT_RES (7).
This token is a value associated with the responding stream, and is obtained
by issuing a
.BR DL_TOKEN_REQ (7)
on that stream.  The DLS provider responds to this request by generating a
token for the stream and returning it to the DLS user in a
.BR DL_TOKEN_ACK (7).
.PP
In the typical connection establishment scenario, the called DLS user
processes one connect indication at a time, accepting the connection on
another stream.  Once the user responds to the current connect indication, the
next connect indication (if any) can be processed.
.B DLPI
also enables the called DLS user to multi-thread incoming connect indications.
The user can receive multiple connect indications before responding to any of
them.  This enables the DLS user to establish priority schemes on incoming
connect requests.
.PP
.B Connection Establishment Rejections
.PP
In certain situations, the connection establishment request cannot be
completed.  The following paragraphs describe the occasions under which
.BR DL_DISCONNECT_REQ (7)
and
.BR DL_DISCONNECT_IND (7)
primitives will flow during connection establishment, causing the connect
request to be aborted.
.PP
Where the DLS provider rejects a connect request for lack of resources or
other reason, the DLS provider sends
.BR DL_DISCONNECT_IND (7)
in response to
.BR DL_CONNECT_REQ (7).
.PP
Where the calling DLS user chooses to abort a previous connection attempt, the
DLS user issues
.BR DL_DISCONNECT_REQ (7)
at some point following a
.BR DL_CONNECT_REQ (7).
The resulting sequence of primitives depends on the relative timing of the
primitives involved.
.RE
.PP
.B Data Transfer Service
.RS 4
The connection-mode data transfer service provides for the exchange of user
data in either direction or inboth directions simultaneously between DLS
users.  Data is transmitted in logical groups called data link service data
units (DLSDUs).  The DLS provider preserves both the sequence and boundaries
of DLSDUs as they are transmitted.
.PP
Normal data transfer is neither acknowledged nor confirmed.  It is up to the
DLS users, if they so choose,to implement a confirmation protocol.  Each
.BR DL_DATA_REQ (7)
primitive conveys a DLSDU from the local DLS user to the DLS provider.
Similarly, each
.BR DL_DATA_IND (7)
primitive conveys a DLSDU from the DLS provider to the remote DLS user.
.RE
.PP
.B Connection Release Service
.RS 4
The connection release service provides for the DLS users or the DLS provider
to initiate the connection release.  Connection release is an abortive
operation, and any data in transit (has not been delivered to the DLS user)
may be discarded.
.BR DL_DISCONNECT_REQ (7)
requests that a connection be released.
.BR DL_DISCONNECT_IND (7)
informs the DLS user that a connection has been released.  Normally, one DLS
user requests disconnection and the DLS provider issues an indication of the
ensuing release to the other DLS user.
.RE
.PP
.B Reset Service
.RS 4
The reset service may be used by the DLS user to resynchronize the use of a
data link connection, or by the DLS provider to report detected loss of data
unrecoverable within the data link service.
.PP
Invocation of the reset service will unblock the flow of DLSDUs if the data
link connection is congested;DLSDUs may be discarded by the DLS provider.  The
DLS user or users that did not invoke the reset will be notified that a reset
has occurred.  A reset may require a recovery procedure to be performed by the
DLS users.
.PP
The interaction between each DLS user and the DLS provider will be one of the
following:
.IP \(em \w'\(em\(em'u
a
.BR DL_RESET_REQ (7)
from the DLS user, followed by a
.BR DL_RESET_CON (7)
from the DLS
provider;
.IP \(em
a
.BR DL_RESET_IND (7)
from the DLS provider, followed by a
.BR DL_RESET_RES (7)
from the
DLS user.  The
.BR DL_RESET_REQ (7)
acts as a synchronization mark in the stream of
DLSDUs that are transmitted by the issuing DLS user;
.IP \(em
the
.BR DL_RESET_IND (7)
acts as a synchronization mark in the stream of DLSDUs that are received by
the peer DLS user.  Similarly, the
.BR DL_RESET_RES (7)
acts as a synchronization mark in the stream of DLSDUs that are transmitted by
the responding DLS user; the
.BR DL_RESET_CON (7)
acts as a synchronization mark in the stream of DLSDUs that are received by
the DLS user which originally issued the reset.
.PP
The resynchronizing properties of the reset service are that:
.IP \(em \w'\(em\(em'u
No DLSDU transmitted by the DLS user before the synchronization mark in that
transmitted stream will be delivered to the other DLS user after the
synchronization mark in that received stream.
.IP \(em
The DLS provider will discard all DLSDUs submitted before the issuing of the
.BR DL_RESET_REQ (7)
that have not been delivered to the peer DLS user when the DLS provider issues
the
.BR DL_RESET_IND (7).
.IP \(em
The DLS provider will discard all DLSDUs submitted before the issuing of the
.BR DL_RESET_RES (7)
that have not been delivered to the initiator of the
.BR DL_RESET_REQ (7)
when the DLS provider issues the
.BR DL_RESET_CON (7).
.IP \(em
No DLSDU transmitted by a DLS user after the synchronization mark in that
transmitted stream will be delivered to the other DLS user before the
synchronization mark in that received stream.
.PP
The complete message flow depends on the origin of the reset, which may be the
DLS provider or either DLS user.
.RE
.SS "Connectionless-mode Services"
The connectionless-mode services enable a DLS user to transfer units of data
to peer DLS users without incurring the overhead of establishing and releasing
a connection.  The connectionless service does not, however, guarantee
reliable delivery of data units between peer DLS users (e.g. lack of flow
control may cause buffer resource shortages that result in data being
discarded).
.PP
Once a stream has been initialized via the local management services, it may
be used to send and receive connectionless data units.
.PP
.B Connectionless Data Transfer Service
.RS 4
The connectionless data transfer service provides for the exchange of user
data (DLSDUs) in either direction or in both directions simultaneously without
having to establish a data link connection.  Data transfer is neither
acknowledged nor confirmed, and there is no end-to-end flow control provided.
As such, the connectionless data transfer service cannot guarantee reliable
delivery of data.  However, a specific DLS provider can provide assurance that
messages will not be lost, duplicated, or reordered. 
.BR DL_UNITDATA_REQ (7)
conveys one DLSDU to the DLS provider.
.BR DL_UNITDATA_IND (7)
conveys one DLSDU to the DLS user.
.RE
.PP
.B QOS Management Service
.RS 4
The QOS (Quality of Service) management service enables a DLS user to specify
the quality of service it can expect for each invocation of the connectionless
data transfer service.  The
.BR DL_UDQOS_REQ (7)
directs the DLS provider to set the QOS parameters to the specified values.
.RE
.PP
.B Error Reporting Service
.RS 4
The connectionless-mode error reporting service may be used to notify a DLS
user that a previously sent data unit either produced an error or could not be
delivered.  This service does not, however, guarantee that an error indication
will be issued for every undeliverable data unit.
.RE
.PP
.B XID and TEST Service
.RS 4
The XID and TEST service enables the DLS User to issue an XID or TEST request
to the DLS Provider.  On receiving a response for the XID or TEST frame
transmitted to the peer DLS Provider, the DLS Provider sends up an XID or TEST
confirmation primitive to the DLS User.  On receiving an XID or TEST frame
from the peer DLS Provider, the local DLS Provider sends up an XID or TEST
indication respectively to the DLS User.  The DLS User must respond with an
XID or TEST response primitive.  If the DLS User requested automatic handling
of the XID or TEST response, at bind time, the DLS Provider will send up an
error acknowledgment on receiving an XID or TEST request.  Also, no
indications will be generated to the DLS User on receiving XID or TEST frames
from the remote side.
.RE
.SS "Acknowledged Connectionless-mode Services"
The acknowledged connectionless-mode services are designed for general use for
the reliable transfer of informations between peer DLS Users.  These services
are intended for applications that require acknowledgment of cross-LAN data
unit transfer, but wish to avoid the complexity that is viewed as being
associated with the connection-mode services.  Although the exchange service
is connectionless, in sequence delivery is guaranteed for data sent by the
initiating station.
.PP
.B Acknowledged Connectionless-mode Data Transfer Services
.RS 4
The acknowledged connectionless-mode data transfer services provide the means
by which the DLS Users can exchange DLSDUs which are acknowledged at the LLC
sublayer, without the establishment of a Data Link connection.  The services
provide a means by which a local DLS User can send a data unit to the peer DLS
User, request a previously prepared data unit, or exchange data units with the
peer DLS User.
.RE
.PP
.B QOS Management Service
.RS 4
The Quality of Service (QOS) management service enables a DLS User to specify
the quality of service it can expect for each invocation of the acknowledged
connectionless data transfer service.  The
.BR DL_UDQOS_REQ (7)
directs the DLS provider to set the QOS parameters to the specified values.
The normal flow of messages is illustrated in section 3.3.2, (Connectionless
mode services).
.RE
.PP
.B Error Reporting Service
.RS 4
The acknowledged connectionless mode error reporting service is the same as
the unacknowledged connectionless-mode error reporting service.  For the
message flow, refer to section 3.3.3.
.RE
.\"
.\"
.\"
.\"
.\"
.SS "Local Management"
.\"