Data Link Provider Interface (DLPI)

DLPI

Section: Data Link Provider Interface (DLPI) (7)
Updated: 2007-06-24
Index Return to Main Contents

NAME

DLPI - Data Link Provider Interface

SYNOPSIS

#include <sys/dlpi.h>

DESCRIPTION

The data link layer (layer 2 in the OSI Reference Model) is responsible for the transmission and error-free delivery of bits of information over a physical communications medium.

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. The description of the model assumes familiarity with the OSI Reference Model.

Each layer of the OSI Reference Model has two standards:

*: one that defines the services provided by the layer, and
*: one that defines the protocol through which layer services are provided.

DLPI is an implementation of the first type of standard. It specifies an interface to the services of the data link layer.

The data link interface is the boundary between the network and data link layers of the OSI Reference Model. The network layer entity is the user of the services of the data link interface (DLS user), and the data link layer entity is the provider of those services (DLS provider). This interface consists of a set of primitives that provide access to the data link layer services, plus the rules for using those primitives (state transition rules). A data link interface service primitive might request a particular service or indicate a pending event.

To provide uniformity among the various UNIX system networking products, an effort is underway to develop service interfaces that map to the OSI Reference Model. A set of kernel-level interfaces, based on the STREAMS(4) development environment, constitute a major portion of this effort. The service primitives that make up these interfaces are defined as STREAMS(4) messages that are transferred between the user and provider of the service. DLPI is one such kernel-level interface, and is targeted for STREAMS(4) protocol modules that either use or provide data link services. In addition, user programs that wish to access a STREAMS(4)-based data link provider directly may do so using the putmsg(2) and getmsg(2) system calls. The DLS provider is configured as a STREAMS(4) driver,and the DLS user accesses the provider using open(2) to establish a stream to the DLS provider. The stream acts as a communication endpoint between a DLS user and the DLS provider. After the stream is created, the DLS user and DLS provider communicate via the messages presented later in this specification. DLPI is intended to free data link users from specific knowledge of the characteristics of the data link provider. Specifically, the definition of DLPI hopes to achieve the goal of allowing a DLS user to be implemented independent of a specific communications medium. Any data link provider (supporting any communications medium) that conforms to the DLPI specification may be substituted beneath the DLS user to provide the data link services. Support of a new DLS provider should not require any changes to the implementation of the DLS user.

MODES OF COMMUNICATION

The data link provider interface supports three modes of communication: connection, connectionless and acknowledged connectionless.

The connection mode is circuit-oriented and enables data to be transferred over a pre-established connection in a sequenced manner. Data may be lost or corrupted in this service mode, however, due to provider-initiated resynchronization or connection aborts.

The connectionless mode is message-oriented and supports data transfer in self-contained units with no logical relationship required between units. Because there is no acknowledgment of each data unit transmission, this service mode can be unreliable in the most general case. However, a specific DLS provider can provide assurance that messages will not be lost, duplicated, or reordered.

The acknowledged connectionless mode provides the means by which a data link user can send data and request the return of data at the same time. Although the exchange service is connectionless, in-sequence delivery is guaranteed for data sent by the initiating station. The data unit transfer is point-to-point.

CONNECTION-MODE SERVICE

The connection-mode service is characterized by four phases of communication: local management,connection establishment, data transfer, and connection release.

Local Management: This phase enables a DLS user to initialize a stream for use in communication and establish an identity with the DLS provider.
Connection Establishment: This phase enables two DLS users to establish a data link connection between them to exchange data. One user (the calling DLS user) initiates the connection establishment procedures, while another user (the called DLS user) waits for incoming connect requests. The called DLS user is identified by an address associated with its stream (as will be discussed shortly).
A called DLS user may either accept or deny a request for a data link connection. If the request is accepted, a connection is established between the DLS users and they enter the data transfer phase. For both the calling and called DLS users, only one connection may be established per stream. Thus, the stream is the communication endpoint for a data link connection. The called DLS user may choose to accept a connection on the stream where it received the connect request, or it may open a new stream to the DLS provider and accept the connection on this new, responding stream. By accepting the connection on a separate stream, the initial stream can be designated as a listening stream through which all connect requests will be processed. As each request arrives, a new stream (communication endpoint) can be opened to handle the connection, enabling subsequent requests to be queued on a single stream until they can be processed.
Data Transfer: In this phase, the DLS users are considered peers and may exchange data simultaneously in both directions over an established data link connection. Either DLS user may send data to its peer DLS user at any time. Data sent by a DLS user is guaranteed to be delivered to the remote user in the order in which it was sent.
Connection Release: This phase enables either the DLS user, or the DLS provider, to break an established connection. The release procedure is considered abortive, so any data that has not reached the destination user when the connection is released may be discarded by the DLS provider.

