This chapter discusses the Data Link Provider Interface (DLPI) which provides access to the LAP-B frame layer, including the primitives necessary to run DLPI.
The Data Link Provider Interface (DLPI) enables a data link service user to access and use the frame or LAP-B layer of the protocol stack. To access the frame layer directly on a port, the port's configuration must be set to allow it. With the frame layer access active, regular X.25 applications cannot use the port.
The interface provides point-to-point data communications and is designed for two systems connected back to back over a communications link. This is provided through a connection-oriented subset of the full DLPI specification. Other implementations of DLPI exist, and shipped with the operating system's portable STREAMS environment is a connectionless-oriented subset. The X.25 Licensed Program only supports the connection-oriented subset of the specification that is shipped with the product.
With X.25 ports that use the twd device driver, the frame layer resides on the adapter. As a result, it is necessary to encode DLPI primitives in commands to the hardware device driver, twd. The application's DLPI primitives are passed to the frame layer through the twd driver.For X.25 ports that use the hdlc device driver, the frame layer resides in the AIX kernel. In this case it is not necessary (or appropriate) to encode the DLPI primitives. They are issued directly to the frame layer.
Thus, a different device driver open is required, depending on the location of the frame layer. Once the open is done, DLPI interactions are identical, regardless of frame location. See the sample programs (referenced below) for the subroutine called dlpi_open. This subroutine provides a single open interface that isolates these base device driver differences form DLPI applications.
For additional information on the twd device driver, see X.25 Licensed Program Functionality .
The data link layer (layer 2 in the OSI Reference Model ) is responsible for the transmission and error-free delivery of information over a physical communications medium. This layer is also referred to as the frame or LAP-B layers .
The model of the data link layer is presented here to describe concepts that are used throughout the specification of DLPI. It is described in terms of an interface architecture, as well as addressing concepts needed to identify different components of that architecture.
Each layer of the OSI Reference Model has two standards:
DLPI is an implementation of the first type of standard. It specifies an interface to the services of the data link layer. The following figure depicts an overview of DLPI.
The data link interface is the boundary between the network and data link layers of the OSI Reference Model. The network layer entity, which is usually the X.25 layer , is the user of the services of the data link interface. This user is DLPI's user application and is sometimes referred to as the Data Link Service (DLS) user . The DLPI layer which provides the programming interface is referred to as the DLS provider. This interface consists of a set of primitives that provide access to the data link layer services.
The service primitives that make up kernel-level interfaces are defined as STREAMS messages that are transferred between the user and provider of the service. DLPI is targeted for STREAMS protocol modules that either use or provide data link services. In addition, user programs that wish to access a STREAMS-based data link provider directly may do so using the putmsg and getmsg subroutines.
The use of DLPI is demonstrated in a set of sample programs located in the /usr/lpp/sx25/samples/dlpi directory for AIX version 3; and /usr/samples/sx25/npi for AIX version 4 users.
Before DLPI primitives can be used by the application, the user must establish a stream to DLPI. It does this by binding to the frame layer that has been made available in the streams environment though the X.25 Licensed Program's installation. Once bound to a stream, the application can send primitives to DLPI and connect and transfer data. When an application wishes to terminate it disconnects the link and unbinds from its stream. The primitives are split into two groups :
The following primitives support the information reporting, attach, and bind services of DLPI. Once a stream has been opened by a DLS user, these primitives initialize the stream and prepare it for use.
| DL_INFO_ACK | |
| Returns information about the stream. | |
| DL_BIND_REQ | |
| Requests the DLS provider to bind a DLSAP to a stream. | |
| DL_BIND_ACK | |
| Reports a DLSAP has been bound. | |
| DL_UNBIND_REQ | |
| Requests the DLS provider unbind a DLSAP. | |
| DL_OK_ACK | |
| Indicates a request primitive was received. | |
| DL_ERROR_ACK | |
| Indicates a previously issued request or response was invalid. | |
This section describes the service primitives that support the connection-mode service of the data link layer. These primitives support:
The following DLPI primitives establish data link connections:
| DL_CONNECT_REQ | |
| Requests a data link connection with a remote user. | |
| DL_CONNECT_CON | |
| Indicates a data link connection has been established. | |
The calling application initiates the connection by issuing a DL_CONNECT_REQ primitive. The DL_CONNECT_CON primitive informs the calling application that the connection has been established.
Once the connection is established, data is exchanged using the STREAMS putmsg and getmsg subroutines.
The data transfer service provides for the exchange of user data in either direction or in both directions simultaneously between the applications. Data is transmitted in local groups called DLSDUs. The DLS provider preserves both the sequence and boundaries of DLSDUs as they are transmitted.
Normal data transfer is neither acknowledged nor confirmed. It is up to the DLS users, if they so choose, to implement a confirmation protocol. Refer to the DLPI sample programs for an example of coding data frames.
The following DLPI primitives provide data link connection release service:
| DL_DISCONNECT_IND | |
| Requests the DLS provider to disconnect a connection. | |
| DL_DISCONNECT_REQ | |
| Confirms the link has been disconnected. | |
The connection release service allows DLS users or the DLS provider to initiate the connection release. Any data in that has not been delivered to the DLS user when the connection release is requested can be discarded. Normally, one DLS user requests disconnection and the DLS provider issues an indication of the ensuing release to the other DLS user.
The following DLPI primitives provide reset service:
| DL_RESET_REQ | |
| Requests the DLS provider to resynchronize a data link connection. | |
| DL_RESET_IND | |
| Informs the DLS user a remote DLS user is resynchronizing the connection. | |
| DL_RESET_RES | |
| Directs the DLS provider to complete resynchronizing the connection. | |
| DL_RESET_CON | |
| Confirms the reset has been completed. | |
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.
If the data link connection is congested, running the reset service unblocks the flow of DLSDUs. DLSDUs may be discarded by the DLS provider. The DLS user or users that did not invoke the reset are notified that a reset has occurred. A reset may require a recovery procedure to be performed by the DLS users.