CONNECTIONLESS-MODE SERVICE

The connectionless mode service does not use the connection establishment and release phases of the connection-mode service. The local management phase is still required to initialize a stream. Once initialized, however, the connectionless data transfer phase is immediately entered. Because there is no established connection, however, the connectionless data transfer phase requires the DLS user to identify the destination of each data unit to be transferred. The destination DLS user is identified by the address associated with that user (as will be discussed shortly).

Connectionless data transfer does not guarantee that data units will be delivered to the destination user in the order in which they were sent. Furthermore, it does not guarantee that a given data unit will reach the destination DLS user, although a given DLS provider may provide assurance that data will not be lost.

ACKNOWLEDGED CONNECTIONLESS-MODE SERVICE

The acknowledged connectionless mode service also does not use the connection establishment and release phases of the connection-mode service. The local management phase is still required to initialize a stream. Once initialized, the acknowledged connectionless data transfer phase is immediately entered. Acknowledged connectionless data transfer guarantees that data units will be delivered to the destination user in the order in which they were sent. A data link user entity can send a data unit to the destination DLS User, request a previously prepared data unit from the destination DLS User, or exchange data units.

DLPI ADDRESSING

Each user of DLPI must establish an identity to communicate with other data link users. This identity consists of two pieces. First, the DLS user must somehow identify the physical medium over which it will communicate. This is particularly evident on systems that are attached to multiple physical media. Second, the DLS user must register itself with the DLS provider so that the provider can deliver protocol data units destined for that user.

PHYSICAL ATTACHMENT IDENTIFICATION

The physical point of attachment (PPA) is the point at which a system attaches itself to a physical communications medium. All communication on that physical medium funnels through the PPA.

On systems where a DLS provider supports more than one physical medium, the DLS user must identify which medium it will communicate through. A PPA is identified by a unique PPA identifier. For media that support physical layer multiplexing of multiple channels over a single physical medium (such as the B and D channels of ISDN), the PPA identifier must identify the specific channel over which communication will occur.

Two styles of DLS provider are defined by DLPI, distinguished by the way they enable a DLS user to choose a particular PPA. The style 1 provider assigns a PPA based on the major/minor device the DLS user opened. One possible implementation of a style 1 driver would reserve a major device for each PPA the data link driver would support. This would allow the STREAMS(4) clone open feature to be used for each PPA configured. This style of provider is appropriate when few PPAs will be supported.

If the number of PPAs a DLS provider will support is large, a style 2 provider implementation is more suitable. The style 2 provider requires a DLS user to explicitly identify the desired PPA using a special attach service primitive. For a style 2 driver, the open(2) creates a stream between the DLS user and DLS provider, and the attach primitive then associates a particular PPA with that stream. The format of the PPA identifier is specific to the DLS provider, and should be described in the provider-specific addendum documentation. DLPI provides a mechanism to get and/or modify the physical address. The primitives to handle these functions are described in Appendix A. The physical address value can be modified in a post-attached state. This would modify the value for all streams for that provider for a particular PPA. The physical address cannot be modified if even a single stream for that PPA is in the bound state.

The DLS User uses the supported primitives (DL_ATTACH_REQ(7), DL_BIND_REQ(7), DL_ENABMULTI_REQ(7), DL_PROMISCON_REQ(7)) to define a set of enabled physical and SAP address components on a per Stream basis. It is invalid for a DLS Provider to ever send upstream a data message for which the DLS User on that stream has not requested. The burden is on the provider to enforce by any means that it chooses, the isolation of SAP and physical address space effects on a per-stream basis.

DATA LINK USER IDENTIFICATION

A data link user's identity is established by associating it with a data link service access point (DLSAP),which is the point through which the user will communicate with the data link provider. A DLSAP is identified by a DLSAP address. The DLSAP address identifies a particular data link service access point that is associated with a stream(communication endpoint). A bind service primitive enables a DLS user to either choose a specific DLSAP by specifying its DLSAP address, or to determine the DLSAP associated with a stream by retrieving the bound DLSAP address. This DLSAP address can then be used by other DLS users to access a specific DLS user. The format of the DLSAP address is specific to the DLS provider, and should be described in the provider-specific addendum documentation. However, DLPI provides a mechanism for decomposing the DLSAP address into component pieces. The DL_INFO_ACK(7) primitive returns the length of the SAP component of the DLSAP address, along with the total length of the DLSAP address. Certain DLS Providers require the capability of binding on multiple DLSAP addresses. This can be achieved through subsequent binding of DLSAP addresses. DLPI supports peer and hierarchical binding of DLSAPs. When the User requests peer addressing, the DLSAP specified in a subsequent bind may be used in lieu of the DLSAP bound in the DL_BIND_REQ(7). This will allow for a choice to be made between a number of DLSAPs on a stream when determining traffic based on DLSAP values. An example of this would be to specify various ether_type values as DLSAPs. The DL_BIND_REQ(7), for example, could be issued with ether_type value of IP, and a subsequent bind could be issued with ether type value of ARP. The Provider may now multiplex off of the ether_type field and allow for either IP or ARP traffic to be sent up this stream. When the DLS User requests hierarchical binding, the subsequent bind will specify a DLSAP that will be used in addition to the DLSAP bound using a DL_BIND_REQ(7). This will allow additional information to be specified, that will be used in a header or used for de-multiplexing. An example of this would be to use hierarchical bind to specify the OUI (Organizationally Unique Identifier) to be used by SNAP.

THE CONNECTION MANAGEMENT STREAM

The earlier description of the connection-mode service assumed that a DLS user bound a DLSAP to the stream it would use to receive connect requests. In some instances, however, it is expected that a given service may be accessed through any one of several DLSAPs. To handle this scenario, a separate stream would be required for each possible destination DLSAP, regardless of whether any DLS user actually requested a connection to that DLSAP. Obvious resource 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 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.

DLPI SERVICES

The various features of the 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.

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 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.

Local Management Services

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.

Information Reporting Service

: This service provides information about the DLPI stream to the DLS user. The message DL_INFO_REQ(7) requests the DLS provider to return operating information about the stream. The DLS provider returns the information in a DL_INFO_ACK(7) message.

Attach Service

: 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 DL_OK_ACK(7); failure with a DL_ERROR_ACK(7).
A PPA may be disassociated with a stream using the DL_DETACH_REQ(7).

Bind Service

The bind service associates a data link service access point (DLSAP) with a stream. The DLSAP is identified by a DLSAP address. 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 DL_BIND_ACK(7); failure with a DL_ERROR_ACK(7).

Certain DLS providers require the capability of binding on multiple DLSAP addresses. DL_SUBS_BIND_REQ(7) provides that added capability. The DLS provider indicates success with a DL_SUBS_BIND_ACK(7); failure with a DL_ERROR_ACK(7).

DL_UNBIND_REQ(7) requests the DLS provider to unbind all DLSAP(s) from a stream. The DL_UNBIND_REQ(7) also unbinds all the subsequently bound DLSAPs that have not been unbound. The DLS provider indicates success with a DL_OK_ACK(7); failure with a DL_ERROR_ACK(7).

DL_SUBS_UNBIND_REQ requests the DLS Provider to unbind the subsequently bound DLSAP. The DLS Provider indicates success with a DL_OK_ACK(7); failure with a DL_ERROR_ACK(7).

DL_ENABMULTI_REQ requests the DLS Provider to enable specific multicast addresses on a per stream basis. The Provider indicates success with a DL_OK_ACK(7); failure with a DL_ERROR_ACK(7).

DL_DISABMULTI_REQ requests the DLS Provider to disable specific multicast addresses on a per Stream basis. The Provider indicates success with a DL_OK_ACK(7); failure with a DL_ERROR_ACK(7).

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 DL_OK_ACK(7); failure with a DL_ERROR_ACK(7).

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 DL_OK_ACK(7); failure with a DL_ERROR_ACK(7).

Connection-mode Services

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.

Connection Establishment Service

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.

Normal Connection Establishment

In the connection establishment model, the calling DLS user initiates connection establishment, while the called DLS user waits for incoming requests. DL_CONNECT_REQ(7) requests that the DLS provider establish a connection. DL_CONNECT_IND(7) informs the called DLS user of the request, which may be accepted using DL_CONNECT_RES(7). DL_CONNECT_CON(7) informs the calling DLS user that the connection has been established.

Once the connection is established, the DLS users may exchange user data using DL_DATA_REQ(7) and DL_DATA_IND(7).

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 DL_CONNECT_RES(7). This token is a value associated with the responding stream, and is obtained by issuing a 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 DL_TOKEN_ACK(7).

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. 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.

Connection Establishment Rejections

In certain situations, the connection establishment request cannot be completed. The following paragraphs describe the occasions under which DL_DISCONNECT_REQ(7) and DL_DISCONNECT_IND(7) primitives will flow during connection establishment, causing the connect request to be aborted.

Where the DLS provider rejects a connect request for lack of resources or other reason, the DLS provider sends DL_DISCONNECT_IND(7) in response to DL_CONNECT_REQ(7).

Where the calling DLS user chooses to abort a previous connection attempt, the DLS user issues DL_DISCONNECT_REQ(7) at some point following a DL_CONNECT_REQ(7). The resulting sequence of primitives depends on the relative timing of the primitives involved.

Data Transfer Service

: 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.
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 DL_DATA_REQ(7) primitive conveys a DLSDU from the local DLS user to the DLS provider. Similarly, each DL_DATA_IND(7) primitive conveys a DLSDU from the DLS provider to the remote DLS user.

Connection Release Service

: 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. DL_DISCONNECT_REQ(7) requests that a connection be released. 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.

Reset Service

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.

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.

The interaction between each DLS user and the DLS provider will be one of the following:

---: a DL_RESET_REQ(7) from the DLS user, followed by a DL_RESET_CON(7) from the DLS provider;
---: a DL_RESET_IND(7) from the DLS provider, followed by a DL_RESET_RES(7) from the DLS user. The DL_RESET_REQ(7) acts as a synchronization mark in the stream of DLSDUs that are transmitted by the issuing DLS user;
---: the DL_RESET_IND(7) acts as a synchronization mark in the stream of DLSDUs that are received by the peer DLS user. Similarly, the DL_RESET_RES(7) acts as a synchronization mark in the stream of DLSDUs that are transmitted by the responding DLS user; the 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.

The resynchronizing properties of the reset service are that:

---: 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.
---: The DLS provider will discard all DLSDUs submitted before the issuing of the DL_RESET_REQ(7) that have not been delivered to the peer DLS user when the DLS provider issues the DL_RESET_IND(7).
---: The DLS provider will discard all DLSDUs submitted before the issuing of the DL_RESET_RES(7) that have not been delivered to the initiator of the DL_RESET_REQ(7) when the DLS provider issues the DL_RESET_CON(7).
---: 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.

The complete message flow depends on the origin of the reset, which may be the DLS provider or either DLS user.

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).

Once a stream has been initialized via the local management services, it may be used to send and receive connectionless data units.

Connectionless Data Transfer Service

: 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. DL_UNITDATA_REQ(7) conveys one DLSDU to the DLS provider. DL_UNITDATA_IND(7) conveys one DLSDU to the DLS user.

QOS Management Service

: 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 DL_UDQOS_REQ(7) directs the DLS provider to set the QOS parameters to the specified values.

Error Reporting Service

: 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.

XID and TEST Service

: 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.

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.

Acknowledged Connectionless-mode Data Transfer Services

: 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.

QOS Management Service

: 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 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).

Error Reporting Service

: 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.

Local Management

Local management provides the following services:

Information Service

DL_INFO_REQ(7)---
DL_INFO_ACK(7)---

Token Service

DL_TOKEN_REQ(7)---
DL_TOKEN_ACK(7)---

Attach Service

DL_ATTACH_REQ(7)---

Detach Service

DL_DETACH_REQ(7)---

Bind Service

DL_BIND_REQ(7)---
DL_BIND_ACK(7)---

Unbind Service

DL_UNBIND_REQ(7)---

Subsequent Bind Service

DL_SUBS_BIND_REQ(7)---
DL_SUBS_BIND_ACK(7)---

Subsequent Unbind Service

DL_SUBS_UNBIND_REQ(7)---

Receipt Acknowledgment Service

DL_OK_ACK(7)---
DL_ERROR_ACK(7)---

Connection Establishment Phase

The connection establishment phase consists of the following services:

Connection Service

DL_CONNECT_REQ(7)---
DL_CONNECT_CON(7)---
DL_CONNECT_IND(7)---
DL_CONNECT_RES(7)---

Connection Data Transfer Phase

The connection data transfer phase consists of the following services:

Data Transfer Service

DL_DATA_REQ(7)---
DL_DATA_IND(7)---

Reset Service

DL_RESET_CON(7)---
DL_RESET_IND(7)---
DL_RESET_REQ(7)---
DL_RESET_RES(7)---

Connection Release Phase

The connection release phase consists of the following services:

Release Service

DL_DISCONNECT_IND(7)---
DL_DISCONNECT_REQ(7)---

Connectionless Data Transfer Phase

The connectionless data transfer phase consists of the following services:

Data Transfer Service

DL_UNITDATA_REQ(7)---
DL_UNITDATA_IND(7)---
DL_UDQOS_REQ(7)---
DL_UDERROR_IND(7)---

Acknowledged Connectionless Data Transfer Phase

The acknowledged connectionless data transfer phase consists of the following services:

Acknowledged Data Transfer Service

DL_DATA_ACK_REQ(7)---
DL_DATA_ACK_IND(7)---
DL_DATA_ACK_STATUS_IND(7)---

Data Transaction Service

DL_REPLY_IND(7)---
DL_REPLY_REQ(7)---
DL_REPLY_STATUS_IND(7)---
DL_REPLY_UPDATE_REQ(7)---
DL_REPLY_UPDATE_STATUS_IND(7)---

XID and Test

The XID and Test functions consist of the following services:

XID Service

DL_XID_CON(7)---
DL_XID_IND(7)---
DL_XID_REQ(7)---
DL_XID_RES(7)---

TEST Service

DL_TEST_CON(7)---
DL_TEST_IND(7)---
DL_TEST_REQ(7)---
DL_TEST_RES(7)---

Miscelaneous Management

The miscellaneous management functions consist of the following services:

Physical Address Service

DL_SET_PHYS_ADDR_REQ(7)---
DL_PHYS_ADDR_REQ(7)---
DL_PHYS_ADDR_ACK(7)---

Promiscuous Monitoring Service

DL_PROMISCOFF_REQ(7)---
DL_PROMISCON_REQ(7)---

Multicast Address Service

DL_ENABMULTI_REQ(7)---
DL_DISABMULTI_REQ(7)---

Statistics Service

DL_GET_STATISTICS_REQ(7)---
DL_GET_STATISTICS_ACK(7)---

HISTORY

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

CONFORMANCE

This interface conforms to DLPI Revision 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]: DLPI Revision 2.0.0, Data Link Provider Interface (DLPI) Specification,No.Draft 2,August 20, 1991,(Parsippany, New Jersey),UNIX. International,Inc.,UNIX International Press. <http://www.openss7.org/doc/dlpi.pdf>
[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,No.15th edition,December 1997,(Reading, Massachusetts),W. R. Stevens,Addison Wesley. [ISBN 0-201-56317-7]